Malware that checks whether it is being watched behaves innocently in the sandbox and runs its real payload on the laptop next door. MITRE ATT&CK T1497 Virtualization/Sandbox Evasion covers the checks adversaries use to recognise virtual machines and analysis environments and then disengage, hide core functions or withhold later payloads. ATT&CK v20 places it in both the Stealth (TA0005) and Discovery (TA0007) tactics for Linux, macOS and Windows, with three sub-techniques: System Checks, User Activity Based Checks and Time Based Checks. This guide explains each, the detection strategies MITRE maps to them on real endpoints, how to reduce what a sandbox gives away, and how to measure whether evasion is beating your analysis pipeline. It is for detection engineers, malware analysts and SOC leads, and covers defence only.
Key takeaways
- Evasion is also discovery. The checks are system discovery run by the malware itself (WMI, registry, process and hardware queries), so they leave telemetry on every real host where the sample runs.
- It is widespread in commodity malware. In the ATT&CK v20 dataset System Checks (T1497.001) alone is linked to 7 groups, 2 campaigns and 63 software entries, including loaders such as GuLoader, QakBot and Bumblebee.
- A clean sandbox verdict is weak evidence. "Nothing happened" may mean the sample detected the environment; treat inconclusive results as a reason to look further, not as benign.
- Detect the burst, not one query. A single CPU count or BIOS query is normal. A short burst of virtualisation-related queries from a new process, then exit or a delayed network connection, is the pattern.
- Layer analysis with endpoint behaviour. Sandboxes catch what detonates; EDR on real hosts catches what waited for a real user. You need both.
What T1497 covers
ATT&CK describes adversaries checking for artefacts that indicate a virtual machine environment or sandbox and, if found, disengaging from the victim, concealing the implant's core functions, or holding back secondary payloads. The information may also shape follow-on behaviour during automated discovery.
| Sub-technique (v20) | What the malware checks | Examples recorded by ATT&CK |
|---|---|---|
| T1497.001 System Checks | VM artefacts in memory, processes, files, hardware and registry; host and domain name; network adapter addresses; CPU core count, memory and disk size; analysis-style file names such as sample or malware; fan, temperature and audio devices | Volt Typhoon running checks for a virtualised environment; Lazarus Group tools in Operation Dream Job checking for sandboxes and VMware services; GuLoader checking for a QEMU guest agent; Mini Shai-Hulud exiting on hosts with too few CPUs |
| T1497.002 User Activity Based Checks | Mouse movement speed and clicks, browser history and bookmarks, number of files in home or desktop folders, waiting for a document to close or a double click | Darkhotel checking cursor position repeatedly; FIN7 lures that activate only on double click of an embedded image; TONESHELL comparing foreground window handles |
| T1497.003 Time Based Checks | Uptime, system clock, GetTickCount and GetSystemTimeAsFileTime before and after a sleep to spot time acceleration | SUNBURST staying dormant for up to two weeks; RansomHub sleeping before execution |
Pure waiting, such as sleep calls and ping loops, is now its own technique, T1678 Delay Execution; see the MITRE ATT&CK T1678 Delay Execution guide for those analytics. Checks that target a specific victim (domain name, locale, keyed payloads) are mapped to T1480 Execution Guardrails. This page focuses on environment and user checks.
Variants worth knowing
- Decoy payloads: ATT&CK records Raspberry Robin carrying real and fake second stages and delivering the real one only when it decides it is not virtualised, so the sandbox report shows the decoy.
- Probability gates: ATT&CK records Mini Shai-Hulud applying a one-in-six random gate before triggering its wiper, so repeated detonations may show nothing. See the Mini Shai-Hulud 2026 SAP npm packages breach page.
- Asking the victim to remove isolation: ATT&CK records Contagious Interview asking targets to disable Docker and other container environments so that the payload runs on the host. See the Contagious Interview Threat Actor Profile.
Detection on real endpoints
ATT&CK v20 maps DET0046 to the parent, DET0168 to System Checks, DET0420 to User Activity Based Checks and DET0141 to Time Based Checks. The table summarises MITRE's analytics.
| Platform | Strategy and analytic | Signals and log sources |
|---|---|---|
| Windows | DET0168 AN0478, DET0046 AN0127 | Sysmon 1 for a rapid sequence of discovery commands or scripts (CPU, RAM, registry keys, running processes, WMI classes such as Win32_ComputerSystem or Win32_BIOS), Sysmon 7 for unusual DLL loads, Sysmon 10 for process access |
| Linux | DET0168 AN0479, DET0046 AN0128 | auditd EXECVE of dmidecode, lspci, lscpu, dmesg and systemd-detect-virt in quick succession, and reads of /sys/class/dmi/id/product_name |
| macOS | DET0168 AN0480, DET0046 AN0129 | Unified log execution of system_profiler, ioreg, kextstat or sysctl queries for hardware model, combined with delays or unusual launchd activity |
| Windows (user checks) | DET0420 AN1182 | Process probing desktop files or registry history shortly after logon or unlock (Security 4800 and 4801), with Sysmon 1 and 10 |
| Linux and macOS (user checks) | DET0420 AN1183, AN1184 | Reads of ~/.bash_history, browser profiles, Safari bookmarks or /dev/input; input-state API use such as CGEventSourceKeyState |
| All (time checks) | DET0141 | Delays followed by sensitive access, file creation or network connections; see the T1678 guide |
systemd-detect-virt is a legitimate tool that reports which virtualisation or container technology a Linux system runs in, and returns exit code 0 when one is detected. Configuration management and monitoring agents call it routinely, so baseline its parents before alerting on it.
Detections to build first
- Discovery burst from a new binary: five or more virtualisation-related queries (BIOS vendor, disk model, MAC prefix lookups, VM tool processes or services, hypervisor registry keys) within a short window from a process first seen in the estate in the last week.
- Office or script host doing hardware discovery: WMI hardware or BIOS queries from
winword.exe,excel.exe,wscript.exe,mshta.exeor a PowerShell child of them. - User-artefact probing by a non-browser: counts of recent documents, desktop files or browser history read by a process that is not a browser, backup or indexing tool.
- Query then exit: a short-lived process that performs discovery and exits without creating windows or files. Correlate with the parent download or email.
- Linux virt checks from writable paths:
dmidecodeorsystemd-detect-virtlaunched by a binary in/tmp,/dev/shmor a home directory.
Making analysis environments harder to spot
Malware sandboxes and analysis VMs are the main target of T1497. The goal is to reduce the obvious artefacts and to stop treating silence as a result. Operating a sandbox safely is covered in the Malware Sandbox Guide; the points below are the evasion-specific ones.
- Realistic guests: enough CPU cores, memory and disk to look like a corporate laptop, a joined or plausible domain name, a lived-in user profile with documents, browser history and installed business software, and a recent uptime.
- Minimise analysis tooling inside the guest: keep monitoring outside the guest where the platform allows, and avoid analysis tool names in process lists, file paths and sample names. Rename samples to plausible business file names.
- Simulate a user: use the platform's human-interaction module to move the mouse, click dialogs, scroll documents and close them, which addresses T1497.002 lures.
- Bare metal or varied guests for high-value samples: run suspected evasive samples on a physical analysis host or several guest profiles and compare behaviour.
- Static and memory analysis alongside detonation: reverse engineering sees code paths that never ran. See the Ghidra for Malware Analysis Guide.
- Protect the platform itself: the sandbox holds live malware and analyst credentials. See Securing the sandbox and malware analysis platform itself.
Choosing an approach
| Approach | Strength against T1497 | Trade-off | Best fit |
|---|---|---|---|
| Commercial cloud sandbox | Vendor maintains anti-evasion guests and interaction | Samples leave your environment; limited guest customisation | Small and mid-size teams |
| Self-hosted open-source sandbox | Full control of guest images and profiles | Needs analyst time to keep guests realistic and patched | Teams with dedicated malware analysts |
| Bare-metal analysis host | Removes most hypervisor artefacts | Slow to reset, few samples per day | High-value or targeted samples |
| EDR telemetry on real hosts | Sees the payload that waited for a real user | Detection happens after execution on a production device | Everyone, as the backstop |
For deciding between services, see the Malware Sandboxes buyer's guide.
How to implement
- Measure the problem: pull 90 days of sandbox results and calculate the inconclusive rate by file type and source.
- Harden one guest profile: build a realistic profile, run the same sample set through old and new profiles, and compare behaviours observed.
- Deploy endpoint analytics in report-only: the five first-build detections above, for two to four weeks, suppressing known inventory, monitoring and virtual desktop agents.
- Route inconclusive verdicts: mail or web items with inconclusive sandbox results go to a hold or extra review queue rather than straight to users, with a time limit agreed with the business.
- Promote and test: enable alerting, then replay known evasive samples from your own case history in a controlled lab and confirm both sandbox and endpoint detections fire. Rollback is reverting the guest image or disabling the rule.
Detection and measurement
- Inconclusive rate: share of detonations with no meaningful behaviour, by file type. A rising trend signals evasion or stale guests.
- Sandbox-to-endpoint misses: samples rated clean or inconclusive that later triggered an endpoint detection. Each one is a tuning case.
- Profile diversity: number of guest profiles in use and their age since last rebuild.
- Rule coverage: sub-techniques (.001, .002, .003) with a tested endpoint detection on each platform.
- Time to verdict for held items: to keep the hold queue acceptable to the business.
Common failure patterns
- Treating a clean sandbox result as proof: evasive loaders are designed to produce exactly that result.
- Default guest images for years: the same small disk, two cores, default user name and no documents make the guest easy to recognise.
- No endpoint visibility for discovery: without Sysmon or EDR process and WMI telemetry, the checks that malware runs on real hosts go unrecorded.
- Single detonation: probability gates and decoy payloads mean one run is not enough for suspicious samples.
- Developers told to disable isolation: social engineering such as the Contagious Interview requests to turn off Docker works when staff do not know that is a red flag.
Responding when evasion is found
Finding environment checks in a sample or on a host changes how the case should be handled.
- Assume the payload ran somewhere: search endpoint telemetry for the same hash, parent document or download URL across the estate. A sample that hid in the sandbox may have executed fully on real hosts.
- Re-run with the gaps closed: detonate again on a realistic profile with interaction enabled, and on bare metal if available; record which checks the sample made so the guest can be fixed.
- Extract indicators statically: configuration, C2 addresses and second-stage URLs often sit in the binary even when they never ran. Feed them to blocking and hunting.
- Feed the lesson back: add the specific artefacts the sample looked for to the guest hardening backlog and the discovery-burst rule.
- Preserve evidence: keep the original sample, sandbox reports from each run and endpoint process trees for the hosts that ran it. See the Malware Analysis Guide for Defenders.
Where identity fits
Many evasive families are credential stealers and loaders. ATT&CK records Lumma Stealer checking user names and WMI system details to spot sandboxes, and the Mini Shai-Hulud worm stole publishing tokens from developer machines. When evasion hides the stealer from analysis, the first visible sign is often a token or session used from somewhere new. Pair sandbox and endpoint work with identity detections: rotate secrets found on affected hosts, revoke sessions and watch for anomalous use of developer and CI tokens. See the Infostealer Logs Monitoring and Response Guide.
Framework mapping
| Framework | References |
|---|---|
| ATT&CK | T1497, T1497.001, T1497.002, T1497.003 (Stealth TA0005, Discovery TA0007); related T1678, T1480, T1082, T1012, T1047, T1083 |
| ATT&CK mitigations | None listed in v20; this guide's controls are analysis and detection practices |
| NIST SP 800-53 Rev. 5 | SC-44 Detonation Chambers, SI-3 Malicious Code Protection, SI-4 System Monitoring, AU-6 Audit Record Review, Analysis, and Reporting |
| NIST CSF 2.0 | DE.CM-09 monitoring of software and runtime environments, DE.AE-02 analysis of adverse events |
| CIS Controls v8.1 | Control 8 Audit Log Management, Control 9 Email and Web Browser Protections, Control 10 Malware Defenses |
| MITRE D3FEND | D3-DA Dynamic Analysis, D3-PSA Process Spawn Analysis, D3-DE Decoy Environment |
Practitioner checklist
- Track sandbox inconclusive rate by file type every month.
- Rebuild guest images with realistic hardware, user profile and uptime, and rotate profiles.
- Enable human-interaction simulation for document and installer samples.
- Collect Sysmon 1, 7 and 10 and WMI activity on Windows, auditd EXECVE on Linux and unified log process events on macOS.
- Alert on discovery bursts from new binaries and from Office or script hosts.
- Hold or re-review inconclusive mail and web verdicts instead of releasing them.
- Detonate high-value suspicious samples more than once and on more than one profile.
- Tell developers that requests to disable containers or security tools are a phishing sign.
Standards and references
- MITRE ATT&CK: Virtualization/Sandbox Evasion (T1497)
- MITRE ATT&CK: System Checks (T1497.001)
- MITRE ATT&CK: User Activity Based Checks (T1497.002)
- MITRE ATT&CK: Time Based Checks (T1497.003)
- MITRE D3FEND: Dynamic Analysis
- Linux man-pages: systemd-detect-virt(1)
- NIST: SP 800-53 Rev. 5 (SC-44 Detonation Chambers)
Related NHI Mgmt Group resources: Malware Analysis Guide for Defenders · Malware Sandbox Guide · MITRE ATT&CK T1678 Delay Execution · MITRE ATT&CK for Mobile Guide · ATT&CK Stealth and Defense Impairment Tactics Guide