In this article, we explore what hotkey-based keyloggers are and how to detect them. Specifically, we explain how these keyloggers intercept keystrokes, then present a detection technique that leverages an undocumented hotkey table in kernel space.

Introduction

In May 2024, Elastic Security Labs published an article highlighting new features added in Elastic Defend (starting with 8.12) to enhance the detection of keyloggers running on Windows. In that post, we covered four types of keyloggers commonly employed in cyberattacks — polling-based keyloggers, hooking-based keyloggers, keyloggers using the Raw Input Model, and keyloggers using DirectInput — and explained our detection methodology. In particular, we introduced a behavior-based detection method using the Microsoft-Windows-Win32k provider within Event Tracing for Windows (ETW).

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.

ホットキー型キーロガーの検知

本記事では、ホットキー型キーロガーとは何かについてと、その検知方法について紹介します。具体的には、ホットキー型キーロガーがどのようにしてキー入力を盗み取るのかを解説した後、カーネルレベルに存在する未公開(Undocumented)のホットキーテーブルを活用した検知手法について説明します。

はじめに

　Elastic Security Labsでは2024年5月、Elastic Defendのバージョン 8.12 より追加された、Windows上で動作するキーロガーの検知を強化する新機能を紹介する記事を公開しました 。具体的には、サイバー攻撃で一般的に使われる4種類のキーロガー(ポーリング型キーロガー、フッキング型キーロガー、Raw Input Modelを用いたキーロガー、DirectInputを用いたキーロガー)を挙げ、それらに対する私たちが提供した検知手法についてを解説しました。具体的にはEvent Tracing for Windows (ETW)における、Microsoft-Windows-Win32kプロバイダを用いた振る舞い検知の方法についてを紹介しました。
　記事公開後、大変光栄なことに記事がMicrosoft社のPrincipal Security ResearcherであるJonathan Bar Or氏の目に留まり、「ホットキー型キーロガーもある」といった貴重なご意見とともに、そのPoCコードも公開してくださりました。そこで本記事では、氏が公開したホットキー型キーロガーのPoCコードである「Hotkeyz」 をもとに、本キーロガーの検知手法の一案についてを述べたいと思います。

ホットキー型キーロガーの概要

そもそもホットキーとは何か？

　ホットキー型キーロガーについて説明する前に、まずホットキーとは何かを解説します。ホットキーとは、キーボードショートカットの一種であり、コンピュータにおいて、特定の機能を直接呼び出して実行させるキーまたはキーの組み合わせのことを指します。例えばWindowsにおいてタスク(ウィンドウ)を切り替える際に「Alt + Tab」を押している人も多いかと思います。この時使っているこの「Alt + Tab」が、タスク切り替え機能を直接呼び出す「ホットキー」にあたります。

(注: ホットキー以外にも、キーボードショートカットは存在しますが、本記事ではそれらは対象外です。また本記事に記載の事項はすべて、筆者が検証に利用した環境である、仮想化ベースのセキュリティが動作していないWindows 10 version 22H2 OS Build 19045.5371が前提になります。他のWindowsのバージョンではまた内部の構造や挙動が違う場合があること、ご注意ください。)

任意のホットキーが登録できることを悪用する

　先ほどの例のようにWindowsで予め設定されたホットキーを使う以外にも、実は自分で任意のホットキーを登録することも可能です。登録方法は様々ありますが、RegisterHotKeyというWindows APIを使えば、指定のキーをホットキーとして登録することができます。例えば、以下がRegisterHotKey APIを使って「A」(virtual-key codeで0x41)キーを、グローバルなホットキーとして登録するためのコードの例です。

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

　ホットキーとして登録後、登録されたキーが押下された場合、RegisterHotKey APIの第一引数で指定したウィンドウ(NULLの場合はホットキー登録時のスレッド)のメッセージキューに、WM_HOTKEYメッセージが届くようになります。以下は実際に、メッセージキューにWM_HOTKEY メッセージが来ていないかをGetMessage APIを使って確認し、届いていた場合、WM_HOTKEYメッセージに内包されていた virtual-key code(今回の場合「0x41」)を取り出しているコード(メッセージループ)になります。

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;
    }
}

　これは言い換えると、例えばメモ帳アプリに文章を書く際、Aキーから入力された文字は、文字としての入力ではなく、グローバルなホットキーとして認識されることになります。

　今回は「A」のみをホットキーとして登録しましたが、複数のキー(BやCやD)を同時に個々のホットキーとして登録することも可能です。これはつまり、RegisterHotKey APIでホットキーとして登録可能な範囲の任意のキー(virtual-key code)の入力は、すべてグローバルなホットキーとして横取りすることも可能であるということです。そしてホットキー型キーロガーはこの性質を悪用して、ユーザから入力されたキーを盗み取ります。
　筆者が手元の環境で試した限りは、英数字と基本的な記号キーだけでなく、それらにSHIFT修飾子をつけたすべてキーがRegisterHotKey APIでホットキーとして登録可能でした。そのため、キーロガーとして問題なく、情報の窃取に必要なキーの監視ができると言えるでしょう。

密かにキーを盗み取る

　ホットキー型キーロガーがキーを盗み取る実際の流れについてを、Hotkeyzを例に紹介します。
Hotkeyzでは最初に、各英数字キーに加えて、一部のキー(VK_SPACEやVK_RETURNなど)のvirtual-key codeを、RegisterHotKey APIを使い個々のホットキーとして登録します。その後キーロガー内のメッセージループにて、登録されたホットキーのWM_HOTKEYメッセージが、メッセージキューに到着していないかをPeekMessageW APIを使って確認します。そしてWM_HOTKEYメッセージが来ていた場合、メッセージに内包されているvirtual-key codeを取り出して、最終的にはそれをテキストファイルに保存します。以下がメッセージループ内のコードのコードです。特に重要な部分を抜粋して掲載しています。

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))
  {
....

　ここで特筆するべき点としては、ユーザにキーロガーの存在を気取られないため、メッセージからvirtual-key codeを取り出した時点で、いったんそのキーのホットキー登録をUnregisterHotKey APIを使って解除し、その上でkeybd_eventを使ってキーを送信することです。これにより、ユーザからは問題無くキーが入力出来ているように見え、キーが裏で窃取されていることに気が付かれにくくなります。そしてキーを送信した後は再びそのキーをRegisterHotKey APIを使ってホットキーとして登録し、再びユーザからの入力を待ちます。以上が、ホットキー型キーロガーの仕組みです。

ホットキー型キーロガーの検知手法

　ホットキー型キーロガーとは何かやその仕組みについて理解したところで、次にこれをどのように検知するかについてを説明します。

ETWではRegisterHotKey APIは監視していない

　以前の記事で書いた方法と同様に、まずはホットキー型キーロガーもEvent Tracing for Windows (ETW) を利用して検知が出来ないかを検討・調査しました。その結果、ETWではRegisterHotKey APIやUnRegisterHotKey APIを監視していないことがすぐに判明しました。Microsoft-Windows-Win32k プロダイバーのマニフェストファイルの調査に加えて、RegisterHotKeyのAPIの内部(具体的にはwin32kfull.sysにあるNtUserRegisterHotKey)をリバースエンジニアリングをしたものの、これらのAPIが実行される際、ETWのイベントを送信しているような形跡は残念ながら見つかりませんでした。
　以下の図は、ETWで監視対象となっているGetAsyncKeyState(NtUserGetAsyncKeyState)と、NtUserRegisterHotKeyの逆コンパイル結果を比較したものを示しています。NtUserGetAsyncKeyStateの方には関数の冒頭に、EtwTraceGetAsyncKeyStateというETWのイベント書き出しに紐づく関数が存在しますが、NtUserRegisterHotKeyには存在しないのが見て取れます。

　
　Microsoft-Windows-Win32k 以外のETWプロバイダーを使って、間接的にRegisterHotKey APIを呼び出しを監視する案もでたものの、次に紹介する、ETWを使わず「ホットキーテーブル」を利用した検知手法が、RegisterHotKey APIを監視するのと同様かそれ以上の効果が得られることが分かり、最終的にはこの案を採用することにしました。

ホットキーテーブル(gphkHashTable)を利用した検知

　ETWではRegisterHotKey APIの呼び出しを直接監視出来ないことが判明した時点で、ETWを利用せずに検知する方法を検討することにしました。検討の最中、「そもそも登録されたホットキーの情報がどこかに保存されているのではないか？」「もし保存されているとしたら、その情報が検知に使えるのではないか？」という考えに至りました。その仮説をもとに調査した結果、すぐにNtUserRegisterHotkey内にてgphkHashTableというラベルがつけられたハッシュテーブルを発見することが出来ました。Microsoft社が公開しているオンラインのドキュメント類を調査してもgphkHashTableについての情報はなかったため、これは未公開(undocumented)のカーネルデータ構造のようです。

　リバースエンジニアリングをした結果、このハッシュテーブルは、登録されたホットキーの情報を持つオブジェクトを保存しており、各オブジェクトはRegisterHotKey APIの引数にて指定されたvirtual-key codeや修飾子の情報を保持していることが分かりました。以下の図(右)がホットキーのオブジェクト(HOT_KEYと命名)の構造体の定義の一部と、図(左)が実際にwindbg上でgphkHashTableにアクセスした上で、登録されたホットキーのオブジェクトを見た時の様子です。

　リバースエンジニアリングをした結果をまとめると、ghpkHashTableは図4のような構造になっていることがわかりました。具体的には、RegisterHotKey APIで指定されたvirtual-key codeに対して0x80の余剰演算をした結果をハッシュテーブルのインデックスにしていました。そして同じインデックスを持つホットキーオブジェクトを連結リストで結ぶことで、virtual-key codeが同じでも、修飾子が違うホットキーの情報も保持・管理出来るようになっています。

　つまりgphkHashTableで保持している全てのHOT_KEYオブジェクトを走査すれば、登録されている全ホットキーの情報が取得できるということになります。取得した結果、主要なキー(例えば単体の英数字キー）全てが個々のホットキーとして登録されていれば、ホットキー型キーロガーが動作していることを示す強い根拠となります。

検知ツールを作成する

　では次に、実際に検知ツールの方を実装していきます。gphkHashTable自体はカーネル空間に存在するため、ユーザモードのアプリケーションからはアクセス出来ません。そのため検知のために、デバイスドライバを書くことにしました。具体的にはgphkHashTableのアドレスを取得した後、ハッシュテーブルに保存されている全オブジェクトを走査した上で、ホットキーとして登録されている英数字キーの数が一定数以上ならば、ホットキー型キーロガーが存在する可能性がある事を知らせてくるデバイスドライバを作成することにしました。

gphkHashTableのアドレスを取得する方法

　検知ツールを作成するにあたり、最初に直面した課題としては「gphkHashTableのアドレスをどのようにして取得すればよいのか？」ということです。悩んだ結果、win32kfull.sysのメモリ空間内でgphkHashTableにアクセスしている命令から直接gphkHashTableのアドレスを取得することにしました。
　リバースエンジニアリングした結果、IsHotKeyという関数内では、関数の冒頭部分にあるlea命令(lea rbx, gphkHashTable)にて、gphkHashTableのアクセスしていることがわかりました。この命令のオプコードバイト(0x48, 0x8d, 0x1d)部分をシグネチャに該当行を探索して、得られた32bit(4バイト)のオフセットからgphkHashTableのアドレスを算出することにしました。

　加えて、IsHotKey関数自体もエクスポート関数でないため、そのアドレスも何らかの方法で取得しなければいけません。そこでさらなるリバースエンジニアリングの結果、EditionIsHotKeyというエクスポートされた関数内で、IsHotKey関数が呼ばれていることがわかりました。そこでEditionIsHotKey関数から前述と同様の方法で、IsHotKey関数のアドレスを算出することにしました。(補足ですが、win32kfull.sysのベースアドレスに関してはPsLoadedModuleListというAPIで探せます。)

　## win32kfull.sysのメモリ空間にアクセスするには

　gphkHashTableのアドレスを取得する方法について検討が終わったところで、実際にwin32kfull.sysのメモリ空間にアクセスして、gphkHashTableのアドレスを取得するためのコードを書き始めました。この時直面した課題としては、win32kfull.sysは「セッションドライバ」であるという点ですが、ここではまず「セッション」とは何かについて、簡単に説明します。
　Windowsでは一般的にユーザがログインした際、ユーザ毎に個別に「セッション」(1番以降のセッション番号)が割り当てられます。かなり大雑把に説明すると、最初にログインしたユーザには「セッション１」が割り当てられ、その状態で別のユーザがログインした場合今度は「セッション２」が割り当てられます。そして各ユーザは個々のセッション内で、それぞれのデスクトップ環境を持ちます。
　この時、セッション別(ログインユーザ別)に管理するべきカーネルのデータは、カーネルメモリ内の「セッション空間」というセッション別の分離したメモリ空間で管理され、win32k ドライバが管理しているようなGUIオブジェクト(ウィンドウ、マウス・キーボード入力の情報等)もこれに該当します。これにより、ユーザ間で画面や入力情報が混ざることがないのです。(かなり大まかな説明のため、より詳しくセッションについて知りたい方はJames Forshaw氏のこちらのブログ記事を読むことをおすすめします。)

　　
以上の背景から、win32kfull.sysは「セッションドライバ」と呼ばれています。つまり、例えば最初のログインユーザのセッション(セッション1)内で登録されたホットキーの情報は、同じセッション内からしかアクセスできないということです。ではどうすれば良いのかというと、このような場合、KeStackAttachProcessが利用できることが知られています。
　KeStackAttachProcessは、現在のスレッドを指定のプロセスのアドレス空間に一時的にアタッチすることが出来ます。この時、対象のセッションにいるGUIプロセス、より正確にはwin32kfull.sysをロードしているプロセスにアタッチすることが出来れば、対象セッションのwin32kfull.sysやそのデータにアクセスすることが出来ます。今回は、ログインユーザが１ユーザであることを仮定して、各ユーザのログオン操作を担うプロセスであるwinlogon.exeを探してアタッチすることにしました。

登録されているホットキーを確認する

　winlogon.exeのプロセスにアタッチし、gphkHashTableのアドレスを特定出来た後は、後はgphkHashTableをスキャンして登録されたホットキーを確認するだけです。以下がその抜粋版のコードです。

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;
}

　コード自体は難しくなく、ハッシュテーブルの各インデックスの先頭から順に、連結リストをたどりながらすべてのHOT_KEYオブジェクトにアクセスして、登録されているホットキーが単体の英数字キーか否かを確認しています。作成した検知ツールでは、すべての単体英数字キーがホットキーとして登録
されていた場合、ホットキー型キーロガーが存在するとしてアラートを挙げます。また、今回実装の簡略化のため、英数字単体キーのホットキーのみを対象としていますが、SHIFTなどの修飾子付きのホットキーも容易に調べることが可能です。

Hotkeyzを検知する

　検知ツール(Hotkey-based Keylogger Detector)は以下にて公開しました。使い方も以下に記載していますので、興味ある方はぜひご覧ください。加えて本研究はNULLCON Goa 2025でも発表しましたので、その発表スライドも併せてご覧いただけます。

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

　最後に、本ツールを用いて実際にHotkeyzを検知する様子を収録したデモ動画が以下になります。

DEMO_VIDEO.mp4

謝辞

　前回の記事を読んで下さり、その上でホットキー型キーロガーの手法について教えてくださり、その上そのPoCとなるHotkeyzを公開してくださった、Jonathan Bar Or氏に心より感謝致します。

はじめに

Elastic Defend 8.12より、Windows上で動作するキーロガーおよび、キーロギング機能を備えたマルウェア(情報窃取型マルウェアや、リモートアクセス型トロイの木馬、通称RAT)の検知の強化を目的に、キーロガーが使用する代表的なWindows API群の呼び出しを監視・記録する機能が追加されました。本記事ではこの新機能に焦点を当て、その技術的な詳細を解説します。加えて、本機能に付随して新たに作成された振る舞い検知ルール(Prebuilt rule)についても紹介します。

キーロガーとはなにか？どのような危険性があるのか？

キーロガーとは、コンピュータ上で入力されたキーの内容を監視および記録(キーロギング)するソフトウェアの一種です(※1)。キーロガーは、ユーザのモニタリングなどの正当な理由で利用されることもありますが、攻撃者によって頻繁に悪用されるソフトウェアです。具体的には、ユーザがキーボード経由で入力した認証情報やクレジットカード情報、各種機密情報などのセンシティブな情報の窃取などに際に使われます。(※1: パソコンにUSB等で直接取り付けるようなハードウェア型のキーロガーもありますが、本記事ではソフトウェア型のキーロガーに焦点を当てます。)

キーロガーを通じて入手したセンシティブな情報は、金銭の窃取やさらなるサイバー攻撃の足がかりに悪用されます。それゆえに、キーロギング行為自体は直接的にコンピュータに被害をおよばさないものの、続くサイバー攻撃の被害を食い止めるためにも、早期の検知が非常に重要だと言えます。

キーロギング機能を持つマルウェアは多々あり、特にRAT、情報窃取型マルウェア、バンキングマルウェアといった種類のマルウェアにキーロギング機能が搭載されている場合があることが確認されています。有名なマルウェアでキーロギング機能を有するものとしてはAgent TeslaやLokibit、そしてSnakeKeyloggerなどが挙げられます。

いかにして入力した文字を盗み取っているのか？

では次に、キーロガーはいかにしてユーザがキーボードから入力した文字を、ユーザに気づかれること無く盗み取っているのかを、技術的な観点から説明していきます。キーロガー自体は、あらゆるOS環境(Windows/Linux/macOSやモバイルデバイス)で存在しうるものではありますが、本記事ではWindowsのキーロガーに焦点を絞って解説します。特にWindows APIや機能を使用してキー入力を取得する4つの異なるタイプのキーロガーについて解説します。

一点補足としては、ここでキーロギングの手法について説明しているのは、あくまで本記事後半で紹介している、新しい検知機能についての理解を深めていただくためです。そのため、例として掲載しているコードはあくまで単なる例であり、実際にそのまま動くコードが掲載されている訳ではありません(※3)。

(※2: Windows上で動作するキーロガーは、カーネル空間(OS)側に設置されるものと、通常のアプリケーションと同じ領域(ユーザ空間)に設置されるものに大別されます。本記事では、後者のタイプを取り上げます。 ) (※3: 以下に掲載されている例のコードを元にキーロガーを作成し悪用した場合、弊社では対応、および、責任について負いかねます 。)

1. ポーリング型キーロガー

このタイプのキーロガーは、キーボードの各キーの状態(キーが押された否か)を短い間隔(1秒よりはるかに短い間隔)で定期的に確認します。そして前回の確認以降に、新たに押されたキーがあることが判明した場合、その押されたキーの文字の情報を記録・保存します。この一連の流れを繰り返すことで、キーロガーは、ユーザが入力した文字列の情報を取得しているのです。

ポーリング型のキーロガーは、キーの入力状態をチェックするWindowsのAPIを利用して実装されており、代表的には GetAsyncKeyState APIが利用されます。このAPIは、特定のキーが現在押されているか否かに加えて、その特定のキーが前回のAPI呼び出し以降押されたか否かの情報を取得することが出来ます。以下がGetAsyncKeyState APIを使ったポーリング型キーロガーの簡単な例です。

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

ポーリング(GetAsyncKeyState)を用いてキー押下状態を取得する手法は、古くから存在する典型的なキーロギングの手法として知られているだけでなく、今でもマルウェアによって使われていることが確認されています。

2. フッキング型キーロガー

フッキング型キーロガーは、ポーリング型キーロガーと同じく、古くから存在する典型的な種類のキーロガーです。ここではまず「そもそもフックとは何か？」について説明します。

フックとは大雑把に言うと「アプリケーションの特定の処理に、独自の処理を割り込ませる仕組み」のことを指す言葉です。そして、フックを使って独自の処理を割り込ませることを「フックする」とも言います。Windowsでは、アプリケーションに対するキー入力などのメッセージ(イベント)をフックすることが出来る仕組みが用意されており、この仕組みはSetWindowsHookEx APIを通じて利用することが出来ます。以下が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);

