Automated Collection (T1119) is a collection technique in MITRE ATT&CK. It covers IaaS, Linux, macOS, Office suites, SaaS and Windows, which means it applies to your laptops, your servers and your cloud accounts.
Once an attacker is inside, finding data by hand is slow. A script that does the searching and copying is faster, quieter and repeatable. This post covers what MITRE documents about the technique, how to spot it and what limits the damage.
How attackers use it
MITRE describes an adversary, once established in a system or network, using automated techniques to collect internal data. That might be a command and scripting interpreter that searches for and copies information matching set criteria such as file type, location or name, at specific time intervals.
In cloud environments, MITRE adds that adversaries may use cloud APIs, data pipelines, command line interfaces or extract, transform and load (ETL) services to collect data automatically. The same functionality can be built into remote access tools.
The technique often works together with others. MITRE names file and directory discovery and lateral tool transfer for identifying and moving files, and cloud service dashboard and cloud storage object discovery for finding resources in cloud environments.
The common thread is repetition. The same search or copy runs again and again, or on a schedule, and picks up new files as they appear. That is a big difference from one-off browsing, and it is also what makes it detectable.
How to detect it
MITRE's strategy is Automated File and API Collection Detection Across Platforms. Its analytics describe:
- Windows: automated execution of native utilities and scripts to find, enumerate and exfiltrate files and clipboard content. The focus is repeated file access, scripting engine use and command line utilities commonly used by collection scripts.
- Linux: repeated or automated access to user document directories or the clipboard using shell scripts or utilities such as xclip or pbpaste, visible through auditd syscall logs or osquery file events.
- macOS: use of pbpaste, AppleScript or third-party automation frameworks such as Automator to collect clipboard or file content in bursts, visible in unified logs.
- Cloud and Office suite: suspicious sign-ins to Graph API or sensitive resources using non-browser scripting agents such as Python or PowerShell, often for programmatic access to mailbox or OneDrive content.
Signals to build on:
- A process reading many files across directories in a short time, especially files of one type such as documents or spreadsheets.
- Searches for specific extensions or keywords by scripting engines.
- Recurring access on a timer, such as the same job at the same minute each hour.
- Files copied into a staging folder, compressed and then sent out.
- In cloud logs, a spike in list and get operations on storage or mail by an identity or application that does not normally make them, or a scripting user agent.
Data sources include process creation logs with command lines, file access auditing on sensitive shares, auditd or osquery on Linux, and cloud audit logs such as storage access and Graph API activity.
How to reduce the risk
MITRE lists two mitigations, and it is candid about their limits:
- Encrypt sensitive information. Encryption and off-system storage of sensitive information can be one way to mitigate collection, but may not stop an adversary who stays in for a long time and can find and use the data through other means. Use strong passwords on encrypted documents that use them, to prevent offline cracking through brute force.
- Remote data storage. Same guidance as above: off-system storage and encryption help, with the same caveat about long intrusions.
Beyond what MITRE lists, practical limits on blast radius:
- Apply least privilege to shares, mailboxes and cloud storage so a single account cannot read everything.
- Separate sensitive data into stores with their own access rules and logging.
- Alert on volume. A normal user does not read thousands of documents in ten minutes.
- Shorten the lifetime of tokens and keys that cloud automation uses, and rotate them.
- Remove idle scheduled tasks and cron entries nobody owns.
Check your own environment
- Where do your most sensitive files and records live, and who can read them?
- Do you log reads on those locations, not only writes?
- Can you detect one identity reading far more than its baseline?
- Are cloud storage and mailbox audit logs enabled and retained?
- Do you know which service accounts and apps have broad read access in your cloud tenants, and why?
- Are scheduled tasks and cron jobs reviewed for owners and purpose?
Read-only commands:
# Windows (cmd): list scheduled tasks in verbose list format to review owners and actions
schtasks /query /fo LIST /v
# Linux: show the current user's cron entries (run as each user, or review /etc/cron.* as root)
crontab -l
Tasks that run scripts you do not recognize, or run under an unexpected account, are the first ones to look into.
Try it yourself
Controlling automated collection in the cloud starts with seeing which accounts and connectors have access to what. This demo walks through cloud connectors.
Click through it at your own pace, or open it full screen.
Quick check
What makes automated collection different from manual browsing?
It repeats on set criteria or intervals, searching and copying files by type, location or name, which creates volume and timing patterns that can be detected.
What caveat does MITRE give about encryption as a mitigation?
It may not stop an adversary who remains in the environment for a long period and can reach the data through other means.
Which cloud mechanisms does MITRE name for automatic collection?
Cloud APIs, data pipelines, command line interfaces and ETL services.
Sources
- MITRE ATT&CK, Automated Collection (T1119)
