DET0188: Local Storage Discovery via Drive Enumeration and Filesystem Probing
DET0188 is a detection strategy for identifying behavior associated with Local Storage Discovery: activity where an adversary enumerates local drives, disk...
Analyst context for executives and security teams
DET0188 is a detection strategy for identifying behavior associated with Local Storage Discovery: activity where an adversary enumerates local drives, disks, volumes, or filesystem attributes. This matters because storage discovery can be a preparatory step before disruptive actions such as ransomware-related encryption, lateral movement planning, or direct volume access. For leaders, the key question is whether the organization can see unusual storage enumeration across relevant environments such as ESXi, IaaS, Linux, and macOS systems before it becomes part of a larger incident.
Executive priority
Prioritize this as an operational resilience and incident-readiness control area rather than a standalone alert. Storage discovery may indicate an actor is mapping what data or systems are available to affect next. Executives should ask whether SOC and IR teams can identify abnormal drive, disk, volume, and filesystem probing on high-value systems, especially virtualization and cloud-hosted infrastructure, and whether that evidence is retained well enough to support investigation, containment decisions, and compliance reporting.
Technical view
This detection strategy detects ATT&CK technique T1680, Local Storage Discovery, under the Discovery tactic. The related technique covers enumeration of local drives, disks, volumes, and attributes such as total/free space and volume serial number. On ESXi, ATT&CK notes that hypervisor CLI activity such as esxcli may be used to list storage. Because the DET0188 object does not provide an official detection analytic or platform list, SOC teams should validate coverage against the related technique platforms: ESXi, IaaS, Linux, and macOS. Focus engineering on distinguishing routine administrative or monitoring inventory from unusual, repeated, or contextually suspicious storage enumeration, especially when correlated with other discovery, lateral movement, or direct volume access activity.
Likely telemetry
- Process execution and command-line telemetry from Linux and macOS systems where available
- ESXi or hypervisor command/activity logs, including evidence of storage-listing commands such as esxcli where collected
- Cloud/IaaS host telemetry and administrative activity logs relevant to disk, volume, and instance storage inspection
- Filesystem, disk, volume, or mount enumeration events where endpoint or host tooling records them
- User, service account, and administrative session context tied to storage enumeration activity
Detection direction
- Validate whether telemetry exists for the related platforms listed by ATT&CK: ESXi, IaaS, Linux, and macOS; the detection strategy object itself does not specify platforms.
- Build or review analytics for abnormal drive, disk, volume, mount, or filesystem probing, using local baselines for administrators, monitoring agents, backup tools, and inventory systems to reduce false positives.
- For ESXi environments, confirm visibility into hypervisor CLI activity and review storage enumeration patterns, including use of esxcli where logs support it.
- Correlate storage discovery with adjacent behaviors referenced by ATT&CK context, including lateral movement preparation and possible precursor activity to direct volume access.
- Avoid treating all storage enumeration as malicious; prioritize alerts when activity occurs from unusual accounts, unusual hosts, unusual timing, or in proximity to other discovery or intrusion behaviors.
Mitigation priorities
- Establish logging and retention for host, cloud/IaaS, and hypervisor activity that can show disk, volume, and filesystem enumeration.
- Limit administrative access to systems where storage visibility is sensitive, especially virtualization and infrastructure hosts, and review who can run storage-inspection commands.
- Baseline legitimate storage inventory, monitoring, backup, and administrative workflows so detections can focus on anomalous use rather than expected operations.
- Ensure incident response playbooks include triage questions for storage discovery: which account ran it, on which asset, what storage was enumerated, and what related activity occurred before and after.
- Use detection validation exercises to confirm SOC visibility across ESXi, IaaS, Linux, and macOS where those platforms exist in the environment.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy, DET0188, and its direct content is sparse: no official description, no official detection logic, no tactics, and no platforms are specified on the object itself. The practical interpretation comes from the relationship showing that DET0188 detects T1680, Local Storage Discovery, whose ATT&CK context identifies Discovery behavior across ESXi, IaaS, Linux, and macOS.
This take is limited to the official STIX fields, the MITRE external reference, and the stated relationship to T1680. It does not assert active exploitation, actor attribution, guaranteed detection coverage, or vendor-specific controls. Local environment baselines and available telemetry are required to determine whether this strategy is actionable.
Local Storage Discovery via Drive Enumeration and Filesystem Probing
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1680 | Local Storage Discovery | This object detects Local Storage Discovery. |
All related ATT&CK context
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 | 702988ce3124… |
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 DET0188Open 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.