T1680 Local Storage Discovery: Detecting Drive and Volume Enumeration

Ransomware, wipers and espionage implants all ask the same early question on a new host: which drives and volumes exist, how big are they and what is on them. MITRE ATT&CK T1680 Local Storage Discovery covers adversaries enumerating local drives, disks and volumes and their attributes, such as total and free space and the volume serial number. ATT&CK v20 places it in the Discovery tactic (TA0007) for ESXi, IaaS, Linux, macOS and Windows. Because the same queries are made constantly by inventory agents, backup tools and the operating system itself, this guide focuses on the context that separates attacker enumeration from normal noise, MITRE's detection strategy DET0188, cloud volume discovery, and how to test and measure coverage. It is written for detection engineers and SOC analysts.

Key takeaways

• It is near universal in malware. ATT&CK v20 links more than 100 groups, campaigns and software entries to T1680, from LockBit, BlackCat, Black Basta and Royal to wipers such as HermeticWiper and WhisperGate.
• The purpose varies. ATT&CK lists preparation for ransomware encryption, lateral movement and Direct Volume Access (T1006). Many implants also use the volume serial number as a victim identifier.
• Single events are worthless alone. Drive queries happen on every host every day. Detect the combination: an unexpected process, user or parent, plus other discovery, plus what follows.
• Much of it is API based. Malware often calls Windows functions such as GetLogicalDrives and GetDriveType directly, so command line rules catch only the hands-on-keyboard cases; EDR behaviour analytics carry the rest.
• Cloud has its own version. AWS, Azure and Google Cloud expose disk listing through their APIs, so a stolen cloud credential can map every volume without touching a host.

What T1680 covers

ATT&CK describes adversaries enumerating local drives, disks or volumes and their attributes. It names the utilities on each platform, listed here at the level needed for detection logic:

Microsoft documents that Get-PSDrive returns Windows logical drives including drives mapped to network shares, plus PowerShell provider drives such as the registry and certificate stores, which is why a single call can reveal both local volumes and the shares a user has mapped. Browsing the contents of those drives is T1083 File and Directory Discovery, and reading data from them is T1005 Data from Local System; this page covers the storage layout step only.

How adversaries use it: recorded cases

The TeamTNT entry links to a wider pattern on cloud hosts. The TeamTNT Worm 2020 breach page describes the same group's worm spreading through exposed Docker APIs and stealing the AWS CLI credential files from user home directories. Host discovery and credential theft went together: once the worm knew the host, it went straight for the machine credentials stored on it.

Volume serial numbers as victim IDs

A recurring use is identification rather than targeting. ATT&CK records CORESHELL, Zebrocy, Sardonic, StrongPity, FELIXROOT, TONESHELL and others collecting the volume serial number, and SampleCheck5000 building unique victim identifiers from it. TONESHELL used a WMI query against win32_logicaldisk for this. A process querying the system volume serial number and then beaconing is a useful correlation for implant detection.

What to detect and where

ATT&CK v20 maps detection strategy DET0188, Local Storage Discovery via Drive Enumeration and Filesystem Probing, to T1680 with four analytics. The table restates them with practical tuning.

MITRE's IaaS platform has no analytic in DET0188, so the cloud row below is NHI Mgmt Group's recommendation.

Cloud volume discovery

AWS documents that EC2 DescribeVolumes returns each volume's size, encryption status, source snapshot, state and attachments, including the instance and device it is attached to. That is enough to pick targets for snapshot sharing or theft. Make sure your CloudTrail trails keep read-only management events (event history records them by default) (or the Azure Activity Log and Google Cloud Admin Activity and Data Access logs) and alert when a principal that has never listed volumes does so, especially in many Regions or projects in a short window, or right after a new access key is first used. The T1580 and T1619 Cloud Infrastructure and Storage Discovery Guide covers the wider cloud discovery picture.

Behaviour sequences worth an alert

1. A newly seen or unsigned process enumerates drives, then queries shadow copies, then a service stop or vssadmin delete follows. This is the ransomware lead-in; see the T1490 Inhibit System Recovery Defensive Guide.
2. Drive enumeration followed by a raw handle to \\.\PhysicalDrive0 or a volume device, which points to Direct Volume Access or wiping. See the MITRE ATT&CK T1006 Direct Volume Access guide.
3. A burst of discovery from one process within a minute: system information, users, network configuration and drives. Single queries are noise; the burst is the signal.
4. Volume serial number query from a process that then makes its first outbound connection.
5. Disk listing from a web application or container process on a Linux server.

