NtCreateKeyedEvent

Prototipo

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

Argumentos

IDs de syscalls por versión de Windows

Stub del 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

Notas no documentadas

Los keyed events son una primitiva de sincronización de Windows deliberadamente minimalista: un único keyed event puede atender un número ilimitado de waiters porque el rendez-vous se hace sobre una *clave* (cualquier valor del tamaño de un puntero, convencionalmente una dirección virtual) en lugar de sobre el objeto event mismo. El kernel mantiene una tabla hash por event indexada por `(process, key)`; `NtWaitForKeyedEvent` bloquea hasta que *otro hilo* llama a `NtReleaseKeyedEvent` con la misma clave. En la práctica casi cada proceso usa la única instancia global en `\KernelObjects\CritSecOutOfMemoryEvent`, que `ntdll.dll` abre al arranque y guarda en `peb->KeyedEventHandle`. Crear un keyed event nuevo con `NtCreateKeyedEvent` es raro fuera de herramientas de diagnóstico y un puñado de allocators históricos (el event global maneja la contención desde Vista).

Uso común por malware

Señal débil. El atractivo principal para uso ofensivo es la *anonimidad*: un keyed event creado con `ObjectAttributes` NULL no produce objeto de kernel nombrado, ni handle de archivo, ni huella de red, y un sleep-mask o stage gate construido sobre `NtWaitForKeyedEvent` (emparejado a `NtReleaseKeyedEvent` desde un hilo par) es invisible a la enumeración de events / semáforos / mutexes nombrados que algunos detectores de sandbox ejecutan. Algunos diseños de obfuscación de sleep (familia Ekko / similares, ciertos Foliage / TimerHandler) usan el event global `\KernelObjects\CritSecOutOfMemoryEvent` como punto de sincronía en lugar de crear el suyo — esa ruta ni siquiera implica `NtCreateKeyedEvent`. Llamadas directas a `NtCreateKeyedEvent` desde código no-Microsoft son inusuales pero no condenatorias.

Oportunidades de detección

Esencialmente indetectable como syscall. No hay evento Sysmon para creación de keyed event y ningún proveedor ETW lo expone limpiamente. La enumeración forense vía `!handle` en WinDbg o la vista de handles de SystemInformer muestra objetos `KeyedEvent` por proceso, pero el event global lo tiene casi cada proceso, así que el único artefacto útil es un handle `KeyedEvent` *anónimo* en un proceso que no tiene nada que ver con infraestructura de critical section de bajo nivel. Aun así, los falsos positivos de allocators in-process y bibliotecas de instrumentación son altos.

Ejemplos de syscalls directos

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

Mapeos MITRE ATT&CK

• T1106Native APImitre ↗