Detecting T1005 Data from local system

How T1005 data from local system shows up in intrusions

Collection from local storage is visible if you log the right file activity on hosts and devices, but it is rarely visible by default. T1005 Data from Local System describes an adversary gathering data of interest from the local file system of a system it already controls, so the signal lives in the host and device telemetry you collect, not in the network perimeter. For SOC leads, the practical question is whether your sensors would record a process reading or staging files from user, application or configuration directories on servers, workstations, hypervisors and network devices, and whether anyone reviews those records. MITRE ATT&CK places Collection (TA0009) among its Enterprise tactics and defines it as the adversary trying to gather data of interest to their goal. T1005 is the local-storage variant of that goal. In a typical intrusion it appears after the adversary has gained access and performed discovery, because the adversary needs to know where the valuable data sits before reading it. It often precedes archiving or staging, which is why the same host telemetry supports several neighboring techniques.

This page targets Enterprise ATT&CK version 20.0. Detection mappings should name the version they target, because releases can rename, deprecate or revoke techniques and change data component references. Before you write rules, confirm the current technique and detection strategy entries in the STIX bundle for that version, and record the version in your detection catalog so that future reviews can tell whether a mapping still matches the framework.

Which telemetry reveals local data collection and which open-source tool collects it

This table maps the data components most often referenced for T1005 to the signal each produces on local hosts, and names an open-source collector for each platform. Read each row as a question to answer in your environment: which events are logged, where they are forwarded and how long they are kept. The main takeaway is that network device and some ESXi and macOS events depend on vendor logging support, so confirm those before writing detections.

Data component or platform	Signal for local data collection	Open-source collector and what to confirm
Process Creation (DC0032)	Archiving, copy or read utilities run against sensitive paths, with parent process and user	Wazuh on Linux and macOS via audit or endpoint logs; Velociraptor for process history on demand
File Creation (DC0039)	New archives or copies written to temporary or user directories after reads	Wazuh file integrity monitoring on Linux and macOS; Velociraptor for hunting new files by path and time
File Access (DC0055)	Reads of sensitive directories, databases or configuration files by unexpected accounts	Requires audit rules on Linux and macOS; confirm read-auditing volume and retention before enabling broadly
Command Execution (DC0064)	Shell or CLI commands that enumerate and copy data, seen in shell history or audit logs	Wazuh log collection from shell and audit sources; confirm ESXi and network device CLI logging is enabled
Network Connection Creation (DC0082)	Outbound sessions that follow local collection, used to correlate with staging activity	Zeek connection logs and Suricata alerts on network sensors; host connection data from Wazuh or Velociraptor where available
ESXi hosts	Shell access, VM file operations and datastore activity, if the host records and forwards them	Forward host syslog to Wazuh; confirm which datastore and file events your ESXi version records
Network devices	Configuration and file access records are often limited to syslog and AAA logs	Zeek and Suricata see traffic only; confirm with the vendor whether file access and command auditing exist
macOS endpoints	Process, file and command events depend on unified logging and agent policy	Wazuh agent and Velociraptor artifacts; confirm which events your agent version exposes

Detection logic for T1005 that SOC teams can tune

Each card below describes one detection idea for T1005 Data from Local System, with the logic, the starting thresholds to tune against your own baseline, and the benign activity that will trigger it. Treat every threshold as a placeholder until you have measured normal volumes for the hosts in scope.

Bulk reads of data directories

This detection flags a single process or user account that reads an unusually large number of files under user or business data directories within a short window. The logic is a count of distinct file-read events per process, per host, over a rolling window, compared with the host's own history rather than a fixed global number. Start with a per-host baseline and alert on deviation from it. Backup agents, antivirus scans, search indexers and sync clients produce the same pattern, so exclude them by signed binary and service account after you have confirmed each one in your environment.

Collection tools from unexpected parents

This detection looks for archiving, copy or scripting utilities started by parents that have no business launching them, such as a web server worker, a database process, a remote management agent or an office application. The logic joins process creation events on parent and child image, then checks whether the parent is on an allowlist of expected launchers. Administrators running maintenance scripts through remote management tools are the most common false positive, so log the originating session so analysts can separate approved work from unexpected activity.

File access spikes on sensitive paths

This detection tracks file access events against paths that hold regulated or high-value data, such as customer record stores, key material directories or finance shares on local disk. The logic counts reads per path per account and raises an alert when the count crosses a threshold set from the path's historical access pattern. Confirm that file access auditing is enabled on the sensitive paths first, since many hosts only log access on paths that were explicitly configured. eDiscovery exports, legal holds and quarterly reporting jobs are predictable sources of spikes, so schedule them into the tuning baseline.

Staging-like writes near collected sets

