NtWaitForSingleObject

Prototype

NTSTATUS NtWaitForSingleObject(
  HANDLE         Handle,
  BOOLEAN        Alertable,
  PLARGE_INTEGER Timeout
);

Arguments

Syscall IDs by Windows version

Syscall stub

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

Undocumented notes

Dispatches through `KeWaitForSingleObject` inside ntoskrnl.exe. SSN `0x04` is stable across every Win10/11 build — one of the most stable in the table. The `Alertable` flag is the linchpin: a non-alertable wait blocks only on the object, while an alertable wait additionally drains pending user APCs and returns `STATUS_USER_APC` (0x000000C0) when one fires. That is precisely why APC-injection chains (T1055.004) require the target thread to perform an alertable wait somewhere. Timeout is in NT 100-ns units; `LARGE_INTEGER` negative values are relative (e.g. `-10000000LL` == 1 second).

Common malware usage

Two completely different abuses share this syscall. (1) Alertable waits are the *delivery vehicle* for queued user APCs — Ekko sleep masks wait alertably on the event signaled by their timer APC; EarlyBird APC injection relies on `ntdll!LdrpInitializeProcess` performing an alertable wait. (2) Short-timeout polling on a synthetic handle is a cheap **anti-sandbox / time-acceleration probe**: malware compares wall-clock delta to expected wait duration; sandboxes that fast-forward sleeps fail the check. Some loaders also wait on a thread handle to serialize multi-stage decryption.

Detection opportunities

Wait calls are pervasive; raw counts are useless. The interesting signal is the *combination* of `NtWaitForSingleObject(..., Alertable=TRUE, ...)` on a handle whose object is a private-named event, performed by a thread whose code lies in unbacked / RWX memory — that is the Ekko / Foliage fingerprint. ETW Threat Intelligence does not emit a wait event but does emit the QueueApc event that pairs with it; correlating QueueApc to a subsequent alertable wait return in the same thread catches APC chains. Stack-walk on wait return is the gold standard.

Direct syscall examples

; Direct syscall stub for NtWaitForSingleObject (SSN 0x04, stable across Win10/11)
NtWaitForSingleObject PROC
    mov  r10, rcx          ; syscall convention
    mov  eax, 04h          ; SSN
    syscall
    ret
NtWaitForSingleObject ENDP

// Block alertably on an event until either it signals or a queued APC fires.
NTSTATUS st;
do {
    st = NtWaitForSingleObject(hEvent, TRUE, NULL); // NULL == INFINITE
} while (st == STATUS_USER_APC); // re-enter wait after the APC ran
if (!NT_SUCCESS(st)) return st;

// Cargo: windows-sys = "0.59"
use windows_sys::Win32::System::Threading::{WaitForSingleObjectEx, INFINITE};
use std::time::Instant;

unsafe fn sandbox_speeds_up_sleeps(h_event: *mut core::ffi::c_void) -> bool {
    let start = Instant::now();
    // Wait 3s alertably on a never-signalled event.
    let _ = WaitForSingleObjectEx(h_event, 3000, 1);
    start.elapsed().as_millis() < 2500
}

MITRE ATT&CK mappings

• T1055.004Asynchronous Procedure Callmitre ↗
• T1497Virtualization/Sandbox Evasionmitre ↗
• T1106Native APImitre ↗