Detecting T1497 Virtualization/sandbox evasion

Why T1497 virtualization and sandbox evasion matters to your SOC

T1497 Virtualization/Sandbox Evasion describes malware that checks whether it is running inside a virtual machine or analysis sandbox and changes its behavior when it is. For a SOC, this matters because a sample that stays quiet during detonation in your sandbox may behave fully once it reaches a production endpoint, so a clean sandbox report is not proof of safety. ATT&CK places the technique under the Stealth tactic (TA0005), which it defines as: "The adversary is trying to hide and conceal their actions, appearing as normal behavior." ATT&CK v19 split the former Enterprise Defense Evasion tactic into Stealth, which keeps the ID TA0005, and Defense Impairment, so check which tactic names your detection content uses. The MITRE ATT&CK tactic page for Stealth is the natural starting point for the current definition.

T1497 has three sub-techniques, which ATT&CK describes as system checks, user activity based checks and time based evasion. System checks look for artifacts that suggest virtualization or analysis tooling, such as hardware, platform or environment characteristics. User activity based checks look for signs of a human operator, such as recent input or interaction, and hold back when none appear. Time based evasion waits or delays execution so that short sandbox runs end before the malicious behavior starts. In intrusions, this behavior typically shows up early, in loaders, droppers or staged scripts, before the payload decides what to do. Confirm the sub-technique names and structure against the ATT&CK page for the version you target before you write them into detection content.

This page targets Enterprise ATT&CK 20.0, which the attack-stix-data repository indexes with a release date of 2026-10-13. Technique IDs, sub-technique structure and mappings can change between releases, and ATT&CK can rename, deprecate or revoke entries. Record the ATT&CK version next to every detection, hunt and coverage claim, and review the MITRE ATT&CK updates page when you upgrade your rule set. Ask your analysis platform team which ATT&CK version their detection content and sandbox reports reference, because a mismatch makes coverage look better or worse than it is.

Which telemetry reveals T1497 and which open-source tool collects it

This table maps each data component ATT&CK uses for T1497 to the signal a defender should look for and the open-source collector that can gather it. Read it as a starting point: the exact fields depend on how each collector is configured, so confirm them in the client environment before writing detection content.

Data component	Signal to look for	Open-source collector	Notes for T1497
Process Creation (DC0032)	Processes started that query hardware, firmware or virtualization indicators, or that run short-lived checks before a payload runs	Wazuh, Sysmon-based pipelines on Windows, auditd on Linux	Core source for T1497 sub-technique activity. Confirm which process fields and parent-child context your collector records.
Command Execution (DC0064)	Shell or script commands that read system details used to judge whether the host is virtual or sandboxed	Wazuh, Velociraptor, auditd on Linux and macOS	Command line capture often needs explicit configuration. Confirm whether arguments are logged in full and how long they are retained.
Module Load (DC0016)	Loading of libraries or modules tied to virtualization or analysis tooling on the host	Sysmon-based pipelines on Windows, Velociraptor for targeted checks	Useful for Windows detection. Module load events can be high volume, so confirm filtering and sampling in your environment.
File Creation (DC0039)	Creation of files or registry-like artifacts that support sandbox or virtual machine checks	Wazuh file integrity monitoring, Velociraptor artifact collection	Supports artifact checks rather than primary detection. Confirm which paths are monitored and the expected noise level.
Telemetry gap check	Whether the chosen collector records the events above on each platform in scope	Wazuh, Velociraptor, Sysmon, auditd (confirm per platform)	Test coverage in the cyber range before relying on any of these sources. Coverage differs between Linux, macOS and Windows.

Detection logic for T1497 that a detection engineer can tune

The four detection ideas below look at T1497 from different angles: who is querying the environment, which virtualization modules get loaded, and what short-lived process chains do afterward. Each one produces noise in legitimate infrastructure, so the thresholds and exclusions matter as much as the logic itself. Treat every value as a starting point to validate in your own estate and in a private cyber range, and record the ATT&CK version your rule targets, which is Enterprise ATT&CK 20.0 for these pages.

Clustering of environment queries

