Skip to content
Reverse Engineering
Anti-Analysisintermediate

Sleep Acceleration Detection

Sandboxes often patch Sleep() to fast-forward time so samples detonate quickly; malware detects the skipped delay by comparing wall-clock timestamps before and after sleeping.

To analyze samples fast, many sandboxes hook Sleep/NtDelayExecution and return immediately instead of waiting. Malware catches this by measuring how much real time actually elapsed across a long sleep.

Check

c
ULONGLONG t0 = GetTickCount64();
Sleep(60 * 1000);                 // ask for 60s
ULONGLONG elapsed = GetTickCount64() - t0;
if (elapsed < 55 * 1000) {
    // Sleep was skipped → likely an instrumented sandbox.
}

At the instruction level the sample snapshots the tick count, sleeps, then subtracts and compares the real elapsed time against the requested delay:

asm
call    GetTickCount            ; t0 -> eax
mov     ebx, eax               ; stash start tick
mov     ecx, 60000             ; 60000 ms requested
call    Sleep
call    GetTickCount            ; t1 -> eax
sub     eax, ebx               ; elapsed = t1 - t0
cmp     eax, 55000             ; less than 55s really passed?
jb      sandbox_detected       ; sleep was skipped -> instrumented sandbox

Variants compare GetSystemTimeAsFileType, QueryPerformanceCounter, or NtQuerySystemTime deltas, which sandboxes may forget to keep consistent with the patched Sleep.

Analysis tips

  • Hook the timing APIs to keep clocks coherent with patched sleeps.
  • Flag a long Sleep immediately followed by a tick-count comparison and a conditional bail-out.
Votes

Comments(0)