AN0605: Analytic 0605
Ransomware encrypts .vmdk, .vmx, .log, or VM config files in VMFS datastores. May rename to .locked or delete/overwrite with encrypted versions. Often correlates with shell commands run through `dcui`, SSH, or vSphere.
Analyst context for executives and security teams
This analytic matters because it focuses on ransomware behavior against ESXi VMFS datastores: encryption, renaming, deletion, or overwrite of virtual disk, VM configuration, and log files. For business leaders, this is a high-consequence resilience scenario because affected ESXi-hosted workloads may become unavailable at scale, including systems that support critical operations, recovery tooling, and audit evidence.
Executive priority
Prioritize this as a virtualization resilience and incident-readiness question: can the organization quickly see suspicious changes to .vmdk, .vmx, .log, and VM configuration files on ESXi, and can responders correlate those changes with administrative access paths such as dcui, SSH, or vSphere? The business decision value is in validating whether monitoring, backup/recovery, privileged access governance, and IR procedures cover the hypervisor layer—not only guest operating systems.
Technical view
The supplied ATT&CK analytic is scoped to ESXi and describes ransomware encryption activity in VMFS datastores, including renaming files to .locked or deleting/overwriting files with encrypted versions. SOC and IR teams should validate whether they can observe datastore file changes affecting VM disk and configuration artifacts and correlate those events with shell commands or administrative sessions through dcui, SSH, or vSphere. No official detection logic is provided, so teams should treat this as a detection engineering requirement rather than a ready-to-run rule.
Likely telemetry
- ESXi host logs relevant to shell activity and administrative access
- vSphere management activity and task/event records
- SSH session and command execution evidence on ESXi hosts
- dcui-related administrative activity where available
- VMFS datastore file change evidence for .vmdk, .vmx, .log, and VM configuration files
Detection direction
- Validate visibility into VMFS datastore changes involving virtual disk, VM configuration, and log files, especially bulk modification, deletion, overwrite, or rename patterns.
- Correlate suspicious datastore file activity with administrative access paths named in the ATT&CK description: dcui, SSH, and vSphere.
- Tune detections to distinguish legitimate administrative maintenance, backup, migration, or snapshot operations from abnormal high-volume or destructive file changes.
- Identify blind spots where ESXi shell access, vSphere task history, or datastore file activity is not centrally logged or retained.
- Because ATT&CK provides no official detection text for this analytic, require local baselining and testing before treating any alert as production-ready.
Mitigation priorities
- Confirm that ESXi administrative access paths are governed, logged, and reviewed, including SSH, dcui, and vSphere activity.
- Prioritize recovery readiness for ESXi-hosted workloads, including protected backups and tested restoration of affected virtual disks and VM configuration files.
- Ensure SOC and IR playbooks explicitly cover hypervisor and datastore ransomware scenarios, not only endpoint ransomware inside guest VMs.
- Review least-privilege and privileged access controls around virtualization administration.
- Retain sufficient ESXi, vSphere, and datastore-related telemetry to support incident scoping and compliance evidence after a destructive event.
Analyst notes and limits
This is a detection analytic object, not a full technique entry. Its value is in highlighting a specific ESXi ransomware behavior pattern against VMFS datastore artifacts and the access paths that may correlate with it. Use it to drive control validation for virtualization monitoring, privileged access, and recovery operations.
The supplied object has no tactics, no relationship context, and no official detection logic. It does not identify actors, campaigns, active exploitation, impact frequency, or guaranteed detection methods. Local ESXi architecture, logging configuration, retention, and administrative workflows are required to determine practical coverage.
Analytic 0605
Ransomware encrypts .vmdk, .vmx, .log, or VM config files in VMFS datastores. May rename to .locked or delete/overwrite with encrypted versions. Often correlates with shell commands run through `dcui`, SSH, or vSphere.
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 | 3c8010a5c329… |
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 AN0605Open 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.