Detecting T1680 Local storage discovery

How local storage discovery shows up in an intrusion

T1680 Local storage discovery is the point where an adversary who already has a foothold on a host or workload starts working out what storage is attached, how it is laid out and what it holds. For a SOC lead, it matters because it is a Discovery (TA0007) signal that often appears after initial access and before collection, staging or impact. MITRE defines the tactic as the adversary trying to figure out the environment, and local storage is one of the places where that reconnaissance turns into a concrete picture of where sensitive data lives. Because the activity happens inside a system the attacker already controls, perimeter tooling rarely sees it, so the detection has to come from the host, hypervisor or platform itself. This page covers T1680 as mapped in Enterprise ATT&CK 20.0 and applies to ESXi, IaaS, Linux, macOS and other platforms in the scope of the page. The platform list matters because the same question, what storage exists here, is answered very differently on a hypervisor datastore, a cloud instance's block devices and a Linux or macOS workstation. Before writing any detection, confirm which of these platforms carry sensitive workloads in your environment, which administrative roles normally inspect storage, and which hosts should never perform storage enumeration at all. Those three answers define your baseline, and the baseline is what turns a noisy signal into a useful alert. The decisions to make early are practical. Decide which telemetry you can collect on each platform, such as process creation and command execution records, and whether your SIEM or Wazuh deployment keeps them long enough to investigate. Check the ATT&CK version your detection mappings target, since releases can rename or revoke techniques, and record it alongside each rule. Confirm with your platform and hypervisor vendors which audit events they expose for storage inspection, because coverage differs by product and version and should not be assumed from the technique name alone.

Which telemetry reveals local storage discovery on each platform

This table maps the data components that expose T1680 Local Storage Discovery to each platform, with the signal to look for and the open-source collector that can capture it. Read each row as a question to answer in your own environment: whether the component exists there, and whether your collector sees it. The main takeaway is that process and command telemetry covers most Linux and macOS cases, while ESXi and IaaS control plane coverage depends on logs you must confirm with the platform owner.

Data source	Signal to look for	Open-source collector and gaps
Process Creation (DC0032)	Storage enumeration utilities launched by unexpected accounts or parent processes, especially in short bursts across several hosts	Wazuh agent, Auditd or Sysmon for Linux and Windows equivalents. Confirm that process auditing is enabled on each host class
Command Execution (DC0064)	Shell sessions or scripts that list mounts, block devices, volumes or datastores before any business task runs	Wazuh command monitoring, shell history forwarding or Velociraptor hunts. Shell history may be incomplete or disabled on some builds
File Access (DC0055)	Reads of storage configuration files, mount tables or datastore inventory files by processes outside normal administration	Auditd file watches or Wazuh syscheck on defined paths. Confirm which paths your platform stores inventory in
User Account Authentication	Interactive or key-based logons to hosts or management interfaces followed by storage listing, from accounts that rarely perform it	Wazuh authentication logs, sshd and PAM logs forwarded to a central index. Coverage depends on which accounts and interfaces log to the collector
ESXi hosts	Storage inventory commands or management API calls for datastores and adapters run from unexpected administrative sessions	Syslog forwarding to Wazuh or Security Onion. Confirm with the vendor and your environment owner which shell and API events ESXi emits and at what level
IaaS control plane	Volume, disk or bucket listing calls from identities that do not normally query storage inventory	Cloud audit logs forwarded to the SIEM, with Wazuh or Security Onion as the collector. Confirm the event names and retention with the cloud provider and your operations team
Linux hosts	Enumeration of block devices, mounts and filesystem usage by service or user accounts that should not inspect storage	Auditd, Wazuh agent and Velociraptor artifacts for hunting across the fleet. Container hosts may need additional collection from the runtime
macOS hosts	Disk utility or volume listing commands run from user sessions or scripts outside managed maintenance windows	Unified logging forwarded through a supported agent, plus Wazuh or Velociraptor for command and file context. Confirm log retention and forwarding limits for your macOS fleet

Confirming the T1680 mapping in ATT&CK 20.0 before you write rules

Detection content should name the ATT&CK version it targets before any rule is written, because releases can rename, deprecate or revoke techniques and change how detections are described. Record the version as Enterprise ATT&CK 20.0 in every rule header, coverage matrix and test plan for T1680 Local storage discovery, so that a later reader can tell which mapping a rule was built against. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, and the ATT&CK updates page is where to check what changed between them.

