T1572 Protocol Tunnelling: Detection and Defence

Egress firewalls that allow only HTTPS, DNS and SSH do not stop an intruder who wraps RDP, SMB or a C2 protocol inside one of those three. MITRE ATT&CK tracks this as T1572 Protocol Tunneling: adversaries encapsulate one protocol inside another to avoid detection or filtering, or to reach systems that would otherwise be unreachable. In current intrusions it ranges from SSH port forwarding and DNS tunnels to reverse tunnel services such as ngrok and Cloudflare Quick Tunnels, and to GRE tunnels configured on compromised network devices. This guide covers how tunnelling works, where it shows up, how to detect it on hosts and the wire, and how to harden egress without breaking legitimate remote access. It is written for SOC analysts, detection engineers and network architects, and stays defensive. For C2 as a whole, see the Command and Control (C2) Guide.

Key takeaways

Tunnels turn allowed ports into any port. Once RDP or SMB rides inside SSH, HTTPS or DNS, port-based rules no longer describe what is crossing the boundary.
Reverse tunnel services are the modern default. ATT&CK v20 records Scattered Spider installing Chisel, ngrok, Pinggy and Teleport, and threat actors in the SharePoint ToolShell campaign using ngrok.
The process is the best sensor. ATT&CK's v20 analytics key on plink.exe, ssh.exe, netsh.exe, socat and unknown binaries making long-lived outbound connections with odd byte ratios.
DNS needs its own controls. Force all name resolution through resolvers you log, prohibit unmanaged DNS over HTTPS and analyse query length and entropy.
Network devices tunnel too. Salt Typhoon created GRE tunnels by changing device configurations, so configuration integrity monitoring is part of T1572 defence.

How the attack works

ATT&CK v20 describes tunnelling as explicitly encapsulating one protocol within another. It can hide malicious traffic among existing flows, add an outer layer of encryption similar to a VPN, and route packets such as SMB or RDP that network appliances would otherwise filter or the internet would not carry. T1572 has no sub-techniques in v20 and applies to Windows, Linux, macOS and ESXi.

Tunnel family	Carrier	What it achieves for the intruder	Examples recorded in ATT&CK v20
SSH port forwarding	SSH, often TCP 22 or a high port	Local or remote forwarding of RDP, SMB or C2 through an encrypted session	FIN6, OilRig and Cobalt Group using Plink; Magic Hound tunnelling RDP over SSH; FIN7 using OpenSSH
HTTP and HTTPS tunnels	TCP 80/443, sometimes via a web shell	Arbitrary TCP sessions through a web server or proxy	reGeorg tunnelling RDP, SSH and SMB through HTTP; Sandworm's GOGETTER using a Yamux TLS channel in the 2022 Ukraine power attack
DNS tunnels	UDP/TCP 53 queries and responses	Data encoded in names and records; works where only DNS leaves the network	Iodine tunnelling IPv4 over DNS in the Cutting Edge campaign; Cobalt Strike encapsulating C2 in DNS
DNS over HTTPS	HTTPS 443	Hides C2 name lookups from resolver logging (with T1568 Dynamic Resolution)	Cyclops Blink, HiddenFace and Brute Ratel C4 using DoH
Reverse tunnel services	Outbound TLS to a SaaS relay	Publishes an internal service to the internet with no inbound rule	ngrok (Fox Kitten, ToolShell exploitation); Chisel to trycloudflare subdomains, Pinggy and Teleport (Scattered Spider); FRP
Network-layer tunnels	GRE, IPsec on routers and firewalls	Routes traffic between attacker infrastructure and internal segments	Salt Typhoon modifying device configurations to create GRE tunnels

T1572 often appears beside T1090 Proxy (a SOCKS proxy inside the tunnel), T1001.003 Protocol or Service Impersonation, T1021.001 Remote Desktop Protocol for the traffic carried, and T1219 Remote Access Tools where a commercial tool provides the channel. See the T1090 Proxy Defensive Guide and the T1102 Web Service Defensive Guide.

Where it shows up

