NtWaitForKeyedEvent

Prototype

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

Arguments

IDs de syscalls par version de Windows

Stub du syscall

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

Notes non documentées

La moitié wait de la paire keyed-event. Utilisée en interne par `ntdll!RtlEnterCriticalSection` comme **fallback bas mémoire** lorsque la contention d'une critical section exigerait normalement d'allouer un objet event et que le système est à court de pool. Dans ce chemin, `ntdll.dll` passe `peb->KeyedEventHandle` (le global `CritSecOutOfMemoryEvent`) et utilise l'adresse du champ `LockSemaphore` de la critical section comme clé, si bien que chaque thread en contention dans le système partage un unique keyed event global. `NtWaitForKeyedEvent` est aussi l'une des deux primitives derrière `WaitOnAddress` (l'autre étant `KeWaitForSingleObject` sur un event thread-local) ; sur les builds modernes, `WaitOnAddress` est le point d'entrée user-mode recommandé.

Usage courant par les malwares

Signal modeste. Les designs d'obfuscation de sommeil voulant une primitive de synchro sans nommer aucun objet noyau apparient `NtWaitForKeyedEvent` (dans le thread endormi) à `NtReleaseKeyedEvent` (dans un gadget ROP de timer de réveil ou un APC). Le handle global étant déjà ouvert dans chaque processus, l'ensemble n'exige aucun nouveau handle — esquivant les sandboxes rudimentaires qui scannent les tables de handles à la recherche d'events / sémaphores fraîchement créés. La famille Ekko et plusieurs démos publiques de sleep-mask s'appuient là-dessus. Un usage direct et délibéré de `NtWaitForKeyedEvent` depuis un binaire non système hors ce pattern est plutôt l'indice d'une implémentation de verrou maison qu'un signal de malware.

Opportunités de détection

Même disposition que `NtCreateKeyedEvent` : pas de surface ETW ou Sysmon utile. Le seul angle blue-team significatif est *comportemental* — un thread bloqué dans `NtWaitForKeyedEvent` sur le handle global anormalement longtemps, alors que son module hôte vit en mémoire non backed / RX-only (typique des beacons sleep-maskés), est suspect. ETW Threat Intelligence + introspection des régions mémoire (ex. `MemoryWorkingSetExInformation` montrant des pages `MEMORY_REGION_PRIVATE`) est plus informatif que tracer le syscall lui-même.

Exemples de syscalls directs

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

Mappings MITRE ATT&CK

• T1027Obfuscated Files or Informationmitre ↗
• T1106Native APImitre ↗