Most outbound network controls are built around an assumption that doesn’t quite hold up: that if you block or proxy the obvious data channels, you’ve blocked the channels attackers will use. In practice, attackers route their exfiltration through protocols that defenders trust by default. DNS resolves names. ICMP confirms reachability. TLS encrypts everything else. Each of these protocols has space inside it that was never intended to carry application data, and each of them gets used to do exactly that.
This category of work first caught my attention earlier in my career as a defender in a Security Operations Center. Pulling apart how attackers move data out of environments they have already compromised is its own craft. The cleverness was rarely in the malware itself. It was in the choice of channel: which protocols a network trusts enough to stop inspecting, and which architectural assumptions defenders had inherited without examining. That curiosity is what shapes most of what follows.
This post is a practitioner-level walkthrough of how data exfiltration through protocol abuse actually works, across the techniques that show up in real incident response work.
Why protocol abuse is effective#
Three structural facts make this category of attack reliable.
The first is that core infrastructure protocols are rarely treated as data channels by security tooling. DNS, ICMP, and the metadata layers inside TLS exist to make the network function. Egress filtering, proxy inspection, and content scanning are typically built around HTTP/HTTPS and SMTP. Everything below or beside those layers gets a pass.
The second is that the optional fields, parameters, and side channels inside common protocols are rich. Most protocols were designed with extensibility in mind. Subdomain labels, query types, header options, sequence numbers, and timing patterns can all carry arbitrary bits if the sender and receiver agree on the encoding.
The third is that the legitimate use of these protocols is so high-volume that any reasonable baseline is loose enough to hide inside. A workstation that does ten thousand DNS lookups per day is not unusual. A few hundred extra lookups carrying encoded data are invisible without targeted detection.
DNS as a covert channel#
DNS is the most common protocol abused for exfiltration because it’s almost always permitted outbound, even from segmented environments where every other protocol is blocked.
The mechanics are straightforward. The attacker controls an authoritative nameserver for a domain they own. The victim host generates DNS queries against subdomains of that domain, encoding data into the labels. When the query hits the attacker’s nameserver, the encoded data arrives as part of the lookup. Responses travel back in record values (A, TXT, NULL, AAAA), enabling bidirectional communication.
A query like e30e7a90bbd1f2.attacker.example.com is structurally valid and resolves through the normal recursive resolver chain, regardless of what content the subdomain label contains. The attacker’s nameserver receives the encoded label and decodes it.
Real-world tooling and tradecraft:
- dnscat2 is the canonical open-source DNS C2 framework. It runs an encrypted session over DNS lookups.
- Iodine tunnels full IPv4 traffic over DNS. It’s older, less stealthy, but still effective in environments where DNS is the only egress.
- Cobalt Strike’s DNS beacon has been a fixture of red team and adversary tooling for years.
- Custom implementations are trivial to build and routinely show up in targeted incidents.
Throughput is modest. A DNS lookup carries at most a few hundred bytes after encoding overhead. That’s enough to exfiltrate credentials, session tokens, configuration files, internal hostnames, and structured intelligence over days or weeks of low-and-slow operation.
Detection signals worth baselining:
- Query rate per host (sudden spikes or sustained increases)
- Subdomain length distribution (long high-entropy labels are unusual)
- Query type ratios (heavy TXT or NULL usage by non-server hosts)
- NXDOMAIN ratio (encoded data often generates failures by design)
- Repeated lookups to the same second-level domain at unusual frequency
ICMP tunneling#
ICMP is allowed outbound in many environments because operators rely on it for troubleshooting. The payload field of ICMP echo request and reply packets has no inherent meaning. The protocol just specifies that the responder returns what the requester sent. That makes the payload a serviceable transport for arbitrary data.
The classic toolset includes Loki, icmpsh, and Ptunnel. None of them are new. All of them still work in environments where outbound ICMP isn’t filtered. Cloud workloads and container environments are particularly likely to permit it.
ICMP exfiltration shows up less often in mature enterprises because explicit outbound ICMP blocking is common in modern egress policy. But “less often” is not “never,” and ICMP tunneling remains a reliable fallback when DNS is monitored more carefully.
Detection considerations:
- ICMP traffic from hosts that have no operational reason to ping out
- Echo request payload sizes that diverge from the operating system default
- High-entropy payloads (legitimate ICMP payloads are typically predictable byte patterns)
- Sustained ICMP rates that exceed troubleshooting plausibility
HTTPS and TLS abuse#
HTTPS is too useful to block. That makes it the largest single egress surface in most environments, and there are several covert paths inside it.
SNI smuggling. The Server Name Indication field in the TLS handshake is sent in cleartext to let the server present the right certificate. Attackers can encode data into the SNI value. The TLS handshake completes against a server they control (which accepts whatever SNI is presented), and the encoded data arrives without ever being part of an encrypted application payload. SNI inspection that does not validate format or entropy will miss this.
Encoded URIs over benign-looking domains. When the attacker controls a legitimate-looking domain or has compromised one, they can encode data into URI paths or query parameters and exfiltrate it through normal-looking HTTPS GETs. The TLS layer protects the content from network inspection. The volume blends with normal user browsing.
Domain fronting. Although large CDN providers have moved to block this, certain CDN configurations still allow a TLS handshake against one fronted domain while the underlying HTTP Host header points elsewhere. The TLS metadata defenders see refers to a trusted fronted domain. The actual destination is somewhere else entirely.
JA3 fingerprint shaping. Defenders increasingly use TLS client fingerprints (JA3, JA4) to detect anomalous clients. Attackers respond by shaping their TLS handshakes to mimic widely deployed clients (Chrome, Firefox, Slack, Teams) so they pass standard fingerprint checks.
Timing and volume channels. Even when the content of an encrypted session is opaque, the size of TLS records and the timing between them carries bits. An attacker can encode data into the rhythm of TLS frames against a trusted destination they control, and detection requires statistical traffic analysis that few environments perform.
Detection here usually comes from metadata analysis: certificate transparency monitoring on suspect domains, JA3 fingerprint baselining, SNI entropy checks, and behavioral profiling of client-server pairs rather than payload inspection.
TCP header field and IP-layer abuse#
The lower-bandwidth, harder-to-detect end of the spectrum is encoding data into fields of the TCP and IP headers themselves. The throughput is small. The detection difficulty is high.
The fields and behaviors typically abused:
- IP Identification field. Sixteen bits per packet, normally used for fragment reassembly. An attacker can replace the value with encoded data.
- TCP Initial Sequence Number. Thirty-two bits of effectively-attacker-controlled data per session establishment.
- TCP Acknowledgment Number. During an active session, the ACK field can be coerced to carry data through deliberate sequence manipulation.
- TCP Urgent Pointer. A field that’s rarely used legitimately, making it both a good covert channel and a strong detection signal if you happen to look at it.
- TCP Options. The options field can carry padding or non-standard options that encode data.
- TCP Timestamp. RFC 1323 timestamps can be subtly manipulated.
- TTL field. Manipulating the TTL value on outbound packets carries a small number of bits per packet.
- Interpacket timing. The delay between consecutive packets can encode a bit stream. Slow, but extremely difficult to detect without statistical analysis of timing distributions.
Historical reference implementations include covert_tcp (Craig Rowland’s original demonstration) and NCovert. Modern adversary tooling rarely defaults to these techniques because the throughput is poor compared to DNS, but they remain in the toolbox for environments where higher-bandwidth options are monitored aggressively.
Detection at this layer requires deep packet inspection paired with statistical baselining of header field distributions. It’s rare to find production environments instrumented for this kind of analysis outside of high-assurance networks.
What defenders can realistically do#
A few patterns separate environments that detect covert exfiltration from environments that do not.
Baseline before you alert. Every protocol in this post has a normal volume, distribution, and shape inside a given network. The detections that work are anomaly-driven, and anomalies are only visible against a baseline. Build the baseline first, then layer detection on top.
Treat DNS as a security data channel. Centralize DNS resolution, log every query at the resolver, and feed those logs to whatever detection stack you operate. Entropy, query rate, subdomain length, and destination diversity are all useful signals.
Inspect TLS metadata, not just content. SNI, JA3/JA4, certificate properties, and destination IP context yield more covert-channel signal than payload inspection ever will, especially in environments where TLS interception is impractical.
Filter ICMP outbound by default. If hosts have no operational need to issue ICMP echo requests outbound, deny it at egress. This eliminates a common fallback path without affecting normal traffic.
Egress filter by protocol class. Many environments tolerate outbound protocols they don’t actually need. Default-deny outbound, with explicit allow rules per protocol per source category, narrows the covert channel surface considerably.
Profile by host, not just by alert. The strongest covert channel detections in mature programs come from behavioral profiling of individual hosts. A workstation that suddenly starts initiating DNS queries with high-entropy labels stands out only if you have a profile of what that workstation normally does.
Closing#
Covert channel exfiltration is not new. The tooling is decades old, the techniques are documented in textbooks, and the defender playbook is well understood by the part of the industry that focuses on it. The reason it remains effective is that most environments invest in payload inspection and content scanning on the channels they think attackers will use, while leaving the protocols they trust most under-monitored.
Cloud, container, and AI workload environments inherit the same pattern, often with even less egress visibility than traditional enterprise networks. The protocols that were trusted in the 1990s are still trusted today, and the same techniques that worked then continue to work now. They just need to be applied somewhere new.
