NtWaitForKeyedEvent

Prototype

NTSTATUS NtWaitForKeyedEvent(
  HANDLE         KeyedEventHandle,
  PVOID          Key,
  BOOLEAN        Alertable,
  PLARGE_INTEGER Timeout
);

Arguments

Syscall IDs by Windows version

Syscall stub

4C 8B D1            mov r10, rcx
B8 E5 01 00 00      mov eax, 0x1E5
F6 04 25 08 03 FE 7F 01   test byte ptr [0x7FFE0308], 1
75 03               jne short +3
0F 05               syscall
C3                  ret
CD 2E               int 2Eh
C3                  ret

Undocumented notes

The wait half of the keyed-event pair. Internally used by `ntdll!RtlEnterCriticalSection` as the **low-memory fallback** when a critical-section contention would normally require allocating an event object and the system is out of pool. In that path `ntdll.dll` passes `peb->KeyedEventHandle` (the global `CritSecOutOfMemoryEvent`) and uses the critical-section's `LockSemaphore` field address as the key, so every contending thread in the system can share one global keyed event. `NtWaitForKeyedEvent` is also one of two primitives behind `WaitOnAddress` (the other is `KeWaitForSingleObject` on a thread-local event); on modern builds `WaitOnAddress` is the recommended user-mode entry point.

Common malware usage

Modest signal. Sleep-obfuscation designs that want a sync primitive without naming any kernel object pair `NtWaitForKeyedEvent` (in the sleeping thread) with `NtReleaseKeyedEvent` (in a wake-up timer ROP gadget or APC). Because the global handle is already open in every process, the entire scheme requires zero new handles to be created — bypassing crude sandboxes that scan handle tables for newly-created events / semaphores. The Ekko family and several published sleep-mask demos rely on this. Direct, deliberate use of `NtWaitForKeyedEvent` from a non-system binary outside that pattern is mostly an indicator of a custom lock implementation rather than malware per se.

Detection opportunities

Same disposition as `NtCreateKeyedEvent`: no useful ETW or Sysmon surface. The only meaningful blue-team angle is *behavioural* — a thread that has been in `NtWaitForKeyedEvent` on the global handle for an unusually long time, while its containing module lives in unbacked / RX-only memory (typical of sleep-masked beacons), is suspicious. ETW Threat Intelligence + memory-region introspection (e.g. `MemoryWorkingSetExInformation` showing pages with `MEMORY_REGION_PRIVATE`) is more informative than tracing the syscall itself.

Direct syscall examples

; Direct syscall stub for NtWaitForKeyedEvent (SSN 0x1E5 on Win11 24H2)
NtWaitForKeyedEvent PROC
    mov  r10, rcx          ; KeyedEventHandle
    mov  eax, 1E5h         ; SSN — drifts per build
    syscall
    ret
NtWaitForKeyedEvent ENDP

// Mirrors what ntdll!RtlpWaitOnCriticalSection does in the out-of-pool path:
// every contending thread parks on the global keyed event using the address
// of the critical section's LockSemaphore slot as the rendezvous key.
#include <windows.h>
#include <winternl.h>

typedef NTSTATUS (NTAPI *pNtWaitForKeyedEvent)(
    HANDLE, PVOID, BOOLEAN, PLARGE_INTEGER);

static pNtWaitForKeyedEvent g_wait;

void ParkOnLockWord(volatile void **lockSlot) {
    if (!g_wait) {
        g_wait = (pNtWaitForKeyedEvent)GetProcAddress(
            GetModuleHandleA("ntdll.dll"), "NtWaitForKeyedEvent");
    }
    // NULL handle ⇒ kernel substitutes peb->KeyedEventHandle = global event.
    g_wait(NULL, (PVOID)lockSlot, FALSE, NULL);
}

// Microsoft's blessed user-mode primitive for the same pattern.
#include <windows.h>
#include <synchapi.h>
#pragma comment(lib, "Synchronization.lib")

void WaitForLockChange(volatile LONG *lock, LONG expected) {
    WaitOnAddress((volatile VOID*)lock, &expected, sizeof(expected), INFINITE);
}

MITRE ATT&CK mappings

• T1027Obfuscated Files or Informationmitre ↗
• T1106Native APImitre ↗