Data Flow & Attribution Protection
The complete path from attacker to target to client—and why every hop matters
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 or Whonix—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 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, 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.
See also: C2 Setup for configuration details.
Target Network
The implant (beacon) 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.
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.
See also: Exfiltration for techniques and channels.
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.
Cloud Storage] T2[Tor Exit] A2[Retrieval Machine] end subgraph Client["Client (Air-gapped)"] CL[Hiring Party] end A --> V1 C2 <--> B B --> D D -.->|Encrypted Upload| DD DD -.->|Different Path| T2 T2 -.-> A2 A2 -.->|Physical/Signal| CL style A fill:#1a1a25,stroke:#ff3366 style C2 fill:#1a1a25,stroke:#9d4edd style B fill:#1a1a25,stroke:#00d4ff style DD fill:#1a1a25,stroke:#00ff88 style CL fill:#1a1a25,stroke:#00ff88
Real-World Pattern: APT Infrastructure
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—see Detection Strategies.
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.
See also: Attribution & Consequences for detailed analysis of how attackers get identified.
Detection Opportunities
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: