AN1640: Analytic 1640
SSH login via hostd or `/var/log/auth.log`, followed by CLI access to host shell or file manipulation in restricted areas.
Analyst context for executives and security teams
This analytic matters because SSH access to an ESXi host can put core virtualization infrastructure within direct administrative reach. For leaders, the practical question is whether the organization can prove who logged into ESXi hosts, when they obtained shell or CLI access, and whether activity touched restricted file areas. Without that evidence, incident responders may struggle to determine whether virtualization management activity was legitimate administration or unauthorized hands-on-keyboard behavior.
Executive priority
Prioritize this as a visibility and governance check for ESXi management access. It supports operational resilience and audit readiness by validating that privileged access to virtualization hosts is logged, retained, and reviewable. Security leaders should ask whether ESXi SSH access is expected, who is authorized to use it, how exceptions are approved, and whether SOC or IR teams can quickly reconstruct host-level activity during an incident.
Technical view
For ESXi platforms, validate collection and parsing of SSH login evidence from hostd and/or /var/log/auth.log, then correlate successful logins with subsequent CLI shell access or file manipulation in restricted areas. Because the supplied ATT&CK object provides no formal detection logic, tactics, or relationship context, detection engineering should treat this as a behavior pattern to operationalize locally: privileged remote access followed by sensitive host interaction.
Likely telemetry
- ESXi hostd logs showing SSH login or management access events
- /var/log/auth.log entries for SSH authentication activity
- Shell or CLI access records where available
- File access or file modification evidence for restricted ESXi host paths
- Privileged account, source address, timestamp, and host identity context
Detection direction
- Confirm ESXi SSH authentication events are centrally collected, normalized, and retained long enough for incident response.
- Correlate SSH login events with subsequent host shell or CLI activity rather than alerting on authentication alone.
- Tune for authorized maintenance windows and known administrator source locations to reduce false positives.
- Review for blind spots where ESXi logs are not forwarded, are overwritten quickly, or are not mapped to named users and source systems.
- Because no official detection logic is supplied, validate any analytic against local administrative practices before using it for high-severity alerting.
Mitigation priorities
- Define and document when SSH access to ESXi hosts is permitted and who can approve it.
- Restrict privileged ESXi host access to authorized administrators and controlled management paths.
- Ensure ESXi host logs relevant to SSH login, CLI access, and restricted file activity are forwarded to central monitoring.
- Review retention and integrity of ESXi logs so IR teams can reconstruct activity after an event.
- Use periodic access reviews and change-control evidence to distinguish expected maintenance from suspicious host-level access.
Analyst notes and limits
This take is based on ATT&CK analytic AN1640 for ESXi: SSH login via hostd or /var/log/auth.log followed by CLI access to host shell or file manipulation in restricted areas. No relationships, tactics, aliases, or official detection logic were supplied, so local environment baselining is required.
The source object is sparse. It does not provide a tactic, detection query, data source mapping, mitigation object, procedure examples, attribution, or exploitation context. Do not treat this as evidence of active exploitation or as a complete detection without environment-specific validation.
Analytic 1640
SSH login via hostd or `/var/log/auth.log`, followed by CLI access to host shell or file manipulation in restricted areas.
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 | 3a7febc92376… |
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 AN1640Open 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.