NtCreateKeyedEvent

Prototyp

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

Argumente

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

Undokumentierte Hinweise

Keyed Events sind eine bewusst minimalistische Windows-Synchronisationsprimitive: Ein einzelnes Keyed Event kann beliebig viele Waiter bedienen, weil das Rendezvous über einen *Key* (jeder Wert in Zeigergröße, üblicherweise eine virtuelle Adresse) statt über das Event-Objekt selbst läuft. Der Kernel hält pro Event eine Hash-Tabelle, indiziert mit `(Process, Key)`; `NtWaitForKeyedEvent` blockiert, bis *irgendein anderer Thread* `NtReleaseKeyedEvent` mit demselben Key aufruft. In der Praxis nutzt fast jeder Prozess die einzige globale Instanz unter `\KernelObjects\CritSecOutOfMemoryEvent`, die `ntdll.dll` beim Start öffnet und in `peb->KeyedEventHandle` ablegt. Ein brandneues Keyed Event mit `NtCreateKeyedEvent` zu erzeugen ist außerhalb von Diagnose-Tools und einer Handvoll historischer XP-Ära-Allokatoren selten (das globale Event handhabt Contention seit Vista).

Häufige Malware-Nutzung

Schwaches Signal. Der Hauptreiz für offensive Nutzung ist *Namenlosigkeit*: Ein Keyed Event mit NULL `ObjectAttributes` erzeugt kein benanntes Kernel-Objekt, kein File-Handle, keine Netzspur, und ein Sleep-Mask oder Stage Gate auf Basis von `NtWaitForKeyedEvent` (gepaart mit `NtReleaseKeyedEvent` aus einem Peer-Thread) ist für die Enumeration benannter Events / Semaphoren / Mutexe, die manche Sandbox-Detektoren ausführen, unsichtbar. Einige Sleep-Obfuscation-Designs (Ekko-/Ekko-ähnliche Familie, manche Foliage- / TimerHandler-artige Designs) nutzen das globale Event `\KernelObjects\CritSecOutOfMemoryEvent` als Sync-Punkt, statt ein eigenes anzulegen — dieser Pfad ruft `NtCreateKeyedEvent` gar nicht auf. Direkte Aufrufe von `NtCreateKeyedEvent` aus Nicht-Microsoft-Code sind ungewöhnlich, aber nicht belastend.

Erkennungs­möglichkeiten

Als Syscall im Grunde nicht detektierbar. Es gibt kein Sysmon-Event für Keyed-Event-Erzeugung und keinen ETW-Provider, der es sauber zeigt. Forensische Enumeration via `!handle` in WinDbg oder SystemInformers Handle-Ansicht zeigt `KeyedEvent`-Objekte pro Prozess, aber das globale Event hält nahezu jeder Prozess — das einzig nützliche Artefakt ist ein *unbenanntes* `KeyedEvent`-Handle in einem Prozess, der nichts mit Low-Level-Critical-Section-Infrastruktur zu tun hat. Selbst dann sind False Positives durch in-process-Allokatoren und Instrumentierungs-Bibliotheken hoch.

Direkte Syscall-Beispiele

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