Lion Cipher Lab
Recognize malware's anti-analysis tricks: debugger, VM, sandbox, and timing checks
- Digital Forensics & IR (DFIR)
- Advanced
- ~50 min
- Free · no account required
Why it matters
Modern malware assumes it will be caught in an automated sandbox, so the first thing it does is look around and ask 'am I being watched?' If the answer is yes, it behaves — it does nothing interesting, exits quietly, or runs a harmless decoy — and the sandbox report comes back clean. An analyst who takes that clean report at face value has been played: the sample didn't fail to do anything, it detected the box and hid. Learning to read the anti-analysis code itself — the debugger checks, the VM tells, the timing traps — lets you recognize evasion for what it is, know that a silent sample is a…
What you'll learn
- recognizing debugger-detection code (IsDebuggerPresent, CheckRemoteDebuggerPresent, PEB BeingDebugged)
- spotting VM/sandbox detection: VMware/VirtualBox artifacts, MAC OUI, registry keys, low core/RAM checks
- reading timing checks (RDTSC and GetTickCount deltas) that catch single-stepping and acceleration
- identifying analysis-tool process enumeration (procmon, Wireshark, x64dbg, OllyDbg)
- reading environment fingerprinting (username, file count, uptime) that flags a sandbox
- the judgment that 'no behavior' in a sandbox usually means evasion succeeded, not that the sample is clean
- mapping evasion behavior to MITRE ATT&CK T1622, T1497, T1057
- deciding when static recognition is enough vs when you must defeat the checks dynamically
Steps in this lab
- The scenario: a 'clean' sandbox report that should worry you
- Artifact 1 — debugger detection (T1622)
- Artifact 2 — VM and sandbox detection (T1497)
- Artifact 3 — timing checks (T1497.003)
- Artifact 4 — analysis-tool process enumeration (T1057)
- Artifact 5 — environment fingerprinting (T1497.001)
- Put it together: read the control flow, not the verdict
- The third rule: when recognition is enough, and how a pro defeats these