Flag a single process that performs many distinct hypervisor, firmware or sandbox-artifact checks within a short window on one host. The useful signal is breadth, not any single check, because one query is common in installers and monitoring agents. Start with a per-process count of distinct check categories over a sliding window, then tune the window and count against baseline telemetry from your fleet. Expect false positives from asset inventory tools and configuration management agents, which query hardware identity by design. Maintain an allowlist keyed on signed binary path and publisher, not process name alone.

Virtualization tooling module loads

Alert when a non-virtualization process loads guest-tools or hypervisor-specific modules that it has no reason to touch, especially on production servers that are not expected to run guest additions. Scope the rule by host role so that developer workstations and VM hosts are evaluated separately. Legitimate VM management agents, backup appliances and CI runners load these modules routinely, so exclude them by hash and parent process lineage rather than by directory. Review the rule quarterly, because agent upgrades change module names and can silently break the exclusion list.

Short-lived process chains after checks

Look for parent-child chains where a process spawns a child, the child exits within a few seconds, and the parent then terminates without producing output or network activity. This pattern resembles a program exiting after a gate check. Tune the lifetime threshold against your own distribution of normal short-lived processes, since package managers, health checks and container init scripts produce many similar chains. Pair the rule with file creation context so analysts can see whether a dropped file preceded the exit. Confirm that your Process Creation telemetry includes process exit events, because many default configurations omit them.

Repeated exits without payload activity

Count executions that terminate with a non-zero code and no subsequent network connection, file write or child process across many hosts in one day. A cluster of such runs on the same image suggests an environment gate rather than a broken tool. Set the count threshold per host group, since build farms and sandboxes generate high volumes by design. Confirm the exclusion list covers known CI runners and detonation systems that are supposed to exit quickly, and ask your team to document which of them are expected.

Validate logic against ATT&CK version changes

Record the ATT&CK version that each rule targets, and re-check mappings after every release because MITRE can rename, deprecate or revoke techniques. Map each rule to the data components it depends on, such as Process Creation (DC0032) and Module Load (DC0016), and confirm those fields still exist in your collection pipeline. Keep sub-technique coverage visible so that a change to one sub-technique does not silently remove detection for the others. Ask your detection content owner to show the mapping in the rule metadata during review.

How to validate that the T1497 detection fires

This sequence proves, in a private cyber range, that the T1497 detections fire for the intended platforms and sub-techniques, and that the alert outcome is recorded well enough to decide whether the rule passes, needs tuning or must be rewritten. It turns a detection idea into evidence that a security operations team can reproduce and audit.

Agree scope and rules of engagement
The security lead, the detection engineer and the range operator agree in writing which platforms, hosts, accounts and telemetry sources are in scope, which T1497 sub-techniques will be exercised, who may start and stop activity, and how the range is isolated from production networks. Sign-off is complete when every named participant has approved the document and the range team confirms that no route to production exists. Ask the range provider to confirm these isolation controls in writing before work starts.
Select an approved emulation plan
Choose an emulation plan that maps each T1497 sub-technique to the platforms in scope, referencing the ATT&CK version the detections target so the mapping stays stable across releases. Review the plan with the detection engineer to confirm that each planned action is described at a level suitable for a lab record, and that the plan names the expected data components, such as Process Creation, Command Execution and Module Load. The step is done when every sub-technique has a documented expected alert and a named owner.
Prepare telemetry and baseline the range
Confirm that endpoint agents, log forwarders and the SIEM on each in-scope platform are running, and capture a baseline of normal alert volume on the same hosts before any emulated activity. The detection engineer checks that the required telemetry arrives with correct host names, time zones and parsing, because a rule cannot fire on fields that never reach the platform. The step closes with a baseline report and a telemetry health checklist signed by the detection engineer.
Run the emulation in the isolated range
The range operator runs the approved plan one sub-technique at a time, on the agreed hosts, while a second observer logs the start and end time of each action in a shared run sheet. Each action is paired with the expected alert so the observer can mark it as fired, delayed or silent. The step is complete when every planned action has a start time, an end time and an observer note, and any unplanned activity is flagged for review.
Record timestamps and telemetry
Export the raw events, alert records and rule identifiers for every run, and align the timestamps from the run sheet with the event times in the SIEM to measure the gap between action and alert. Keep the exports with the run identifier, the ATT&CK version, the rule version and the host list, so the evidence can be reproduced later. The step is complete when each run has a stored evidence bundle that another engineer can open and read without help from the people who ran it.
Compare alert outcomes with expectations
The detection engineer compares each run's observed alerts with the expected result in the emulation plan and classifies every outcome as detected, detected with noise, delayed or missed. Missed and delayed results are investigated first, because they usually point to missing telemetry, a field mismatch or a logic gap. The step closes with a results table that lists each sub-technique, platform and outcome, with the evidence reference beside each row.
Decide pass, tune or rewrite
The review group decides, for each detection, whether to pass it as validated, tune it to reduce false positives while keeping the expected alert, or rewrite it because the logic does not match the observed telemetry. Each decision is recorded with the reason, the owner and the rule version it applies to, and any tuned or rewritten rule is re-run in the range before it is accepted. The sequence is finished when every detection has a recorded decision and a retest result, and the outcome is filed for the next review cycle.