3. Raw Input Modelを用いたキーロガー

このタイプのキーロガーは、キーボードなどの入力デバイスから得られた、生の入力データ(Raw Input)を取得し、それを保存・記録します。このキーロガーの詳細について説明する前に、まずWindowsにおける入力方式である「Original Input Model」と「Raw Input Model」について理解する必要があります。以下がそれぞれの入力方式についての説明です。

• Original Input Model: キーボードなどの入力デバイスから入力されたデータを、一度OSを介して必要な処理をした後、アプリケーション側に届ける方式
• Raw Input Model: キーボードなどの入力デバイスから入力されたデータを、そのままアプリケーション側が直接受け取る方式

Windowsでは当初、Original Input Modelのみが使われていました。しかしWindows XP以降に、おそらくは入力デバイスの多様化などの要因から、Raw Input Modelが導入されました。Raw Input Modelでは、RegisterRawInputDevices APIを使い、入力データを直接受け取りたい入力デバイスを登録します。そしてその後、GetRawInputData) APIを用いて生データを取得します。 以下がこれらのAPIを使った、Raw Input Modelを用いたキーロガーの簡単な例です。

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;
}

この例では、最初に生入力を受け取りたい入力デバイスをRegisterRawInputDevicesを用いて、登録します。ここでは、キーボードの生入力データを受け取るように設定・登録しています。

