NtCreateKeyedEvent

Prototype

NTSTATUS NtCreateKeyedEvent(
  PHANDLE            KeyedEventHandle,
  ACCESS_MASK        DesiredAccess,
  POBJECT_ATTRIBUTES ObjectAttributes,
  ULONG              Flags
);

Arguments

Syscall IDs by Windows version

Syscall stub

4C 8B D1            mov r10, rcx
B8 B7 00 00 00      mov eax, 0xB7
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

Keyed events are a deliberately minimal Windows synchronization primitive: a single keyed event can service an unbounded number of waiters because the rendezvous is done on a *key* (any pointer-sized value, conventionally a virtual address) rather than on the event object itself. The kernel maintains a per-event hash table keyed by `(process, key)`; `NtWaitForKeyedEvent` blocks until *some other thread* calls `NtReleaseKeyedEvent` with the same key. In practice almost every process uses the single global instance at `\KernelObjects\CritSecOutOfMemoryEvent`, which `ntdll.dll` opens during startup and stashes in `peb->KeyedEventHandle`. Creating a brand-new keyed event with `NtCreateKeyedEvent` is rare outside diagnostic tools and a handful of historical XP-era allocators (the global event has handled contention since Vista).

Common malware usage

Weak signal. The primary attraction for offensive use is *namelessness*: a keyed event created with NULL `ObjectAttributes` produces no named kernel object, no file handle, and no network footprint, and a sleep-mask or stage gate built on `NtWaitForKeyedEvent` (paired with `NtReleaseKeyedEvent` from a peer thread) is invisible to enumeration of named events / semaphores / mutexes that some sandbox detectors run. A few sleep-obfuscation designs (the Ekko / Ekko-lookalike family, some Foliage / TimerHandler-style designs) use the global `\KernelObjects\CritSecOutOfMemoryEvent` as a sync point rather than creating their own — that path doesn't even involve `NtCreateKeyedEvent`. Direct calls to `NtCreateKeyedEvent` from non-Microsoft code are unusual but not damning.

Detection opportunities

Essentially undetectable as a syscall. There is no Sysmon event for keyed-event creation and no ETW provider that surfaces it cleanly. Forensic enumeration via `!handle` in WinDbg or SystemInformer's handle view will show `KeyedEvent` objects per process, but the global event is held by nearly every process so the only useful artifact is an *unnamed* `KeyedEvent` handle in a process that has no business with low-level critical-section infrastructure. Even then, false positives from in-process allocators and instrumentation libraries are high.

Direct syscall examples

; Direct syscall stub for NtCreateKeyedEvent (SSN 0xB7 on Win11 24H2)
NtCreateKeyedEvent PROC
    mov  r10, rcx          ; KeyedEventHandle
    mov  eax, 0B7h         ; SSN — drifts per build
    syscall
    ret
NtCreateKeyedEvent ENDP

// No public Win32 wrapper. Almost all callers use the global instance instead.
#include <windows.h>
#include <winternl.h>

#define KEYEDEVENT_ALL_ACCESS (STANDARD_RIGHTS_REQUIRED | 0x3)

typedef NTSTATUS (NTAPI *pNtCreateKeyedEvent)(
    PHANDLE, ACCESS_MASK, POBJECT_ATTRIBUTES, ULONG);

HANDLE MakePrivateKeyedEvent(void) {
    HANDLE h = NULL;
    pNtCreateKeyedEvent fn = (pNtCreateKeyedEvent)GetProcAddress(
        GetModuleHandleA("ntdll.dll"), "NtCreateKeyedEvent");
    fn(&h, KEYEDEVENT_ALL_ACCESS, NULL /* unnamed */, 0);
    return h;
}

MITRE ATT&CK mappings

• T1106Native APImitre ↗