If malware can tell it is in an analysis environment, it can behave well until it is not. T1497, Virtualization/Sandbox Evasion, covers that. MITRE files it under both stealth and discovery, for Linux, macOS and Windows. It has three sub techniques: system checks, user activity based checks and time based checks.
How attackers use it
Adversaries may use various means to detect and avoid virtualization and analysis environments. That includes changing behavior based on checks for artifacts of a virtual machine environment or sandbox. If a virtual environment is found, they may alter the malware to disengage from the victim or conceal the core functions of the implant. They may also search for artifacts before dropping secondary payloads, and use what they learn during automated discovery to shape follow on behavior.
MITRE lists methods that include checking for security monitoring tools such as Sysinternals and Wireshark, looking for system artifacts linked to analysis or virtualization, checking for real user activity, and using sleep timers or loops to avoid operating inside a short lived sandbox.
MITRE's procedure examples include malware that performs anti sandbox and anti virtualization checks, malware that checks whether the system runs on VMware, and a loader that delivers a fake second stage payload and only delivers the real one when it decides it is not in a virtual environment.
How to detect it
MITRE's detection strategy has one analytic per platform.
- Windows: discovery commands or API calls that look for virtualization artifacts such as registry keys, device drivers or services, as well as sleep or skipped execution behavior and sandbox evasion DLLs, before a payload is deployed.
- Linux: commands that enumerate virtualization related files or processes, for example DMI product data, dmesg, lscpu and lspci, or that query hypervisor interfaces before malware runs.
- macOS: scripts or binaries that check for virtualization indicators, for example system_profiler, ioreg and kextstat, paired with delay functions or unusual launchd activity.
MITRE does not name log sources. The analytics center on command execution and API call activity. Process creation logs with command lines are your main source.
The signal is a burst of hardware and system queries from a process that has no business asking, often right before it does nothing at all.
How to reduce the risk
MITRE says this technique is difficult to mitigate with preventive controls because it abuses normal system features. The defender's work is to make analysis more realistic and to detect what follows.
- Make your analysis sandbox look like a real workstation, with realistic hardware values, files, history and uptime. Evasion checks target the gaps.
- Run analysis for longer, and handle sleep calls rather than waiting through them.
- Pair sandbox verdicts with endpoint behavior detection. A sample that looks clean in a sandbox can still behave badly on a real host.
- Treat a sample that does nothing as suspicious, not as clean.
Check your own environment
- Compare your sandbox against a real endpoint on CPU count, memory, disk size, and installed software.
- Check whether your sandbox simulates user activity such as mouse movement and document interaction.
- Confirm your sandbox timeout is long enough to outlast common sleep delays.
- Confirm process creation logging captures command lines on endpoints.
Quick check
How does evasion shape the malware's behavior?
If a virtual environment is detected, malware may disengage, hide core functions or withhold secondary payloads.
Why is a quiet sample not proof of safety?
It may have detected analysis and chosen not to act.
What are the three sub techniques?
System checks, user activity based checks and time based checks.
