Shortly after publication, we were honored to have our article noticed by Jonathan Bar Or, Principal Security Researcher at Microsoft. He provided invaluable feedback by pointing out the existence of hotkey-based keyloggers and even shared proof-of-concept (PoC) code with us. Leveraging his PoC code Hotkeyz as a starting point, this article presents one potential method for detecting hotkey-based keyloggers.

Overview of Hotkey-based Keyloggers

What Is a Hotkey?

Before delving into hotkey-based keyloggers, let’s first clarify what a hotkey is. A hotkey is a type of keyboard shortcut that directly invokes a specific function on a computer by pressing a single key or a combination of keys. For example, many Windows users press Alt + Tab to switch between tasks (or, in other words, windows). In this instance, Alt + Tab serves as a hotkey that directly triggers the task-switching function.

(Note: Although other types of keyboard shortcuts exist, this article focuses solely on hotkeys. Also, all information herein is based on Windows 10 version 22H2 OS Build 19045.5371 without virtualization based security. Please note that the internal data structures and behavior may differ in other versions of Windows.)

Abusing Custom Hotkey Registration Functionality

In addition to using the pre-configured hotkeys in Windows as shown in the previous example, you can also register your own custom hotkeys. There are various methods to do this, but one straightforward approach is to use the Windows API function RegisterHotKey, which allows a user to register a specific key as a hotkey. For instance, the following code snippet demonstrates how to use the RegisterHotKey API to register the A key (with a virtual-key code of 0x41) as a global hotkey:

/*
BOOL RegisterHotKey(
  [in, optional] HWND hWnd, 
  [in]           int  id,
  [in]           UINT fsModifiers,
  [in]           UINT vk
);
*/
RegisterHotKey(NULL, 1, 0, 0x41);

After registering a hotkey, when the registered key is pressed, a WM_HOTKEY message is sent to the message queue of the window specified as the first argument to the RegisterHotKey API (or to the thread that registered the hotkey if NULL is used). The code below demonstrates a message loop that uses the GetMessage API to check for a WM_HOTKEY message in the message queue, and if one is received, it extracts the virtual-key code (in this case, 0x41) from the message.

MSG msg = { 0 };
while (GetMessage(&msg, NULL, 0, 0)) {
    if (msg.message == WM_HOTKEY) {
        int vkCode = HIWORD(msg.lParam);
        std::cout << "WM_HOTKEY received! Virtual-Key Code: 0x"
            << std::hex << vkCode << std::dec << std::endl;
    }
}

In other words, imagine you're writing something in a notepad application. If the A key is pressed, the character won't be treated as normal text input — it will be recognized as a global hotkey instead.

In this example, only the A key is registered as a hotkey. However, you can register multiple keys (like B, C, or D) as separate hotkeys at the same time. This means that any key (i.e., any virtual-key code) that can be registered with the RegisterHotKey API can potentially be hijacked as a global hotkey. A hotkey-based keylogger abuses this capability to capture the keystrokes entered by the user.

Based on our testing, we found that not only alphanumeric and basic symbol keys, but also those keys when combined with the SHIFT modifier, can all be registered as hotkeys using the RegisterHotKey API. This means that a keylogger can effectively monitor every keystroke necessary to steal sensitive information.

Capturing Keystrokes Stealthily

Let's walk through the actual process of how a hotkey-based keylogger captures keystrokes, using the Hotkeyz hotkey-based keylogger as an example.

In Hotkeyz, it first registers each alphanumeric virtual-key code — and some additional keys, such as VK_SPACE and VK_RETURN — as individual hotkeys by using the RegisterHotKey API.

Then, inside the keylogger's message loop, the PeekMessageW API is used to check whether any WM_HOTKEY messages from these registered hotkeys have appeared in the message queue. When a WM_HOTKEY message is detected, the virtual-key code it contains is extracted and eventually saved to a text file. Below is an excerpt from the message loop code, highlighting the most important parts.