Confirm the T1680 entry directly in the enterprise-attack 20.0 STIX bundle published in the attack-stix-data repository. Check the technique's listed platforms, its tactic membership, whether it has any sub-techniques, and the data components it references. Since ATT&CK v18 replaced technique-page detections with detection strategies (DET IDs) and analytics, also look for linked detection strategy and analytic IDs, and confirm which data components those analytics depend on. Do not assume that T1680 shares the platforms, data components or mitigations of sibling Discovery techniques such as T1083 or T1082. Each mapping should be read from the bundle and written down with the version it came from.

Once the mapping is confirmed, compare it against the telemetry your environment actually collects. If the bundle points to a data component such as File Access, confirm that your ESXi, IaaS, Linux and macOS sources forward that event type to the SIEM, and log the gap if they do not. Record which mitigations the entry maps to and treat them as a checklist for your own hardening decisions, not as proof of coverage. Ask your rule author or implementation partner to attach the bundle version, the DET and analytic IDs and the data component list to each detection so the mapping can be re-verified at the next ATT&CK release.

Detection ideas for T1680 local storage discovery

T1680 Local Storage Discovery is easy to confuse with routine disk administration, so each idea below pairs a suspicious pattern with the benign work that produces the same telemetry. Tune every idea against a baseline of your own hosts before it pages anyone. The cards cover host process logic, file access on storage paths, identity context for IaaS and ESXi management, and a correlation with later collection.

Storage enumeration on hosts without admin work

Alert when a storage listing or partition query runs on a host class that normally runs no such administrative work, such as application web tier or developer workstations. The logic is about context: the same command is routine on a storage administrator's jump host and unusual on a container node. Required data is process creation and command execution with parent process, user and host role. Start with a threshold of more than one enumeration command per host per hour, then tune. Known false positives include backup agents, monitoring agents, configuration management runs and scheduled maintenance windows. Keep an allowlist keyed on signed binary and parent, not on command text alone.

File access on storage paths

Watch for a process that reads mount tables, device directories or storage metadata paths across many volumes in a short window. Enumeration usually touches many paths quickly, while normal monitoring touches a fixed set repeatedly. Require File Access telemetry on the paths your Linux and macOS estate actually monitors, and confirm the audit configuration covers reads, not only writes. Baseline the number of distinct storage paths touched per process per interval. Known false positives include backup software, disk health checks, endpoint security scanners and inventory agents that deliberately walk every mount. Record which of these agents are approved so the rule excludes them by name and version.

Authentication context for IaaS and ESXi

On IaaS control planes and ESXi management interfaces, a storage query from an identity that has not historically used that API or console is the signal worth reviewing. Pair User Account Authentication events with the subsequent storage or datastore inventory calls, and compare the source address, client type and time of day with that identity's history. Confirm which audit logs your cloud provider and vCenter or ESXi deployment emit, because field names and retention differ. Known false positives include automation service accounts that refresh inventory, new administrators during onboarding, and vendor support sessions. Route those identities to documented owners so reviewers can close alerts quickly.

Discovery followed by collection

Join a discovery event with later collection activity on the same host or identity within a window you set from your own incident data. Discovery alone is noisy, but a storage enumeration followed by bulk reads of files, archive creation or staging to a new directory is a stronger lead. Use Process Creation for the discovery step and File Access or Process Access for the collection step, keyed on host and user. Start with a short window and widen it only after reviewing hits. Known false positives include nightly backup jobs, log rotation and large data pipeline runs, so exclude them by schedule and service identity.

Sigma rules with version tags

Express each idea above as a Sigma rule so the logic can move between SIEM backends and be reviewed in version control. Each rule should record the ATT&CK version it targets in its metadata, because releases can rename, deprecate or revoke techniques and detection mappings drift over time. Current ATT&CK releases use detection strategies and data components, so map each rule to the data component it depends on and note any gaps. Test rules against replayed telemetry in your cyber range before promoting them. Confirm the exact ATT&CK version your organization has adopted with your own detection governance owner before writing it into rule metadata.

Validating the T1680 detection with a planned emulation

This sequence confirms that the T1680 Local Storage Discovery detections fire on the platforms in scope, reach triage, and produce a documented record that can be re-tested after every change. It runs entirely in a lab or private cyber range under written rules of engagement. The output is a validated detection set with known gaps and tuning decisions recorded against a named ATT&CK version.

