Virtual machines transformed malware analysis. They made suspicious files cheap to detonate, easy to reset and relatively safe to contain. But malware learned the trick too.
Increasingly, a sample that appears harmless inside a sandbox may simply have decided that the computer running it looks wrong.
The response in serious analysis pipelines has not been to abandon the sandbox. It has been to put physical hardware back behind it, as a second stage that runs only when the first stage produces something suspicious in its silence.
Sandbox evasion has its own ATT&CK technique
MITRE ATT&CK classifies this behaviour as T1497, Virtualization/Sandbox Evasion, with sub-techniques covering system checks, user activity based checks and time based checks.
Those categories are worth taking literally, because they map onto three quite different things a sample can look at.
System checks are the cheapest detections to implement, and they are also the easiest to enumerate, because almost all of them come down to reading a value the platform hands over voluntarily.
The table below sets out the main ones, from the instruction-level check that costs a single opcode through to the long tail of artefacts left behind by the guest tooling.
| Check | Where it lives | What it reveals |
| Hypervisor present bit | CPUID leaf 0x01, ECX bit 31 | Whether a hypervisor is present at all. The canonical starting point on x86. |
| Hypervisor vendor string | CPUID leaf 0x40000000 | Names the hypervisor outright: VMwareVMware, KVMKVMKVM, XenVMMXenVMM, VBoxVBoxVBox, Microsoft Hv |
| Guest addition drivers and services | Running services, loaded drivers, installed file paths | Presence of the vendor’s guest tooling, which is installed on analysis images almost by default |
| SMBIOS strings | Firmware tables (system manufacturer, product name, BIOS vendor) | A hypervisor vendor’s name carried in the virtual firmware |
| Registry strings | Windows registry keys covering disks, system BIOS and installed software | The same vendor names, persisted where the OS records its own hardware |
| Virtual device names | Device enumeration (disk controllers, display and network adapters) | Emulated hardware that does not correspond to any physical product |
| MAC address prefixes | Network adapter configuration | OUI ranges assigned to virtualisation vendors, which map straight back to the platform |
None of this is subtle, and that is rather the point. Every item above is documented, most analysts already recognise them on sight, and each one can be suppressed or spoofed by an operator who has taken the trouble to harden their environment.
Their value lies in cost rather than robustness: a handful of reads that will still catch a large share of samples running on default images, which is why they remain the first thing to look for.
Time based checks exploit the fact that virtualisation is not free. Instructions that trap to the hypervisor take far longer than they do on hardware, so a sample can time a sequence of them, compare the result against a clock it trusts, and infer that something is intercepting.
User activity based checks are the hardest for a lab to defeat, because they are not about the hypervisor at all.
Real endpoints carry browser history, half-finished documents, drivers for a printer someone owned three jobs ago, recently used file lists, several user accounts and months of accumulated mess.
A freshly built analysis VM looks like a lab specimen. The absence of wear is itself the signal.
The prevalence figures and their limits
The scale of this is measurable, and it has been measured. Kirat, Vigna and Kruegel’s BareCloud built a transparent bare-metal analysis system and compared each sample’s behaviour there against its behaviour in emulated, virtualised and hypervisor-based environments.
Across 110,005 samples in their large-scale experiment, 5,835 were identified as evasive, about 5.3 percent.
That figure should not be treated as a universal prevalence rate. It reflects one corpus, one set of analysis environments and one detection method, and evasion rates in any given feed will depend heavily on where the samples came from.
What it does establish is that environmental evasion is common enough to justify a second line of analysis.
The same group’s earlier work makes the point more sharply on a smaller scale. In their evaluation of BareBox, they took 42 samples from seven families already known to stay silent under virtualisation or emulation and ran each in VMware, in QEMU and on commodity bare-metal hardware.
All 42 showed their true malicious behaviour on the physical machine, and the gaps were wide. The Rebhip family made 346 network-related system calls on bare metal against 10 in VMware, and Agobot created 50 processes where VMware saw three.
What a quiet sample actually looks like
The escalation trigger is rarely an alert. More often it is an absence. A packed dropper runs, exits with a clean status, writes nothing outside its own working directory and opens no sockets, on a machine built an hour earlier with no browser history, no documents and a single user account. Nothing has failed. That is the difficulty.
A sample that terminates without error and without artefacts has either done nothing or decided to do nothing, and the VM run cannot tell you which.
The contradiction between an expected payload and an empty behavioural trace is the only signal triage gives you before the sample goes to hardware.
Building a stage the sample cannot recognise
Physical hardware removes the hypervisor artefacts, but it does not make the environment anonymous.
BareCloud’s authors were explicit about this in their own limitations, naming the MAC address of the network device and the presence of the iSCSI driver as features that could fingerprint their platform. A lab inherits the same problem.
Anything held constant across every run becomes a stable identifier, so the hardware profile, the storage path and the network identity all have to be treated as part of the sample’s view of the world, and varied accordingly.
Reset is where the cost lands. Reverting a snapshot takes seconds.
Re-imaging a physical disk, whether over the network with PXE or from a local golden image, takes minutes, and those minutes fall between every sample, so throughput on a bare-metal stage is largely a function of the imaging path.
The evidence store belongs on a separate host with one-way collection, because the machine that just executed the sample is not the machine you want holding the artefacts.
Egress is the judgement call. Many families will not reach their real behaviour without contacting infrastructure, so the containment question is not whether to allow network access but how much, to where, and logged how.
That decision is also where the legal and contractual exposure sits.
That last point matters most when the hardware is not yours. Acceptable use policies are written to prohibit hosting and distributing malicious software, and detonating live samples on rented infrastructure with any outbound path sits close enough to that line to require asking first.
For labs that do not want to buy and maintain their own machines, it is workable to rent an Advance server and run it as an isolated analysis node, provided the arrangement is agreed with the provider and the egress policy is written down before the first sample lands.
The pipeline runs cheap first and physical second
None of this argues for retiring the sandbox. Volume belongs in virtualisation, where a sample costs almost nothing to run and a machine costs almost nothing to reset.
CAPE’s documentation is a fair picture of how mature that tooling has become, treating isolated guest networks, snapshot and clone management, agent deployment and repeatable machine preparation as ordinary operational concerns rather than research problems.
The escalation criterion is the interesting part, because it has to exist before it is needed. Anti-analysis indicators found statically, unexplained sleeps and long delays, explicit environment checks, and above all the expected-payload-with-empty-trace contradiction all argue for sending a sample to hardware.
Everything else stays in the queue and costs pennies.
Once both runs exist, the comparison is the finding. BareCloud’s central insight is that divergence between environments is itself evidence of evasion, and the working version of that in a lab is simply keeping both traces and diffing them.
A sample that behaves identically in both places has told you something. A sample that behaves differently has told you considerably more.
Bare metal is slower, dearer and harder to scale
Machines consume rack space, power and maintenance time. Hardware fails, and it fails at a physical layer where nobody is on call at three in the morning. Re-imaging is slower than reverting.
Growing capacity means buying, with lead times, where the sandbox estate would simply provision.
The subtler cost is instrumentation. A hypervisor gives you an out-of-band vantage point on the guest, and giving that up means falling back on in-guest agents, which are themselves detectable, or on external evidence such as network capture and post-mortem disk analysis, which is honest but coarse.
This is a real trade. A physical stage buys the sample’s true behaviour and charges you visibility into how it got there.
It is also worth saying plainly that a physical stage mitigates environmental evasion. It does not end it.
Hygiene, authorisation and the paperwork
The technical controls are the familiar ones. Isolated networks, controlled and logged egress, disposable credentials that exist nowhere else in the organisation, and evidence stores the detonation host can write to but never read from.
The procedural controls get less attention and cause more trouble. Samples need a clear authorisation trail covering where they came from and what the lab is permitted to do with them.
Anything touching live command-and-control traffic, credential material recovered from a sample, or data belonging to a third party carries obligations that vary by jurisdiction and are not the analyst’s alone to interpret.
Provider terms apply on top of all of it whenever the hardware is rented.
NIST’s small business cybersecurity guidance is written for a very different reader, but its framing holds here.
Identify what you are protecting, protect it deliberately, detect when something goes wrong, and have a response prepared before you need it.
A malware analysis lab is an environment where things are supposed to go wrong, which makes the last of those the one that actually gets tested.
If you are adding a physical stage, the two decisions worth making before the first sample lands are the escalation criterion and the egress policy. Write both down. Almost everything else about a bare-metal lab is procurement.
Disclosure: this article was produced as part of a sponsored placement. The technical claims are sourced to the primary literature linked above.
