NtDelayExecution

Prototyp

NTSTATUS NtDelayExecution(
  BOOLEAN        Alertable,
  PLARGE_INTEGER DelayInterval
);

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

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

Die Win32-APIs `Sleep` und `SleepEx` sind dünne Wrapper um `NtDelayExecution`. Der SSN ist über alle ausgelieferten Win10/11-Builds hinweg `0x34` geblieben — eine der vorhersagbarsten Syscall-Nummern im User-Mode. Kernelseitig läuft der Handler über `KeDelayExecutionThread` und blockiert letztlich am Timer-Dispatcher. Ein Aufruf mit relativem Nullintervall oder NULL gibt den Rest des Quants ab — entspricht `SwitchToThread()`.

Häufige Malware-Nutzung

Kanonische Anti-Sandbox- / Time-Based-Evasion-Primitive (MITRE T1497.003). Lange, nicht-alertable Sleeps (5–30 min) überdauern das Analysefenster automatisierter Sandboxes, die ein Sample nur 1–2 Minuten beobachten. Moderne Sleep-Mask-Frameworks (Ekko, Foliage, Cronos, Cobalt Strikes Sleep Mask Kit, Brute Ratel C4) klammern `NtDelayExecution` zwischen Verschlüsselung und Entschlüsselung: `.text` und Heap des Beacons werden in-place verschlüsselt, `NtDelayExecution` aufgerufen, beim Aufwachen wieder entschlüsselt — ein Memory-Scan im Schlaf sieht nur Chiffrat. In Kombination mit ungehooktem / gepatchten `ntdll!NtDelayExecution` (direkter oder indirekter Syscall) umgeht der Aufruf auch User-Mode-EDR-Hooks während der Ruhezeit.

Erkennungs­möglichkeiten

Detektion ist schwer, weil `Sleep` allgegenwärtig ist. Hilfreich: ungewöhnlich lange Sleeps aus nicht-interaktiven Prozessen; Schleifen `NtQuerySystemTime` → `NtDelayExecution` (klassischer Sandbox-Zeit-Skip-Check); Thread-Stack-Snapshots, in denen die Rücksprungadresse in RWX/Private-Memory statt in einem geladenen Modul liegt (Signatur eines schlafenden Beacons). Die ETW-Provider `Microsoft-Windows-Kernel-Process` und Threat Intelligence liefern Wait-Reasons. EDR-Hersteller snapshotten zunehmend RX-Private-Memory in festen Intervallen, gerade um Sleep-Mask-Implants zwischen Encrypt/Decrypt-Zyklen zu fangen.

Direkte Syscall-Beispiele

; Direct syscall stub for NtDelayExecution (SSN 0x34, all Win10/11 builds)
NtDelayExecution PROC
    mov  r10, rcx          ; syscall convention
    mov  eax, 34h          ; SSN
    syscall
    ret
NtDelayExecution ENDP

// Sleep 10 s of wall time, verify the kernel actually slept that long.
// Sandboxes that patch Sleep / accelerate timers will return early.
#include <windows.h>
#include <winternl.h>

extern "C" NTSTATUS NTAPI NtDelayExecution(BOOLEAN, PLARGE_INTEGER);
extern "C" NTSTATUS NTAPI NtQuerySystemTime(PLARGE_INTEGER);

BOOL LooksLikeSandbox(void) {
    LARGE_INTEGER t0, t1, delay;
    NtQuerySystemTime(&t0);
    delay.QuadPart = -10LL * 10000000LL;       // 10 s, relative
    NtDelayExecution(FALSE, &delay);
    NtQuerySystemTime(&t1);
    LONGLONG elapsedSec = (t1.QuadPart - t0.QuadPart) / 10000000LL;
    return elapsedSec < 9;                      // sandbox skipped the sleep
}

// Cargo: windows-sys = "0.59"
use std::arch::asm;

#[unsafe(naked)]
unsafe extern "system" fn nt_delay_execution(
    _alertable: u8,
    _interval: *const i64,
) -> i32 {
    asm!(
        "mov r10, rcx",
        "mov eax, 0x34",
        "syscall",
        "ret",
        options(noreturn),
    );
}

pub fn sleep_seconds(s: i64) {
    // 100 ns units, negative = relative
    let interval: i64 = -s * 10_000_000;
    unsafe { nt_delay_execution(0, &interval as *const _); }
}

MITRE ATT&CK-Mappings

• T1497Virtualization/Sandbox Evasionmitre ↗
• T1497.003Time Based Evasionmitre ↗
• T1027.011Fileless Storagemitre ↗
• T1106Native APImitre ↗