NtReleaseKeyedEvent

Prototyp

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

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

4C 8B D1            mov r10, rcx
B8 7D 01 00 00      mov eax, 0x17D
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 Wake-Hälfte des Keyed-Event-Paares und bekanntlich *symmetrisch* zu `NtWaitForKeyedEvent`: Eine Release ohne passenden Waiter blockiert den Aufrufer, bis ein Waiter erscheint, anstatt den Wake wie ein normales Event zu verwerfen. Genau das macht die Primitive korrekt für `RtlEnterCriticalSection`s Out-of-Pool-Pfad — Releases und Waits drosseln sich gegenseitig, sodass ein einziges globales Event unbegrenzte Contention bedient, ohne Wakes zu verlieren. Kernel-Handler ist `ExpReleaseWaitForKeyedEvent` (winzige Umkehrung von `ExpWaitForKeyedEvent`); beide konsultieren die Per-Event-Hashtabelle, die `(Process, Key)`-Tupel paart.

Häufige Malware-Nutzung

Spiegelbild von `NtWaitForKeyedEvent`. In Sleep-Obfuscation-Ketten ist dies der Syscall, der *den Beacon weckt*, nachdem die Sleep-Mask sich entschützt und entschlüsselt hat. Manche Designs rufen ihn aus einem APC, das von einem `NtSetTimer2`-Callback geliefert wird, andere aus einem ROP-Gadget über einen gefälschten Kontext — so oder so wird durch das globale Handle im PEB kein neues benanntes Objekt angefasst. Außerhalb dieses sehr engen Musters sind Aufrufe von `NtReleaseKeyedEvent` aus Nicht-Microsoft-Code praktisch nicht vorhanden.

Erkennungs­möglichkeiten

Wie `NtWaitForKeyedEvent` — keine gezielte ETW-/Sysmon-Oberfläche. Memory-Introspection-ETW (`AllocVm`/`ProtectVm`-Events des Providers `Microsoft-Windows-Threat-Intelligence`), die einen RW→RX-Flip auf privaten Pages *unmittelbar gefolgt von* einem Thread, der `NtWaitForKeyedEvent` verlässt, einfangen, ist eine deutlich stärkere Spur als das isolierte Tracing dieses Syscalls.

Direkte Syscall-Beispiele

; Direct syscall stub for NtReleaseKeyedEvent (SSN 0x17D on Win11 24H2)
NtReleaseKeyedEvent PROC
    mov  r10, rcx          ; KeyedEventHandle
    mov  eax, 17Dh         ; SSN — drifts per build
    syscall
    ret
NtReleaseKeyedEvent ENDP

// Companion to the NtWaitForKeyedEvent low-memory critical-section example.
#include <windows.h>
#include <winternl.h>

typedef NTSTATUS (NTAPI *pNtReleaseKeyedEvent)(
    HANDLE, PVOID, BOOLEAN, PLARGE_INTEGER);

static pNtReleaseKeyedEvent g_release;

void WakeOnLockWord(volatile void **lockSlot) {
    if (!g_release) {
        g_release = (pNtReleaseKeyedEvent)GetProcAddress(
            GetModuleHandleA("ntdll.dll"), "NtReleaseKeyedEvent");
    }
    // NULL handle ⇒ kernel substitutes peb->KeyedEventHandle.
    // If no waiter exists yet, this call blocks until one shows up — that
    // symmetry is what keeps the global event correct under contention.
    g_release(NULL, (PVOID)lockSlot, FALSE, NULL);
}

// On Win8+ this is the preferred user-mode wake primitive; underneath it
// resolves to keyed-event releases for the futex-style address path.
use windows_sys::Win32::System::Threading::WakeByAddressSingle;

unsafe fn wake_one(addr: *mut u32) {
    WakeByAddressSingle(addr as *const _ as _);
}

MITRE ATT&CK-Mappings

• T1027Obfuscated Files or Informationmitre ↗
• T1106Native APImitre ↗