AN0175: Analytic 0175
Detects Python script or interpreter execution on ESXi hosts via embedded BusyBox shells, nested installations, or dropped files via SSH or datastore mount. Flags unusual scripting or post-compromise enumeration behavior.
Analyst context for executives and security teams
This analytic is about spotting Python script or interpreter activity on ESXi hosts, especially when it appears through BusyBox shells, nested or unusual installations, SSH-delivered files, or datastore-mounted files. For leaders, the significance is that ESXi is a business-critical virtualization layer: unexpected scripting there can indicate hands-on post-compromise activity, enumeration, or preparation for broader operational disruption. The value is not in assuming compromise, but in validating whether the organization can see and investigate unusual interpreter use on hypervisor infrastructure.
Executive priority
Prioritize this as a resilience and incident-readiness question for virtualization environments: do security teams have visibility into scripting activity on ESXi hosts, and is that visibility usable during an incident? Because no tactic mapping or relationship context is supplied, this should be treated as a targeted detection validation item rather than a complete risk statement. It is most relevant to managed detection scope, IR evidence collection, virtualization hardening, and audit evidence that privileged infrastructure is monitored.
Technical view
SOC and IR teams should validate whether ESXi host monitoring can identify Python interpreter or script execution from embedded BusyBox shells, unexpected nested installations, files dropped over SSH, or scripts run from datastore-mounted locations. Since the official detection logic is not provided, teams should translate the analytic description into local checks using available ESXi shell, SSH, file, process, and datastore telemetry. Baseline legitimate administrative scripting before alerting broadly, because virtualization administrators may use scripts for maintenance or troubleshooting.
Likely telemetry
- ESXi host shell activity, including BusyBox shell usage where available
- Process execution records or command-line evidence for Python interpreters and scripts on ESXi
- SSH access logs and related file transfer evidence to ESXi hosts
- Datastore file activity or mount-path evidence involving scripts or interpreter binaries
- Administrative session logs for privileged ESXi access
Detection direction
- Confirm whether ESXi telemetry includes enough process, shell, SSH, and datastore context to distinguish routine administration from unusual scripting.
- Look for Python execution paths or script locations that are abnormal for the environment, especially under datastore-mounted paths, dropped-file locations, or nonstandard nested installations.
- Tune detections against known administrative automation to reduce false positives, while preserving alerts for new script locations, new interpreter binaries, or scripting during unusual administrative sessions.
- Because ATT&CK provides no detection logic here, document the local rule assumptions, required logs, and known blind spots before treating the analytic as operational coverage.
- Use this analytic as a validation scenario for hypervisor incident response: can analysts reconstruct who accessed the host, what was executed, from where, and what files were introduced?
Mitigation priorities
- Restrict and review privileged SSH and shell access to ESXi hosts according to operational need.
- Maintain an approved baseline for administrative scripts, interpreter locations, and datastore paths used for maintenance.
- Harden and monitor ESXi management access so that unexpected scripting is not the first observable sign of misuse.
- Ensure IR playbooks include evidence preservation for ESXi shell history, SSH logs, datastore artifacts, and host configuration state.
- Periodically test whether monitoring and retention are sufficient to investigate scripting activity on ESXi without relying on guest VM telemetry.
Analyst notes and limits
The supplied object is a detection analytic for ESXi platforms only. It describes Python script or interpreter execution associated with BusyBox shells, nested installations, SSH-dropped files, or datastore mounts, and frames the behavior as unusual scripting or post-compromise enumeration. No ATT&CK tactics, related techniques, mitigations, procedures, or formal detection logic were supplied, so implementation must be based on local ESXi logging and administrative baselines.
Official detection content is not provided, and no relationship context is supplied. This take does not assert active exploitation, actor attribution, specific impact, or guaranteed detectability. Local ESXi configuration, logging depth, retention, and administrative practices will determine whether the analytic is practical.
Analytic 0175
Detects Python script or interpreter execution on ESXi hosts via embedded BusyBox shells, nested installations, or dropped files via SSH or datastore mount. Flags unusual scripting or post-compromise enumeration behavior.
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 | 97b85d028ff5… |
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 AN0175Open 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.