Data Exfiltration Guide: Techniques and Detection

Data theft is now the main payoff of most intrusions, and the largest thefts increasingly leave through legitimate cloud services and stolen tokens rather than through anything a firewall would call suspicious. Extortion crews take data before, or instead of, encrypting it, and SaaS campaigns have emptied CRM tenants through API exports that looked like normal integration traffic. This guide maps the MITRE ATT&CK v20 Collection and Exfiltration techniques at the level defenders need, then spends most of its length on detection, prevention and response: egress control, DNS and proxy telemetry, cloud and SaaS audit logs, volume baselines and the identity controls that decide how much data a stolen credential can reach. It is written for detection engineers, SOC leads, cloud security and identity teams, and deliberately describes techniques only at ATT&CK description level.

Key takeaways

• Exfiltration is the last step of a chain you can see earlier. Collection (TA0009) and staging (T1074, T1560) usually precede the transfer, and they are often easier to detect than the transfer itself.
• The hard cases use trusted services. Exfiltration Over Web Service (T1567) and Transfer Data to Cloud Account (T1537) ride on cloud storage, sharing links and provider APIs that your organisation already allows.
• Identity decides the blast radius. A stolen OAuth token, API key or service account with standing read access to a CRM, warehouse or bucket can export everything it can see, without touching an endpoint.
• Volume per identity is the most useful signal. Baseline bytes, objects and API calls per user, app and service principal, and alert on departures, rather than relying on signatures for specific tools.
• Many logs that matter are off or short-lived by default. CloudTrail S3 data events, Microsoft Graph activity logs and long SaaS audit retention all need deliberate configuration before an incident, not during it.

How data theft unfolds

ATT&CK describes the Exfiltration tactic (TA0010) simply: "The adversary is trying to steal data." It is fed by Collection (TA0009). In real incidents the stages run in sequence, each leaving different evidence:

1. Access: the attacker holds a valid account, session, token or key. In SaaS theft this is often the whole intrusion: no malware, just an identity with read rights.
2. Discovery and collection: data is located and gathered from local systems (T1005), removable media (T1025), network shares (T1039), cloud storage (T1530), information repositories such as SharePoint, Confluence, code repositories, CRM and databases (T1213), or mailboxes (T1114).
3. Staging: ATT&CK notes that "Adversaries may stage collected data in a central location or directory prior to Exfiltration" (T1074, local .001 or remote .002). Archive Collected Data (T1560, via utility, library or custom method) then compresses and often encrypts it.
4. Transfer: the data leaves over the command and control channel (T1041), another protocol (T1048), a web service (T1567), a cloud account on the same provider (T1537), a physical medium (T1052) or another network medium (T1011). Transfers may be throttled (T1030), timed (T1029) or automated (T1020).
5. Use: extortion, sale, or mining the data for further secrets. Google Threat Intelligence reported the Salesloft Drift actor searching exported Salesforce data for AWS access keys, passwords and Snowflake tokens.

A programme that only watches the perimeter for the final transfer sees one of five stages, and the hardest one.

Techniques at a glance

The ATT&CK v20 techniques defenders meet most often, with the telemetry most likely to show them.

Clipboard Data (T1115) and Screen Capture (T1113) are endpoint problems for EDR. Sync tools enable most large transfers: ATT&CK's software entry S1040 describes Rclone as "a command line program for syncing files with cloud storage services" and records its use in Conti and DarkSide ransomware operations and by Scattered Spider. Detect unapproved sync clients on servers whatever the binary is called.

Where identity fits

For cloud and SaaS data, the credential is the exfiltration channel: the attacker calls the provider's API from their own infrastructure with your token, and nothing crosses your network.

• OAuth tokens held by integrations: Google Threat Intelligence reported that from 8 August to at least 18 August 2025, UNC6395 used compromised OAuth tokens for the Salesloft Drift application and "systematically exported large volumes of data from numerous corporate Salesforce instances". See the Gainsight Salesforce breach for the same long-lived token pattern, and the SaaS and OAuth App Governance Guide.
• Connected apps added by social engineering: the ShinyHunters Salesforce data theft campaign used phone calls to get users to authorise malicious connected apps that then pulled CRM data in bulk.
• Stolen user credentials without MFA: the Snowflake breach showed infostealer credentials opening data warehouse accounts that had no MFA.
• App identities reading mail: in the Microsoft Midnight Blizzard breach, an OAuth application with mailbox access was used to read executive email (T1114.002 Remote Email Collection), which appears in logs as app activity, not a user sign-in.
• Sharing tokens and links: a storage SAS token or anonymous link is a bearer credential. ATT&CK lists anonymous links and Azure SAS URIs under T1537, and the Microsoft SAS token exposure shows how one over-permissive link exposed 38TB.
• Service accounts and API keys: inventory, scope and rotate keys with standing read access to buckets, warehouses or repositories. See the API Key Management Guide and the Service Account Security Guide.

