AN0470: Analytic 0470
Detects modification or truncation of `/var/log/shell.log` used to persist ESXi shell command history. Especially suspicious shortly after login or config changes.
Analyst context for executives and security teams
AN0470 matters because it focuses on tampering with ESXi shell history stored in `/var/log/shell.log`. For security leaders, this is less about a single log file and more about whether activity on critical virtualization infrastructure can be reconstructed after an incident. Modification or truncation of this file, especially near logins or configuration changes, can reduce incident response visibility and weaken audit evidence.
Executive priority
Treat this as a control-assurance item for ESXi administration and incident readiness. If ESXi hosts support important workloads, leaders should ask whether shell activity, login events, and configuration changes are centrally collected and protected from local tampering. The priority is preserving trustworthy evidence on systems that can affect business continuity, not assuming this analytic alone proves compromise.
Technical view
Validate monitoring for ESXi hosts that can identify modification or truncation of `/var/log/shell.log`, then correlate those events with recent logins and configuration changes. Because ATT&CK provides no detailed detection logic for this analytic, SOC and detection engineering teams should define local baselines for expected shell history rotation, maintenance activity, and authorized administrative workflows before alerting on changes.
Likely telemetry
- ESXi `/var/log/shell.log` file metadata and content change events
- ESXi login and authentication events
- ESXi configuration change records
- Centralized syslog or log-forwarding records from ESXi hosts
- File integrity monitoring or host audit evidence for log modification/truncation
Detection direction
- Alert on unexpected truncation, deletion, or modification of `/var/log/shell.log` on ESXi systems.
- Correlate shell log changes with recent successful logins and configuration changes, as highlighted by the official analytic description.
- Tune for legitimate maintenance, log rotation, or approved administrative activity to reduce false positives.
- Validate that ESXi logs are forwarded off-host quickly enough that local log tampering does not remove all evidence.
- Document coverage gaps where ESXi file integrity, authentication, or configuration telemetry is not collected.
Mitigation priorities
- Restrict ESXi shell and administrative access to authorized personnel and approved workflows.
- Centralize ESXi logging so local modification of `/var/log/shell.log` does not eliminate investigative evidence.
- Use change control for ESXi configuration activity and compare alerts against approved maintenance windows.
- Review retention, access control, and integrity protections for hypervisor logs used in incident response and compliance evidence.
- Ensure incident response playbooks include evidence preservation steps for ESXi hosts when shell history tampering is suspected.
Analyst notes and limits
This take is based only on the supplied ATT&CK analytic fields. The object is a detection analytic for ESXi and has no supplied tactic, relationship context, or official detection logic beyond the description. Local ESXi configuration, logging architecture, and administrative practices will determine practical alert quality.
No relationships, procedure examples, data components, or detailed detection pseudocode were supplied. This summary should not be read as evidence of active exploitation, attribution, or guaranteed detection coverage.
Analytic 0470
Detects modification or truncation of `/var/log/shell.log` used to persist ESXi shell command history. Especially suspicious shortly after login or config changes.
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 | 5a9becf96cba… |
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 AN0470Open 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.