AN0670: Analytic 0670
Detection of syslog configuration tampering using esxcli system syslog config set or reload. Defender correlates command execution with absence of syslog forwarding activity.
Analyst context for executives and security teams
This analytic matters because ESXi syslog forwarding is often a key evidence source during a virtualization incident. If an attacker or unauthorized administrator changes or reloads syslog configuration and forwarding then goes quiet, the organization may lose visibility exactly when it needs it for containment, recovery, audit, and root-cause analysis.
Executive priority
Treat this as a resilience and evidence-integrity control for VMware ESXi environments. Security leaders should ask whether ESXi command activity and syslog forwarding health are monitored together, not separately. The business issue is not only configuration change; it is whether incident responders can still trust that critical infrastructure logs are being exported when investigating disruption or compromise.
Technical view
For ESXi, validate monitoring for command execution involving `esxcli system syslog config set` or `esxcli system syslog config reload`, then correlate that activity with reduced or absent syslog forwarding. Because the official detection field is not provided and no ATT&CK relationships or tactics are supplied, teams should implement this as a behavior-specific detection analytic rather than infer broader technique coverage. Useful validation includes testing authorized syslog maintenance, reloads, configuration changes, and expected forwarding patterns so alerts distinguish legitimate administration from suspicious loss of telemetry.
Likely telemetry
- ESXi command execution records showing `esxcli system syslog config set` or `reload` activity
- ESXi syslog configuration change evidence
- Syslog forwarding activity or absence of expected forwarded events
- Central log collector or SIEM ingestion status for ESXi sources
- Administrative change records or maintenance windows for ESXi logging changes
Detection direction
- Correlate ESXi syslog configuration commands with a subsequent absence or drop in syslog forwarding activity.
- Tune for legitimate maintenance, planned logging changes, and troubleshooting reloads to reduce false positives.
- Alert on configuration change plus telemetry loss rather than command execution alone where possible.
- Validate that the SIEM or log pipeline can detect both the command event and the absence of forwarded logs; absence-based detections commonly fail when source inventory or heartbeat expectations are incomplete.
- Do not assume coverage beyond ESXi because the supplied platform is ESXi only and no relationship context is provided.
Mitigation priorities
- Maintain an authoritative inventory of ESXi hosts expected to forward syslog.
- Require change control for ESXi syslog configuration changes and reloads.
- Monitor log forwarding health with heartbeat or expected-volume checks for each ESXi host.
- Restrict and review administrative access capable of changing ESXi syslog configuration.
- Ensure incident response playbooks include verification of ESXi log forwarding integrity before relying on collected logs.
Analyst notes and limits
AN0670 is a detection analytic for ESXi syslog configuration tampering. The supplied ATT&CK text specifically names `esxcli system syslog config set` and `esxcli system syslog config reload` and describes correlation with absence of syslog forwarding activity. No tactics, relationships, aliases, labels, or official detection logic were supplied.
This take is limited to the official STIX fields, external reference, and supplied context. It does not establish active exploitation, adversary attribution, impact, or complete detection coverage. Local ESXi logging architecture, command telemetry availability, syslog collector behavior, and approved administration patterns are required to operationalize and tune the analytic.
Analytic 0670
Detection of syslog configuration tampering using esxcli system syslog config set or reload. Defender correlates command execution with absence of syslog forwarding activity.
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 | 339d09de31aa… |
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 AN0670Open 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.