Preventive controls that reduce T1497 exposure

ATT&CK maps several mitigations to T1497 Virtualization/sandbox evasion and its sub-techniques. The four below cover logging, endpoint blocking, execution control and account hygiene, and each one narrows a different part of the path an adversary uses to decide whether it is running in an analysis environment. Treat each mitigation as a control you must verify on your own platform and version, not as a guarantee.

Audit (M1047)

Audit is the mitigation that makes T1497 visible at all. Enable process creation logging and command line capture on Linux, macOS and Windows hosts so that checks for virtualization artifacts, such as hypervisor-specific drivers, registry values or hardware identifiers, leave a record. Without this telemetry, a sandbox-aware payload can run its checks and branch silently. Confirm which audit policies, auditd rules or endpoint agent settings your platform version exposes, and confirm that the logs reach your SIEM with usable fields.

Behavior prevention on endpoint (M1040)

This mitigation relies on endpoint products that block or flag suspicious behavior rather than only matching known signatures. For T1497, the useful behaviors are repeated queries for hypervisor or sandbox indicators followed by a change in execution path. Ask your endpoint vendor whether behavioral rules can be tuned for these patterns, how false positives are handled on build servers and virtual desktop fleets, and whether alerts are exported to your monitoring stack. Test the rules against your own analysis environments before relying on them.

Execution prevention (M1038)

Execution prevention controls decide which binaries, scripts and modules may run on a host, typically through allowlisting or application control. Applied to T1497, these controls reduce the number of unknown programs that can reach the environment-checking stage in the first place. Review which interpreters and script hosts are permitted on user endpoints and servers, and document the exceptions. Confirm how your application control product handles unsigned tools that developers and security staff use during testing, because those exceptions are often where evasion checks go unobserved.

User account management (M1018)

Account management limits who can install software, change host configuration or deploy into the analysis fleet. For T1497, the concern is that a standard user or a compromised service account could alter sandbox images, disable logging or add tools that help a payload recognize its surroundings. Review administrative rights on sandbox and detonation hosts, separate their credentials from production, and log every change to their configuration. Confirm how your identity platform and host management tooling enforce these boundaries in your version.

Triage and response when a T1497 alert fires

Confirm the alert before anyone isolates a host. Start by checking that the alert is a true T1497 hit and not a known analyst or lab workflow. Pull the raw Process Creation and Module Load events behind the alert, not only the rule summary, and confirm the host name, user account, time window and the ATT&CK version your rule targets. Then establish process lineage: which parent launched the process, whether it ran from a user profile or temporary directory, and whether the same parent appears on other hosts. Check the host's asset record to see whether it is a managed analyst workstation, a build agent, a test VM or a general-purpose laptop. A match against an approved sandbox image, a documented virtualization tool used by the security or QA team, or a change ticket usually closes the alert as benign, but record the reason so the decision can be audited later. If the activity cannot be explained, treat it as suspicious and move to containment.

Decide on isolation based on what the host is doing, not only what the rule matched. Isolate the endpoint when the lineage is unexplained and the process is linked to other suspicious activity, such as unusual network connections, credential access or new persistence. Your EDR or Wazuh active response should be able to contain the host, but confirm the isolation action and its rollback path with the operations team before a rule goes into automated response. Before isolating, start evidence collection with Velociraptor or a similar agent-based tool so volatile artifacts are captured first. Preserve the process tree, loaded modules, command history, relevant event logs and a memory image if your policy allows it, and hash each collected artifact with its collection time and collector identity recorded. Keep the chain of custody written down, because an investigation may later depend on whether the evidence was collected in a defensible way.