This detection watches for new files created in temporary or user-writable locations shortly after a burst of reads from data directories, since a collected set is often written to a single new location before it leaves the host. The logic correlates file creation events with preceding file access volume on the same host and within a short time window. Build scoping rules for known batch jobs, extract-transform-load pipelines and developer build caches, because these write large files near data stores as part of normal work. The same signal overlaps with T1074 Data Staged, so keep the rule versioned against the ATT&CK release you target.

Admin scripts and indexing services

This card covers the benign processes most likely to cross the thresholds above: enterprise search indexers, database maintenance jobs, configuration management runs and privileged administrator scripts. The practical control is an inventory of these processes per host class, with their expected paths, accounts and schedules recorded in the detection documentation. Analysts should be able to tell in seconds whether a read burst matches an approved job. Ask each platform owner to confirm the schedule and account for their jobs before you lock any allowlist.

Backups and eDiscovery exports

Backup software and eDiscovery tooling read large volumes of local data by design, which makes them the largest source of false positives for bulk read logic. Treat them as a separate class in your rules, with their own thresholds, service accounts and maintenance windows, rather than as broad exclusions. Legal and compliance teams should confirm which export jobs are authorized and when they run, so that an unscheduled export triggers review. Keep records of each approved job so that the exclusion can be audited later.

How to validate that T1005 detections fire

This sequence proves, in a private cyber range, that collection of local data on ESXi, Linux, macOS and network devices produces telemetry, alerts and SOC actions that match what the detection strategies promise. It ends with a documented list of gaps that the detection owner can close and retest.

Agree scope and rules of engagement
The detection engineer, the SOC lead and the cyber range operator agree in writing which hosts, device types and local data stores are in scope, which collection behaviors are allowed, who may stop the exercise, and how evidence is handled. The client's change or risk owner signs off before any activity starts. Done means a signed scope note that names the ATT&CK version under test, for example v20, and the detection strategy identifiers being validated, such as the DET IDs that cover Process Creation, File Creation and File Access for T1005.
Select representative hosts and devices
Choose a small set of cyber range systems that mirror production: at least one ESXi host, one Linux server, one macOS endpoint and one network device where the platform matrix applies. Confirm each one forwards logs to the lab Wazuh or Security Onion pipeline and that the expected Sysmon-equivalent or audit sources are enabled. Done means an inventory showing each asset, its log sources and the data components it can produce.
Run approved collection behaviors through an emulation tool
The red team or purple team operator runs a pre-approved collection scenario through an emulation tool such as Atomic Red Team or CALDERA, limited to the sensitive-looking local files the exercise defines. The operator records the exact behavior, the starting time and the target host. Done means a run log that maps each action to the T1005 technique and its sub-technique status, so results can be compared with the detection logic later.
Record timestamps and raw telemetry
Capture the time of each action and pull the raw events from every source: process creation, file creation and file access on hosts, and network telemetry from devices. Keep the clock sources aligned across systems and note any skew. Done means an evidence bundle with raw events, a timeline and a table showing which data components produced events for each action.
Confirm alerts reach the SOC queue
Check that the rules or analytics derived from the detection strategies fire in Wazuh, Security Onion or the SIEM in use, and that alerts appear in the SOC ticketing or queue with the correct severity, host and ATT&CK mapping. The analyst on shift records the time to triage and whether the alert contained enough context to act. Done means a screenshot or export of each alert with its queue ID, linked to the emulation log entry.
Document gaps and assign fixes
Compare expected detections with observed results. Record each missed action, noisy rule or missing data component, and classify the cause as logging, rule logic, parsing or scope. Assign an owner for each gap and state whether the gap blocks the detection from being accepted. Done means a gap register that the client can review, plus a note on which DET IDs passed, failed or need tuning.
Retest after changes and track version drift
After fixes are applied, rerun the same emulation steps against the same hosts to confirm each gap closes without new false positives. Before each retest, check the ATT&CK release notes for changes to T1005, its data components or its detection strategies, because a release can rename or revise them. Done means a retest report that names the ATT&CK version used in both runs and records the final pass or fail status for each detection.

Preventive controls that limit what local collection can reach

Local collection succeeds when sensitive data sits where any process running under a compromised account can read it. The controls below narrow that reach by deciding what data is allowed on each host, how it is protected at rest, who can open it, and which actions are logged for review.

Data loss prevention (M1057)

Data Loss Prevention (M1057) is the ATT&CK mitigation most directly tied to T1005, because it governs what sensitive content may sit on endpoints and servers and whether it may leave them. Start by classifying the data types that matter, such as customer records, keys and source code, then confirm which hosts a DLP agent or policy actually covers. Ask the team whether local file reads of classified content generate alerts or only block exfiltration paths, since collection often happens before any outbound transfer.

Encryption of sensitive information

