ATT&CK Collection Tactic (TA0009) Guide: Catching Data Gathering Before Exfiltration

Before data leaves an organisation it has to be found, gathered and packaged, and the Collection tactic (TA0009) in MITRE ATT&CK is the window in which defenders can still stop the loss. ATT&CK v20 describes the tactic as the adversary "trying to gather data of interest to their goal", and notes that the next step is usually to exfiltrate it or use it to learn more about the target. Collection is noisier than exfiltration: bulk reads from file shares, SharePoint and cloud storage, mailbox syncs, archive creation and staging directories all leave records. This guide maps the 17 Collection techniques in v20, shows where they appear, and concentrates on the data access telemetry, analytics and controls that catch collection early. It is written for SOC analysts, data security and DLP owners, and cloud and SaaS administrators.

Key takeaways

• Collection is the last cheap place to catch a data theft. Once data is archived and leaving over an encrypted channel, the options shrink to containment and notification.
• Local files and staging dominate the procedure data. In the v20 dataset Data from Local System (T1005) has 236 recorded uses, Screen Capture (T1113) 172, Keylogging (T1056.001) 155, Local Data Staging (T1074.001) 144 and Archive via Utility (T1560.001) 89.
• Many Collection techniques have no direct mitigation. ATT&CK lists no mitigations for Screen Capture, Clipboard Data, Audio Capture, Video Capture and Data Staged, so detection and least-privilege data access carry the load.
• Repositories and cloud storage are the high-value targets. T1213 Data from Information Repositories (SharePoint, Confluence, code repositories, CRM, messaging, databases), T1530 Data from Cloud Storage and T1114 Email Collection reach far more data than any single endpoint.
• Most large collection uses valid identities. Stolen user sessions, OAuth apps and service account keys read data through normal APIs, so data access baselines per identity matter more than malware detection.

How the attack works

Collection follows discovery (finding where valuable data is) and precedes exfiltration or impact. A typical sequence is to enumerate shares, sites and buckets, read or download the data of interest, stage it in one location, then compress and often encrypt it. ATT&CK groups the 17 techniques as follows.

Packaging is the most reliable common step: whatever the source, attackers usually gather data into one place and compress it before sending it out. See the T1560 and T1074 Archive and Stage Collected Data Defensive Guide for that stage, and the Data Exfiltration Guide for what happens next.

Where it shows up

• Ransomware double extortion: operators collect from file servers and document repositories, stage on one host, archive with common utilities and then exfiltrate before encrypting.
• SaaS data theft with stolen credentials: infostealer credentials or hijacked sessions are used to read Jira, Confluence, Salesforce or SharePoint at volume through normal APIs. See the T1213 Data from Information Repositories Defensive Guide.
• Mailbox espionage: remote collection through Exchange Web Services or Graph by a compromised account or OAuth app, or a forwarding rule that copies mail outside the organisation. See the T1114 Email Collection Defensive Guide.
• Cloud storage: a leaked access key or over-permissive role used to list and download buckets or blob containers. See the T1530 Data from Cloud Storage Defensive Guide.
• Code repositories: source code and embedded secrets cloned from GitHub, GitLab or Bitbucket using a stolen developer token.
• Endpoint spyware: keylogging, screenshots and clipboard capture by remote access trojans and infostealers.

Impact

Collection on its own does not destroy anything, but it sets the scale of the eventual breach. What was collected decides the notification obligations, the extortion leverage, the intellectual property lost and the secrets that must be rotated. A collected code repository often contains API keys and cloud credentials, which turns a data loss into a second intrusion. Collection evidence also defines scope during response: audit records such as the Microsoft 365 MailItemsAccessed action exist so that investigators can say which items an attacker accessed, and without them the safe assumption is that everything reachable was taken.

Detection

ATT&CK v20 detection strategies for Collection focus on access volume, unusual access by identity and the transition from reading to packaging.

Telemetry to enable first

1. Cloud storage data events: CloudTrail S3 data events for sensitive buckets (management events alone do not record GetObject), and equivalent diagnostic logs for Azure Storage and Google Cloud Storage.
2. Microsoft 365 audit: confirm the unified audit log is on and that MailItemsAccessed is recorded; Microsoft documents it as enabled by default for users with E3 or E5 licences and recording both sync (folder download) and bind (single message) access.
3. File share access: Event ID 5145 detailed file share auditing on servers that hold sensitive data, scoped to avoid volume problems.
4. SaaS application logs: Atlassian, Salesforce, GitHub and Slack audit and export events into the SIEM.
5. Endpoint: EDR file and API telemetry for screen, clipboard and audio capture, which native logs rarely show.

