NtWaitForSingleObject

Prototyp

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

Argumente

Syscall-IDs pro 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

Undokumentierte Hinweise

Dispatcht über `KeWaitForSingleObject` in ntoskrnl.exe. SSN `0x04` ist über jeden Win10/11-Build stabil — eine der stabilsten der Tabelle. Das `Alertable`-Flag ist der Schlüssel: ein nicht-alertable Wait blockiert nur am Objekt, während ein alertable Wait zusätzlich anstehende User-APCs abarbeitet und beim Feuern eines APC `STATUS_USER_APC` (0x000000C0) zurückgibt. Genau deshalb verlangen APC-Injection-Ketten (T1055.004), dass der Zielthread irgendwo einen alertable Wait ausführt. Das Timeout liegt in NT-100-ns-Einheiten vor; negative `LARGE_INTEGER`-Werte sind relativ (z. B. `-10000000LL` == 1 Sekunde).

Häufige Malware-Nutzung

Zwei völlig verschiedene Missbräuche teilen sich diesen Syscall. (1) Alertable Waits sind das *Zustellfahrzeug* für eingereihte User-APCs — Ekko-Sleep-Masks warten alertable auf das vom Timer-APC signalisierte Event; EarlyBird-APC-Injection setzt darauf, dass `ntdll!LdrpInitializeProcess` einen alertable Wait durchführt. (2) Polling mit kurzem Timeout auf einem synthetischen Handle ist eine billige **Anti-Sandbox-/Zeitbeschleunigungssonde**: Malware vergleicht den Wall-Clock-Delta mit der erwarteten Wartezeit; Sandboxes, die Sleeps vorspulen, fallen durch. Manche Loader warten zudem auf ein Thread-Handle, um eine mehrstufige Entschlüsselung zu serialisieren.

Erkennungs­möglichkeiten

Wait-Aufrufe sind allgegenwärtig; reine Zählungen nützen nichts. Das interessante Signal ist die *Kombination* `NtWaitForSingleObject(..., Alertable=TRUE, ...)` auf ein Handle, dessen Objekt ein privates benanntes Event ist, ausgeführt von einem Thread, dessen Code in nicht-gemapptem / RWX-Speicher liegt — das ist der Ekko-/Foliage-Fingerabdruck. ETW Threat Intelligence emittiert kein Wait-Event, aber das QueueApc-Event, das damit zusammengeht; eine Korrelation von QueueApc mit einem nachfolgenden alertable-Wait-Return im selben Thread fängt APC-Ketten ab. Stack-Walk beim Wait-Return ist der Goldstandard.

Direkte Syscall-Beispiele

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