Scope across the fleet and feed the result back into tuning. Search the same process name, parent, command pattern and module load across all endpoints for the window around the alert, using your SIEM or Velociraptor hunts, and group hits by host role. Any new hit that matches the suspicious lineage becomes a separate incident with its own triage. Once the investigation closes, record which environments produced false positives, such as approved analyst images, and tune the rule with an allowlist scoped by host group, parent path and signed binary rather than by a global exclusion. Each tuning change should name the ATT&CK version, the data components used and the test that proves the change does not hide the original behavior. Confirm with your detection engineering owner how changes are reviewed and versioned before they reach production.

Rehearsing T1497 detection in a private cyber range

On Linux, the range is usually a set of virtual machines or containers on an isolated hypervisor network with no route to production or the internet. The facilitator builds a baseline image, a sensor stack and a test workload that the scenario will run, then records the expected events before the exercise starts.

Range build: Use an isolated network segment, snapshot-based images and host auditing rules that record process execution and module loading. Store the sensor configuration in version control so the team can reproduce the setup.
Injects: Script a labeled test that checks for common virtualization indicators and then changes its behavior. Run it at a time the blue team agrees on in advance, and keep the facilitator log separate from the team's view.
Good detection: Process Creation and Command Execution events are correlated to the host and account, and the alert maps to a documented detection rule that names the ATT&CK version targeted. The analyst can rebuild the sequence from the agreed time window.
Good response: The analyst follows the runbook, isolates the host through the agreed control, preserves evidence with a snapshot and records timestamps for each step.

Check that the rule fired on the labeled inject, stayed quiet on the clean baseline and matches the facilitator log.

Practitioner questions about T1497 detection

How do I stop VM management tools from flooding T1497 alerts?

Start by allowlisting known hypervisor management activity by source host, service account and parent process, then alert only on deviations from that baseline. Hypervisor agents, backup jobs, endpoint management suites and configuration tools often run the same checks that a sandbox evasion detection looks for, so their activity is the main source of false positives. Build the allowlist from your own environment: export a few weeks of process creation and module load telemetry from known management hosts, confirm each recurring pattern with the owning team, and record every exception with an owner and review date. Keep the allowlist narrow, since a broad exclusion on a common process name can hide the same behavior when an adversary uses it. Revalidate the exceptions after each hypervisor, agent or endpoint tool upgrade.

Which MITRE ATT&CK version should my T1497 detections target?

Pin each detection to the ATT&CK version you tested against and record that version in the rule metadata. ATT&CK v18 was released on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, and each release can rename, deprecate or revoke techniques. In v19, the Enterprise Defense Evasion tactic was split into Stealth, which keeps ID TA0005, and Defense Impairment, which has ID TA0112, so mappings written against older tactic names need a review. Check the ATT&CK updates page when you upgrade your mapping, and maintain a short change log that lists which technique and sub-technique IDs your rules reference. Re-run your coverage check whenever you move to a new version so that tactic changes do not silently leave gaps.

How can I test T1497 detections without running live malware?

Test the telemetry path and the rule logic with benign, documented triggers in a private cyber range rather than with live samples. The goal is to confirm that the right data components, such as Process Creation, Command Execution and Module Load, reach your SIEM with the fields your rules expect, and that the rule fires once and only once for a known action. Use an isolated lab with snapshots so each test can be reset, record the expected alert before each run, and compare it with the observed result. Keep a registry of test cases keyed to the sub-technique IDs, so that a failed test points to a specific gap. Involve the detection engineers who own the rules, because they can tell you whether a trigger reflects realistic adversary behavior in your environment.

How do I confirm my Wazuh rules cover T1497?

Confirm coverage by mapping each Wazuh rule to the ATT&CK technique and sub-technique it addresses, then testing that each mapping produces an alert from real telemetry in your lab. Check that the Wazuh agents on your Linux, macOS and Windows endpoints forward the event sources your rules depend on, and review the rule files for the technique tags they carry. Run the lab tests from the previous step and record the rule ID, the alert timestamp and the agent that generated the event. Coverage is only confirmed for the platforms and sub-techniques you tested, so list the gaps explicitly rather than assuming inheritance from a parent technique. Confirm the rule versions in your Wazuh deployment match the versions you reviewed, because a rule update can change behavior without changing its name.

