AN0519: Analytic 0519
Identify lateral transfer via datastore file uploads or internal scp/ssh sessions that result in new VMX/VMDK or script files. Correlate transfer with VM execution or datastore modification.
Analyst context for executives and security teams
This analytic matters because ESXi datastore file movement can be a signal that activity is spreading inside the virtualization layer, especially when new VM configuration, disk, or script files appear and are followed by VM execution or datastore changes. For leaders, the practical question is whether the organization can see and investigate file transfers inside ESXi environments, not just activity on guest operating systems.
Executive priority
Prioritize validation where ESXi supports critical workloads. Coverage gaps in datastore upload, scp/ssh, VM execution, and datastore modification logging can weaken incident response, audit evidence, and operational resilience during a virtualization-layer investigation. Security leaders should ask whether SOC and IR teams can quickly determine who transferred files, what changed on the datastore, and whether a VM was executed afterward.
Technical view
For ESXi environments, validate the ability to identify lateral transfer patterns involving datastore file uploads or internal scp/ssh sessions that create new VMX, VMDK, or script files. The key analytic value is correlation: file transfer alone may be benign administration, but transfer followed by VM execution or datastore modification should be reviewed with higher priority. No ATT&CK tactic or relationship context was supplied, so teams should map this analytic to local ESXi administration workflows and alert triage procedures.
Likely telemetry
- ESXi datastore file upload events or equivalent datastore modification records
- Internal scp/ssh session evidence involving ESXi hosts or datastores
- File creation metadata for VMX files, VMDK files, and scripts on datastores
- VM execution or power-on activity following file transfer
- Administrative authentication and session context for users or service accounts performing transfers
Detection direction
- Confirm whether ESXi telemetry captures datastore uploads and internal scp/ssh activity with enough user, source, destination, timestamp, and file-path detail for correlation.
- Tune for creation of new VMX, VMDK, or script files, especially when followed by VM execution or datastore modification.
- Separate expected administrative maintenance, backup, migration, and deployment activity from unusual transfer paths or timing to reduce false positives.
- Validate correlation windows between transfer, datastore change, and VM execution using local operational baselines.
- Treat absence of supplied tactic and relationship context as a limitation; do not assume broader intrusion behavior without local evidence.
Mitigation priorities
- Restrict and review administrative access paths to ESXi hosts and datastores, including accounts allowed to use ssh/scp where applicable.
- Maintain logging and retention sufficient to reconstruct datastore file transfers and subsequent VM activity.
- Establish change-control expectations for VMX, VMDK, and script creation on datastores so unexpected changes are reviewable.
- Ensure incident response playbooks include ESXi datastore triage and ownership validation for newly introduced VM artifacts.
- Periodically test SOC visibility by confirming that legitimate controlled datastore uploads and VM execution events are observable and correlated.
Analyst notes and limits
The supplied object is a detection analytic for ESXi, external ID AN0519, focused on identifying lateral transfer through datastore uploads or internal scp/ssh sessions that create new VMX/VMDK or script files and correlating those transfers with VM execution or datastore modification. No official detection logic, tactics, aliases, labels, or relationship context were supplied.
This take is limited to the official STIX fields, external reference, and the provided description. It does not assert active exploitation, adversary attribution, guaranteed detection, or applicability beyond ESXi. Local ESXi configuration, logging, administrative workflows, and retention determine whether this analytic is actionable.
Analytic 0519
Identify lateral transfer via datastore file uploads or internal scp/ssh sessions that result in new VMX/VMDK or script files. Correlate transfer with VM execution or datastore modification.
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 | 12b083db9ac7… |
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 AN0519Open 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.