NtWaitForKeyedEvent

Prototyp

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

Argumente

Syscall-IDs pro 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

Undokumentierte Hinweise

Die Wait-Hälfte des Keyed-Event-Paares. Intern von `ntdll!RtlEnterCriticalSection` als **Low-Memory-Fallback** verwendet, wenn die Contention einer Critical Section normalerweise das Allokieren eines Event-Objekts erfordern würde und der Pool erschöpft ist. Auf diesem Pfad übergibt `ntdll.dll` `peb->KeyedEventHandle` (das globale `CritSecOutOfMemoryEvent`) und nutzt die Adresse des `LockSemaphore`-Felds der Critical Section als Key — so kann jeder konkurrierende Thread im System ein einziges globales Keyed Event teilen. `NtWaitForKeyedEvent` ist außerdem eine von zwei Primitiven hinter `WaitOnAddress` (die andere ist `KeWaitForSingleObject` auf einem Thread-lokalen Event); auf modernen Builds ist `WaitOnAddress` der empfohlene User-Mode-Einstieg.

Häufige Malware-Nutzung

Bescheidenes Signal. Sleep-Obfuscation-Designs, die eine Sync-Primitive ohne benanntes Kernel-Objekt wollen, paaren `NtWaitForKeyedEvent` (im schlafenden Thread) mit `NtReleaseKeyedEvent` (in einem Wakeup-Timer-ROP-Gadget oder APC). Da das globale Handle in jedem Prozess bereits offen ist, kommt das gesamte Schema ohne neu erzeugte Handles aus — primitive Sandboxes, die Handle-Tables nach frisch erzeugten Events / Semaphoren scannen, werden umgangen. Die Ekko-Familie und mehrere publizierte Sleep-Mask-Demos bauen darauf. Bewusster direkter Aufruf von `NtWaitForKeyedEvent` aus einem Nicht-System-Binary außerhalb dieses Musters ist eher ein Hinweis auf eine eigene Lock-Implementierung als ein Malware-Signal.

Erkennungs­möglichkeiten

Gleiche Lage wie `NtCreateKeyedEvent`: keine nützliche ETW- oder Sysmon-Oberfläche. Der einzige sinnvolle Blue-Team-Winkel ist *verhaltensbasiert* — ein Thread, der ungewöhnlich lange in `NtWaitForKeyedEvent` auf dem globalen Handle hängt, während sein Modul in unbacked / nur RX-Speicher lebt (typisch für sleep-gemaskte Beacons), ist verdächtig. ETW Threat Intelligence + Memory-Region-Introspektion (z. B. `MemoryWorkingSetExInformation` mit `MEMORY_REGION_PRIVATE`-Seiten) ist aussagekräftiger als das Tracen des Syscalls selbst.

Direkte Syscall-Beispiele

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