Data from Local System (T1005) is a collection technique. Before exfiltrating anything, adversaries search local system sources such as file systems, configuration files, local databases, virtual machine files and process memory to find files of interest and sensitive data. MITRE lists ESXi, Linux, macOS, Network Devices and Windows as platforms.
This step is quiet. It looks like a user or an administrator browsing files. The sensitive part is what comes next, which is moving the data out.
How attackers use it
MITRE says adversaries may use a command and scripting interpreter, such as cmd, or a network device CLI, to interact with the file system and gather information. They may also use automated collection on the local system. Nothing exotic is needed. Built-in commands that list and read files do the work.
The technique is also a reminder of why data location matters. What an adversary finds depends on what you left lying around: unencrypted exports, old backups, configuration files with passwords, and key material in home directories.
How to detect it
MITRE's detection strategy is platform-specific:
- Windows: collection through PowerShell, WMI or direct file API calls, which often shows up as recursive file listings, targeted file reads and temporary file staging.
- Linux: bash scripts or tools that recursively enumerate user home directories, configuration files or SSH keys.
- macOS: bash, zsh or AppleScript used to locate files and targets such as user keychains or documents.
- Network devices: configuration collection through CLI commands such as show running-config, copy flash, or more, often followed by TFTP or SCP transfers.
- ESXi: access to datastore or configuration files through vim-cmd, esxcli or SCP to pull logs, VMs or host configuration.
Useful data sources are command execution logs, process creation events, file access auditing on sensitive locations and network device command accounting.
One strong approach is to pick a small set of high-value folders and watch only those. Alerting on every file read is noise. Alerting on a script walking a directory of customer exports is a signal.
How to reduce the risk
MITRE lists one mitigation, Data Loss Prevention. It can restrict access to sensitive data and detect sensitive data that is unencrypted.
Make that practical:
- Find sensitive data first, using discovery tools, so you know where it sits.
- Encrypt data at rest where you can, so a file read is not the end of the story.
- Delete data you no longer need. A forgotten export cannot be stolen.
- Limit who can read sensitive locations, and use separate accounts for administration.
- Watch for staging. Large archives created shortly before outbound transfers are a classic pair.
Think like the data
The most useful exercise for this technique is to follow the data instead of the attacker. Pick one sensitive dataset, such as customer records, signing keys or source code. Trace where copies of it live: the primary store, the replicas, the backups, the exports somebody made for a report, the laptop of a developer who tested with real data. Each copy is a place for collection to succeed.
Write the list down. For each copy, note who can read it, whether it is encrypted and whether reads are logged. You will find gaps, and each gap is a cheap fix compared with an incident.
A small watch plan
- Choose five locations that hold sensitive material on servers.
- Turn on file read auditing for those folders only.
- Exclude the service accounts that need access, so the alerts mean something.
- Add an alert for archive creation, such as compressed files, close to those locations.
- Send the results to a place the server's own administrators cannot edit.
Five folders with clean alerts beat five thousand with noise.
Signals that matter after collection
Collection leads to staging, then transfer. The pairs to correlate are file reads followed by archive creation, archive creation followed by outbound connections, and outbound connections that carry roughly the same amount of data as the archive. Each pair alone is weak. Together they tell a story.
For network devices and ESXi hosts, the story is shorter. A configuration read followed by a TFTP or SCP transfer from a device that never initiates transfers is nearly always worth a look.
Check your own environment
A few read-only questions to settle this month:
- Where are your unencrypted exports, database dumps and backups?
- Which folders hold secrets such as keys, tokens or config files with passwords?
- Do your servers log command execution, and who reads those logs?
- On network devices, is command accounting sent to a central server?
Secrets in files are a common finding. The demo below shows how scanning for them works.
Click through it at your own pace, or open it full screen.
Quick check
Why is collection hard to detect on its own?
Listing and reading files is normal activity. Detection works best when it watches high-value locations and correlates reads with staging and outbound transfers.
What single mitigation does MITRE list for T1005?
Data Loss Prevention, which can restrict access to sensitive data and detect sensitive data that is unencrypted.