Mitigations and controls

ATT&CK v20 maps no mitigations to T1680; the information is available to any process by design. Controls therefore aim at the actor and at what follows. These are NHI Mgmt Group recommendations:

• Application control: limit which binaries can run on servers, so an unknown implant cannot run at all.
• Restrict interactive utilities on servers: where operationally possible, block or alert on wmic and script hosts for non-admin users; Microsoft has deprecated WMIC, which makes its use on modern builds more suspicious.
• Protect recovery data: keep backups offline or immutable and protect shadow copies, so discovery of every volume does not translate into loss of every volume.
• Cloud least privilege: do not grant ec2:DescribeVolumes and similar list rights through broad read-only policies to workload roles that do not need them, and scope snapshot sharing permissions tightly.
• Remove stored credentials from hosts: the TeamTNT case shows discovery and credential theft travelling together; long-lived cloud keys in home directories should be replaced with instance roles or short-lived credentials.

Where identity fits

On cloud platforms T1680 is performed with an identity, not a binary: whichever role, access key or service account the attacker holds. Workload roles that inherited a broad read-only policy can list every volume and snapshot in the account. Review which non-human identities have storage list rights, alert on their use from outside their expected compute, and treat a leaked key as able to map all storage it can read. The Cloud Access Key Leak Playbook covers the response.

Common failure patterns

• Alerting on every wmic logicaldisk or lsblk: the rule is muted within a week and the real case is lost in the noise.
• Allow-listing by process name only: malware that names itself after an inventory agent passes; allow-list by signer, path and parent.
• Command line rules only: API based enumeration by ransomware never spawns a utility, so coverage that stops at process creation misses most families in the table above.
• Cloud read events not collected: trails configured for write events only cannot show volume listing by a stolen key.
• No link to the next step: analysts triage the discovery alert alone and miss the shadow copy deletion five minutes later.

How to test your coverage

1. Baseline first: collect a week of drive enumeration events by process, signer, parent and user on servers and workstations, and record the legitimate sources.
2. Emulate in a test window: on lab hosts, run drive and volume listing from a non-admin shell, from a script host and from a new unsigned test binary; on a test cloud account, list volumes from a fresh test principal in several Regions.
3. Confirm telemetry and correlation: check the events arrive and that the burst and sequence rules fire, while the baselined agents stay quiet.
4. Roll back: remove the test binary and principal and record results against DET0188 in your coverage map.

Metrics

• Percentage of servers sending process creation with command line and PowerShell script block logs.
• Number of drive enumeration alerts per week closed as benign, as an allow-list health measure.
• Percentage of cloud accounts capturing read-only management events centrally.
• Median time from a test enumeration sequence to an alert.
• Number of workload roles holding storage list permissions they have not used in 90 days.

Framework mapping

Practitioner checklist

• Baseline legitimate drive enumeration by signer, path and parent before writing rules.
• Capture process command lines and PowerShell script block logs on servers.
• Correlate drive enumeration with other discovery, shadow copy queries and raw disk access.
• Rely on EDR behaviour analytics for API based enumeration, not only command lines.
• Collect cloud read-only management events and alert on new principals listing volumes.
• Remove long-lived cloud keys from hosts and scope storage list rights for workload roles.
• Keep immutable or offline backups so discovery of every volume does not mean loss of every volume.
• Test the analytics and record results against DET0188.

Standards and references

• MITRE ATT&CK: T1680 Local Storage Discovery
• CISA: #StopRansomware: LockBit 3.0 (AA23-075A)
• Microsoft: Volt Typhoon targets US critical infrastructure with living-off-the-land techniques
• Microsoft Learn: Get-PSDrive
• AWS: EC2 DescribeVolumes API Reference
• MITRE ATT&CK: T1006 Direct Volume Access

Related NHI Mgmt Group resources: MITRE ATT&CK T1006 Direct Volume Access · MITRE ATT&CK T1486 Data Encrypted for Impact · LockBit Threat Actor Profile · Volt Typhoon Threat Actor Profile · Sysmon Guide · MITRE ATT&CK T1082 System Information Discovery Guide · MITRE ATT&CK T1083 File and Directory Discovery Guide · MITRE ATT&CK T1673 Virtual Machine Discovery Guide