Agree scope and rules of engagement
The detection owner, the red team lead, the SOC triage lead and the system owners for each platform sign a short written scope before any activity starts. The scope names the platforms in play (for example ESXi, IaaS, Linux and macOS), the isolated lab or range, the test accounts, the time window, the stop conditions and who can halt the exercise. It also confirms that no production hosts or production identity tenants are in scope. Done when every named party has acknowledged the document and the stop contact is reachable during the window.
Define expected telemetry for each platform
For each platform in scope, the detection engineer lists the data components the T1680 detection strategies rely on, such as Process Creation, Command Execution and User Account Authentication, and maps each to the log source that should carry it (for example, an auditing subsystem, a hypervisor log or a cloud audit trail). Gaps are recorded before the exercise, not discovered during it. Record the ATT&CK version the mapping targets, since releases can rename or deprecate techniques. Done when every expected data source has a named owner and a confirmed collection path into the SIEM.
Describe the approved test activity
The red team or purple team lead writes the test activity as a plain-language description of the behavior to be exhibited, such as enumerating local storage locations from an authenticated session on a lab host, without any commands, payloads or evasion steps in the record. The description states the expected outcome per platform and the telemetry that outcome should generate. A second person reviews it against the scope. Done when the reviewer confirms the activity stays inside the agreed scope and the expected alerts are listed.
Run the emulation in the cyber range
The operator executes the approved activity on the isolated range hosts while a scribe logs the start and end time of each action against the agreed window. The range team confirms that the environment is isolated before execution and that the stop conditions are observed. Operators do not improvise beyond the written description. Done when the scribe has a timestamped log that matches the approved activity list one for one.
Confirm alerts reach triage
The SOC analyst follows each expected detection from the SIEM into the case queue and checks that the alert contains the host, user, data source and rule identifier needed for triage. The analyst also confirms that the alert arrives within the latency the SOC has agreed as acceptable for that log source. Missing or malformed alerts are logged as failures, not corrected silently. Done when each expected alert either appears in the queue with a complete record or has a documented failure reason.
Record results and capture evidence
The detection engineer records, for each test, the timestamp, host, platform, data source, rule ID, ATT&CK version, alert status and triage outcome, and stores the raw log excerpts in the evidence location. Results are marked as detected, partially detected or not detected, with the reason for any gap. The record is kept so that an independent reviewer or auditor can trace each claim to its evidence. Done when every test has a complete row in the results register and the evidence references resolve.
Tune for false positives and re-test
The detection engineer reviews benign activity observed during the window, such as administrative scripts or backup jobs that touch storage, and adjusts exclusions only where the reason is documented and the exclusion is scoped to a specific host group or account. Each tuning change is versioned and tied to the rule ID. After any change to rules, log sources or platforms, the affected tests are run again and the register is updated. Done when the re-test shows the intended detections still fire and no new unexplained noise appears.

Rehearsing local storage discovery in a private cyber range

Build the range with one or two ESXi hosts in a management segment, a vCenter-style management endpoint if your environment uses one, and a log forwarder that ships host and shell logs to your Wazuh or Security Onion collector. Keep a non-privileged administrative account on each host so that the facilitator can stage discovery-style activity without touching production datastores. Illustrative scenario: during a planned maintenance window, an account runs a routine storage inventory on a host, and a later step attempts to read datastore contents from an unexpected source address.

Range topology: Two hosts, one management network, one datastore volume that holds only synthetic data, and a collector that receives process and command logs.
Facilitator injects: A storage inventory run inside the approved maintenance window, followed a few hours later by a collection-style read of the datastore from an account outside the change record.
Detection outcome: An alert fires on the out-of-window activity, and the host name and account are attributed correctly in the alert.
Triage outcome: The analyst follows the runbook, confirms the change calendar entry and records whether the activity was approved.
Response outcome: The team decides on containment (for example, disabling the account), preserves host logs and records lessons learned.

Check with your hypervisor vendor which shell and audit logs are available on your version and whether they can be forwarded off-host before you rely on them in the range.

Triage and response when a local storage discovery alert fires

