NtCreateKeyedEvent

Prototype

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

Arguments

IDs de syscalls par version de Windows

Stub du syscall

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

Notes non documentées

Les keyed events sont une primitive de synchronisation Windows volontairement minimale : un unique keyed event peut servir un nombre illimité de waiters car le rendez-vous se fait sur une *clé* (toute valeur de la taille d'un pointeur, conventionnellement une adresse virtuelle) plutôt que sur l'objet event lui-même. Le noyau maintient une table de hachage par event indexée par `(process, key)` ; `NtWaitForKeyedEvent` bloque jusqu'à ce qu'un *autre thread* appelle `NtReleaseKeyedEvent` avec la même clé. En pratique, quasiment chaque processus utilise l'unique instance globale à `\KernelObjects\CritSecOutOfMemoryEvent`, que `ntdll.dll` ouvre au démarrage et stocke dans `peb->KeyedEventHandle`. Créer un keyed event neuf avec `NtCreateKeyedEvent` est rare hors outils de diagnostic et d'une poignée d'allocateurs historiques (l'event global gère la contention depuis Vista).

Usage courant par les malwares

Signal faible. L'attrait principal pour l'usage offensif est *l'absence de nom* : un keyed event créé avec `ObjectAttributes` NULL ne produit aucun objet noyau nommé, aucun handle de fichier, aucune empreinte réseau, et un sleep-mask ou stage gate bâti sur `NtWaitForKeyedEvent` (apparié à `NtReleaseKeyedEvent` depuis un thread pair) est invisible à l'énumération d'events / sémaphores / mutexes nommés qu'effectuent certains détecteurs de sandbox. Quelques designs d'obfuscation de sommeil (famille Ekko / similaires, certains Foliage / TimerHandler) utilisent l'event global `\KernelObjects\CritSecOutOfMemoryEvent` comme point de synchro plutôt que de créer le leur — ce chemin n'implique même pas `NtCreateKeyedEvent`. Les appels directs à `NtCreateKeyedEvent` depuis du code non Microsoft sont inhabituels mais pas accablants.

Opportunités de détection

Essentiellement indétectable en tant que syscall. Aucun événement Sysmon pour la création de keyed event, aucun provider ETW ne le surface proprement. L'énumération forensique via `!handle` dans WinDbg ou la vue handles de SystemInformer montre des objets `KeyedEvent` par processus, mais l'event global est détenu par presque chaque processus — le seul artefact utile est donc un handle `KeyedEvent` *anonyme* dans un processus qui n'a rien à faire avec l'infrastructure de critical section bas niveau. Et même là, les faux positifs d'allocateurs in-process et de bibliothèques d'instrumentation sont nombreux.

Exemples de syscalls directs

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

Mappings MITRE ATT&CK

• T1106Native APImitre ↗