ATT&CK's own mitigation for T1048 includes issuing "temporary access tokens instead of permanent credentials", and for T1537 limiting "user account and IAM policies to the least privileges required". Removing standing bulk read access shrinks every cloud exfiltration scenario at once. See the JIT Access Guide.

Detection: the telemetry that matters

No single log shows exfiltration end to end. Close the default gaps before you need them. See the Log Management and Retention Guide.

Analytics that hold up

• Per-identity volume baselines: ATT&CK's analytic for T1567 watches user accounts that "call file upload APIs (M365, Google Drive, Box) at rates outside their baseline". Apply it to downloads, exports, Graph responses and S3 reads for every user, app and service principal, over rolling 7 and 30 day windows so throttled (T1030) and scheduled (T1029) transfers still add up.
• Collection followed by transfer: correlate bulk reads or archive creation with a large outbound transfer from the same host or identity within hours. This survives tool renaming.
• Cross-account movement in cloud: alert on snapshot sharing, backup exports, bucket policy changes or SAS URI generation that grants an account or tenant not on an approved list.
• New external sharing patterns: anonymous links on sensitive sites, sharing to a domain never seen before, and ownership transfers to external users.
• Unapproved sync and transfer clients: cloud sync, FTP or SFTP clients appearing on servers, domain controllers or database hosts.
• AI agents leaving their lane: for T1700, ATT&CK's analytic looks for an AI agent accessing protected data followed by a transfer "to a destination outside authorized data flows". See the AI Agent Observability and Incident Response Guide.

Give each analytic a documented test and an owner. See the Detection Engineering Guide.

Prevention: closing the channels

• Default-deny egress for servers: force outbound web traffic through a proxy, deny direct internet access from server subnets and allow DNS only to internal resolvers, as ATT&CK's Filter Network Traffic mitigation (M1037) describes for T1048. See the Firewall Management Guide and the Network Segmentation Guide.
• Restrict web destinations: per M1021 Restrict Web-Based Content, block personal cloud storage, paste sites and anonymous transfer services by category, and allow only your sanctioned storage tenants where the proxy or SSE supports tenant restrictions.
• Govern cloud sharing: T1537's mitigation M1054 is to "Configure appropriate data sharing restrictions in cloud services". In SharePoint and OneDrive, set organisation sharing to "New and existing guests" or tighter, make any Anyone links expiring and view only, default to "Specific people" links and use "Limit external sharing by domain" for partners. In AWS, keep S3 Block Public Access on at account level and restrict snapshot sharing.
• Remove standing access to bulk data: scope OAuth apps and connected apps to the minimum, remove broad API export permissions from user profiles, apply IP restrictions to integration identities and prefer short-lived tokens. GTIG's Drift guidance adds avoiding "full" scope and granting API access only through permission sets. See the Cloud PAM and CIEM Guide.
• Control removable media and other media: block or read-only USB mass storage on managed endpoints with exceptions by device ID, and disable Bluetooth file transfer where it is not needed. See the Endpoint Security Guide.
• Constrain AI agents: ATT&CK's T1700 mitigations are sandboxing (M1048) and restricting file and directory permissions (M1022). Give agents the narrowest data scope and allowlist outbound destinations. The ForcedLeak vulnerability showed an expired allowlisted domain becoming the exfiltration endpoint. See the Prompt Injection Guide.
• Content-aware controls: DLP and CASB policies (ATT&CK M1057) catch labelled and pattern-matched data, not encrypted archives or data the classifier has never seen. One layer, not the plan.

Choosing where to invest

Rolling out exfiltration controls

1. Inventory crown-jewel data and who can read it in bulk: the stores whose theft would be reportable, and the users, apps and service principals with read or export rights.
2. Turn on the missing logs first: S3 data events for sensitive buckets, Graph activity logs, SaaS event monitoring and resolver query logs, with at least a year of retention.
3. Baseline for 30 days: normal volumes per identity and host, and normal destinations per server group.
4. Deploy detections in alert-only mode: tune for two to four weeks, document expected business exceptions (backups, analytics exports, migrations) and assign an owner for each alert.
5. Tighten egress in rings: start with the server subnets with fewest dependencies, build the allowlist from firewall logs, and keep the previous rule set ready to restore.
6. Tighten sharing and token scope: expire anonymous links, change default link types, reduce integration scopes and add IP restrictions, telling data owners first.
7. Test: SP 800-53 SC-7(10) asks organisations to "Conduct exfiltration tests". Push synthetic data through each channel in the technique table and confirm the expected alert or block.

