Once an attacker holds a valid account or token, the richest data in most organisations sits in collaboration and data platforms that were built to be searched, shared and exported. MITRE ATT&CK tracks this as T1213 Data from Information Repositories in the Collection tactic (TA0009), with six sub-techniques in v20: Confluence, SharePoint, code repositories, CRM software, messaging applications and databases. This guide explains the technique at the level ATT&CK describes it, then concentrates on what defenders can do: the detection strategies and log sources MITRE maps to each sub-technique, the audit events to collect in Microsoft 365, GitHub, Confluence, Salesforce and Snowflake, the hardening that limits what a stolen identity can read, and how to measure progress. It is for detection engineers, SaaS and platform owners, and data governance teams.
Key takeaways
- T1213 is legitimate access used at the wrong scale. Almost every case starts with a valid human account, OAuth app or API token, so the signal is volume, breadth and context, not a malicious binary.
- Non-human identities are both the key and the prize. Integration tokens and service accounts read repositories in bulk by design, and the repositories themselves hold API keys and passwords that feed the next stage.
- Logging coverage decides detection. Several platforms do not record reads by default, keep them for days rather than months, or put them behind a higher licence tier. Confirm what you actually receive before writing analytics.
- Least privilege and export controls beat alerts. Restricting who can bulk export, who can approve connected apps and which networks can log in removes most of the attacker's speed.
- Treat repositories as credential stores. Scan wikis, chat and code for secrets, rotate what you find, and keep incident response conversations off channels an intruder may be reading.
How the attack works
ATT&CK describes T1213 as adversaries leveraging information repositories, tools for storing and sharing information between users, to mine data that helps further objectives such as Credential Access, Lateral Movement or Defense Evasion, or that is the target itself. MITRE also notes that attackers may abuse external sharing features to send documents outside the organisation, which overlaps with T1537 Transfer Data to Cloud Account. From a defender's view the technique needs three things:
- An identity with read access: a phished or infostealer-captured user login, a session token, or an OAuth app or API key that already has broad read scopes (see the MITRE ATT&CK T1078 Valid Accounts Guide).
- Over-broad reach: sites, spaces, channels or tables readable by "everyone", stale group memberships, or repositories exposed to the internet. MITRE calls out cloud-hosted services such as Amazon RDS, Redis and Elasticsearch being left open to unauthenticated users.
- Bulk retrieval paths: search, API pagination, sync clients, export functions and database clients that let a session pull thousands of objects quickly.
| ID | Name (ATT&CK v20) | What attackers look for | Platforms |
|---|---|---|---|
| T1213 | Data from Information Repositories | Policies, network and architecture diagrams, test credentials, source snippets, links to shares, partner and customer PII | Linux, Windows, macOS, SaaS, IaaS, Office Suite |
| T1213.001 | Confluence | Development documentation, runbooks, credentials pasted into pages | SaaS |
| T1213.002 | Sharepoint | Internal structure of networks and systems, procedures, project schedules | Office Suite, Windows |
| T1213.003 | Code Repositories | Proprietary source code and credentials committed to it, to build exploits or reuse as valid accounts | SaaS |
| T1213.004 | Customer Relationship Management Software | Customer names, emails, phone numbers, addresses, purchase and support history for phishing, SIM swapping and extortion | SaaS |
| T1213.005 | Messaging Applications | Credentials, code, proprietary data and live incident response discussions in Teams, Google Chat or Slack | Office Suite, SaaS |
| T1213.006 | Databases | Usernames, password hashes, PII and financial data in MySQL, PostgreSQL, MongoDB, RDS, Azure SQL, Firebase or Snowflake, for extortion or sale | IaaS, Linux, macOS, SaaS, Windows |
T1213.003 is distinct from the Reconnaissance sub-technique T1593.003, which covers searching public code repositories before an intrusion. Data pulled from repositories is usually staged and archived (see the T1560 and T1074 Archive and Stage Collected Data Defensive Guide) and then exfiltrated over web services. The parent tactic is covered in the ATT&CK Collection Tactic Guide.
Where it shows up
- Data warehouses: Mandiant's June 2024 report on UNC5537 found the actor logging into Snowflake customer instances with infostealer-harvested passwords, listing tables with
SHOW TABLES, then copying whole tables through temporary stages using legitimate clients such as SnowSQL and DBeaver. See the Snowflake Breach 2024. - CRM platforms: in the ShinyHunters Salesforce Data Theft Campaign, callers posing as IT support persuaded staff to approve a modified Data Loader connected app, which then bulk-exported tables through the API. ATT&CK records this as campaign C0059 against T1213.004.
- Code platforms: MITRE lists LAPSUS$, Scattered Spider, ShinyHunters and APT41 among users of T1213.003. In the Samsung source code leak, roughly 190GB of code published by Lapsus$ contained 6,695 secrets according to GitGuardian's analysis.
- Collaboration suites: HAFNIUM, Chimera, APT28 and Akira are among the groups ATT&CK links to SharePoint collection. See the SharePoint and OneDrive Security Guide.
- Chat: ATT&CK notes attackers reading messaging platforms to follow and evade an ongoing incident response, citing Scattered Spider and LAPSUS$ activity.
Impact
- Extortion and resale: customer and database records are the commodity in the Snowflake and Salesforce campaigns; prosecutors reported over $2.5 million in ransom paid in the Snowflake case.
- Credential harvest: secrets found in pages, chat and code become new valid accounts. See the MITRE ATT&CK T1552 Unsecured Credentials Guide, especially T1552.008 Chat Messages.
- Response compromise: an intruder reading the incident channel knows which accounts are being reset before they are.
Detection
ATT&CK v20 replaces free-text detection notes with detection strategies (DET IDs) made of platform-specific analytics (AN IDs) and named log sources. The table lists what MITRE maps for T1213, read from the official v20 dataset. See the ATT&CK Detection Strategies and Analytics Guide for how to use them.
| Technique | Detection strategy | Behaviour to detect | Log sources named by MITRE |
|---|---|---|---|
| T1213 | DET0413 Abuse of Information Repositories for Data Collection | Accounts not normally using a repository enumerating many files or downloading sensitive content in bursts; scripted scraping of wikis or internal APIs | Windows Security 5145; M365 unified audit SharePoint access; Confluence access.content; Slack exports and admin API |
| T1213.001 | DET0358 Programmatic and Excessive Access to Confluence Documentation | Burst page views or exports, REST API access from non-browser agents, privileged users mass enumerating spaces | Confluence access, logon and REST API events |
| T1213.002 | DET0500 Detecting Abnormal SharePoint Data Mining by Privileged or Rare Users | Privileged or rarely used accounts bulk accessing files or metadata in a short window | M365 unified audit FileAccessed, FileDownloaded, SearchQueried; Entra sign-in logs |
| T1213.003 | DET0263 Detecting Bulk or Anomalous Access to Private Code Repositories via SaaS Platforms | Bulk clone or download by non-developer accounts, preceded by unusual login, new token or OAuth authorisation | GitHub repo.download, repo.clone, oauth.authorize, token creation |
| T1213.004 | DET0550 Detecting Suspicious Access to CRM Data in SaaS Environments | High-volume access to customer records or PII fields by a non-admin account, after a rare location or device | Salesforce DataExport, RestAPI, Login, ReportExport |
| T1213.005 | DET0567 Detecting Unauthorized Collection from Messaging Applications | Mass retrieval of chat history via API, automation token or export after a rare sign-in; Teams messages via eDiscovery or Graph export | Slack conversations.history, files.list, audit logs; M365 unified audit |
| T1213.006 | DET0242 Suspicious Database Access and Dump Activity Across Environments | Database clients run by non-admin users or odd parents, dump-like files written, outbound transfer soon after; SELECT * on sensitive tables by identities outside analytics groups | Security 4688, Sysmon 11, 3 and 22; auditd execve; CloudTrail rds:ExecuteStatement and S3 PutObject; Snowflake query logs |
Platform audit events to confirm you collect
| Platform | Events | Coverage caveat |
|---|---|---|
| Microsoft 365 (Purview Audit) | FileAccessed, FileDownloaded, SearchQueryPerformed; eDiscovery PurviewSearchExportJobSubmitted | Microsoft states the same user and file are not logged again for FileAccessed within five minutes, so count distinct files, not events |
| GitHub Enterprise Cloud | git.clone, git.fetch, git.push | Git events are only available through the REST API, streaming or exports, not the web UI, with 7-day retention via the API: stream them to your SIEM |
| Confluence Cloud | Space export, permission and anonymous access changes, public links, content viewed with admin key | Atlassian states the site audit log does not record content edits, and its list does not include ordinary page views; it is not available on the Free plan |
| Snowflake | ACCESS_HISTORY joined to QUERY_HISTORY by query_id; login history and client application IDs | ACCESS_HISTORY needs Enterprise Edition or higher, has up to three hours' latency and keeps 365 days |
Analytic patterns that work
- Distinct-object volume per identity: distinct files, pages, repositories or tables read per hour against the identity's own 30-day baseline and its peer group.
- Sequence, not single event: new sign-in context (country, ASN, commercial VPN, device) or new token or app consent, followed within an hour by bulk reads.
- Client fingerprint: unfamiliar user agents or client application IDs, such as scripting libraries against SaaS APIs. Mandiant published Snowflake client IDs seen in UNC5537 sessions for this purpose.
- Export and share actions: eDiscovery exports, workspace exports, report exports and anonymous link creation by anyone outside a small approved group.
- Canaries: decoy documents, wiki pages and database rows that no legitimate process should ever read.
Prevention and hardening
ATT&CK lists seven mitigations for the parent technique. The table turns them into concrete actions.
| Mitigation | Sub-techniques | Concrete action |
|---|---|---|
| M1018 User Account Management | All | Least privilege on sites, spaces, repositories, CRM profiles and database roles; remove "everyone" grants; restrict bulk export and API permissions to named roles |
| M1032 Multi-factor Authentication | Parent, .003 | Phishing-resistant MFA on every human login to repositories and data platforms, including contractors; SSO so session policy applies |
| M1047 Audit | All | Periodic access reviews of sensitive repositories; check databases are not exposed publicly; scan code and chat for credentials |
| M1017 User Training | All | Published rules on what may be stored in wikis, chat, CRM and databases; support staff trained never to approve apps or read codes on a call |
| M1054 Software Configuration | Parent, .004, .006 | Retention policies that archive or delete data no longer needed, shrinking what can be taken |
| M1041 Encrypt Sensitive Information | Parent, .006 | Encryption at rest, plus column masking or tokenisation for the fields attackers sell |
| M1060 Out-of-Band Communications Channel | Parent, .005 | A separate, pre-arranged channel for incident response when the main chat may be compromised |
Rollout order
- Confirm telemetry: list each repository, whether read and export events are logged, at what licence tier, and for how long. Stream short-retention sources such as GitHub git events to the SIEM. Test by performing a known download and finding it.
- Close public and tenant-wide exposure: remove anonymous links, public spaces and internet-reachable databases; pilot on one business unit and roll back individual sites by restoring their previous sharing setting if a process breaks.
- Lock down integration identities: inventory OAuth apps and API tokens with read scopes, give each an owner, remove unused ones and restrict who may approve new connected apps. See the SaaS and OAuth App Governance Guide.
- Restrict network and session context: IP allow lists or conditional access for data platforms and admin consoles; this is the control UNC5537 victims lacked alongside MFA.
- Sweep for secrets: scan wikis, chat exports and full repository history, rotate live findings, then turn on push protection.
- Deploy analytics in alert-only mode: run the volume and sequence detections for two to four weeks, tune per-identity baselines and allow lists for backup, search crawler and eDiscovery service accounts, then move high-confidence rules to automated session revocation.
Choosing where to start
If your crown jewels sit in a data warehouse or CRM, start with MFA, network restrictions and export permissions there: those three settings would have blocked the published 2024 and 2025 campaigns. If code is the main asset, start with SSO enforcement, token hygiene and git event streaming. Small organisations can rely on native platform alerts plus quarterly sharing reviews; large ones need SIEM correlation across sign-in and repository logs and a data access governance programme. See the Data Access Governance Guide.
Where identity fits
Service accounts, connected apps and personal access tokens are the identities most likely to read repositories in bulk, and they are often exempt from MFA and session controls. Give each a single owner, the narrowest read scope that works, a network restriction, a short lifetime and a separate baseline from human users. The Snowflake case shows the cost of password-only accounts; Snowflake has since announced the phase-out of single-factor password sign-in. See the Snowflake Security Guide and the GitHub Personal Access Tokens Security Guide.
Lessons from incidents
- A password was enough: Mandiant found that at least 79.7% of accounts used against Snowflake customers had prior credential exposure, some unchanged for years.
- Users could approve data-reading apps: the Salesforce vishing campaign worked because ordinary staff could authorise a new connected app with export rights.
- Code held keys: the Samsung leak turned a source code theft into thousands of exposed secrets that each needed rotation.
Framework mapping
| Framework | Relevant items |
|---|---|
| NIST SP 800-53 Rev. 5 | AC-2 Account Management; AC-3 Access Enforcement; AC-6 Least Privilege; AU-12 Audit Record Generation; AU-6 Audit Record Review, Analysis, and Reporting; SI-4 System Monitoring; SC-28 Protection of Information at Rest |
| NIST CSF 2.0 | PR.AA-05 access permissions managed with least privilege; PR.DS-01 data at rest protected; DE.CM-03 personnel activity and technology usage monitored; DE.AE-02 adverse events analysed |
| ISO/IEC 27001:2022 Annex A | 5.15 Access control; 8.3 Information access restriction; 8.15 Logging; 8.16 Monitoring activities |
| CIS Controls v8.1 | Control 3 Data Protection; Control 6 Access Control Management; Control 8 Audit Log Management |
| Related ATT&CK | T1078.004 Cloud Accounts; T1528 Steal Application Access Token; T1566.004 Spearphishing Voice; T1119 Automated Collection; T1530 Data from Cloud Storage; T1567.002 Exfiltration to Cloud Storage |
Practitioner checklist
- Map every information repository to its read, export and sign-in log source, licence tier and retention, and fix gaps.
- Stream GitHub git events, M365 audit, CRM event logs and warehouse access history to the SIEM.
- Remove public and tenant-wide access to sites, spaces, channels and databases holding sensitive data.
- Require phishing-resistant MFA and SSO for all human access, including contractors, and network restrictions for data platforms.
- Inventory OAuth apps, service accounts and tokens with read scopes; assign owners and restrict who can approve new apps.
- Limit bulk export, report export and eDiscovery export rights to named roles and alert on their use.
- Scan wikis, chat and code history for secrets and rotate every live finding.
- Deploy volume and sequence analytics per identity, plus canary documents and rows.
- Agree an out-of-band incident channel before you need it.
Standards and references
- MITRE ATT&CK: Data from Information Repositories (T1213)
- MITRE ATT&CK: Databases (T1213.006)
- Google Cloud (Mandiant): UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion
- Microsoft Learn: Audit log activities
- GitHub Docs: Audit log events for your organization
- Atlassian: View the audit log (Confluence Cloud)
- Snowflake Documentation: ACCESS_HISTORY view
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Data Access Governance Guide · ATT&CK Collection Tactic Guide · SaaS and OAuth App Governance Guide · MITRE ATT&CK T1552 Unsecured Credentials Guide