---
{
  "title": "Virtualization/Sandbox Evasion",
  "summary": "Sandbox evasion changes behavior when software recognizes a virtual or analysis environment.",
  "topic": "forensics",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1497"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1497: Virtualization/Sandbox Evasion",
      "url": "https://attack.mitre.org/techniques/T1497"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Sandbox evasion changes behavior when software recognizes a virtual or analysis environment. An apparently quiet test run may not represent behavior on an intended victim host.


## An investigation example

A suspicious executable exits after environment checks in a sandbox but continues on a normal workstation.

## Evidence to examine

Inspect environment queries, timing, configuration conditions, and differences between observed execution environments.

## A common analytical pitfall

No observed harm in one test environment is not evidence that the program is universally benign.

## Response considerations

Use isolated authorized analysis and describe environmental limitations when reporting observed behavior and confidence.


## Environment-dependent behavior limits a clean verdict

Some software changes its behavior when it recognizes an analysis environment, virtual machine, or signs of limited user activity. An intruder may use that behavior to delay or avoid observation. However, legitimate software can also check virtualization for compatibility, licensing, or performance reasons. A single environment query does not establish evasion by itself.

An analysis run that shows no harmful behavior is therefore a bounded observation, not proof that a sample is safe in every environment. Timing, available services, user interaction, and configuration can affect execution. Document the analysis conditions and the behavior actually observed rather than claim universal conclusions from one short run.

## A fictional quiet sample

An academy's training sample performs system checks and then exits in an isolated lab. Analysts compare the recorded checks with the sample's broader context and review whether the run reached meaningful functionality. They do not conclude that it is harmless solely because the sandbox produced no obvious alert.

Further analysis should remain within an approved environment and procedure. Do not weaken real security controls or move an unknown sample onto a personal computer to make it behave differently. Controlled comparison and specialist review can explore uncertainty without creating unnecessary exposure. Preserve sample identity, environment details, tool versions, and timing for reproducibility.

## Write a defensible analysis result

Use fictional observations from a short sandbox run. State what executed, which checks appeared, what behavior was absent during the observation period, and which conditions limit the conclusion. Then propose a safe next analytical step. The goal is to explain uncertainty rather than force a binary safe-or-malicious verdict from incomplete evidence.

A lack of observed activity can arise from errors, missing dependencies, an expired condition, or deliberate avoidance. Keep these explanations distinct and seek evidence that differentiates them. This reasoning helps analysts avoid both false reassurance and unsupported claims that every inactive sample contains sophisticated anti-analysis logic.

## Related concepts

- [[digital-forensics]]
- [[incident-timeline]]
- [[logs-and-telemetry]]