NtWaitForAlertByThreadId

Prototipo

NTSTATUS NtWaitForAlertByThreadId(
  PVOID          Address,
  PLARGE_INTEGER Timeout
);

Argumentos

IDs de syscalls por versión de Windows

Stub del syscall

4C 8B D1            mov r10, rcx
B8 E3 01 00 00      mov eax, 0x1E3
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

Contraparte de `NtAlertThreadByThreadId`. El argumento `Address` *no* lo desreferencia el kernel — es solo una clave de hash que se enruta a la wait table del EPROCESS (KiWaitChainList / RtlpHashAddress). Cuando se invoca `NtAlertThreadByThreadId` con el TID correspondiente, el kernel recorre el bucket, encuentra el hilo coincidente y lo señala. El hashing por dirección habilita la semántica sin objeto barata de `WaitOnAddress`. El rango de SSN (0x1B3 → 0x1E3) es de los más volátiles de ntoskrnl — se mueve casi en cada actualización mayor porque está al final de la SST y la tabla crece detrás.

Uso común por malware

Lo usan las implementaciones modernas de sleep-mask (estilo Ekko y sucesoras) que quieren una primitiva de espera *no* respaldada por un objeto Event/Mutex. Aparque el hilo beacon dormido en este syscall con timeout largo; señale con `NtAlertThreadByThreadId` cuando llegue trabajo. Sin entrada `\BaseNamedObjects\…`, sin handle visible en la vista de handles de System Informer, sin evento `Microsoft-Windows-Kernel-Object` de creación. Combinado con un polling estilo `WaitOnAddress` sobre una palabra de estado, el implante puede pasarse por cualquier proceso Win32 moderno con SRWLOCK o los nuevos internals de std::mutex. El volumen legítimo lo convierte en mal objetivo primario de detección — y por eso atractivo para autores.

Oportunidades de detección

Microsoft-Windows-Threat-Intelligence no emite evento por llamada. La única anomalía realista es *frecuencia × contexto*: un hilo que pasa la mayor parte del tiempo en `NtWaitForAlertByThreadId` con timeout relativo no NULL, en un proceso con egress de red, mapping RX-only, creado por un hijo de explorer.exe o de una app Office. Los escáneres de memoria (Moneta, Hunt-Sleeping-Beacons) atrapan la región RX circundante; el syscall solo es colorido. Los EDR a veces marcan el patrón de llamada inusual (alert/wait desde DLL no sistema) pero los falsos positivos son altos porque runtimes C++ modernos usan la misma ruta.

Ejemplos de syscalls directos

// Park a worker thread until a partner calls NtAlertThreadByThreadId
// with our TID. No event handle ever exists.
typedef NTSTATUS(NTAPI* fnWait)(PVOID, PLARGE_INTEGER);

void ParkWorker(volatile LONG* statusWord, ULONGLONG ns100) {
    HMODULE n = GetModuleHandleA("ntdll.dll");
    fnWait p = (fnWait)GetProcAddress(n, "NtWaitForAlertByThreadId");
    LARGE_INTEGER t;
    t.QuadPart = -(LONGLONG)ns100; // relative timeout
    p((PVOID)statusWord, &t);
}

; SSN 0x1E3 on win11-24h2 / winserver-2025. Moves on nearly every feature update.
NtWaitForAlertByThreadId PROC
    mov  r10, rcx
    mov  eax, 1E3h
    syscall
    ret
NtWaitForAlertByThreadId ENDP

// Park between beacon cycles using the address of a status word as hash key.
use windows_sys::Win32::System::LibraryLoader::{GetModuleHandleA, GetProcAddress};

type NtWaitForAlertByThreadId = unsafe extern "system" fn(addr: *mut u8, to: *mut i64) -> i32;

pub unsafe fn park(status: *mut u32, hundred_ns: i64) -> i32 {
    let n = GetModuleHandleA(b"ntdll.dll\0".as_ptr());
    let addr = GetProcAddress(n, b"NtWaitForAlertByThreadId\0".as_ptr()).unwrap();
    let f: NtWaitForAlertByThreadId = std::mem::transmute(addr);
    let mut t: i64 = -hundred_ns;
    f(status as *mut u8, &mut t)
}

Mapeos MITRE ATT&CK

• T1106Native APImitre ↗
• T1027Obfuscated Files or Informationmitre ↗