NtWaitForSingleObject

Prototype

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

Arguments

IDs de syscalls par version de Windows

Stub du syscall

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

Notes non documentées

Passe par `KeWaitForSingleObject` dans ntoskrnl.exe. La SSN `0x04` est stable sur chaque build Win10/11 — l'une des plus stables de la table. Le flag `Alertable` est l'élément clé : un wait non-alertable bloque uniquement sur l'objet, tandis qu'un wait alertable draine en plus les APC utilisateur en attente et renvoie `STATUS_USER_APC` (0x000000C0) lorsqu'un APC s'exécute. C'est précisément pour cela que les chaînes d'injection APC (T1055.004) requièrent que le thread cible effectue un wait alertable. Le timeout est en unités NT de 100 ns ; les valeurs `LARGE_INTEGER` négatives sont relatives (ex. `-10000000LL` == 1 seconde).

Usage courant par les malwares

Deux abus totalement différents partagent ce syscall. (1) Les waits alertables sont le *vecteur de livraison* des APC utilisateur — les sleep masks à la Ekko attendent alertablement sur l'événement signalé par leur APC de timer ; l'injection EarlyBird APC repose sur le wait alertable effectué par `ntdll!LdrpInitializeProcess`. (2) Le polling court sur un handle synthétique est une **sonde anti-sandbox / d'accélération du temps** : le malware compare le delta wall-clock à la durée d'attente attendue ; les sandboxes qui accélèrent les sleeps échouent au contrôle. Certains loaders attendent aussi un handle de thread pour sérialiser un déchiffrement multi-étapes.

Opportunités de détection

Les appels wait sont omniprésents ; les comptes bruts sont inutiles. Le signal intéressant est la *combinaison* `NtWaitForSingleObject(..., Alertable=TRUE, ...)` sur un handle dont l'objet est un événement nommé privé, effectué par un thread dont le code est en mémoire non-backed / RWX — c'est l'empreinte Ekko / Foliage. ETW Threat Intelligence n'émet pas d'événement wait mais émet l'événement QueueApc qui s'y associe ; corréler QueueApc à un retour de wait alertable suivant dans le même thread attrape les chaînes APC. Le stack-walk au retour du wait est l'étalon-or.

Exemples de syscalls directs

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

Mappings MITRE ATT&CK

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