AN0479: Analytic 0479
Shell script or binary uses multiple system commands (e.g., dmidecode, lscpu, lspci) in quick succession to detect virtualization environment
Analyst context for executives and security teams
This analytic is about spotting Linux scripts or binaries that rapidly run hardware and system-inventory commands such as dmidecode, lscpu, and lspci to determine whether they are executing in a virtualized environment. For leaders, the value is not the commands themselves; it is the possibility that software is checking its environment before deciding how to behave. That can matter for SOC readiness, malware triage, sandbox reliability, and incident response decisions where adversary behavior may differ between virtual analysis systems and production hosts.
Executive priority
Prioritize this as a validation point for Linux endpoint visibility and analysis-environment confidence. Security leaders should ask whether Linux servers and investigation sandboxes collect enough process telemetry to show rapid command chaining and whether SOC playbooks treat environment-discovery behavior as context rather than a standalone incident. This is especially relevant where Linux workloads support critical business services, cloud-hosted infrastructure, or regulated systems requiring evidence of monitoring coverage.
Technical view
For SOC and detection engineering teams, validate whether Linux process execution telemetry can identify a shell script or binary invoking multiple system-discovery utilities in quick succession, including examples named by ATT&CK: dmidecode, lscpu, and lspci. Because no official detection logic, tactics, or relationship context is supplied, treat this as a behavioral analytic pattern rather than a complete rule. Detection should focus on burst patterns, parent-child process relationships, command-line visibility, execution user, host role, and whether the activity occurs in an expected administrative, inventory, troubleshooting, or virtualization-management context.
Likely telemetry
- Linux process creation events, including executable path and command line
- Parent-child process relationships for shell scripts, binaries, and spawned system utilities
- Timestamps precise enough to identify multiple system commands executed in quick succession
- User, service account, and privilege context for the executing process
- Host role and environment context, such as server, workstation, container host, or analysis/sandbox system where available
Detection direction
- Confirm that Linux telemetry captures executions of dmidecode, lscpu, lspci, and similar system-inventory commands with command-line and parent process details.
- Look for rapid sequences of multiple hardware or platform-discovery commands launched by the same parent process, user, or script within a short time window.
- Tune against expected administrative activity, asset inventory agents, configuration management, troubleshooting scripts, and virtualization or hardware diagnostics to reduce false positives.
- Use this behavior as enrichment or triage context when paired with other suspicious activity, since the supplied ATT&CK object does not provide tactics, relationships, or a complete detection method.
- Check for blind spots on Linux systems where process auditing, EDR, shell logging, or command-line capture is absent or inconsistently deployed.
Mitigation priorities
- Establish reliable Linux process execution logging before relying on this analytic for operational detection.
- Baseline legitimate administrative and inventory tooling that commonly invokes hardware and CPU discovery commands.
- Restrict unnecessary privileged access to hardware-enumeration utilities where operationally feasible, since some commands may require elevated permissions or expose detailed system information.
- Ensure incident response and malware-analysis workflows account for environment-detection behavior, especially when interpreting results from virtualized analysis systems.
- Document monitoring coverage and tuning decisions as audit or compliance evidence where Linux workload monitoring is in scope.
Analyst notes and limits
The supplied object is a detection analytic for Linux only. It describes a behavioral pattern: a shell script or binary using multiple system commands in quick succession to detect virtualization. No ATT&CK tactics, technique relationships, official detection text, malware or group relationships, or mitigation mappings were supplied, so this take intentionally frames the analytic as a visibility and triage validation point rather than a confirmed indicator of malicious activity.
This assessment is limited to the official STIX fields, the single external reference, and the absence of relationship context. Local environment baselines are required to separate suspicious environment discovery from normal administration, asset inventory, diagnostics, or configuration management. No claim is made about active exploitation, attribution, impact, or guaranteed detection coverage.
Analytic 0479
Shell script or binary uses multiple system commands (e.g., dmidecode, lscpu, lspci) in quick succession to detect virtualization environment
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 689653e529e3… |
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 AN0479Open 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.