4. DirectInputを用いたキーロガー

最後に、DirectInputを用いたキーロガーについて説明します。このキーロガーは簡単に言えばMicrosoft DirectXの機能を悪用したキーロガーです。DirectXとは、ゲームや動画などのマルチメディア関連の処理を扱うためのAPI群の総称(ライブラリ)です。

ゲームにおいて、ユーザから各種入力が取得できることは必須機能と言って良いことから、DirectXにおいてもユーザの入力を処理するAPI群が提供されています。そして、DirectXのバージョン8以前に提供されていたそれらAPI群のことを「DirectInput」と呼びます。以下がDirectInputに関連するAPIを使ったキーロガーの簡単な例です。補足ですが、DirectInputを用いてキーを取得する際、裏ではRegisterRawInputDevices APIが呼ばれています。

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);
}

Windows API呼び出しを監視してキーロガーを検出する

Elastic Defendでは、Event Tracing for Windows (ETW ※4)を用いて、前述の種類のキーロガーを検知しています。具体的には、関連するWindows API群の呼び出しを監視し、その挙動のログを取得することで実現しています。監視するWindows API群と、付随して新規に作成したキーロガーの検知ルールは以下です。(※4 一言でいうとWindowsが提供する、アプリケーションやデバイスドライバなどのシステム側のコンポーネントを、トレースおよびロギングする仕組み。)

