# Data Flow & Attribution Protection The complete path from attacker to target to client—and why every hop matters ## The Central Question Every attacker faces the same problem: **how do you get commands to the target** **and data back without revealing who you are?** The answer is layers—layers of infrastructure, indirection, and plausible deniability. This chapter maps the complete data flow from operator to objective. ## The Complete Attack Flow This is the full path that commands and data travel during a sophisticated operation. Each layer exists for a reason. Remove one, and you've created a potential point of attribution. ``` ┌────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ COMPLETE ATTACK DATA FLOW │ ├────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────┐ │ │ │ │ CLIENT │ Contracts attacker, never touches infrastructure │ │ │ │ (Hiring │ Communication via: Signal, dead drops, cryptocurrency │ │ │ │ Party) │◄─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │ │ └─────────────┘ │ │ │ │ │ │ │ │ (Air-gapped handoff) │ │ │ ▼ │ │ │ ┌─────────────┐ │ │ │ │ ATTACKER │ Physical location: Unknown │ │ │ │ WORKSTATION │ OS: Tails/Whonix (amnesiac) │ │ │ │ │ Connection: Public WiFi + MAC spoofing │ │ │ └──────┬──────┘ │ │ │ │ │ │ │ │ Encrypted tunnel (WireGuard/OpenVPN) │ │ │ ▼ │ │ │ ┌─────────────┐ │ │ │ │ VPN 1 │ Provider: No-logs jurisdiction (Panama, Switzerland) │ │ │ │ (Entry) │ Payment: Cryptocurrency (Monero) │ │ │ └──────┬──────┘ │ │ │ │ │ │ │ │ Nested tunnel │ │ │ ▼ │ │ │ ┌─────────────┐ │ │ │ │ VPN 2 │ Different provider, different jurisdiction │ │ │ │ (Exit) │ Purpose: If VPN1 is compromised, trail goes cold │ │ │ └──────┬──────┘ │ │ │ │ │ │ │ │ SSH tunnel │ │ │ ▼ │ │ │ ┌─────────────┐ │ │ │ │ JUMP BOX 1 │ Compromised/rented VPS │ │ │ │ (Proxy) │ Location: Country with weak cyber cooperation │ │ │ └──────┬──────┘ No logs, burns after operation │ │ │ │ │ │ │ │ Reverse SSH tunnel │ │ │ ▼ │ │ │ ┌─────────────┐ │ │ │ │ REDIRECTOR │ Cloud function (Lambda/Workers) OR │ │ │ │ (Front) │ CDN with domain fronting OR │ │ │ └──────┬──────┘ Legitimate-looking domain with HTTPS │ │ │ │ │ │ │ │ HTTPS (looks like normal web traffic) │ │ │ ▼ │ │ │ ┌─────────────┐ │ │ │ │ C2 SERVER │ The actual command & control │ │ │ │ (Hidden) │ Never directly touched by operator │ │ │ └──────┬──────┘ Receives commands via redirector only │ │ │ │ │ │ │ │ C2 protocol (Cobalt Strike, Sliver, Havoc) │ │ │ │ Encrypted, looks like HTTPS/DNS │ │ │ ▼ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ │ TARGET NETWORK │ │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ │ │ │ Implant │───►│ Internal │───►│ Data │ │ │ │ │ │ │(Beacon) │ │ Pivot │ │ Target │ │ │ │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ │ │ └──────────────────────────┬──────────────────────────────────┘ │ │ │ │ │ │ │ │ Exfiltration (encrypted, chunked) │ │ │ ▼ │ │ │ ┌─────────────┐ │ │ │ │ DEAD DROP │ Cloud storage (S3, Azure Blob, Google Drive) │ │ │ │ (Staging) │ Encrypted, anonymous account │ │ │ └──────┬──────┘ Data sits until retrieved via separate path │ │ │ │ │ │ │ │ Retrieved through different infrastructure │ │ │ │ (never same path as C2) │ │ │ │ │ │ │ ▼ │ │ │ ┌─────────────┐ │ │ │ │ ATTACKER │ Downloads via Tor/different VPN chain │ │ │ │ RETRIEVAL │ Decrypts locally │ │ │ └──────┬──────┘ Prepares for handoff │ │ │ │ │ │ │ └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─►│ │ │ │ │ ─────────── = Live connection (commands flow) │ │ │ ─ ─ ─ ─ ─ = Air-gapped / async (data handoff) │ │ │ │ └────────────────────────────────────────────────────────────────────────────────────────────────┘ ## Understanding Each Layer ### The Attacker's Workstation The operator never uses their real computer or network. A dedicated attack machine runs [Tails](https://tails.net/) or [Whonix](https://www.whonix.org/)—operating systems designed to leave no traces. Connection happens from public WiFi with a spoofed MAC address. The device itself might be purchased with cash, wiped between operations, and physically destroyed after major engagements. **What this protects against:** Physical device seizure, local network traffic analysis, ISP records. ### VPN Chain Multiple VPN providers in different jurisdictions, paid anonymously. The outer VPN sees your real-ish location (the coffee shop). The inner VPN only sees the outer VPN's exit. Neither sees the full picture. If one is compromised or served with a warrant, investigators hit a wall at the next hop. **What this protects against:** Single-point VPN compromise, traffic correlation at the ISP level, legal requests in any single jurisdiction. ### Jump Box / Proxy A compromised or rented server in a country with weak international cooperation. Russia, certain Eastern European countries, or jurisdictions that don't respond to US/EU legal requests. This box is ephemeral—used for one operation, then burned. Even if seized, there's nothing to find. **What this protects against:** International legal cooperation, infrastructure takedowns, forensic analysis of persistent infrastructure. ### Redirector This is what the target actually sees in their logs. It might be a Cloudflare Worker, an AWS Lambda function, or a legitimate-looking website. Traffic appears to be normal HTTPS to a CDN or cloud provider. [Domain fronting](/content/shadow/pages/12-advanced.html) techniques can make C2 traffic look like it's going to google.com while actually reaching your server. **What this protects against:** Network traffic analysis, IP blocking, reputation-based detection. ### C2 Server The actual command and control infrastructure running [Sliver](https://github.com/BishopFox/sliver), [Havoc](https://github.com/HavocFramework/Havoc), or similar frameworks. The operator never connects directly to this server—all interaction goes through the redirector. If the C2 is identified, investigators find a server that only talks to another server. ### Target Network The implant ([beacon](/content/shadow/pages/07-beaconing.html)) on the compromised system reaches out to the redirector on a schedule—maybe every 5 minutes, with jitter to avoid pattern detection. Commands flow down, results flow up. Internal pivoting happens as described in [Lateral Movement](/content/shadow/pages/10-lateral-movement.html). ### Dead Drop & Exfiltration Stolen data doesn't travel the same path as commands. It's encrypted, chunked, and uploaded to cloud storage—an anonymous Mega account, a compromised SharePoint, or steganographically hidden in images uploaded to social media. The attacker retrieves this data through a _completely different infrastructure path_. ### Client Handoff The ultimate destination: whoever contracted the operation. Nation-state actors deliver to intelligence agencies through classified channels. Criminal groups use encrypted messaging and cryptocurrency. The handoff is air-gapped—no digital trail connects the attack infrastructure to the recipient. ## Visual Flow: Command Path vs Exfil Path Critical concept: **the command path and the exfiltration path should never be the same**. If one is compromised, the other remains operational. If investigators follow the C2 traffic, they miss the data. If they find the data drop, they can't trace back to the C2. ## Real-World Pattern: APT Infrastructure Case Study: Typical APT Setup Analysis of documented APT campaigns (APT29, APT28, Lazarus Group) reveals consistent patterns: - 3-5 layers of proxy infrastructure - Compromised legitimate websites as redirectors - C2 servers in non-cooperative jurisdictions - Exfiltration to cloud storage, not back to C2 - Separate infrastructure for each target - Infrastructure burned after each operation ### What Defenders See When a target organization investigates a breach, here's what their logs typically show: ``` # Firewall logs show: Outbound HTTPS to cdn.cloudflare.com (legitimate CDN) Outbound HTTPS to *.amazonaws.com (normal cloud traffic) Outbound HTTPS to storage.googleapis.com (common SaaS) # DNS logs show: Queries for legitimate-looking domains Maybe some DNS-over-HTTPS to known resolvers # Endpoint logs show: PowerShell executing encoded commands certutil downloading from internal shares Scheduled tasks with generic names ``` Nothing screams "attack." Every component looks like normal enterprise traffic. This is why behavioral analysis and anomaly detection matter more than signature-based detection. ## When Attribution Happens Anyway Despite all these layers, attackers get caught. Here's why: ### Infrastructure Reuse Using the same C2 server, domain, or certificate across multiple operations. Threat intelligence correlates attacks and builds profiles. ### Timezone Slips Activity patterns reveal operator timezones. If all commands happen during Moscow business hours, that's a clue. ### Language Artifacts Code comments, error messages, and file metadata in a specific language. Cyrillic in compiled binaries. Chinese in PDF metadata. ### Tooling Fingerprints Custom tools have signatures. The same unique obfuscation pattern across campaigns links them to the same actor. ## Detection Opportunities For Defenders Each layer in the attack flow creates potential detection points: | Layer | Detection Opportunity | Technique | | --- | --- | --- | | Redirector | CDN/cloud traffic anomalies | JA3 fingerprinting, certificate analysis | | C2 Channel | Beaconing patterns | Time-series analysis, frequency detection | | Implant | Process behavior | EDR, parent-child process monitoring | | Exfiltration | Data volume anomalies | DLP, network baseline deviation | | Dead Drop | Unusual cloud uploads | CASB, cloud access monitoring | ## MITRE ATT&CK Mapping This chapter covers techniques across multiple tactics: - [**T1090**](https://attack.mitre.org/techniques/T1090/) \- Proxy (multi-hop proxying) - [**T1090.003**](https://attack.mitre.org/techniques/T1090/003/) \- Multi-hop Proxy - [**T1572**](https://attack.mitre.org/techniques/T1572/) \- Protocol Tunneling - [**T1071**](https://attack.mitre.org/techniques/T1071/) \- Application Layer Protocol (C2 over HTTPS) - [**T1102**](https://attack.mitre.org/techniques/T1102/) \- Web Service (dead drops) - [**T1537**](https://attack.mitre.org/techniques/T1537/) \- Transfer Data to Cloud Account - [**T1001**](https://attack.mitre.org/techniques/T1001/) \- Data Obfuscation