Prerequisites
- Target system, dependencies and environment configured.
Usage
Purpose
The objective of many intrusions is data theft, and the final phase is exfiltration — getting data out of the environment. Simulating exfiltration tests the organisation's data-loss controls and detection: can they see and stop data leaving? This skill covers the exfiltration phase of an authorised engagement, done safely with dummy data (never real sensitive data), and — the defensive core — how exfiltration is detected and prevented. It tests the last line of defence against data breaches.
When to use it
The objective/final phase of an authorised engagement (RoE) where testing data-loss prevention is in scope. The critical safety rule: simulate with dummy/canary data, never actual sensitive data — the point is testing the controls, not exfiltrating real information.
Procedure (authorised, dummy data)
- Use dummy/canary data — the safety rule. Never exfiltrate real sensitive data (that would be causing the very breach you're testing against). Use marked dummy data or canary tokens that simulate sensitive data and can be tracked. This tests the controls without the risk.
- Operate within the RoE, with the data-handling terms explicit (what data is used, how it's handled and destroyed — the scoping skill covers this).
- Understand the exfiltration channels (conceptual) — how adversaries get data out:
- Over C2 — through the existing command-and-control channel.
- Over alternative protocols — DNS tunnelling, HTTPS to cloud storage, email.
- To external services — cloud storage, file-sharing sites, paste sites.
- Physical/other — removable media (where in scope).
- Emulate the actor's exfiltration approach (the emulation-planning skill) and attempt to move the dummy data out via the relevant channels.
- Focus on testing detection and prevention — the defensive point. The questions: does Data Loss Prevention (DLP) detect/block the data leaving? does network monitoring catch the exfiltration channel (DNS tunnelling, large outbound transfers, unusual destinations — the threat-hunting DNS/proxy skill)? does the SOC alert? Data leaving undetected is the finding.
- Understand how exfiltration is detected and prevented (the valuable defensive knowledge):
- DLP — content inspection detecting sensitive data patterns leaving.
- Network detection — DNS tunnelling signatures, large/unusual outbound transfers, connections to file-sharing/cloud-storage destinations (the DNS/proxy hunting and network skills).
- Egress controls — restricting outbound connections (segmentation, egress filtering) so exfiltration channels are limited.
- Test multiple channels to gauge coverage depth — DLP might catch email but miss DNS tunnelling; testing several reveals whether detection is comprehensive or channel-specific.
- Report the exfiltration outcome — "which channels succeeded in moving (dummy) data out undetected, and which were caught" is a critical finding that drives DLP, egress control, and network-detection improvements — the last line of defence against data breaches.
Cheatsheet
many intrusions aim at DATA THEFT ; exfiltration = final phase (data OUT)
simulate -> test data-loss controls + detection (last line of defence vs breaches)
SAFETY RULE: DUMMY / canary data ONLY, never real sensitive data (that = causing the breach)
RoE with explicit data-handling + destruction terms
channels (conceptual)
over C2 | alternative protocols (DNS tunnelling, HTTPS to cloud, email)
| external services (cloud storage, file-sharing, paste sites) | removable media (if in scope)
emulate actor's approach -> attempt to move dummy data out
DEFENSIVE POINT: test DETECTION + PREVENTION
DLP (content inspection catches sensitive patterns leaving)
network detection: DNS tunnelling signatures | large/unusual outbound | file-sharing/cloud destinations
[dns-and-proxy-hunting, network]
egress controls (restrict outbound -> limit channels)
TEST MULTIPLE channels (DLP catches email but misses DNS tunnelling?) -> coverage depth
report: which channels succeeded undetected + which caught -> improve DLP/egress/detection
Reading the phase
- Dummy data exfiltrated undetected = a data-loss control gap; the last line of defence didn't catch data leaving. A critical finding, since data theft is the objective of many intrusions. Drives DLP, egress, and network-detection improvements.
- Exfiltration detected/blocked by DLP or network monitoring = the defensive win; the controls caught data leaving, which is exactly what the phase tests. Note which control caught it and which channel.
- DLP catching one channel (email) but missing another (DNS tunnelling) = channel-specific, shallow coverage; testing multiple channels reveals whether detection is comprehensive. A common gap — DNS tunnelling especially evades content-based DLP.
- Large or unusual outbound transfers not flagged = a network-detection gap; volume and destination anomalies are catchable signals (the network and hunting skills).
- Unrestricted egress allowing exfiltration to any destination = an egress-control gap; restricting outbound connections limits the channels available. Segmentation/egress filtering is the architectural fix.
- Which channels succeeded undetected and which were caught = the critical finding; the phase's value is testing and improving the organisation's ability to detect and prevent data loss.
Pitfalls
- Using real sensitive data. The cardinal safety error — exfiltrating real data is the breach you're testing against. Use dummy/canary data only, with explicit handling/destruction terms.
- Testing one channel. DLP and detection are often channel-specific (catch email, miss DNS tunnelling); test multiple channels to reveal coverage depth. A single-channel test overstates the defence.
- Focusing on succeeding over the defensive outcome. The value is which channels are detected/blocked; that's the finding, not whether data got out.
- Ignoring the egress-control angle. Detection is one axis; restricting outbound connections (egress filtering, segmentation) limits the channels available and is part of the fix.
- Providing operational exfiltration tooling. Conceptual by design; the value is understanding channels and their detection/prevention.
References
- MITRE ATT&CK — TA0010 (Exfiltration): T1041, T1048 (alternative protocol), T1567 (web service)
- The threat-hunting dns-and-proxy-hunting and network-security domains (detection), and DLP guidance
- Canary tokens (canarytokens.org) for safe exfiltration simulation
- The scoping-and-rules-of-engagement and attack-emulation-planning skills
Inputs
- Relevant source code, logs, network traces, or system specifications.
Outputs
- Analysis findings, security audit report, or generated code artifacts.
1---2name: exfiltration-simulation3description: Use when testing data-loss controls in an authorised engagement — simulating exfiltration with dummy data to see whether the organisation detects and prevents data leaving.4---5678## Prerequisites9- Target system, dependencies and environment configured.1011## Usage12### Purpose1314The objective of many intrusions is data theft, and the final phase is exfiltration — getting data out of the environment. Simulating exfiltration tests the organisation's data-loss controls and detection: can they see and stop data leaving? This skill covers the exfiltration phase of an authorised engagement, done safely with dummy data (never real sensitive data), and — the defensive core — how exfiltration is detected and prevented. It tests the last line of defence against data breaches.1516### When to use it1718The objective/final phase of an authorised engagement (RoE) where testing data-loss prevention is in scope. The critical safety rule: simulate with **dummy/canary data**, never actual sensitive data — the point is testing the controls, not exfiltrating real information.1920### Procedure (authorised, dummy data)21221. **Use dummy/canary data — the safety rule.** Never exfiltrate real sensitive data (that would be causing the very breach you're testing against). Use marked dummy data or canary tokens that simulate sensitive data and can be tracked. This tests the controls without the risk.232. **Operate within the RoE**, with the data-handling terms explicit (what data is used, how it's handled and destroyed — the scoping skill covers this).243. **Understand the exfiltration channels** (conceptual) — how adversaries get data out:25 - **Over C2** — through the existing command-and-control channel.26 - **Over alternative protocols** — DNS tunnelling, HTTPS to cloud storage, email.27 - **To external services** — cloud storage, file-sharing sites, paste sites.28 - **Physical/other** — removable media (where in scope).294. **Emulate the actor's exfiltration approach** (the emulation-planning skill) and attempt to move the dummy data out via the relevant channels.305. **Focus on testing detection and prevention — the defensive point.** The questions: does Data Loss Prevention (DLP) detect/block the data leaving? does network monitoring catch the exfiltration channel (DNS tunnelling, large outbound transfers, unusual destinations — the threat-hunting DNS/proxy skill)? does the SOC alert? Data leaving undetected is the finding.316. **Understand how exfiltration is detected and prevented** (the valuable defensive knowledge):32 - **DLP** — content inspection detecting sensitive data patterns leaving.33 - **Network detection** — DNS tunnelling signatures, large/unusual outbound transfers, connections to file-sharing/cloud-storage destinations (the DNS/proxy hunting and network skills).34 - **Egress controls** — restricting outbound connections (segmentation, egress filtering) so exfiltration channels are limited.357. **Test multiple channels to gauge coverage depth** — DLP might catch email but miss DNS tunnelling; testing several reveals whether detection is comprehensive or channel-specific.368. **Report the exfiltration outcome** — "which channels succeeded in moving (dummy) data out undetected, and which were caught" is a critical finding that drives DLP, egress control, and network-detection improvements — the last line of defence against data breaches.3738### Cheatsheet3940```41many intrusions aim at DATA THEFT ; exfiltration = final phase (data OUT)42 simulate -> test data-loss controls + detection (last line of defence vs breaches)4344SAFETY RULE: DUMMY / canary data ONLY, never real sensitive data (that = causing the breach)45 RoE with explicit data-handling + destruction terms4647channels (conceptual)48 over C2 | alternative protocols (DNS tunnelling, HTTPS to cloud, email)49 | external services (cloud storage, file-sharing, paste sites) | removable media (if in scope)5051emulate actor's approach -> attempt to move dummy data out5253DEFENSIVE POINT: test DETECTION + PREVENTION54 DLP (content inspection catches sensitive patterns leaving)55 network detection: DNS tunnelling signatures | large/unusual outbound | file-sharing/cloud destinations56 [dns-and-proxy-hunting, network]57 egress controls (restrict outbound -> limit channels)58TEST MULTIPLE channels (DLP catches email but misses DNS tunnelling?) -> coverage depth59report: which channels succeeded undetected + which caught -> improve DLP/egress/detection60```6162### Reading the phase6364- **Dummy data exfiltrated undetected** = a data-loss control gap; the last line of defence didn't catch data leaving. A critical finding, since data theft is the objective of many intrusions. Drives DLP, egress, and network-detection improvements.65- **Exfiltration detected/blocked by DLP or network monitoring** = the defensive win; the controls caught data leaving, which is exactly what the phase tests. Note which control caught it and which channel.66- **DLP catching one channel (email) but missing another (DNS tunnelling)** = channel-specific, shallow coverage; testing multiple channels reveals whether detection is comprehensive. A common gap — DNS tunnelling especially evades content-based DLP.67- **Large or unusual outbound transfers not flagged** = a network-detection gap; volume and destination anomalies are catchable signals (the network and hunting skills).68- **Unrestricted egress allowing exfiltration to any destination** = an egress-control gap; restricting outbound connections limits the channels available. Segmentation/egress filtering is the architectural fix.69- **Which channels succeeded undetected and which were caught** = the critical finding; the phase's value is testing and improving the organisation's ability to detect and prevent data loss.7071### Pitfalls7273- **Using real sensitive data.** The cardinal safety error — exfiltrating real data *is* the breach you're testing against. Use dummy/canary data only, with explicit handling/destruction terms.74- **Testing one channel.** DLP and detection are often channel-specific (catch email, miss DNS tunnelling); test multiple channels to reveal coverage depth. A single-channel test overstates the defence.75- **Focusing on succeeding over the defensive outcome.** The value is which channels are detected/blocked; that's the finding, not whether data got out.76- **Ignoring the egress-control angle.** Detection is one axis; restricting outbound connections (egress filtering, segmentation) limits the channels available and is part of the fix.77- **Providing operational exfiltration tooling.** Conceptual by design; the value is understanding channels and their detection/prevention.7879### References8081- MITRE ATT&CK — TA0010 (Exfiltration): T1041, T1048 (alternative protocol), T1567 (web service)82- The threat-hunting dns-and-proxy-hunting and network-security domains (detection), and DLP guidance83- Canary tokens (canarytokens.org) for safe exfiltration simulation84- The scoping-and-rules-of-engagement and attack-emulation-planning skills8586## Inputs87- Relevant source code, logs, network traces, or system specifications.8889## Outputs90- Analysis findings, security audit report, or generated code artifacts.