Edge-exposed web servers: a web shell turned into a TCP tunnel gives interactive access to the internal network through port 443. See the T1190 Exploit Public-Facing Application Defensive Guide.
Virtualisation management: ATT&CK records Scattered Spider placing tunnelling tools on VMware vCenter and on virtual machines it created, where EDR coverage is often weakest. ESXi has its own analytics in v20.
Developer and admin workstations: ngrok, cloudflared, SSH clients and Teleport are legitimate tools, so their presence alone is not malicious and their misuse is easy to miss.
Network infrastructure: routers and firewalls that can be reconfigured to build GRE or IPsec tunnels, as in the Salt Typhoon telecom intrusions, where our breach analysis also records SSH servers started on high ports.
Locked-down segments: OT and server networks where only DNS reaches out are the natural home of DNS tunnels.

Impact

Egress policy bypass: RDP and SMB reach attacker infrastructure through ports the firewall allows, defeating segmentation the organisation believes is in place.
Inbound access without inbound rules: a reverse tunnel publishes an internal service to the internet, which ATT&CK notes FRP does for resources behind firewalls or NAT.
Blind spots for inspection: SSH and pinned TLS cannot be decrypted by most proxies, and DoH removes queries from resolver logs.
Exfiltration channel: the same tunnel carries stolen data (T1048 Exfiltration Over Alternative Protocol). See the Data Exfiltration Guide.

Detection

ATT&CK v20's detection strategy for T1572 looks for anomalous process-to-network relationships, large asymmetric flows and port usage mismatches, using Sysmon Event IDs 1, 3 and 22 on Windows, auditd socket and connect calls plus sshd syslog on Linux, the unified log on macOS (ssh launched with forwarding flags), and ESXi vpxd and listening socket data.

Signal	Telemetry	Tunnel family	Tuning note
plink.exe, ssh.exe or socat started with forwarding options, or netsh interface portproxy rules added	EDR or Sysmon 1 command lines; registry and netsh auditing	SSH, port proxy	Allowlist admin jump hosts; alert elsewhere
Long-lived outbound session from a non-browser process with steady low-volume traffic in both directions	Sysmon 3, flow logs, Zeek conn.log duration and bytes	All	Rank by duration times host rarity, not raw volume
Connections to reverse tunnel services (connect.ngrok-agent.com, trycloudflare.com subdomains and similar)	DNS and proxy logs	Reverse tunnels	Separate sanctioned ngrok use, which can run through a custom connect URL, from unknown accounts
High volume of unique, long or high-entropy subdomains under one parent domain; TXT or NULL record heavy traffic	Resolver query logs, Zeek dns.log	DNS	CDN and security vendor domains are noisy; allowlist them deliberately
HTTPS to public DoH resolvers from managed endpoints	Proxy logs, firewall logs against a DoH resolver list	DoH	Browsers may try DoH by default; enforce policy first, then alert
RDP or SMB session arriving from 127.0.0.1 or from a host that does not normally administer the target	Windows 4624 logon type 10 with source address, RDP operational logs	SSH, HTTP	A loopback RDP source is a classic tunnel indicator
New GRE or IPsec tunnel interface, or ACL change, on a router or firewall	Configuration management diffs, AAA command accounting	Network-layer	Compare against approved change tickets

Measuring the detection programme

Resolver enforcement: percentage of endpoints whose DNS goes only to managed resolvers (aim for 100% of managed estates).
Tunnel tool inventory: number of hosts with ngrok, cloudflared, Chisel-style binaries or SSH servers outside the approved list, trending to zero.
Long-session review: share of outbound sessions over eight hours from servers that have a known owner and purpose.
Configuration drift: unapproved network device changes found per month and time to detect them.
Detection test pass rate: purple-team runs of SSH, DNS and reverse tunnel scenarios detected within the target time.

Prevention and hardening

ATT&CK v20 lists M1037 Filter Network Traffic and M1031 Network Intrusion Prevention for T1572. The practical programme turns these into a default-deny egress design with named exceptions.

