Detecting Local Storage Discovery (MITRE ATT&CK T1680)

Local Storage Discovery (T1680) is a Discovery technique in which adversaries list local drives, disks and volumes, along with attributes such as total and free space and volume serial number. MITRE lists ESXi, IaaS, Linux, macOS and Windows as platforms.

How attackers use it

MITRE gives three purposes: preparing for ransomware-related encryption, supporting Lateral Movement, and acting as a precursor to Direct Volume Access (T1006).

The commands depend on the platform:

• ESXi. Hypervisor CLI (T1059.012) commands such as esxcli to list storage attached to the host, and to find .vmdk files.
• Windows. wmic logicaldisk get to find information about local and network drives, PowerShell Get-PSDrive, and Windows API functions such as GetDriveType.
• Linux. parted, lsblk, fdisk, lshw and df list partitions, with size, type, file system and free space.
• macOS. diskutil to list disks, and system_profiler SPStorageDataType for details such as mount path, file system and drive type.
• IaaS. Provider commands such as describe volume in AWS, gcloud compute disks list in GCP and az disk list in Azure.

The technique page lists a long set of malware and ransomware that enumerate volumes, read disk size or free space, or collect the volume ID.

How to detect it

The hard part is that every one of these commands is also legitimate. System inventory tools, backup software and admins use them daily. MITRE's detection strategy focuses on context:

• Windows. Drive enumeration with Get-PSDrive, wmic logicaldisk or Win32 API calls by non-admin users, or outside baseline inventory scripts.
• Linux. Unusual use of lsblk, fdisk -l, lshw -class disk or parted by non-admin users or in non-interactive shells.
• macOS. diskutil list or system_profiler SPStorageDataType run outside user login or unrelated to system inventory tools.
• ESXi. esxcli storage or vim-cmd vmsvc/getallvms from unusual sessions, or from interactive shells unrelated to maintenance.

Build a baseline first. If a certain service account runs df every five minutes, that is background. If a web server account suddenly lists disks, that is a lead.

On its own, storage discovery is a low-severity signal. It becomes a strong one when it appears with other discovery commands, a new account, or the staging of data.

How to reduce the risk

MITRE lists no formal mitigation for this technique since it abuses legitimate features. The useful controls reduce what an adversary can do next:

• Limit shell access and interactive logins on servers and hypervisors.
• Use least privilege so that service accounts cannot reach every volume.
• Keep backups on storage that the compromised host cannot modify.
• Alert on discovery commands run by accounts that do not normally administer systems.

Check your own environment

These read-only commands show what an adversary would see, so you know what a baseline looks like.

Linux:

lsblk
df -h

macOS:

diskutil list

Windows PowerShell:

Get-PSDrive -PSProvider FileSystem

Then check:

• Which accounts and scripts routinely run these commands?
• Is command line logging enabled on your servers, so you could see who ran one?
• Are backup volumes writable from the hosts they protect?

Quick check

Sources

• MITRE ATT&CK, Local Storage Discovery (T1680): https://attack.mitre.org/techniques/T1680