Encrypt Sensitive Information (M1041) reduces the value of a file that an adversary can read locally. Where full-disk or file-level encryption is applied, a process running under an account without the decryption key may only collect ciphertext. Confirm which datastores, backups and application directories are encrypted at rest, where the keys are held, and whether those keys are reachable from the same account that runs the application.

Audit of file access

Audit (M1047) keeps the record that makes T1005 detectable after the fact. Enable file access auditing on directories holding sensitive data, and forward those events to your central log platform so that bulk reads by unusual processes can be correlated with Process Creation and File Access telemetry. Confirm the audit policy covers the paths that matter, and that log volume and retention are sized for the hosts in scope.

Account and permission management

User Account Management (M1018) limits which identities can read sensitive local data in the first place. Review group memberships and file permissions on application data stores, remove standing access that is not needed, and separate service accounts from interactive administrators. Ask for a current list of accounts with read access to each sensitive directory, and confirm that dormant or shared accounts are removed.

Local data minimization and review

Collection cannot reach data that was never stored locally. Work with data owners to identify exports, temporary files, debug dumps and cached copies left on servers and workstations, and set rules to remove or move them to controlled storage. Confirm the review cadence and who signs off on exceptions, because stale copies are a common source of unexpected collection targets.

Triage steps when a T1005 alert fires

Start by deciding whether the activity is legitimate, because most alerts on local data collection come from backup agents, migration jobs, eDiscovery exports or administrators working through a change window. Check the alert against the change calendar and the owner of the affected host, then confirm the process ancestry, the user or service account, and the time of activity. Where the originating process is an interpreter, a scripting host or an unfamiliar binary, treat the alert as suspicious until the owner confirms otherwise. Record the answer in the case file before moving on, since the same questions will come back from data owners and auditors.

Next, scope the affected hosts or devices. On ESXi, Linux, macOS and network devices, pull every host where the same account, process name or file pattern appears in the detection window, and note which datastores, directories or configuration repositories were read. Compare file access volumes against that host's normal baseline, and check whether sensitive paths were touched by an account that has no business need for them. Preserve volatile evidence before you reboot, isolate or clean anything: capture running processes, open file handles, active network sessions and logged-in users, and export the relevant logs to a location the affected account cannot write to. Confirm with your forensics lead which artifacts your retention policy requires you to keep.

Review access logs for the specific data involved, not just the host. Identify which records, folders or configuration files were read, by whom, and whether any of them carry regulated or personal data. Ask the data owner to confirm what the data represents and whether the access pattern matches their expected use. Containment should follow from those answers: restrict the account, suspend the job, or isolate the host if the activity is unexplained and ongoing, but avoid broad shutdowns that destroy evidence or disrupt services. Finally, notify the data owner, the legal team and the privacy function early, with a written summary of facts, scope and open questions, because notification obligations may run from discovery rather than from confirmation. Confirm your own notification timelines with counsel.

Rehearsing T1005 detection in a private cyber range

The range for this tab mirrors the client's virtualization estate: at least one ESXi host, a management plane, a datastore holding sample virtual machine disks and configuration files, and a log path from the hypervisor and guest operating systems into the SIEM. Keep the range private, with no route to production datastores, and use synthetic data labeled as such. The client sets the rules of engagement, including which hosts, datastores and accounts the exercise may touch and when it may run.

Topology: One or more isolated ESXi hosts, a test vCenter or equivalent management plane, a sample datastore, and a Wazuh or Security Onion collector receiving host and hypervisor logs.
Injects: Schedule a scripted read of virtual disk and configuration files from a service account outside its normal pattern, followed by a bulk copy of a datastore folder to a staging location.
Detection in the SIEM: Expect file access events on the datastore paths, process or shell events on the hypervisor, and an alert that correlates unusual account behavior with file reads over a short window. Tune until a benign backup job does not trigger the same rule.
Response in the runbook: Define who isolates the host, how the service account is disabled or its token revoked, and how the datastore is preserved for forensic review before cleanup.
Evidence: Record the time of each inject, the alert identifier, the analyst action and the restoration step, so the exercise can be reviewed afterward.

Check that every inject maps to a named detection and that the runbook has been walked through by the people who would execute it at 2 a.m.

Questions SOC leads and detection engineers ask about T1005

How do I separate backup jobs from T1005 collection activity?

Start by building an allowlist of known backup agents, service accounts, schedules and destination paths, then alert on deviations from that baseline rather than on file reads alone. Backup software reads large volumes of files in predictable windows, so the signal that matters is an unfamiliar process, an unusual user, an off-hours run or a destination that is not the approved backup target. Record the parent process, the account and the output location for every collection-like event, and review the allowlist after each change to backup tooling. Confirm the exact process names and service accounts with your backup vendor and in your own environment before writing any exclusion, because a broad exclusion can hide the activity you are trying to find.