When a T1680 Local storage discovery alert fires, the first decision is whether the activity matches a known administrative or backup task on that host. Start by comparing the alert against the baseline for the host role: which accounts normally list block devices, datastores or mounted volumes, and at what times. Identify the host, the account and the session that produced the event, then check the change calendar, backup schedules and storage vendor maintenance windows for the same period. On ESXi and IaaS hosts, confirm whether a backup agent, storage management tool or configuration management job was running. Record each check so the decision can be reviewed later. If the activity cannot be tied to an approved task, treat it as unexplained and move on to correlation.

Correlate the alert with authentication and file access events from the 30 minutes before and after it, using the telemetry named on this page (Process Creation, Command Execution and User Account Authentication). Look for a new or unusual logon to the host, failed attempts that precede a success, and any discovery activity against other hosts in the same segment. Ask the storage and platform owners to confirm which volumes and datastores the account should see. Set the escalation threshold in writing before the alert fires, so the analyst does not have to decide under pressure. Escalate when the account is unexpected, the activity repeats across hosts, or it appears alongside authentication anomalies.

Preserve evidence before containment. Capture the relevant logs, process and command history, and volatile state from the affected host through the agreed forensic procedure, and hash the collected files. Containment should prefer narrow controls, such as restricting the account's session or its access path, over powering off or isolating hosts that serve production storage. Confirm with the platform owner before any action that could interrupt replication, backups or running workloads. Scope the incident by searching the same signatures across similar hosts, then feed the outcome back into the rule: document false positives with the reason, adjust allow-lists using named accounts and maintenance IDs rather than broad exclusions, and rehearse the revised rule in the cyber range.

Preventive controls that reduce exposure to T1680

ATT&CK maps a small set of mitigations most often to Discovery techniques in version 20.0, and several of them apply directly to how an adversary enumerates local storage. Each control below limits a specific part of that activity, so the reader should confirm the exact mapping for T1680 Local storage discovery in the ATT&CK STIX bundle before citing it in a control matrix.

Least-privilege storage management access

Map ATT&CK mitigation M1018 (User Account Management) to the accounts that can list disks, volumes, datastores and mount points. Routine users and service accounts rarely need interactive storage inspection on ESXi hosts, IaaS instances or Linux and macOS endpoints. Review who holds those rights, remove standing administrator roles that are no longer needed, and confirm the mapping for T1680 in the STIX bundle.

Hardened storage and host configuration

ATT&CK mitigation M1028 (Operating System Configuration) covers hardening settings that restrict which tools and interfaces can read storage metadata on a host. Examples include restricting remote shell access to hypervisors, limiting which packages can query block devices, and enforcing configuration baselines on Linux and macOS fleets. Ask your team to document the baseline and to confirm with the STIX bundle whether M1028 is mapped to T1680.

Audit logging of storage enumeration

ATT&CK mitigation M1047 (Audit) supports the telemetry that detection depends on. Enable process auditing and command logging on hosts so that storage enumeration by privileged accounts appears in Process Creation and Command Execution records. Verify that logs from hypervisors, cloud control planes and Linux and macOS endpoints reach the central SIEM, because a detection cannot fire on events that were never written.

Segmented management networks

ATT&CK mitigation M1030 (Network Segmentation) limits where a foothold can reach storage management interfaces. Place hypervisor management, storage array consoles and backup control planes on restricted management networks, and allow access only from named administrative jump hosts. Test the segmentation rules from a standard user subnet to confirm that the storage interfaces are unreachable.

Intrusion prevention on management traffic

ATT&CK mitigation M1031 (Network Intrusion Prevention) adds inline blocking of suspicious access to management protocols. Deploy signatures or rules in Suricata or a comparable sensor to flag and block unexpected sessions to storage and hypervisor management ports. Tune the rules in a test environment first, since false positives on administrative traffic can disrupt operations.

Removal of unused storage tooling

ATT&CK mitigation M1042 (Disable or Remove Feature or Program) reduces the number of built-in utilities that can enumerate storage. Inventory storage management tools, remote management agents and unused services on each platform, then disable or uninstall what the business does not require. Record each exception with an owner so that the reduced set stays current after upgrades.

Questions SOC leads and detection engineers ask about T1680

Which data components should I start with to detect T1680 on ESXi?

Start with Process Creation and Command Execution, since these are the data components the ATT&CK detection strategies most often reference for discovery activity on hypervisor hosts that expose a shell or management tooling. Add File Access where your ESXi logging can record access to datastore and configuration paths. Confirm in your own environment which of these your ESXi logging actually captures, because support for each data source depends on how the hosts forward logs and what the vendor exposes. Check the current technique page in the ATT&CK version you target before building rules on it.