while (...)
{
    // Get the message in a non-blocking manner and poll if necessary
    if (!PeekMessageW(&tMsg, NULL, WM_HOTKEY, WM_HOTKEY, PM_REMOVE))
    {
        Sleep(POLL_TIME_MILLIS);
        continue;
    }
....
   // Get the key from the message
   cCurrVk = (BYTE)((((DWORD)tMsg.lParam) & 0xFFFF0000) >> 16);

   // Send the key to the OS and re-register
   (VOID)UnregisterHotKey(NULL, adwVkToIdMapping[cCurrVk]);
   keybd_event(cCurrVk, 0, 0, (ULONG_PTR)NULL);
   if (!RegisterHotKey(NULL, adwVkToIdMapping[cCurrVk], 0, cCurrVk))
   {
       adwVkToIdMapping[cCurrVk] = 0;
       DEBUG_MSG(L"RegisterHotKey() failed for re-registration (cCurrVk=%lu,    LastError=%lu).", cCurrVk, GetLastError());
       goto lblCleanup;
   }
   // Write to the file
  if (!WriteFile(hFile, &cCurrVk, sizeof(cCurrVk), &cbBytesWritten, NULL))
  {
....

One important detail is this: to avoid alerting the user to the keylogger's presence, once the virtual-key code is extracted from the message, the key's hotkey registration is temporarily removed using the UnregisterHotKey API. After that, the key press is simulated with keybd_event so that it appears to the user as if the key was pressed normally. Once the key press is simulated, the key is re-registered using the RegisterHotKey API to wait for further input. This is the core mechanism behind how a hotkey-based keylogger operates.

Detecting Hotkey-Based Keyloggers

Now that we understand what hotkey-based keyloggers are and how they operate, let's explain how to detect them.

ETW Does Not Monitor the RegisterHotKey API

Following the approach described in an earlier article, we first investigated whether Event Tracing for Windows (ETW) could be used to detect hotkey-based keyloggers. Our research quickly revealed that ETW currently does not monitor the RegisterHotKey or UnregisterHotKey APIs. In addition to reviewing the manifest file for the Microsoft-Windows-Win32k provider, we reverse-engineered the internals of the RegisterHotKey API — specifically, the NtUserRegisterHotKey function in win32kfull.sys. Unfortunately, we found no evidence that these APIs trigger any ETW events when executed.

The image below shows a comparison between the decompiled code for NtUserGetAsyncKeyState (which is monitored by ETW) and NtUserRegisterHotKey. Notice that at the beginning of NtUserGetAsyncKeyState, there is a call to EtwTraceGetAsyncKeyState — a function associated with logging ETW events — while NtUserRegisterHotKey does not contain such a call.

　
Although we also considered using ETW providers other than Microsoft-Windows-Win32k to indirectly monitor calls to the RegisterHotKey API, we found that the detection method using the "hotkey table" — which will be introduced next and does not rely on ETW — achieves results that are comparable to or even better than monitoring the RegisterHotKey API. In the end, we chose to implement this method.

Detection Using the Hotkey Table (gphkHashTable)

After discovering that ETW cannot directly monitor calls to the RegisterHotKey API, we started exploring detection methods that don't rely on ETW. During our investigation, we wondered, "Isn't the information for registered hotkeys stored somewhere? And if so, could that data be used for detection?" Based on that hypothesis, we quickly found a hash table labeled gphkHashTable within NtUserRegisterHotKey. Searching Microsoft's online documentation revealed no details on gphkHashTable, suggesting that it's an undocumented kernel data structure.

Through reverse engineering, we discovered that this hash table stores objects containing information about registered hotkeys. Each object holds details such as the virtual-key code and modifiers specified in the arguments to the RegisterHotKey API. The right side of Figure 3 shows part of the structure definition for a hotkey object (named HOT_KEY), while the left side displays how the registered hotkey objects appear when accessed via WinDbg.

We also determined that ghpkHashTable is structured as shown in Figure 4. Specifically, it uses the result of the modulo operation (with 0x80) on the virtual-key code (specified by the RegisterHotKey API) as the index into the hash table. Hotkey objects sharing the same index are linked together in a list, which allows the table to store and manage hotkey information even when the virtual-key codes are identical but the modifiers differ.

In other words, by scanning all HOT_KEY objects stored in ghpkHashTable, we can retrieve details about every registered hotkey. If we find that every main key — for example, each individual alphanumeric key — is registered as a separate hotkey, that strongly indicates the presence of an active hotkey-based keylogger.

Implementing the Detection Tool

Now, let's move on to implementing the detection tool. Since gphkHashTable resides in the kernel space, it cannot be accessed by a user-mode application. For this reason, it was necessary to develop a device driver for detection. More specifically, we decided to develop a device driver that obtains the address of gphkHashTable and scans through all the hotkey objects stored in the hash table. If the number of alphanumeric keys registered as hotkeys exceeds a predefined threshold, it will alert us to the potential presence of a hotkey-based keylogger.

How to Obtain the Address of gphkHashTable

While developing the detection tool, one of the first challenges we faced was how to obtain the address of gphkHashTable. After some consideration, we decided to extract the address directly from an instruction in the win32kfull.sys driver that accesses gphkHashTable.

Through reverse engineering, we discovered that within the IsHotKey function — right at the beginning — there is a lea instruction (lea rbx, gphkHashTable) that accesses gphkHashTable. We used the opcode byte sequence (0x48, 0x8d, 0x1d) from that instruction as a signature to locate the corresponding line, and then computed the address of gphkHashTable using the obtained 32-bit (4-byte) offset.

Additionally, since IsHotKey is not an exported function, we also need to know its address before looking for gphkHashTable. Through further reverse engineering, we discovered that the exported function EditionIsHotKey calls the IsHotKey function. Therefore, we decided to compute the address of IsHotKey within the EditionIsHotKey function using the same method described earlier. (For reference, the base address of win32kfull.sys can be found using the PsLoadedModuleList API.)

Accessing the Memory Space of win32kfull.sys

Once we finalized our approach to obtaining the address of gphkHashTable, we began writing code to access the memory space of win32kfull.sys to retrieve that address. One challenge we encountered at this stage was that win32kfull.sys is a session driver. Before proceeding further, here’s a brief, simplified explanation of what a session is.

In Windows, when a user logs in, a separate session (with session numbers starting from 1) is assigned to each user. Simply put, the first user to log in is assigned Session 1. If another user logs in while that session is active, that user is assigned Session 2, and so on. Each user then has their own desktop environment within their assigned session.

Kernel data that must be managed separately for each session (i.e., per logged-in user) is stored in an isolated area of kernel memory called session space. This includes GUI objects managed by win32k drivers, such as windows and mouse/keyboard input data, ensuring that the screen and input remain properly separated between users.

(This is a simplified explanation. For a more detailed discussion on sessions, please refer to James Forshaw’s blog post.)

Based on the above, win32kfull.sys is known as a session driver. This means that, for example, hotkey information registered in the session of the first logged-in user (Session 1) can only be accessed from within that same session. So, how can we work around this limitation? In such cases, it is known that KeStackAttachProcess can be used.

KeStackAttachProcess allows the current thread to temporarily attach to the address space of a specified process. If we can attach to a GUI process in the target session — more precisely, a process that has loaded win32kfull.sys — then we can access win32kfull.sys and its associated data within that session. For our implementation, assuming that only one user is logged in, we decided to locate and attach to winlogon.exe, the process responsible for handling user logon operations.

Enumerating Registered Hotkeys

Once we have successfully attached to the winlogon.exe process and determined the address of gphkHashTable, the next step is simply scanning gphkHashTable to check the registered hotkeys. Below is an excerpt of that code:

BOOL CheckRegisteredHotKeys(_In_ const PVOID& gphkHashTableAddr)
{
-[skip]-
    // Cast the gphkHashTable address to an array of pointers.
    PVOID* tableArray = static_cast<PVOID*>(gphkHashTableAddr);
    // Iterate through the hash table entries.
    for (USHORT j = 0; j < 0x80; j++)
    {
        PVOID item = tableArray[j];
        PHOT_KEY hk = reinterpret_cast<PHOT_KEY>(item);
        if (hk)
        {
            CheckHotkeyNode(hk);
        }
    }
-[skip]-
}

VOID CheckHotkeyNode(_In_ const PHOT_KEY& hk)
{
    if (MmIsAddressValid(hk->pNext)) {
        CheckHotkeyNode(hk->pNext);
    }

    // Check whether this is a single numeric hotkey.
    if ((hk->vk >= 0x30) && (hk->vk <= 0x39) && (hk->modifiers1 == 0))
    {
        KdPrint(("[+] hk->id: %u hk->vk: %x\n", hk->id, hk->vk));
        hotkeyCounter++;
    }
    // Check whether this is a single alphabet hotkey.
    else if ((hk->vk >= 0x41) && (hk->vk <= 0x5A) && (hk->modifiers1 == 0))
    {
        KdPrint(("[+] hk->id: %u hk->vk: %x\n", hk->id, hk->vk));
        hotkeyCounter++;
    }
-[skip]-
}
....
if (CheckRegisteredHotKeys(gphkHashTableAddr) && hotkeyCounter >= 36)
{
   detected = TRUE;
   goto Cleanup;
}

The code itself is straightforward: it iterates through each index of the hash table, following the linked list to access every HOT_KEY object, and checks whether the registered hotkeys correspond to alphanumeric keys without any modifiers. In our detection tool, if every alphanumeric key is registered as a hotkey, an alert is raised, indicating the possible presence of a hotkey-based keylogger. For simplicity, this implementation only targets alphanumeric key hotkeys, although it would be easy to extend the tool to check for hotkeys with modifiers such as SHIFT.

Detecting Hotkeyz

The detection tool (Hotkey-based Keylogger Detector) has been released below. Detailed usage instructions are provided as well. Additionally, this research was presented at NULLCON Goa 2025, and the presentation slides are available.

https://github.com/AsuNa-jp/HotkeybasedKeyloggerDetector

The following is a demo video showcasing how the Hotkey-based Keylogger Detector detects Hotkeyz.

DEMO_VIDEO.mp4

Acknowledgments

We would like to express our heartfelt gratitude to Jonathan Bar Or for reading our previous article, sharing his insights on hotkey-based keyloggers, and generously publishing the PoC tool Hotkeyz.

Introduction

Starting with Elastic Defend 8.12, we have enhanced the detection of keyloggers and malware with keylogging capabilities (such as information-stealing malware or remote access trojans, better known as RATs) on Windows by monitoring and recording the calls to representative Windows APIs used by keyloggers. This publication will focus on providing a detailed technical background of this new feature. Additionally, we will introduce the new prebuilt behavioral detection rules created in conjunction with this feature.

What is a keylogger and what are their risks?

A keylogger is a type of software that monitors and records the keystrokes entered on a computer (※1). While keyloggers can be used for legitimate purposes such as user monitoring, they are frequently abused by malicious actors. Specifically, they are used to steal sensitive information such as authentication credentials, credit card details, and various confidential data entered through the keyboard. (※1: While there are hardware keyloggers that can be attached directly to a PC via USB, this article focuses on software keyloggers.)

The sensitive information obtained through keyloggers can be exploited for monetary theft or as a stepping stone for further cyber attacks. Therefore, although keylogging itself does not directly damage the computer, early detection is crucial to preventing subsequent, more invasive cyber attacks.

There are many types of malware with keylogging capabilities, particularly RATs, information stealers, and banking malware. Some well-known malware with keylogging functionality includes Agent Tesla, LokiBot, and SnakeKeylogger.

How are keystrokes stolen?

Next, let's explain from a technical perspective how keyloggers function without being detected. While keyloggers can be used within various operating system environments (Windows/Linux/macOS and mobile devices), this article will focus on Windows keyloggers. Specifically, we will describe four distinct types of keyloggers that capture keystrokes using Windows APIs and functions (※2).

As a side note, the reason for explaining keylogging methods here is to deepen the understanding of the new detection features introduced in the latter half of this article. Therefore, the example code provided is for illustrative purposes only and is not intended to be executable as is (※3).

(※2: Keyloggers running on Windows can be broadly divided into those installed in kernel space (OS side) and those installed in the same space as regular applications (user space). This article focuses on the latter type.) (※3: If a keylogger is created and misused based on the example code provided below, Elastic will not be responsible for any consequences.)

1. Polling-based keylogger

This type of keylogger polls or periodically checks the state of each key on the keyboard (whether the key is pressed) at short intervals (much shorter than one second). If a keylogger detects that a new key has been pressed since the last check, it records and saves the information of the pressed key. By repeating this process, the keylogger captures the characters entered by the user.

Polling-based keyloggers are implemented using Windows APIs that check the state of key inputs, with the GetAsyncKeyState API being a representative example. This API can determine whether a specific key is currently pressed and whether that key has been pressed since the last API call. Below is a simple example of a polling-based keylogger using the GetAsyncKeyState API:

while(true)
{
    for (int key = 1; key <= 255; key++)
    {
        if (GetAsyncKeyState(key) & 0x01)
        {
            SaveTheKey(key, "log.txt");
        }
    }
    Sleep(50);
}

The method of polling (GetAsyncKeyState) to capture key press states is not only a well-known, classic keylogging technique, but it is also commonly used by malware today.

1. Hooking-based keylogger

Hooking-based keyloggers, like polling-based keyloggers, are a classic type that has been around for a long time. Let's first explain what a "hook" is.

A hook is a mechanism that allows you to insert custom processing (custom code) into specific operations of an application. Using a hook to insert custom processing is known as "hooking."

Windows provides a mechanism that allows you to hook messages (events) such as key inputs to an application, and this can be utilized through the SetWindowsHookEx API. Below is a simple example of a hooking-based keylogger using the SetWindowsHookEx API:

HMODULE hHookLibrary = LoadLibraryW(L"hook.dll");
FARPROC hookFunc = GetProcAddress(hHookLibrary, "SaveTheKey");

HHOOK keyboardHook = NULL;

keyboardHook = SetWindowsHookEx(WH_KEYBOARD_LL,
                (HOOKPROC)hookFunc,
                hHookLibrary,
                0);

1. Keylogger using the Raw Input Model

This type of keylogger captures and records raw input data obtained directly from input devices like keyboards. Before delving into the details of this type of keylogger, it's essential to understand the "Original Input Model" and "Raw Input Model" in Windows. Here's an explanation of each input method:

• Original Input Model: The data entered from input devices like keyboards is processed by the OS before being delivered to the application.
• Raw Input Model: The data entered from input devices is received directly by the application without any intermediate processing by the OS.

Initially, Windows only used the Original Input Model. However, with the introduction of Windows XP, the Raw Input Model was added, likely due to the increasing diversity of input devices. In the Raw Input Model, the RegisterRawInputDevices API is used to register the input devices from which you want to receive raw data directly. Subsequently, the GetRawInputData API is used to obtain the raw data.

Below is a simple example of a keylogger using the Raw Input Model and these APIs:

LRESULT CALLBACK WndProc(HWND hWnd, UINT uMessage, WPARAM wParam, LPARAM lParam)
{

    UINT dwSize = 0;
    RAWINPUT* buffer = NULL;

    switch (uMessage)
    {
    case WM_CREATE:
        RAWINPUTDEVICE rid;
        rid.usUsagePage = 0x01;  // HID_USAGE_PAGE_GENERIC
        rid.usUsage = 0x06;      // HID_USAGE_GENERIC_KEYBOARD
        rid.dwFlags = RIDEV_NOLEGACY | RIDEV_INPUTSINK;
        rid.hwndTarget = hWnd;
        RegisterRawInputDevices(&rid, 1, sizeof(rid));
        break;
    case WM_INPUT:
        GetRawInputData((HRAWINPUT)lParam, RID_INPUT, NULL, &dwSize, sizeof(RAWINPUTHEADER));

        buffer = (RAWINPUT*)HeapAlloc(GetProcessHeap(), 0, dwSize);

        if (GetRawInputData((HRAWINPUT)lParam, RID_INPUT, buffer, &dwSize, sizeof(RAWINPUTHEADER)))
        {
            if (buffer->header.dwType == RIM_TYPEKEYBOARD)
            {
                SaveTheKey(buffer, "log.txt");
            }
        }
        HeapFree(GetProcessHeap(), 0, buffer);
        break;
    default:
        return DefWindowProc(hWnd, uMessage, wParam, lParam);
    }
    return 0;
}

In this example, RegisterRawInputDevices is used to register the input devices from which raw input data is to be received. Here, it is set to receive raw input data from the keyboard.

1. Keylogger using DirectInput

Finally, let's discuss a keylogger that uses DirectInput. In simple terms, this keylogger abuses the functionalities of Microsoft DirectX. DirectX is a collection of APIs (libraries) used for handling multimedia tasks such as games and videos.

Since obtaining various inputs from users is essential in gaming, DirectX also provides APIs for processing user inputs. The APIs provided before DirectX version 8 are known as DirectInput. Below is a simple example of a keylogger using related APIs. As a side note, when acquiring key states using DirectInput, the RegisterRawInputDevices API is called in the background.

LPDIRECTINPUT8        lpDI = NULL;
LPDIRECTINPUTDEVICE8    lpKeyboard = NULL;

BYTE key[256];
ZeroMemory(key, sizeof(key));

DirectInput8Create(hInstance, DIRECTINPUT_VERSION, IID_IDirectInput8, (LPVOID*)&lpDI, NULL);
lpDI->CreateDevice(GUID_SysKeyboard, &lpKeyboard, NULL);
lpKeyboard->SetDataFormat(&c_dfDIKeyboard);
lpKeyboard->SetCooperativeLevel(hwndMain, DISCL_FOREGROUND | DISCL_NONEXCLUSIVE | DISCL_NOWINKEY);

while(true)
{
    HRESULT ret = lpKeyboard->GetDeviceState(sizeof(key), key);
    if (FAILED(ret)) {
        lpKeyboard->Acquire();
        lpKeyboard->GetDeviceState(sizeof(key), key);
    }
  SaveTheKey(key, "log.txt");    
    Sleep(50);
}

Detecting keyloggers by monitoring Windows API calls

Elastic Defend uses Event Tracing for Windows (ETW ※4) to detect the aforementioned keylogger types. This is achieved by monitoring calls to related Windows APIs and logging particularly anomalous behavior. Below are the Windows APIs being monitored and the newly created keylogger detection rules associated with these APIs. (※4: In short, ETW is a mechanism provided by Microsoft for tracing and logging the execution of applications and system components in Windows, such as device drivers.)

Monitored Windows APIs:

• GetAsyncKeyState
• SetWindowsHookEx
• RegisterRawInputDevice

New keylogger endpoint detection rules:

• GetAsyncKeyState API Call from Suspicious Process
• GetAsyncKeyState API Call from Unusual Process
• Keystroke Input Capture via DirectInput
• Keystroke Input Capture via RegisterRawInputDevices
• Keystroke Messages Hooking via SetWindowsHookEx
• Keystrokes Input Capture from a Managed Application
• Keystrokes Input Capture from a Suspicious Module
• Keystrokes Input Capture from Suspicious CallStack
• Keystrokes Input Capture from Unsigned DLL
• Keystrokes Input Capture via SetWindowsHookEx

With this new set of capabilities, Elastic Defend can provide comprehensive monitoring and detection of keylogging activity, enhancing the security and protection of Windows endpoints against these threats.

Detecting Windows keyloggers

Next, let’s walk through an example of how the detection works in practice. We'll detect a keylogger using the Raw Input Model with Elastic Defend. For this example, we prepared a simple PoC keylogger named Keylogger.exe that uses the RegisterRawInputDevices API and executed it in our test environment ※5. (※5:The execution environment is Windows 10 Version 22H2 19045.4412, the latest version available at the time of writing.)

　 Shortly after the keylogger was executed, a detection rule (Keystroke Input Capture via RegisterRawInputDevices) was triggered on the endpoint, showing an alert. The further details of this alert can be viewed within Kibana.

Here are the details of the detection rule, note the specific API referenced in the example.

query = '''
api where
 process.Ext.api.name == "RegisterRawInputDevices" and not process.code_signature.status : "trusted" and
 process.Ext.api.parameters.usage : ("HID_USAGE_GENERIC_KEYBOARD", "KEYBOARD") and
 process.Ext.api.parameters.flags : "*INPUTSINK*" and process.thread.Ext.call_stack_summary : "?*" and
 process.thread.Ext.call_stack_final_user_module.hash.sha256 != null and process.executable != null and
 not process.thread.Ext.call_stack_final_user_module.path :
                         ("*\\program files*", "*\\windows\\system32\\*", "*\\windows\\syswow64\\*",
                          "*\\windows\\systemapps\\*",
                          "*\\users\\*\\appdata\\local\\*\\kumospace.exe",
                          "*\\users\\*\\appdata\\local\\microsoft\\teams\\current\\teams.exe") and 
 not process.executable : ("?:\\Program Files\\*.exe", "?:\\Program Files (x86)\\*.exe")
'''

This rule raises an alert when an unsigned process, or a process signed by an untrusted signer, calls the RegisterRawInputDevices API to capture keystrokes. More specifically, Elastic Defend monitors the arguments passed to the RegisterRawInputDevices API, particularly the members of the RAWINPUTDEVICE structure, which is the first argument of this API.

This raises an alert when these argument values indicate an attempt to capture keyboard input. The logs of the RegisterRawInputDevices API can also be viewed within Kibana.

Data Collected During Windows API Calls

Due to space constraints, this article does not cover all of the detection rules and API details that were added. However, we will briefly describe the data that Elastic Defend collects during calls to the relevant Windows APIs. For further explanations for each item, please refer to the Elastic Common Schema (ECS) mapping detailed in custom_api.yml.

| API Name | Field | Description | Example | | --- | --- | --- | --- | | GetAsyncKeyState | process.Ext.api.metadata.ms_since_last_keyevent | This parameter indicates an elapsed time in milliseconds between the last GetAsyncKeyState event. | 94 | | GetAsyncKeyState | process.Ext.api.metadata.background_callcount | This parameter indicates a number of all GetAsyncKeyState api calls, including unsuccessful calls, between the last successful GetAsyncKeyState call. | 6021 | | SetWindowsHookEx | process.Ext.api.parameters.hook_type | Type of hook procedure to be installed. | "WH_KEYBOARD_LL" | SetWindowsHookEx | process.Ext.api.parameters.hook_module | DLL containing the hook procedure. | "c:\windows\system32\taskbar.dll" | SetWindowsHookEx | process.Ext.api.parameters.procedure | The memory address of the procedure or function. | 2431737462784 | | SetWindowsHookEx | process.Ext.api.metadata.procedure_symbol | Summary of the hook procedure. | "taskbar.dll" | | RegisterRawInputDevices | process.Ext.api.metadata.return_value | Return value of RegisterRawInputDevices API call. | 1 | | RegisterRawInputDevices | process.Ext.api.parameters.usage_page | This parameter indicates the top-level collection (Usage Page) of the device. First member RAWINPUTDEVICE structure. | "GENERIC" | | RegisterRawInputDevices | process.Ext.api.parameters.usage | This parameter indicates the specific device (Usage) within the Usage Page. Second member RAWINPUTDEVICE structure. | "KEYBOARD" | | RegisterRawInputDevices | process.Ext.api.parameters.flags | Mode flag that specifies how to interpret the information provided by UsagePage and Usage. Third member RAWINPUTDEVICE structure. | "INPUTSINK" | | RegisterRawInputDevices | process.Ext.api.metadata.windows_count | Number of windows owned by the caller thread. | 2 | | RegisterRawInputDevices | process.Ext.api.metadata.visible_windows_count | Number of visible windows owned by the caller thread. | 0 | | RegisterRawInputDevices | process.Ext.api.metadata.thread_info_flags | Thread info flags. | 16 | | RegisterRawInputDevices | process.Ext.api.metadata.start_address_module | Name of the module associated with the starting address of a thread. | "C:\Windows\System32\DellTPad\ApMsgFwd.exe" | | RegisterRawInputDevices | process.Ext.api.metadata.start_address_allocation_protection | Memory protection attributes associated with the starting address of a thread. | "RCX" |

Conclusion

In this article, we introduced the keylogger and keylogging detection features for Windows environments that were added starting from Elastic Defend 8.12. Specifically, by monitoring calls to representative Windows APIs related to keylogging, we have integrated a behavioral keylogging detection approach that does not rely on signatures. To ensure accuracy and reduce the false positive rate, we have created this feature and new rules based on months of research.

In addition to keylogging-related APIs, Elastic Defend also monitors other APIs commonly used by malicious actors, such as those for memory manipulation, providing multi-layered protection. If you are interested in Elastic Security and Elastic Defend, please check out the product page and documentation.