Can network devices produce usable file access telemetry for T1005?

Usually only in a limited way, so confirm it for each device model before you rely on it. Most network devices expose configuration changes, authentication events, and command or session logs through syslog or an API, but they rarely record per-file reads the way a host agent does. Where a device logs administrative commands that read or copy configuration files, those logs can support detection of T1005 on that platform, and they map to the Network Devices platform coverage in your detection strategy. Ask the vendor which log categories are available, whether they include command content, and how they are forwarded to your collector. Treat anything you cannot verify as a gap to document, not as coverage.

How do I map T1005 detections to ATT&CK version 20.0 analytics?

Name the ATT&CK version in every mapping, then trace each detection to a detection strategy, its analytics and the data components those analytics depend on. Since ATT&CK v18, technique pages reference detection strategies (DET IDs) and analytics rather than the older detection text, and data components use DC IDs, with several data sources deprecated. For T1005 the data components most relevant to Collection techniques include Process Creation (DC0032), File Creation (DC0039) and File Access (DC0055). Pull the ATT&CK 20.0 STIX bundle, record the IDs your rules depend on, and rerun the mapping after each release, because techniques can be renamed, deprecated or revoked between versions.

How often should we retest T1005 detections in the cyber range?

Retest after every change that can alter the telemetry path, and on a fixed schedule that your own risk assessment sets. Triggers include a new ATT&CK version, an agent upgrade, a change to logging policy on a host or device, a new backup or sync tool, and any detection rule edit. Each retest should replay the same scenario, confirm that the expected alert fires, and confirm that the alert reaches the queue your analysts watch. Keep the results with the rule version so that an auditor or incident reviewer can see what was tested and when. The exact cadence is a decision for your team and your governance model, so agree it in writing before the first test cycle.

What should we do about T1005 sub-technique gaps?

Treat each gap as a documented decision with an owner, a compensating control and a review date. T1005 has no sub-techniques in the ATT&CK data used for these pages, so the gaps that matter are usually platform gaps: a platform where your sensors do not record file access, or a data source you cannot collect at all. For each gap, list the platform, the missing data component, the detections that depend on it, and the compensating measure, such as a stricter Data Loss Prevention policy, tighter access control on sensitive directories or a broader audit policy. Review the register after each ATT&CK release, since the set of sub-techniques can change between versions.

Who owns T1005 detection: the SOC, platform teams or the data owners?

Ownership is shared, and the split works best when each group owns the part it controls. The SOC typically owns the detection logic, alert triage and response playbooks, platform engineering owns the agents, log forwarding and audit policy on hosts, and data owners define which directories and datasets are sensitive enough to monitor closely. Put the split in a RACI that names a single accountable person for the detection itself. Without that, a rule change in one team can silently break telemetry another team depends on.

Can our own team run T1005 detection and cyber range exercises without outside help?

Yes, many teams do, provided they already have logging, a rule pipeline and a safe lab, and can staff the work. The skills needed are log source configuration, detection engineering against ATT&CK, scenario design for a private range and disciplined change control. Where those skills or the staff time are missing, a fixed-scope engagement can cover the gap, and DeployOpen plans, implements and documents open-source detection platforms and runs private cyber ranges inside the client's own infrastructure. Compare the written scope from any provider against the checklist above, and confirm which parts will be handed over to your team.

How DeployOpen builds T1005 detections and range scenarios

DeployOpen approaches T1005 Data from Local System as a written, fixed-scope engagement inside the client's own infrastructure. The work covers telemetry, detection logic, validation in a private cyber range and the documentation a security team needs to run the detections after handover.

How we scope

Confirm which ESXi, Linux, macOS and network device estates hold data that matters to the business.
Agree the telemetry sources in scope, such as Process Creation, File Creation and File Access, before any work starts.
Record the ATT&CK version the detection mappings target, so later releases can be compared cleanly.

How we build

Write detection logic for T1005 in plain language first, then translate it into open-source rules for the chosen SIEM.
Configure collection with Wazuh, Security Onion, Zeek or Velociraptor where the client already runs them or agrees to add them.
Map each detection to the Data Loss Prevention mitigation (M1057) and to the owning data classes the client identifies.

How we hand over

Deliver a cyber range scenario that simulates local data gathering on the agreed platforms, with expected alert outcomes written down.
Provide validation results showing which detections fired, which did not and what tuning was applied.
Document response steps, analyst runbooks and the evidence the client should keep for internal and external reviews.

How we support

Explain that engagements are fixed-scope, with the written scope setting deliverables and timelines.
Offer ongoing support, upgrades and continuous testing as a retainer, once the written scope allows it.
Re-test detections when the client upgrades platforms or when the ATT&CK version the mappings target changes.

T1005 Data from local system