監視するWindows API群:

• GetAsyncKeyState
• SetWindowsHookEx
• RegisterRawInputDevice

追加したキーロガー検知ルール一覧:

• 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

新規に追加した機能および検知ルールにより、Elastic Defendにてキーロガー・キーロギングの包括的な監視と検出が可能となり、これらの脅威に対するWindowsエンドポイントのセキュリティと保護の強化を実現しました。

Windowsのキーロガーを検知する

次に実際の検知の様子をお見せします。例として、Raw Input Modelを用いたキーロガーをElastic Defendで検出してみます。ここではRegisterRawInputDevices APIを用いた簡易的なキーロガー「Keylogger.exe」を用意し、テスト環境で実行してみました※5。(※5 実行環境はWindows 10の執筆時点の最新版であるWindows 10 Version 22H2 19045.4412です。)

キーロガーを実行した直後に、検知ルール(Keystroke Input Capture via RegisterRawInputDevices)が発動し、エンドポイント側でアラートが上がりました。このアラートのさらなる詳細はKibana上から見ることが出来ます。

以下が検知ルールの詳細です。検知に使われているAPIの部分を中心に説明します。

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")
'''

このアラートは簡単に言うと「署名されていないプロセス」または「署名されているが、その署名者が信頼できないプロセス」が、キー入力を取得する目的でRegisterRawInputDevices APIを呼び出した時に発せられるアラートです。RegisterRawInputDevices APIが呼び出された際の引数の情報に着目しており、より具体的にはAPIの第一引数である、RAWINPUTDEVICE構造体のメンバの情報を検知に用いています。

この引数の値が、キーボード入力の取得を試みていることを示している場合、キーロガーが実行されたと見なして、アラートを上げるようになっています。 RegisterRawInputDevices APIのログはKibana上でも確認できます。

各Windows APIの呼び出しの際に取得しているデータ

分量の都合で、追加したすべての検知ルールとAPIの詳細については本記事では説明しません。ですが最後に、対象のWindows APIの呼び出しの際にElastic Defend側で取得しているデータについて、簡単にご紹介します。各項目についてさらに知りたい方は、custom_api.ymlに記載されているElastic Common Schema（ECS）とのマッピングをご参照ください。

まとめ

本記事では、Elastic Defend 8.12にて導入された、Windows環境におけるキーロガーおよびキーロギング検知機能についてご紹介しました。具体的には、キーロギングに関連する代表的なWindows API群の呼び出しを監視することで、シグネチャに依存しない、振る舞い検知によるキーロガー検出を実現しました。精度を高め、誤検知率を減らすために、数ヶ月にわたる研究・調査をもとにこの機能と新しいルールを開発しました。

Elastic Defendではキーロガー関連のAPI以外にも、攻撃者に一般的に利用されるメモリ操作等のAPI群なども監視することで、多層的な防御を実現しております。Elastic Security および Elastic Defendについて気になった方はぜひ製品ページやドキュメントを御覧頂ければ幸いです。

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.

2. 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);

3. 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.

4. 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.

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.