Responding to suspected exfiltration

1. Contain the identity before the host: revoke the OAuth grant, refresh tokens, sessions and API keys of the identity doing the transfer, disable the connected app or service principal, and rotate keys it could read. Salesloft and Salesforce revoked all Drift access and refresh tokens on 20 August 2025. See the Leaked Credential Response Playbook.
2. Block the destination: add the destination domain, IP range, cloud account or tenant to proxy and firewall blocks, and remove external shares and links created during the window.
3. Preserve evidence: export audit logs before retention expires and snapshot affected hosts. GTIG noted the Drift actor deleted query jobs but "logs were not impacted".
4. Scope what left: use per-identity volume, object names and response sizes to list data sets accessed; treat everything the identity could read as exposed until logs prove otherwise.
5. Hunt for secrets in the stolen data: scan the exported records for keys and passwords, as the Drift actor did, and rotate any you find.
6. Notify and recover: involve legal and privacy early because personal data theft triggers notification duties. See the Incident Response Guide and the Digital Forensics (DFIR) Guide.

Measuring whether it works

• Log coverage: percentage of crown-jewel data stores with data-plane access logging enabled and retained for at least 12 months.
• Egress posture: percentage of server subnets with default-deny outbound and DNS restricted to internal resolvers.
• Standing bulk access: identities, human and non-human, with export or read-all rights to crown-jewel data, trending down.
• Open external sharing: anonymous links and external shares on sensitive sites, and how many are older than 90 days.
• Test pass rate: percentage of exfiltration test cases that produced an alert or block within the agreed time.
• Time to contain: median time from first volume alert to token revocation or host isolation.

Framework mapping

Common failure patterns

• Watching the network while the data leaves by API: integrations and stolen tokens call SaaS APIs from attacker infrastructure, so nothing crosses your egress path. The Salesloft Drift breach is the clearest example.
• Logs that do not exist on the day: S3 data events off, SaaS event monitoring unlicensed, or retention shorter than dwell time. Scoping then defaults to "everything".
• Unrestricted server egress: database and file servers reach any destination, so a sync client needs no exception to upload terabytes.
• Single-event thresholds: alerting on one large transfer misses data split under the limit or spread over nights and weekends.
• Anyone links as the default: permanent anonymous links on sensitive sites, nobody reviewing them, and no record of who used them.
• Treating the stolen data as the end of the incident: exported records containing keys and passwords are not rotated, so the next breach starts from the first one.

Practitioner checklist

• Map your detections to every TA0010 technique and the staging techniques T1074 and T1560, and record the gaps.
• Enable data-plane logging for crown-jewel stores and keep identity and SaaS audit logs for at least a year.
• Baseline download, export and API volume per user, app and service principal, over 7 and 30 day windows.
• Default-deny outbound traffic from servers and force DNS through internal resolvers with query logging.
• Block personal cloud storage, paste and anonymous transfer services, and allow only sanctioned storage tenants.
• Restrict external sharing defaults, expire anonymous links and alert on cross-account snapshot or bucket shares.
• Remove standing bulk read and export rights from integrations and service accounts; prefer short-lived, IP-restricted tokens.
• Log AI agent tool calls and allowlist agent outbound destinations.
• Run exfiltration tests with synthetic data at least annually and after major network changes.
• Include token revocation and secret scanning of stolen data in the exfiltration response runbook.

Standards and references

• MITRE ATT&CK: Exfiltration (TA0010)
• MITRE ATT&CK: Collection (TA0009)
• MITRE ATT&CK: Transfer Data to Cloud Account (T1537)
• NIST SP 800-53 Rev. 5 (csf.tools rendering): SC-7(10) Prevent Exfiltration
• Microsoft Learn: Microsoft Graph activity logs
• AWS: GuardDuty S3 Protection finding types
• Microsoft Learn: Manage sharing settings for SharePoint and OneDrive
• Google Threat Intelligence: Data theft from Salesforce instances via Salesloft Drift (UNC6395)

Related NHI Mgmt Group resources: SaaS and OAuth App Governance Guide · Lateral Movement Guide · Detection Engineering Guide · API Key Management Guide · Incident Response Guide