AN0660: Analytic 0660
Detection of changes to /etc/rc.local.d/local.sh or rc.local during post-boot script execution with abnormal commands or additions.
Analyst context for executives and security teams
AN0660 is a detection analytic for ESXi hosts focused on suspicious changes to post-boot startup scripts, specifically /etc/rc.local.d/local.sh or rc.local. For leaders, the practical issue is persistence risk on virtualization infrastructure: if unauthorized commands are added to boot-time scripts, activity can survive reboots and affect systems that many business services depend on.
Executive priority
Prioritize this as a virtualization resilience and incident-readiness question: do teams have evidence of who changed ESXi startup scripts, when they changed, and what commands were added? This matters for business continuity because ESXi hosts often support critical workloads, and weak visibility into host-level persistence can slow containment, recovery, and audit explanation after an incident.
Technical view
SOC, detection engineering, and IR teams should validate whether ESXi file-integrity, configuration-change, and administrative activity telemetry can show modifications to /etc/rc.local.d/local.sh or rc.local and the content of abnormal additions. Because the official ATT&CK object provides no detection logic and no relationship context, local baselining is essential: distinguish expected administrative changes from unusual commands, unexpected persistence entries, or changes occurring outside approved maintenance windows.
Likely telemetry
- ESXi host file modification events for /etc/rc.local.d/local.sh and rc.local
- File integrity monitoring or configuration compliance snapshots for ESXi hosts
- Administrative login and command activity on ESXi hosts
- Change-management records for approved ESXi startup script modifications
- Host reboot or post-boot execution context where available
Detection direction
- Confirm whether changes to /etc/rc.local.d/local.sh or rc.local are logged centrally and retained long enough for investigation.
- Baseline legitimate startup script contents across ESXi hosts and alert on unauthorized additions or abnormal commands.
- Correlate script changes with administrative authentication, maintenance windows, and approved change tickets to reduce false positives.
- Review blind spots where ESXi host logs are local-only, overwritten, inconsistently collected, or not mapped into SOC detection workflows.
- Because no official detection logic is supplied, treat this analytic as a validation target rather than a ready-to-run rule.
Mitigation priorities
- Restrict and review administrative access to ESXi hosts.
- Use configuration management or file integrity monitoring to detect and evidence unauthorized startup script changes.
- Require change approval and documentation for ESXi boot-time script modifications.
- Centralize ESXi administrative and configuration telemetry for SOC and incident response use.
- Periodically compare ESXi startup script contents against known-good baselines.
Analyst notes and limits
This object is a detection analytic, not a technique record. The supplied ATT&CK fields identify the platform as ESXi and the behavior as changes to post-boot scripts with abnormal commands or additions. No tactics, relationships, or official detection procedure were provided, so defensive value depends on local ESXi logging, baselining, and change-control evidence.
No relationship context, tactic mapping, detection pseudocode, data source list, mitigation mapping, or procedure examples were supplied. This take should not be read as evidence of active exploitation, attribution, impact, or guaranteed detection coverage.
Analytic 0660
Detection of changes to /etc/rc.local.d/local.sh or rc.local during post-boot script execution with abnormal commands or additions.
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 | aade3069bb18… |
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 AN0660Open 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.