MITRE ATT&CK Exfiltration (TA0010): a guide for defenders

A common belief comes up again and again in committee: if the MITRE ATT&CK matrix is green for the Exfiltration tactic (TA0010), leaks are covered. In practice, things look different. A green box says that a rule exists somewhere. It does not say whether that rule blocks the file leaving this Tuesday, from this workstation, through this channel.

In MITRE ATT&CK, the Exfiltration tactic (ID TA0010) groups the techniques an attacker uses to get data out of your network. MITRE sums it up plainly: the adversary is trying to steal data.

No attack recipe here. We use TA0010 as a grid, to see where your controls have gaps and what to test first. For the general method, see our page on data exfiltration testing.

What TA0010 contains

At the time of writing, in October 2026, the official tactic page on attack.mitre.org lists nine techniques, several of which have sub-techniques. The framework changes with every release, usually twice a year: check the list before you freeze a coverage matrix. Here is today’s list, read from the defence side.

Scroll the table →

Read TA0010 as families, not rows

1. Network channels

T1041 and T1048 fall under outbound filtering, the proxy and network monitoring. What interests us is what the firewall lets out; you already know its configuration. Two blind spots come up again and again: DNS and encrypted traffic. Each has its own article: DNS exfiltration and the limits of TLS inspection.

2. Cloud and SaaS services

T1567 and T1537 are the hardest to handle, because the destinations are legitimate. Block consumer storage? Frankly difficult when the same vendor, Microsoft or Google for example, hosts both your internal tools and your employees’ personal accounts. Here, the domain name does not help you. The DLP has to look at what is leaving, and to which account.

3. Endpoint and physical

T1052 and T1011 concern the workstation. These are often the first rules deployed, and the least retested. Is your USB policy three years old? Has it survived the agent updates and the exceptions granted since? The simplest check is still to plug a USB stick into one workstation of each profile.

4. Behaviour modifiers

T1020, T1030 and T1029 describe ways of using a channel: automate, split, schedule. Put simply, if a rule stops a large file but lets the same file through once split into small chunks, a patient attacker gets around it effortlessly. Many silent false negatives come from there.

From matrix to controls: a five-step method

1. Inventory your egress controls. Endpoint DLP, network DLP, proxy, CASB, email DLP, native cloud rules. For each one, note what it covers in your environment: workstations, inspected flows.
2. Map each control to TA0010 IDs. In your environment, the same technique may be covered by two controls, or by none. The empty boxes become your first work list.
3. Separate “covered on paper” from “proven coverage”. A box ticked because a rule exists remains a hypothesis until a scenario has been replayed against it.
4. Replay the scenarios with synthetic data. Our campaigns chain discovery, collection, staging, automation and exfiltration, like a real operator, but with decoys: fake numbers, fake labelled documents. The early stages belong to the Discovery (TA0007) and Collection (TA0009) tactics. See the article on synthetic data in production.
5. Measure over time. Coverage observed in January can fail in March after a migration or an agent update. So rerun the campaigns after each such change; on the Enforcis side, upcoming versions will let you schedule periodic replays, or replays triggered by a change, depending on how critical the scope is and how fresh the evidence needs to be.

A concrete scenario, from the defender’s side

Example: a fintech has deployed endpoint DLP and a filtering proxy. Its matrix shows T1052, T1048 and T1567 as covered. The CISO still asks for a test: the team checks USB on each workstation profile, and an exfiltration test replays the network and web service channels.

Plausible outcome: USB blocking works on managed Windows workstations, but not on those of a subsidiary still running a different agent profile. The proxy blocks large uploads to consumer storage, except that a split synthetic file gets through (T1567 combined with T1030). On the SOC side, an alert arrives for one case in three, with no escalation.

None of these gaps was visible in the console, and that is the trap. The fix is often simple: align a profile, lower a cumulative threshold, add a correlation rule. You still need to know where to start. On the Enforcis side, upcoming versions will bring multi-level reporting (leadership, CISO, operations), with MITRE ATT&CK mappings and, where the correspondence is established, MITRE D3FEND, as well as SIEM integrations.

Quick checklist for your TA0010 matrix

• Every technique in the current official list has at least one of your controls mapped to it.
• Every mapping has been tested by replay, with the date of its last test.
• Sub-techniques are handled separately when the control differs: T1567.002 (cloud storage) and T1567.001 (code repository) are not filtered the same way.
• The modifiers (T1020, T1030, T1029) are tested in combination with a channel.
• You check detection as well as blocking: alert generated, received, handled.
• The results lead to a prioritised action list, not just a coverage score.

The limits of ATT&CK for data leak prevention

FAQ