The Egress Problem
A rogue device on your network is only useful to an attacker if it can communicate with the outside world. The device needs a channel to send collected data out, receive commands and provide remote access. That channel is the tunnel.
Your detection stack is designed to catch exactly this: unauthorized outbound communication from internal devices. Firewalls restrict egress ports. IDS signatures match known tunnel protocols. NDR platforms flag anomalous connection patterns. Proxy servers inspect HTTP traffic.
The question is whether these controls work against tunnels that are specifically designed to evade them. ShadowTap answers that question by trying each tunnel type in sequence and documenting what gets caught.
1. Cloudflare ARGO: Hiding in the CDN
Cloudflare ARGO is the first tunnel in the cascade, and it is the hardest to detect.
The tunnel establishes an outbound HTTPS connection to Cloudflare's content delivery network. From the perspective of your firewall and proxy, this looks like standard HTTPS traffic to a legitimate CDN. Cloudflare serves millions of legitimate websites. Many organizations already have significant Cloudflare traffic flowing through their network.
Darktrace and similar NDR platforms can potentially flag this through beaconing analysis, detecting the regular keepalive pattern of the tunnel connection. However, if other devices on your network already communicate with Cloudflare services, the additional connection blends into established traffic patterns. The AI has seen Cloudflare traffic before. One more connection to the same infrastructure does not necessarily trigger an anomaly.
Detection depends heavily on context. Networks with existing Cloudflare traffic have higher false positive risk for this detection. Networks with no Cloudflare traffic would flag it more easily. This is why we test in your specific environment rather than making assumptions.
2. Iodine DNS: Data in the Subdomains
If Cloudflare ARGO is blocked, ShadowTap falls back to Iodine DNS tunneling. Iodine encodes data directly into DNS queries, using the subdomain field to carry payloads.
A normal DNS query looks like this: www.example.com. An Iodine DNS tunnel query looks more like this: dXNlcm5hbWU9YWRtaW4mcGFzc3dvcmQ9.t.yourdomain.com. The subdomain contains base32 or base64 encoded data. The authoritative DNS server for the tunnel domain decodes the data and routes it to the attacker's infrastructure.
DNS monitoring tools can detect this pattern. The queries are unusually long. The subdomain entropy is high (random-looking characters instead of readable words). The query volume from a single host to a single domain is abnormal. These are clear indicators of DNS tunneling.
But blocking it is harder than detecting it. You cannot simply block DNS resolution without breaking every application, website lookup and email delivery on the network. You can restrict DNS to known resolvers, but if your internal resolver forwards queries upstream, the tunnel data still reaches its destination. You can inspect DNS query content, but this requires dedicated DNS security tooling that many organizations lack.
Iodine is obvious to DNS monitoring. The question is whether your organization has DNS monitoring deployed and configured to alert on tunnel indicators.
3. ICMP Ptunnel: Data in the Pings
ICMP ptunnel hides data inside ping packets. ICMP echo request and echo reply packets have a data payload field that is normally filled with pattern data for diagnostic purposes. Ptunnel uses this field to carry actual data, encapsulating TCP traffic inside ICMP packets.
The detection challenge is nuanced. A few ICMP packets are normal. Workstations ping servers. Monitoring tools run connectivity checks. Routers exchange ICMP messages for path MTU discovery. Normal ICMP traffic is expected on any network.
What is not normal is sustained, high-volume ICMP traffic between an internal host and an external destination. Ptunnel generates significantly more ICMP traffic than legitimate diagnostic usage. The packet sizes are larger than standard pings. The traffic pattern is bidirectional and sustained rather than occasional.
Most IDS platforms have signatures for ICMP tunneling. Large ICMP payload sizes, unusual ICMP type codes and sustained ICMP sessions between the same hosts all trigger alerts. Darktrace flags this through volumetric analysis: the AI notices that a device is generating far more ICMP traffic than its historical baseline.
ICMP ptunnel gets caught more often than DNS or Cloudflare tunnels. It is included in the cascade because some networks have lax ICMP policies and no ICMP-specific monitoring. When it succeeds, it reveals a significant gap.
4. SSH Reverse Tunnel: The Last Resort
The SSH reverse tunnel is the most straightforward and the most detectable. ShadowTap establishes an outbound SSH connection to our lab and creates a reverse port forward, giving us access back into the client network through the encrypted SSH channel.
This is the last resort tunnel because SSH is heavily monitored on most corporate networks. Outbound SSH connections to unknown external hosts are a common IDS alert. Firewalls frequently restrict port 22 to specific destinations or block it entirely.
ShadowTap uses port 443 for the SSH connection when possible, blending with HTTPS traffic. Keepalive intervals are randomized rather than using SSH's default fixed interval, which breaks the beacon pattern that NDR platforms use for detection. But even with these evasion techniques, SSH generates a recognizable handshake and encrypted session pattern that deep packet inspection can identify.
If the SSH tunnel succeeds, it tells us that your egress controls do not inspect outbound encrypted traffic on port 443, or that your IDS lacks SSH-over-443 detection signatures. Both are actionable findings.
The Fifth Channel: JML ICMP Timing
Beyond the four primary tunnels, ShadowTap supports JML ICMP timing channels. This technique encodes data not in packet payloads but in the timing between ICMP packets. The interval between pings carries binary information. Short interval means 1. Long interval means 0. The packet payloads themselves are completely normal, standard ICMP echo requests with standard diagnostic data.
JML ICMP timing is extremely slow. The data transfer rate is measured in bits per second, not kilobytes. But it is nearly impossible to detect through payload inspection because there is no anomalous payload. Detection requires statistical analysis of inter-packet timing, which almost no production IDS or NDR platform performs on ICMP traffic.
This channel is primarily used to provide host details and initial reconnaissance data back to the testing lab when all other tunnels are blocked. It is not practical for interactive testing but proves that data exfiltration is possible even in extremely restricted environments.
What the Cascade Reveals
Each tunnel that fails teaches us about your detection. Each one that succeeds teaches you about your gaps.
If Cloudflare ARGO succeeds, your HTTPS egress inspection has blind spots around CDN traffic. If Iodine DNS succeeds, you lack DNS content inspection. If ICMP ptunnel succeeds, your ICMP policies are too permissive. If SSH reverse succeeds, your encrypted traffic inspection is incomplete.
The cascade is not just about finding one working tunnel. It is about mapping your complete egress detection coverage. The ShadowTap report documents every tunnel attempt, whether it succeeded or failed, how long it took for detection to occur and what specific alert or control blocked it.
This mapping tells you exactly which egress channels an attacker could exploit and which your controls would catch. It is the difference between assuming your egress controls work and knowing which ones do.