AN0232: Analytic 0232
Adversary modifies ESXi host login banner or MOTD file (/etc/motd), either through SSH or host console access. May involve configuration file overwrite or API calls from compromised vSphere clients.
Analyst context for executives and security teams
This analytic is about changes to an ESXi host’s login banner or message-of-the-day file. On its own, a banner change may look administrative, but in a virtualization environment it can also be a sign that someone has gained SSH, console, or vSphere-client-mediated access to a host and is altering local configuration. For executives and security leaders, the decision value is whether ESXi host configuration changes are visible, attributable, and reviewable before they become part of a broader incident involving critical virtual infrastructure.
Executive priority
Prioritize this as a virtualization control and auditability question: can the organization prove who changed ESXi host local files or banner settings, from where, and through which access path? Because the supplied object is limited to ESXi and does not include impact or attribution, it should not be treated as evidence of a specific threat by itself. It is most useful for validating privileged access governance, change-control evidence, SOC visibility into hypervisor administration, and incident response readiness for critical infrastructure hosted on ESXi.
Technical view
Validate monitoring around ESXi host configuration changes to /etc/motd and any supported mechanisms that can alter the login banner, including SSH, host console access, and API-driven changes from compromised or misused vSphere clients. Since ATT&CK provides no official detection logic for AN0232, detection engineering should focus on building environment-specific baselines for authorized ESXi administration, expected maintenance windows, and approved configuration-management activity. IR teams should treat unexpected MOTD or banner modification as a prompt to review ESXi authentication, session history, source systems, and related vSphere client activity rather than as a standalone conclusion.
Likely telemetry
- ESXi host authentication and session logs for SSH and console access
- ESXi system and shell activity logs showing local file or configuration changes
- File integrity or configuration monitoring for /etc/motd and login banner settings
- vCenter or vSphere task, event, and API audit logs tied to host configuration changes
- Privileged account activity records for administrators and service accounts with ESXi access
Detection direction
- Confirm whether ESXi logs and vCenter/vSphere audit events are collected centrally and retained long enough for incident review.
- Alert on modification of /etc/motd or ESXi login banner settings when not tied to approved change windows, known administrative sources, or authorized automation.
- Correlate banner or MOTD changes with SSH logins, console access, vSphere API activity, and privileged account use to reduce false positives from legitimate administration.
- Tune for local operational practices, because banners may be intentionally changed for legal notices, maintenance messaging, or compliance wording.
- Watch for blind spots where direct host access bypasses vCenter-centered monitoring or where ESXi shell access is enabled but not adequately logged.
Mitigation priorities
- Establish approved change-control for ESXi login banners and MOTD content, including documented owners and expected update mechanisms.
- Restrict and review SSH, console, and vSphere administrative access to ESXi hosts using least privilege and strong privileged-access governance.
- Centralize ESXi and vSphere audit logging so host-level changes can be investigated even if the host is later unavailable.
- Use configuration baselines or file integrity monitoring for ESXi host settings where operationally supported.
- Regularly test incident response procedures for suspicious ESXi configuration changes, including validation of accounts, source systems, and related vSphere activity.
Analyst notes and limits
AN0232 is a detection analytic object, not a technique, and no tactics or relationship context were supplied. Its value is therefore in guiding validation of ESXi host-change visibility rather than mapping a complete adversary behavior chain. The official description specifically mentions modification of the ESXi host login banner or /etc/motd through SSH, host console access, or API calls from compromised vSphere clients.
The official object does not provide detection logic, relationships, tactics, procedures, attribution, or impact statements. Any assessment of maliciousness requires local evidence such as change tickets, administrator activity, ESXi/vSphere logs, and baseline configuration data. This take should not be read as claiming active exploitation or guaranteed detection coverage.
Analytic 0232
Adversary modifies ESXi host login banner or MOTD file (/etc/motd), either through SSH or host console access. May involve configuration file overwrite or API calls from compromised vSphere clients.
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 | 4c90246d0bd5… |
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 AN0232Open 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.