T1680: Local Storage Discovery
MITRE ATT&CK T1680: Local Storage Discovery Technique details for ESXi, IaaS, Linux, with detection guidance, relationships and mapped CVEs.
Security context for executives and security teams
Local Storage Discovery matters because it is often the adversary’s inventory step before deciding what to encrypt, move toward, or access directly. For executives and security leaders, the business issue is not the disk-listing command itself; it is whether the organization can see when servers, endpoints, ESXi hosts, or cloud accounts are being surveyed for storage that may contain critical data or virtual machines.
Executive priority
Prioritize this technique where storage availability and data recovery are business-critical: virtualization platforms, cloud block storage, file-heavy servers, and systems supporting regulated or operationally important data. Leaders should ask whether SOC and IR teams can distinguish normal administrative storage inventory from unusual discovery, especially in ESXi and IaaS environments where storage enumeration may precede ransomware-related encryption, lateral movement, or direct volume access. This also supports audit and resilience evidence: teams should be able to show logging, alert logic, and response playbooks for suspicious storage discovery across Windows, Linux, macOS, ESXi, and cloud control planes.
Technical view
ATT&CK lists this as a Discovery technique across ESXi, IaaS, Linux, macOS, and Windows. Validate visibility for local drive, disk, volume, partition, filesystem, and cloud disk enumeration. On endpoints and servers, detection engineering should focus on process and command-line telemetry for storage-discovery utilities and APIs referenced by ATT&CK, including Windows logical disk and PowerShell drive enumeration, Linux disk and filesystem listing utilities, macOS storage inventory commands, and ESXi hypervisor CLI activity. In cloud, validate audit logging for storage listing actions such as AWS volume description, GCP disk listing, and Azure disk listing. Relationship context shows this behavior is mapped to multiple ATT&CK campaigns, groups, and software, and DET0188 is a related detection strategy for drive enumeration and filesystem probing; use that context to test coverage without assuming any specific actor is present.
Likely telemetry
- Endpoint process creation and command-line logs for storage, drive, partition, and filesystem enumeration utilities
- PowerShell activity and script/block logging where available for drive discovery behavior
- Windows API or EDR-derived drive enumeration signals where available
- Linux and macOS shell command telemetry for disk, volume, mount, and filesystem listing
- ESXi shell or hypervisor CLI logs, especially storage and virtual disk inventory activity
Detection direction
- Baseline legitimate storage inventory activity by administrators, backup tooling, monitoring agents, and cloud automation to reduce false positives.
- Alert more strongly when storage discovery is performed by unusual users, unexpected processes, newly observed scripts, remote sessions, or accounts that do not normally manage storage.
- Correlate local storage enumeration with adjacent suspicious behavior, especially credential use, lateral movement attempts, direct volume access indicators, or rapid file/VM targeting patterns.
- For ESXi, confirm that hypervisor command activity and virtual disk inventory events are collected; many endpoint-centric SOC programs have weak visibility on virtualization hosts.
- For IaaS, confirm cloud audit logs capture disk and volume list/read operations and include identity, source, region/project/subscription, and API client context.
Mitigation priorities
- Start with visibility: ensure endpoint, server, ESXi, and cloud audit logging can capture storage enumeration with user and process context.
- Apply least privilege for storage administration in operating systems, hypervisors, and cloud accounts so routine users and workloads cannot broadly inventory disks or volumes without need.
- Harden and monitor privileged access paths used for storage management, including administrative shells, PowerShell, hypervisor CLI access, and cloud CLIs/APIs.
- Document approved administrative storage discovery workflows so the SOC has an allowlist baseline and can escalate deviations quickly.
- Integrate storage discovery alerts into ransomware and lateral-movement response playbooks, with emphasis on protecting backups, virtual machines, and critical data stores.
Additional notes and limits
The supplied ATT&CK object has broad platform coverage and useful examples, but no official detection guidance. The strongest defensive value comes from correlating otherwise common administrative commands or cloud API calls with identity, host, timing, and follow-on behavior. Relationship context indicates this technique is used by numerous ATT&CK-tracked campaigns, groups, and software, but that should be treated as prioritization context rather than evidence of a specific intrusion.
This take uses only the provided ATT&CK fields, references, and relationships. It does not establish active exploitation, actor attribution, customer exposure, or guaranteed detection coverage. Local baselines, logging configuration, EDR/cloud audit capabilities, and administrative workflows are required to determine actual risk and detection quality.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Local Storage Discovery
No official description is available in the imported ATT&CK source object.
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.
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.
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.