Once an attacker is running code on a host, the files, configuration, local databases and keys already sitting on that host are the cheapest data they will ever steal, and most organisations log almost none of the reads. MITRE ATT&CK tracks this as T1005 Data from Local System, a Collection (TA0009) technique on ESXi, Linux, macOS, Network Devices and Windows. It is one of the most widely used techniques in the framework: the ATT&CK v20 data links more than 200 groups, campaigns and software families to it. This guide is for detection engineers, endpoint and server owners and NHI owners. It takes the technique view: what ATT&CK says, real procedures, the v20 detection analytics, mitigations and how to test. For the data protection programme itself, see the CIS Control 3 Data Protection Guide.
Key takeaways
- Collection follows discovery. Attackers first find files with T1083 File and Directory Discovery, then read and gather them under T1005. Detection is strongest when you see the two together.
- The target list includes machine secrets. ATT&CK names file systems, configuration files, local databases, virtual machine files and process memory. Config files and SSH keys hold the non-human credentials that turn one host into many.
- Read events are off by default. On Windows, Event 4663 is only written when the object's SACL has a matching entry. Without targeted auditing, bulk reads leave no trace.
- Only one mitigation is mapped. ATT&CK v20 lists M1057 Data Loss Prevention. Least privilege on data, secrets out of files and OS privacy controls are NHI Mgmt Group recommendations on top.
- AI tooling now does the gathering. ATT&CK v20 records a campaign in which an AI coding agent was tasked to gather credentials and configuration from local systems, and a 2025 supply chain attack tried to use local AI CLIs to search developer machines.
What the technique covers
ATT&CK v20 (technique version 1.8, last modified 11 September 2026) describes adversaries searching local system sources, such as file systems, configuration files, local databases, virtual machine files or process memory, to find files of interest and sensitive data prior to exfiltration. It names Command and Scripting Interpreter tools such as cmd, T1059.008 Network Device CLI and T1119 Automated Collection as ways to do it. T1005 has no sub-techniques.
| Platform | What is typically gathered | Why it matters |
|---|---|---|
| Windows | Office and PDF documents, browser cookies and saved logins, registry hives, event logs, the Active Directory database on domain controllers | Documents are the prize in espionage; cookies, hives and the AD database give credentials for the next step |
| Linux | Home directories, SSH keys, application config files, .env files, local database files | Server config files are where service account passwords and API keys most often live |
| macOS | Documents, Desktop and Downloads folders, keychains | Developer and executive laptops concentrate source code, tokens and sensitive documents |
| ESXi | Datastore files, VM disks, host configuration and logs | One hypervisor holds the disks of many servers |
| Network Devices | Running configuration, flash contents, cached data | Configs hold credential hashes, SNMP strings, VPN keys and topology |
Related techniques with their own pages: T1680 Local Storage Discovery (finding volumes), T1552 Unsecured Credentials (credentials in files as a Credential Access goal) and T1560 and T1074 (packing and staging what was gathered). The AI system equivalent is AML.T0037 Data from Local System.
How adversaries use it: real cases
Procedure examples from the ATT&CK v20 data, with the source ATT&CK cites, and two NHI Mgmt Group breach analyses:
- AI-orchestrated campaign (C0062, 2025): ATT&CK records that the adversary tasked Claude Code to automatically gather sensitive data from the local system, including credentials, system configurations and operational data (Anthropic, November 2025). Our analysis notes the agents extracted authentication certificates from configuration files and then tested them across internal APIs, databases, registries and logging systems. See the Anthropic GTG-1002 Campaign 2025 analysis.
- Nx s1ngularity supply chain attack (August 2025): a post-install script in malicious Nx packages scanned developer machines for GitHub and npm tokens, SSH keys, cloud credentials and AI tool configuration, and prompted locally installed AI CLIs with permission-skipping flags to help find files. GitGuardian counted 2,349 distinct secrets in the resulting public repositories. See the Nx s1ngularity Attack 2025 analysis.
- Volt Typhoon (G1017): stole files from a sensitive file server and the Active Directory database, and used Wevtutil to extract logs (ATT&CK procedure).
- Cutting Edge (C0029): threat actors stole the running configuration and cache data from Ivanti Connect Secure VPN appliances (Volexity and Mandiant, January 2024), a network device case of T1005.
- Windigo (G0124): used a script to gather credentials left in files on disk by OpenSSH backdoors (ESET, 2018).
- GALLIUM (G0093): collected password hashes from the SAM hive in the Registry (Cybereason, 2019).
- Kimsuky (G0094): collected Office, PDF and HWP documents, and harvested files through the Windows recent files list (Securelist and Talos).
- TeamPCP (G1056): stole source code from victim environments (Flashpoint, May 2026).
The pattern across these cases: espionage groups go for documents, but intrusions that spread go for credentials in files, because a config file with a service account password is worth more than any single document.
What to detect and where
ATT&CK v20 detection strategy DET0380, Detection of Local Data Collection Prior to Exfiltration, has one analytic per platform. The table condenses them with the log sources ATT&CK names.
| Platform | Analytic | Data components and log sources (from ATT&CK) | Practical rule |
|---|---|---|---|
| Windows | AN1070: PowerShell, WMI or file API collection with recursive listings, targeted reads and temporary staging | Process Creation (Security 4688); File Creation (Sysmon 11) | Script host or unsigned binary reading many documents across user folders, then writing an archive or temp file |
| Linux | AN1071: shell scripts or tools recursively enumerating home directories, config files or SSH keys | File Access (auditd SYSCALL open); Process Creation (auditd execve) | Reads of ~/.ssh, .env and cloud credential files by processes that are not the owning application |
| macOS | AN1072: bash, zsh or AppleScript locating keychains or documents | Process Creation (unified log process spawn); File Access (fs_usage) | Interpreter processes reading keychain files or bulk-reading Documents |
| Network Devices | AN1073: config collection via CLI (show running-config, copy flash, more), often followed by TFTP or SCP transfer | Command Execution (CLI command logging) | Config display or copy commands outside change windows or from unexpected source addresses |
| ESXi | AN1074: datastore or config access via vim-cmd, esxcli or SCP | File Access (vmkernel datastore access); Command Execution (hostd) | Shell or SCP sessions reading VM disks or host config; see the ESXi Logs Detection Guide |
Make the reads visible
- Windows SACLs on high-value paths: Event 4663 records that an access right was used, and Microsoft states it is generated only if the object's SACL has the required ACE. Put read auditing on a short list of folders (finance shares mirrored locally, secrets folders, browser profile paths on sensitive hosts) rather than everywhere, or you drown in noise.
- Linux audit watches: auditd watches on credential and key paths for the service accounts that own them, so a read by any other process stands out.
- Canary files: plant decoy credential files and documents in places only an attacker would read; any access is a high-fidelity alert. See the File Integrity Monitoring Guide for the monitoring side.
- Network device AAA accounting: send command accounting to a collector so
showandcopycommands are attributable. See the Network Device Syslog and Configuration Change Detection Guide.
Sequences worth alerting on
- Discover, read, pack: recursive listing, then reads of many files of a few extensions, then compression (T1083 then T1005 then T1560).
- Credential sweep: one process touching SSH keys, cloud CLI credential files,
.npmrc,.envand browser stores within minutes. - Agent or package process reading secrets: an AI CLI, package manager hook or build script reading credential files it has no reason to touch.
- Log theft: event log export by a non-admin tool, as in the Volt Typhoon and Aquatic Panda procedures.
Mitigations
ATT&CK v20 maps one mitigation to T1005: M1057 Data Loss Prevention, noting that DLP can restrict access to sensitive data and detect sensitive data that is unencrypted. The rows after it are NHI Mgmt Group recommendations.
| Control | Source | What it stops or reveals |
|---|---|---|
| Endpoint DLP with sensitivity labels | ATT&CK M1057 | Flags or blocks copying of classified files; see the Endpoint DLP Guide |
| Secrets out of files | NHI Mgmt Group recommendation | Inject credentials at runtime from a secrets manager so config files hold no reusable secret |
| Least privilege on data | NHI Mgmt Group recommendation | Service accounts and users read only what their job needs, which shrinks what a hijacked process can gather |
| OS privacy controls (macOS) | Apple platform security | Since macOS 10.15 the system requires user consent before an app accesses Desktop, Documents, Downloads, iCloud Drive and network volumes; Full Disk Access must be granted explicitly. Manage these grants by MDM and keep Full Disk Access lists short; see the macOS TCC and Privacy Permissions Management Guide |
| Encryption at rest | NHI Mgmt Group recommendation | Protects data on lost devices and offline disks; it does not stop a process running as the logged-in user, so pair it with access controls |
| Credential Guard and LSA protection (Windows) | NHI Mgmt Group recommendation | Reduces what can be harvested from memory; see Credential Guard and VBS |
Where identity fits
T1005 is where most non-human credentials are first stolen. Service account passwords in application config, cloud access keys in CLI credential files, deploy keys in ~/.ssh and API keys in .env files are all local data. Both breach cases above turned local files into access elsewhere: the GTG-1002 agents reused certificates found in config files across many services, and the Nx malware harvested tokens that unlocked thousands of repositories. Three controls reduce the payoff: replace static secrets with workload identity or short-lived tokens, scope each machine credential to one purpose so a stolen one does not work across systems, and give AI coding agents their own identity with read access limited to the project. See the Claude Code Security Guide for agent-side settings.
How to test and roll out
- Pick the targets: list where secrets and sensitive files live on each server class, developer laptops and network devices. Scanning for secrets in files is the fastest way to find the worst exposures.
- Turn on targeted auditing: SACLs on a few Windows paths, auditd watches on key Linux paths, AAA command accounting on network devices, ESXi hostd and shell logs forwarded.
- Emulate safely: an authorised tester runs an emulation mapped to T1005 that reads planted test documents and decoy credential files, on pilot hosts only.
- Validate and tune: confirm each analytic fires; add named exclusions for backup agents, indexers and EDR scanners rather than broad path exclusions.
- Roll out by ring: pilot servers, then sensitive server classes, then developer endpoints. Watch audit volume at each step.
- Roll back: if audit volume or performance becomes a problem, remove the SACL or watch from the noisiest path first and keep canaries in place.
Metrics
- Share of servers with no plaintext secrets in config files (from secret scanning).
- Number of high-value paths with read auditing or canaries in place.
- Time from emulated collection to alert triage.
- Network devices with command accounting sent to the SIEM.
- Apps holding macOS Full Disk Access, tracked down over time.
Common failure patterns
- Auditing writes but not reads: file integrity monitoring catches change, but collection is all reads.
- Auditing everything: broad read SACLs produce so many 4663 events that they are filtered out before anyone looks.
- Secrets in config files: the most valuable local data is often a password the application could fetch at runtime instead.
- Ignoring network devices and hypervisors: configs and datastores are local data too, and these platforms rarely run EDR.
- Trusting developer tooling: package install hooks and AI CLIs run with the developer's file access; the Nx case shows that access being turned against the machine.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1005; TA0009; DET0380; M1057 | Technique, detection strategy, mitigation |
| MITRE ATT&CK (related) | T1083; T1119; T1552.001; T1560; T1074.001 | Steps before and after collection |
| MITRE ATLAS | AML.T0037 Data from Local System | AI system equivalent |
| NIST SP 800-53 Rev 5 | AC-3 Access Enforcement; AC-6 Least Privilege; SC-28 Protection of Information at Rest | Limit what a process can read |
| NIST SP 800-53 Rev 5 | AU-2 Event Logging; AU-12 Audit Record Generation; SI-4 System Monitoring | Read auditing and monitoring |
| NIST CSF 2.0 | PR.DS-01; PR.AA-05; DE.CM-09 | Protect data at rest, least privilege, monitor endpoints |
Practitioner checklist
- Scan servers and developer endpoints for secrets in files and move them to a secrets manager.
- Put read auditing or canaries on a short list of high-value local paths.
- Alert on the discover, read and pack sequence on servers.
- Alert on processes other than the owner reading SSH keys and cloud credential files.
- Log network device
showandcopycommands with AAA accounting. - Forward ESXi hostd and shell logs and alert on datastore reads over SCP.
- Manage macOS Full Disk Access by MDM and review the list quarterly.
- Give AI coding agents scoped identities and project-only file access.
Standards and references
- MITRE ATT&CK: Data from Local System (T1005)
- MITRE ATT&CK: Data Loss Prevention (M1057)
- MITRE ATT&CK: Anthropic AI-orchestrated Campaign (C0062)
- Microsoft: 4663(S) An attempt was made to access an object
- Apple: Controlling app access to files in macOS
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: ATT&CK Collection Tactic Guide · CIS Control 3 Data Protection Guide · MITRE ATT&CK T1552 Unsecured Credentials Guide · T1083 File and Directory Discovery · Data Exfiltration Guide · MITRE ATT&CK T1039 Data from Network Shared Drive · MITRE ATT&CK T1025 Data from Removable Media · MITRE ATT&CK T1602 Data from Configuration Repository