Security teams can detect local storage discovery activity by monitoring for processes that enumerate drives, mounted volumes, removable media, and user directories in bulk. Attackers often use this to find data, wallets, or staging locations before exfiltration. Review file-system access patterns, command usage, and access from scripts or non-interactive processes.
How local storage discovery shows up in telemetry
local storage discovery is often visible as a burst of filesystem enumeration rather than a single suspicious file read. Look for processes that rapidly query drive letters, mounted volumes, removable media, home folders, browser profile locations, wallet directories, and other user storage paths in a short window. The signal is stronger when the activity comes from scripts, shells, archivers, remote administration tools, or non-interactive processes that do not normally browse the filesystem in bulk.
What matters is pattern, not one path. A few ordinary reads can be harmless, but broad traversal across many directories, repeated directory listings, and probes of hidden or uncommon locations often indicate a search for high-value data, staging space, or exfiltration candidates. Watch for command lines and parent-child process chains that make the enumeration explainable, or not.
On Windows, that can look like file and directory discovery across drives and user profiles; on other platforms, the same behavior may show up through shell loops, recursive directory walks, or scripting engines. The detection goal is to separate normal application reads from discovery behavior that is broad, repetitive, and opportunistic.
Which signals are most reliable for detection?
File-system telemetry is usually the clearest source because it shows where a process looked, how broadly it searched, and whether it touched removable or mounted storage that it had no obvious reason to inspect. Pair that with process telemetry so you can see whether the activity came from a user launching a file manager or from a hidden script, service, or remote execution context. Command-line logging is especially useful when the actor uses built-in tools to list directories or recurse through storage.
Sequence matters. Local storage discovery is more convincing when it appears before compression, archiving, staging, or network transfer. If a host suddenly starts enumerating storage and then soon after creates archives or writes to temporary folders, the discovery phase may be the opening step in a broader theft workflow. This is why endpoint and host telemetry should be reviewed together instead of in isolation.
Discovery also becomes more suspicious when the process touches storage locations that are unusual for the account, such as another user’s profile, mounted external media, backup folders, or application-specific data stores. That is where a broad telemetry source set helps, because storage discovery is often a precursor to credential theft, data theft, or wallet hunting rather than a goal in itself.
For defenders building broader attack-path coverage, Top 10 NHI Issues is useful context for how discovery, visibility gaps, and unmanaged access can create downstream exposure once a host is already being searched.
How to reduce false positives and improve investigation quality
Local storage discovery is noisy if you only alert on the existence of directory listing activity. Tune detections around breadth, timing, and context. A backup agent, indexer, EDR sensor, or legitimate search utility may enumerate many paths, but it does so in a predictable way, under a known process name, and often on a schedule. Suspicious activity tends to be interactive-looking only in appearance, while actually running from automation, a payload, or an unusual parent process.
Correlate the enumeration with user context. If the account is logged on but the process tree shows script interpreters, administrative shells, or remote tooling, treat that as more material than the same access from a file explorer. Also weigh whether the process is crossing trust boundaries, such as moving from standard user directories into other profiles, shared drives, mounted devices, or application data associated with wallets or other high-value stores.
A useful investigative rule is to ask whether the host is merely being used, or being searched. Ordinary use tends to access a small set of predictable paths. Discovery tends to fan out quickly, especially when the goal is to locate data for collection, encryption, or exfiltration. That distinction helps analysts avoid overreacting to normal storage activity while still catching early-stage attacker recon.
Operationally, it helps to map storage enumeration behavior to a larger discovery sequence rather than treating it as a standalone alert. That is where NHI Lifecycle Management Guide is relevant as a practical model for visibility, inventory, and ownership discipline around assets that should not be left discoverable or unmanaged.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1083 — File and Directory Discovery | This question is about detecting filesystem enumeration behavior. |
| Recommendation — Map broad path enumeration to T1083 and alert on abnormal discovery across user and storage locations. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detection depends on collecting and reviewing endpoint and command telemetry. |
| Recommendation — Centralize and review file, process, and command logs to spot bulk storage discovery. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Local storage discovery detection requires telemetry that records filesystem and process activity. |
| Recommendation — Enable audit record generation for relevant endpoint events and retain the records for investigation. | ||
Practitioner Guidance
What to prioritize: Start with the combination of breadth and abnormal context. A single directory read is weak evidence; repeated enumeration across user folders, mounted volumes, removable media, and hidden locations from a script or service is much stronger.
What to verify: Confirm whether the process tree, account, and host role make the activity plausible. If the same pattern appears before compression, staging, or outbound transfer, treat the discovery as an early compromise signal rather than a benign scan.
What good looks like: You can explain the process, the parent process, and the target paths. If you cannot explain why that combination of account, process, and storage scope exists, escalate the event for deeper host review.
Practitioner takeaway: The best detections do not look for “file browsing” in the abstract, they look for broad, context-free enumeration that precedes data handling or exfiltration behavior.