Analytics that work

• Per-identity volume baselines: downloads or object reads per user, service account and OAuth app per day, alerting on multiples of the 30-day baseline (D3FEND D3-UBA User Behavior Analysis and D3-FAPA File Access Pattern Analysis).
• First access to a repository: an identity reading a SharePoint site, Confluence space or bucket it has never touched, at volume.
• Read then archive: large numbers of file reads followed within minutes by archive creation on the same host.
• Decoy files: canary documents and fake credentials in high-value shares that alert on any open (D3-DF Decoy File).

Metrics that show it is working

• Logging coverage: share of sensitive data stores (buckets, sites, repositories) with data access logging enabled and in the SIEM.
• Baseline coverage: share of service accounts and OAuth apps with a data access baseline and volume alert.
• Time to detect bulk access: measured with planned purple-team downloads from a test account.
• Oversharing trend: count of anonymous or organisation-wide sharing links on sensitive sites, falling quarter on quarter.

Prevention and hardening

Phased rollout

1. Classify: identify the 10 to 20 data stores whose loss would matter most and who owns each.
2. Log: turn on data access logging for those stores and confirm events reach the SIEM.
3. Baseline: collect 30 days of access by identity and agree normal volumes with data owners.
4. Alert in monitor mode: run volume and first-access analytics without paging, tune for backup jobs, search indexers and migration tools.
5. Restrict: remove broad permissions and enforce DLP block rules in rings; keep a rollback to audit-only per rule if business processes break.

Decision guidance

• Prevent or detect: permission clean-up reduces exposure permanently; detection catches what permissions allow. Start with permissions on the most sensitive stores, detection everywhere else.
• Small organisations: lean on the SaaS platforms' built-in audit and sharing controls and block external forwarding; full DLP can wait.
• Large organisations: invest in per-identity baselines for non-human identities, which perform most bulk reads and are rarely reviewed.

Framework mapping

Where identity fits

Bulk collection from SaaS and cloud storage is almost always performed by an authenticated identity: a stolen user session, an OAuth app granted broad read scopes, or a service account key. Review OAuth grants with Files.Read.All, Mail.Read or Sites.Read.All style scopes, give integration accounts the narrowest data scope, and alert when a non-human identity reads from a store outside its normal pattern. See the SharePoint and OneDrive Security Guide.

Lessons from incidents

• Infostealer credentials into a repository: in the Schneider Electric Jira breach (November 2024), credentials linked by Hudson Rock to a Lumma infostealer infection were used to access an internal Jira server; the attacker claimed over 40GB of compressed project data and said a REST API was used to scrape about 400,000 rows of user data. Per-identity download volume alerts and API rate monitoring are the controls that would surface this kind of collection.

Common failure patterns

• Management events without data events: cloud logging that records configuration changes but not object reads leaves collection invisible.
• Audit logs not retained long enough: collection is often discovered weeks later, after short retention has expired.
• Oversharing by default: organisation-wide links and Everyone permissions let any compromised account read everything.
• No baseline for service accounts: integration identities can read at volume every day, so attacker use of them blends in unless their normal is defined.
• External forwarding allowed: a single inbox rule silently copies a mailbox for months.

Practitioner checklist

• List the most sensitive data stores and confirm data access logging is on for each.
• Enable CloudTrail S3 data events (or equivalents) for sensitive buckets.
• Confirm the Microsoft 365 unified audit log and MailItemsAccessed are recorded and retained.
• Build per-identity download and object-read baselines with volume alerts.
• Alert on archive creation following bulk file reads on the same host.
• Block automatic external mail forwarding and alert on new forwarding rules.
• Remove broad share and site permissions and review anonymous links.
• Review OAuth apps holding tenant-wide read scopes.
• Plant decoy files in high-value shares and repositories.

Standards and references

• MITRE ATT&CK: Collection (TA0009)
• MITRE ATT&CK: Data from Information Repositories (T1213)
• MITRE ATT&CK: Archive Collected Data (T1560)
• MITRE ATT&CK: Data from Cloud Storage (T1530)
• Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts
• MITRE D3FEND: User Behavior Analysis
• NIST: SP 800-53 Rev. 5
• CIS: CIS Controls v8.1

Related NHI Mgmt Group resources: Data Exfiltration Guide · T1560 and T1074 Archive and Stage Collected Data Defensive Guide · T1114 Email Collection Defensive Guide · ATT&CK Credential Access Tactic Guide