AN0524: Analytic 0524
Tracks suspicious use of ESXi shell commands or PowerCLI to delete logs, rotate system files, or tamper with hostd/vpxa history.
Analyst context for executives and security teams
This analytic matters because ESXi hosts often support critical virtualized workloads, and suspicious attempts to delete logs, rotate system files, or tamper with hostd/vpxa history can reduce an organization’s ability to reconstruct what happened during an incident. For executives and security leaders, the practical issue is not only whether ESXi is monitored, but whether logging and administrative activity evidence survives long enough to support outage triage, incident response, audit requests, and recovery decisions.
Executive priority
Prioritize this as an operational resilience and evidence-preservation concern for environments running ESXi. Leaders should ask whether virtualization administrators, SOC teams, and incident responders can prove who changed or removed ESXi evidence, when it happened, and which workloads may have been affected. This is especially relevant to incident readiness, compliance evidence, and business continuity because tampered host logs can delay containment and root-cause analysis.
Technical view
Validate monitoring around ESXi shell activity and PowerCLI activity that indicates log deletion, system file rotation, or tampering with hostd/vpxa history. Because the official object does not provide a detection rule or tactic mapping, teams should use this analytic as a coverage requirement: confirm that ESXi administrative command activity, relevant host log changes, and PowerCLI-driven management actions are captured, centralized, and reviewable. Detection engineering should focus on distinguishing authorized maintenance or log rotation from unusual timing, unexpected administrators, abnormal command patterns, or activity occurring during an incident window.
Likely telemetry
- ESXi shell command history or equivalent administrative activity records
- PowerCLI execution and administrative session records
- ESXi host logs related to hostd and vpxa activity
- File modification, deletion, or rotation events for ESXi system and log files where available
- Centralized log collection status for ESXi hosts
Detection direction
- Confirm whether ESXi shell and PowerCLI activity is actually visible to the SOC; many environments monitor guest workloads better than hypervisor administration.
- Create or tune detections for suspicious log deletion, system file rotation, and hostd/vpxa history tampering, while accounting for approved maintenance and normal log-management tasks.
- Correlate suspicious ESXi file or log activity with administrator identity, source system, time of day, change tickets, and concurrent incident indicators.
- Validate that logs are forwarded off-host quickly enough that local tampering does not erase the only evidence source.
- Treat the lack of an official detection expression as a prompt for local engineering and testing rather than as a complete coverage statement.
Mitigation priorities
- Restrict and review ESXi shell and PowerCLI administrative access based on least privilege and operational need.
- Centralize ESXi logs and protect retained evidence from modification by routine host administrators where feasible.
- Define approved maintenance procedures for log rotation and system file handling so detections can separate expected activity from suspicious behavior.
- Include ESXi evidence preservation in incident response playbooks and tabletop exercises.
- Periodically audit hypervisor logging, administrative access, and retention settings as part of compliance and resilience validation.
Analyst notes and limits
This Glexia take is based only on the supplied MITRE analytic fields. The object identifies ESXi as the platform and describes suspicious use of ESXi shell commands or PowerCLI to delete logs, rotate system files, or tamper with hostd/vpxa history. No tactic mapping, detection logic, or relationship context was supplied, so recommendations are framed as validation and defensive coverage direction rather than confirmed ATT&CK behavior chains.
Official detection content and relationship context were not provided. Local ESXi configuration, logging architecture, administrative practices, and change-management records are required to determine what is suspicious and what telemetry is available.
Analytic 0524
Tracks suspicious use of ESXi shell commands or PowerCLI to delete logs, rotate system files, or tamper with hostd/vpxa history.
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 | 998c99f15b90… |
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 AN0524Open 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.