DET0420: Detect User Activity Based Sandbox Evasion via Input & Artifact Probing
DET0420 is a detection strategy for spotting software that changes behavior when it thinks it is being watched in a sandbox or virtualized analysis environ...
Analyst context for executives and security teams
DET0420 is a detection strategy for spotting software that changes behavior when it thinks it is being watched in a sandbox or virtualized analysis environment. The business value is not just malware detection; it is validating whether SOC and incident response workflows can recognize evasion behavior that may prevent automated analysis from revealing the real payload or intent.
Executive priority
Prioritize this as an assurance question for detection engineering, malware triage, and incident response readiness: can the organization identify suspicious user-activity and environment-probing behavior before relying on sandbox results as evidence of low risk? This matters for business continuity because evasive malware can delay containment decisions, weaken audit confidence in analysis outputs, and create blind spots in managed detection or IR handoffs.
Technical view
The supplied relationship says this strategy detects ATT&CK T1497.002, User Activity Based Checks, associated with stealth and discovery on Linux, macOS, and Windows. SOC and IR teams should validate whether endpoint and analysis telemetry can show processes checking for user activity or sandbox/virtual-machine artifacts and then changing behavior, exiting, delaying, or withholding payload activity. Because the detection strategy object does not include official detection logic, teams should treat this as a coverage-validation theme rather than a ready analytic.
Likely telemetry
- Endpoint process creation and command-line telemetry
- API or system-call level telemetry related to user input, session, display, timing, or environment checks where available
- File, registry, device, hardware, or virtualization artifact access telemetry relevant to the monitored operating system
- Sandbox detonation logs showing process behavior, delays, exits, conditional branching, or lack of payload execution
- EDR alerts or behavioral events for discovery-like activity tied to stealthy execution patterns
Detection direction
- Validate that sandbox results are not treated as conclusive when samples show little or no behavior; absence of activity can itself require follow-up when environment probing is observed.
- Tune for suspicious combinations: environment or user-activity checks followed by process termination, sleep/delay behavior, payload suppression, or altered execution paths.
- Correlate probing behavior with the related ATT&CK context of stealth and discovery rather than alerting on every benign application that checks display, input, hardware, or session state.
- Review false positives from legitimate software installers, licensing tools, diagnostics, accessibility software, and virtualization-aware enterprise tools.
- Confirm coverage across the related platforms named in the relationship context—Linux, macOS, and Windows—only where those platforms are in scope for the environment.
Mitigation priorities
- Establish malware-analysis procedures that include follow-up for samples that appear inert or behave differently in sandbox conditions.
- Harden detection engineering around endpoint behavior, not only sandbox verdicts, so evasive checks can be observed on real or representative systems.
- Document what telemetry is collected for user activity, environment artifacts, process behavior, and sandbox execution outcomes to support compliance and incident evidence.
- Create IR decision criteria for when evasive or inconclusive sandbox results require escalation, manual analysis, or broader endpoint hunting.
- For managed detection or consulting programs, map tested analytics and evidence sources to T1497.002 and identify platform-specific gaps.
Analyst notes and limits
This take is based on the detection strategy name, external reference DET0420, and its relationship to T1497.002 User Activity Based Checks. The ATT&CK object itself has no official description, no official detection text, and no platforms or tactics directly specified; platform and tactic context comes from the related technique only.
No vendor logic, event IDs, data components, analytic thresholds, or concrete detection procedure were supplied. Local validation is required to determine whether an organization can actually observe this behavior and distinguish it from legitimate virtualization-aware or user-session-aware software.
Detect User Activity Based Sandbox Evasion via Input & Artifact Probing
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1497.002 | User Activity Based Checks Sub-technique | This object detects User Activity Based Checks. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | e23f02ef9767… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0420Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.