AN1558: Analytic 1558
Detection of unset HISTFILE or modified history variables in ESXi shell sessions. Correlation of suspicious shell sessions with no recorded commands despite active usage.
Analyst context for executives and security teams
This analytic matters because ESXi shell history can be one of the few straightforward records of hands-on-keyboard activity on a virtualization host. If HISTFILE is unset or shell history variables are modified, responders may lose command-level evidence needed to understand what happened on an ESXi system. For leaders, the practical issue is not just detecting a variable change; it is whether the organization can preserve enough host activity evidence to make timely containment, recovery, and audit decisions after suspicious ESXi administration.
Executive priority
Prioritize this as an evidence-readiness and resilience control for ESXi environments. Security leaders should ask whether ESXi shell access is monitored, whether command history tampering is visible, and whether incident responders have alternate telemetry when shell history is missing. This is especially important where ESXi supports critical workloads, because weak host-level evidence can slow scope determination, recovery confidence, and compliance reporting after an incident.
Technical view
For SOC, detection engineering, and IR teams, validate visibility into ESXi shell sessions where HISTFILE is unset or history-related variables are modified. The supplied ATT&CK object describes correlating suspicious shell sessions with active usage but no recorded commands. Detection should therefore not rely only on the absence of history; it should be compared with evidence of shell activity, authentication, session start and stop events, and administrative actions on the ESXi host. Because no official detection logic is provided, teams should develop and test local analytics against their ESXi logging configuration and operational administration patterns.
Likely telemetry
- ESXi shell session start, stop, and authentication records
- Shell environment variable changes related to HISTFILE or command history behavior
- Command history files or evidence that expected history records are absent
- Administrative activity on ESXi hosts during the same time window
- Centralized log collection from ESXi hosts and management infrastructure
Detection direction
- Confirm whether ESXi shell activity and relevant environment changes are collected centrally before assuming this analytic is feasible.
- Correlate missing or empty command history with independent signs of active shell usage to reduce false positives from short, automated, or restricted administrative sessions.
- Tune against approved maintenance workflows where shell history may be intentionally disabled by policy or automation.
- Alert quality should emphasize suspicious combinations: active shell session, history variables changed or unset, and no recorded commands when commands would normally be expected.
- Document visibility gaps where ESXi hosts do not forward sufficient shell or administrative logs.
Mitigation priorities
- Restrict and govern ESXi shell access so interactive use is limited, approved, and attributable.
- Centralize ESXi logging so local history loss does not eliminate investigative evidence.
- Define administrative baselines for expected shell history behavior and investigate deviations.
- Ensure IR playbooks include alternate evidence sources when ESXi shell history is unavailable.
- Review compliance and audit requirements for privileged access evidence on virtualization infrastructure.
Analyst notes and limits
This is a detection analytic object for ESXi only. The official description focuses on unset HISTFILE or modified history variables and correlation with active shell sessions that have no recorded commands. No tactics, related techniques, detection logic, groups, software, or campaigns were supplied, so this take frames the behavior around evidence preservation and defensive validation rather than attribution or impact.
The object provides no official detection query and no relationship context. Local ESXi configuration, logging levels, administrative practices, and centralized collection determine whether this behavior can be detected reliably. Absence of command history alone is not sufficient to conclude malicious activity.
Analytic 1558
Detection of unset HISTFILE or modified history variables in ESXi shell sessions. Correlation of suspicious shell sessions with no recorded commands despite active usage.
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 | 002ce056244a… |
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 AN1558Open 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.