How do I separate backup and monitoring noise from local storage discovery?

Build an allowlist from the process names, service accounts and source hosts that your backup agents, monitoring collectors and configuration management tools use, then document each entry with an owner and a review date. Scope the rule to interactive or unexpected parent processes rather than to the storage commands alone, because the same command can be routine for one account and suspicious for another. Replay a week of normal telemetry against the rule before enabling alerts, and track the false positive rate per source. Confirm the scheduled jobs in each host group with the teams that own them.

How should I version Sigma rules against ATT&CK releases?

Put the ATT&CK version in the rule metadata and in the repository path, so every detection shows which technique and detection strategy it targets. ATT&CK releases can rename, deprecate or revoke techniques, and v18 replaced detections in technique pages with detection strategies and analytics, so a rule written against an older mapping needs a review. Use the enterprise-attack STIX bundle for the version you target as the reference for mappings, and keep a changelog that records each mapping change. Confirm the release you are targeting against the ATT&CK updates page before each review cycle.

How do I tell whether my platform supports a given data source?

Check the vendor documentation for the specific log type, the version of the product you run and the collection method, then confirm with a test event rather than assuming support from the product name. Many gaps come from logs that exist but are not forwarded, are rotated too quickly or lack the command or user fields a rule needs. Record each data source as supported, partial or unavailable for each platform in your inventory, and map that record to the detection strategies you plan to use. Ask your vendor or implementation partner to demonstrate the events on your own hosts.

How often should I re-run a cyber range exercise for T1680?

Re-run the exercise after any change that affects telemetry or rules, such as a logging agent upgrade, a new ESXi or Linux build, a Sigma rule change or an ATT&CK version update, and on a fixed cadence set by your risk owners. A quarterly or semi-annual cadence is common in practice, but the right interval depends on how fast your environment changes and what your compliance commitments require, so confirm it with your audit and risk teams. Keep each run's results with the rule version, the telemetry snapshot and the time to detect, so trends are visible across runs.

Can my own team run this detection work without an outside partner?

Yes, many teams do, provided they have someone who can read ATT&CK mappings, write and test Sigma rules, and operate the log pipeline in Wazuh, Security Onion or a similar stack. The work that often stretches internal teams is the data source validation across each platform and the recurring range exercises, which need a safe, isolated environment. A fixed-scope engagement can cover the initial build, validation and rehearsal, while retainers can cover ongoing testing and upgrades. Confirm your team's skills and capacity against the written scope before deciding which parts to keep in-house.

What should a detection engineer record for each T1680 test?

Record the ATT&CK technique and version, the rule identifier and version, the platform and host group tested, the telemetry fields that matched, the time from activity to alert and any tuning changes made. Also record the exact scope of the exercise, the accounts used and the approval from the system owner, so the test can be audited later. Keep these records in the same place as your rule repository so that a change in a rule can be traced to the test that prompted it. Confirm with your compliance team which records they need to retain and for how long.

How DeployOpen builds T1680 detections and range exercises

DeployOpen approaches T1680 Local storage discovery as a fixed-scope engagement inside your own environment, covering the platforms you run and the telemetry you already collect. The work turns the technique into detection logic, validated detections and rehearsed response in a private cyber range.

How we scope

Confirm which platforms in scope expose local storage enumeration, such as ESXi, IaaS, Linux and macOS hosts.
Inventory which telemetry sources already feed your SIEM, including Process Creation and Command Execution, and where gaps sit.
Agree the ATT&CK version the detection mapping targets, and record it in the written scope before work starts.

How we build

Write detection logic in plain terms, mapped to the T1680 entry and its data components in the ATT&CK knowledge base.
Build open-source rules for Wazuh or Sigma-compatible pipelines, tuned against administrator tasks that legitimately list disks and volumes.
Document known false positives, required log fields and the sensors or agents each detection depends on.

How we hand over

Deliver a written detection specification, rule files and a validation record showing which test scenarios fired each rule.
Run exercises in a private cyber range so your analysts rehearse triage, escalation and containment on the same logic.
Provide runbooks and gap notes that your team can maintain after the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer for detections as ATT&CK versions change.
Re-validate rules after platform upgrades, log format changes or new ATT&CK releases that rename or revoke related content.
Confirm with your team which support tier, review cadence and response expectations fit your environment before signing.

T1680 Local storage discovery