How do I confirm my Sigma rules cover T1497 sub-techniques?

Review each Sigma rule's ATT&CK tags, logsource definition and detection logic against the sub-technique it claims to cover, then convert the rules to your SIEM query language and test the converted versions. A Sigma rule can carry a technique tag without actually detecting that behavior, so validate the logic by replaying the lab test cases and checking the result. Confirm that the logsource fields in the rule match what your collectors actually send, since a field-name mismatch produces silent non-detection. Keep a coverage matrix that lists each sub-technique, the rule that addresses it, the data components used and the date of the last successful test. Treat a sub-technique without a passing test as uncovered until the test passes.

Which ATT&CK mitigations should I review alongside T1497 detections?

Review Audit (M1047), Behavior Prevention on Endpoint (M1040), Execution Prevention (M1038), User Account Management (M1018), Restrict File and Directory Permissions (M1022) and Privileged Account Management (M1026), which ATT&CK most often maps to Stealth techniques and their sub-techniques. Audit tells you whether the logging needed for detection is enabled and retained, which is the first thing to check when a test fails. Behavior Prevention on Endpoint and Execution Prevention are endpoint controls whose policies should be tested in the same cyber range, since a blocked action can prevent the telemetry your rule depends on. Confirm each mitigation's configuration in your own environment, because ATT&CK describes the control category and not how your tooling implements it.

Official ATT&CK sources for T1497 and the Stealth tactic

Start with the official ATT&CK tactic page for Stealth (TA0005) before you map any rule to T1497. The page describes the tactic as adversary activity that hides actions and makes them appear as normal behavior, which is the framing behind virtualization and sandbox evasion: malware checks whether it runs on an analysis platform and changes its behavior when it does. Use the MITRE ATT&CK tactic page for Stealth to confirm the tactic name, its ID and the list of techniques and sub-techniques that currently sit under it, including T1497 and its three sub-techniques. Keep a dated copy of that page in your detection documentation so auditors can see what the mapping looked like when you wrote it.

Next, read the ATT&CK updates page and the release notes for the version you target. Stealth was split from the broader Defense Evasion tactic in v19, with Defense Impairment added as a separate tactic, so older rules or dashboards that label T1497 under Defense Evasion may need relabeling. Releases can also rename, deprecate or revoke techniques and sub-techniques, so confirm the exact version against the release notes before you publish a Sigma rule or a Wazuh rule that cites an ATT&CK ID.

For technique and data component mappings, use the enterprise-attack 20.0 STIX bundle as the reference. It is the machine-readable source for the relationships between T1497, its sub-techniques, the data components such as Process Creation and Module Load, and the mitigations that apply. Reference it in the enterprise-attack 20.0 bundle in the mitre-attack/attack-stix-data repository, and pin the version in your rule metadata. Before you write rules, parse the bundle for T1497 and compare the output against the tactic page. If the two disagree, record the discrepancy and confirm the mapping with MITRE before you rely on it.

How DeployOpen builds T1497 detections and range scenarios

DeployOpen approaches T1497 Virtualization/sandbox evasion as a fixed-scope engagement inside your own environment, starting from the written scope and the telemetry you already collect. Detection logic, range scenarios and documentation are delivered together so your team can run and maintain them.

How we scope

Confirm which platforms are in scope for T1497, including Linux, macOS and Windows endpoints.
Agree which of the three T1497 sub-techniques the detection will cover, and which will be excluded.
Inventory Process Creation, Command Execution and Module Load telemetry already available in your stack.

How we build

Map detection logic to the ATT&CK version named in the scope, so mappings stay traceable across releases.
Write detection rules for open-source tooling such as Wazuh and Sigma, and test them against sample telemetry.
Build a private cyber range scenario that reproduces T1497 behavior in a controlled lab, without exposing production hosts.

How we hand over

Deliver rule files, test results and tuning notes in a format your detection engineers can review and version.
Document the validation steps, expected alerts and the response runbook for T1497 detections.
Walk your security and platform teams through the range exercise so they can rehearse it independently.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover rule updates when ATT&CK releases rename, deprecate or revoke related mappings.
Confirm the support boundaries, response expectations and review cadence in the written scope before work starts.

T1497 Virtualization/sandbox evasion