AN0890: Analytic 0890
Unusual ESXi shell commands disabling syslog forwarding or stopping hostd/vpxa daemons. Detect modifications to firewall rules on ESXi host or disabling of lockdown mode.
Analyst context for executives and security teams
This analytic matters because it focuses on ESXi host activity that can weaken visibility or management control, such as unusual shell commands that disable syslog forwarding, stop host management daemons, modify firewall rules, or disable lockdown mode. For executives and security leaders, the practical issue is not just a single command: it is whether the organization can still monitor, manage, and investigate virtualization infrastructure when host-level controls are changed.
Executive priority
Prioritize this as a resilience and incident-readiness validation for VMware ESXi environments. Leaders should ask whether ESXi administrative actions are centrally logged, whether changes to logging, firewall rules, lockdown mode, and host management services generate reviewable evidence, and whether the SOC can distinguish approved maintenance from suspicious visibility-reduction behavior. This is also relevant to audit and compliance evidence because disabled forwarding or altered host controls can create investigation gaps.
Technical view
For SOC, detection engineering, and IR teams, validate monitoring for ESXi shell activity and configuration changes involving syslog forwarding, hostd/vpxa daemon state, ESXi firewall rules, and lockdown mode. Because no ATT&CK detection logic is provided, teams should build or review local detections around change events and command execution evidence on ESXi hosts, then tune against known administrative workflows such as maintenance windows, troubleshooting, patching, and authorized infrastructure changes.
Likely telemetry
- ESXi shell command execution logs or equivalent host activity records
- ESXi syslog forwarding configuration changes
- Service state changes for hostd and vpxa daemons
- ESXi firewall rule or ruleset modification events
- Lockdown mode enablement or disablement events
Detection direction
- Confirm ESXi hosts forward logs to a central location and that alerting still works if forwarding is disabled or interrupted.
- Create or validate alerts for stopping hostd or vpxa, disabling lockdown mode, modifying ESXi firewall rules, and changing syslog forwarding settings.
- Tune detections against authorized maintenance and break-glass administration to reduce false positives without suppressing high-risk changes.
- Correlate ESXi configuration changes with administrative identity, source system, maintenance ticket, and timing where those data sources are available.
- Treat missing or suddenly reduced ESXi telemetry as a detection signal, not only explicit suspicious commands.
Mitigation priorities
- Establish baseline ESXi configurations for syslog forwarding, firewall rules, lockdown mode, and required management services.
- Restrict and review administrative access to ESXi shell and host configuration functions.
- Require change control for ESXi logging, firewall, lockdown mode, and management daemon changes.
- Ensure central logging is resilient enough to retain evidence when host-level logging settings are altered.
- Regularly test SOC and IR playbooks for ESXi management-plane visibility loss and recovery.
Analyst notes and limits
This object is a detection analytic for ESXi and provides a concise behavior description but no formal detection logic, tactic mapping, or relationship context. The highest-value use is as a control-validation prompt: can the organization see and explain changes that reduce ESXi logging, management availability, or host hardening?
The supplied ATT&CK fields do not include detection pseudocode, data source mappings, mitigations, tactics, procedures, or related techniques. Local ESXi versioning, logging configuration, administrative model, and change-management records are required to determine coverage and severity.
Analytic 0890
Unusual ESXi shell commands disabling syslog forwarding or stopping hostd/vpxa daemons. Detect modifications to firewall rules on ESXi host or disabling of lockdown mode.
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 | 54d19e31821f… |
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 AN0890Open 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.