Route web egress through an authenticating proxy: servers and user devices should not open direct outbound TLS (NIST SP 800-53 SC-7(8) Route Traffic to Authenticated Proxy Servers). See the Proxies and Forward vs Reverse Proxy Security Guide.
Control DNS centrally: block outbound UDP and TCP 53 and TCP 853 except from your resolvers, use protective DNS, and set the Windows policy Configure DNS over HTTPS (DoH) name resolution (Computer Configuration\Policies\Administrative Templates\Network\DNS Client). Microsoft warns not to use Require DoH on domain-joined machines because Active Directory DNS does not support DoH. See the Protective DNS Guide.
Allow outbound SSH only from jump hosts: block TCP 22 and SSH on other ports elsewhere, and on servers set AllowTcpForwarding no and PermitTunnel no in sshd_config unless forwarding is a documented need.
Govern reverse tunnel tools: block reverse tunnel services by category and domain, and if ngrok is sanctioned, use its custom connect URL option so the default connect hosts can be blocked, which ngrok notes also stops users bringing their own accounts. Cloudflare describes Quick Tunnels as intended for testing and development only, which is a reasonable basis to block trycloudflare.com on corporate networks.
Application control: prevent unapproved tunnelling binaries from running (NIST SP 800-53 CM-7(5) allow-by-exception, ATT&CK M1042 Disable or Remove Feature or Program for portproxy and unused SSH servers).
Protect network device configuration: require AAA accounting, store golden configurations and alert on new tunnel interfaces. See the Edge Device Security Guide.

Rolling it out

Log first: collect two to four weeks of DNS, SSH and proxy bypass data to find legitimate tunnels (backup agents, vendor support tools, developers).
Agree exceptions with owners and expiry dates, then block direct DNS and SSH for one pilot segment.
Extend by network zone, servers first, keeping a firewall rule rollback documented for each change.
Re-test with authorised purple-team scenarios after every phase.

Choosing an approach: small organisations get most of the benefit from a cloud SWG or protective DNS service plus EDR command-line detections. Large estates should add network detection on DNS and flow data, and treat network device configuration as a monitored asset. Where TLS inspection is impossible, rely on process attribution and session duration rather than payload.

Lessons from incidents

Patching the entry point does not close the tunnel. ATT&CK records threat actors in the SharePoint ToolShell exploitation campaign using ngrok tunnels to deliver PowerShell payloads; the ToolShell SharePoint exploitation analysis shows how attackers kept access after patching. Hunt for tunnel tools during any web server compromise.
Infrastructure tunnels outlast host clean-up. In the Salt Typhoon telecom intrusions, configuration changes on network devices, including SSH servers on high ports, kept access alive; ATT&CK adds GRE tunnel creation for the same group. See the Salt Typhoon Threat Actor Profile.
Hypervisors are tunnel hosts. Scattered Spider's use of vCenter and its own virtual machines shows that EDR-only detection leaves gaps. See the Scattered Spider Threat Actor Profile.

Where identity fits

Tunnels need credentials at both ends: SSH keys placed on servers or devices, accounts for ngrok or Cloudflare, and the valid accounts used to sign in over the tunnelled RDP. Inventory authorized_keys files and device local accounts, alert on new keys, and treat a tunnel finding as a credential compromise. See the SSH Key Management Guide.

Framework mapping

Framework	Reference	Relevance
ATT&CK v20 mitigations	M1037 Filter Network Traffic; M1031 Network Intrusion Prevention; M1030 Network Segmentation; M1042 Disable or Remove Feature or Program	Egress filtering, signatures, segment design, removing forwarding features
MITRE D3FEND	D3-OTF Outbound Traffic Filtering; D3-DNSTA DNS Traffic Analysis; D3-PMAD Protocol Metadata Anomaly Detection; D3-RTSD Remote Terminal Session Detection	Default-deny egress, DNS tunnel analytics, mismatched protocol metadata, tunnelled RDP sessions
NIST SP 800-53 Rev. 5	SC-7 and SC-7(8); SC-21; AC-17; CM-7(5); SI-4(4)	Boundary and proxy routing, secure resolvers, governed remote access, allowlisted software, outbound monitoring
NIST CSF 2.0	PR.IR-01; DE.CM-01	Protect networks from unauthorised use and monitor network services

Practitioner checklist

Block direct outbound DNS, DoT and SSH except from approved resolvers and jump hosts.
Set the DoH client policy and browser DoH policies on managed devices.
Block reverse tunnel services by category; route sanctioned ngrok use through a custom connect URL.
Disable TCP forwarding and tunnelling in sshd_config where not required.
Alert on plink, ssh, socat and netsh portproxy use outside admin hosts.
Hunt weekly for long-lived, low-volume outbound sessions from servers.
Analyse resolver logs for high-entropy subdomains and TXT-heavy domains.
Diff network device configurations daily and alert on new tunnel interfaces.
Extend monitoring to vCenter and ESXi hosts.
Run authorised tunnel detection tests quarterly.

T1572 Protocol Tunnelling Defensive Guide: Detecting SSH, DNS and HTTP Tunnels