NtReleaseKeyedEvent

Prototype

NTSTATUS NtReleaseKeyedEvent(
  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 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

Notes non documentées

La moitié wake de la paire keyed event, et fameusement *symétrique* de `NtWaitForKeyedEvent` : une release sans waiter correspondant bloque l'appelant jusqu'à ce qu'un waiter apparaisse, plutôt que de perdre le réveil comme le ferait un event ordinaire. C'est ce qui rend la primitive correcte pour le chemin out-of-pool de `RtlEnterCriticalSection` — releases et waits s'auto-régulent, si bien qu'un seul event global gère une contention illimitée sans perdre de réveils. Le handler noyau est `ExpReleaseWaitForKeyedEvent` (minuscule inverse de `ExpWaitForKeyedEvent`) ; tous deux consultent la table de hachage par event appariant les tuples `(process, key)`.

Usage courant par les malwares

Miroir de `NtWaitForKeyedEvent`. Dans les chaînes d'obfuscation de sommeil, c'est ce syscall qui *réveille le beacon* après que le sleep mask se soit déprotégé et déchiffré. Certains designs l'invoquent depuis un APC livré par un callback `NtSetTimer2`, d'autres depuis un gadget ROP enchaîné sur un faux contexte — quoi qu'il en soit, le handle global sur le PEB fait qu'aucun nouvel objet nommé n'est touché. Hors de ce pattern très étroit, les appels à `NtReleaseKeyedEvent` depuis du code non Microsoft sont quasi inexistants.

Opportunités de détection

Identique à `NtWaitForKeyedEvent` — pas de surface ETW / Sysmon ciblée. Les ETW d'introspection mémoire (événements `AllocVm` / `ProtectVm` du provider `Microsoft-Windows-Threat-Intelligence`) saisissant un flip RW→RX sur des pages privées *immédiatement suivi* d'un thread sortant de `NtWaitForKeyedEvent` constituent une piste bien plus forte que tracer ce syscall isolément.

Exemples de syscalls directs

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

Mappings MITRE ATT&CK

• T1027Obfuscated Files or Informationmitre ↗
• T1106Native APImitre ↗