Protocol Tunneling (T1572) is a command and control technique. The adversary wraps one protocol inside another. The goal is to avoid detection or network filtering, or to reach systems that would otherwise be unreachable. MITRE lists ESXi, Linux, macOS and Windows as platforms.
Tunneling is not exotic. Administrators use SSH port forwarding every day. That is exactly why it is useful to an attacker: the outer layer looks normal.
How attackers use it
MITRE describes several benefits of tunneling.
- Blending in. Malicious traffic can hide inside traffic that already exists on the network.
- An outer layer of encryption. MITRE compares this to a VPN. The inner content is hidden from anything that only inspects the outside.
- Reaching what is blocked. Tunneling can carry traffic that network appliances would filter or that would not route over the internet, such as SMB or RDP.
MITRE gives SSH tunneling, also called SSH port forwarding, as a concrete example. Arbitrary data is forwarded over an encrypted SSH connection.
It also notes a DNS angle. During Dynamic Resolution (T1568), queries to resolve command and control infrastructure may be wrapped in encrypted HTTPS packets, known as DNS over HTTPS (DoH).
Finally, tunneling may be combined with Proxy (T1090) and with Protocol or Service Impersonation (T1001.003) to further conceal command and control communications and infrastructure.
How to detect it
MITRE's detection strategy covers each platform.
Windows. Processes such as plink.exe, ssh.exe or netsh.exe making outbound connections where the traffic pattern shows an encapsulated protocol, for example RDP over SSH. Signals include odd process-to-network relationships, large asymmetric data flows and port usage that does not match the protocol.
Linux. sshd, socat or custom binaries starting port forwarding or encapsulating traffic like RDP or SMB through SSH or HTTP. Defenders may see unusual connect and bind system calls, encrypted traffic on ports normally used for unencrypted services, and outlier traffic volumes.
macOS. launchd or user-run processes such as ssh and socat wrapping traffic in SSH tunnels, VPN-style tooling or DNS-over-HTTPS clients. A signal is outbound TLS traffic with embedded DNS or RDP payloads.
ESXi. VMware daemons or user processes encapsulating traffic, for instance guest VMs tunneling through hostd. Look for network services inside ESXi making flows that do not fit management plane traffic, such as SSH forwarding or DoH from management interfaces.
Across all four, the pattern is the same: a process that has no business forwarding traffic is forwarding traffic, and the flow shape (volume, direction, port) does not match what the protocol should look like.
How to reduce the risk
MITRE lists two mitigations.
- Filter network traffic. Consider filtering traffic to untrusted or known bad domains and resources.
- Network intrusion prevention. Signature-based systems can identify traffic for specific adversary malware at the network level.
A few plain steps follow from the detection notes:
- Decide which hosts are allowed to make outbound SSH at all, and block it elsewhere.
- Disable SSH forwarding on servers that do not need it.
- Control which resolvers hosts may use, so DoH to arbitrary providers stands out.
- Alert on forwarding tools (plink, socat) appearing on hosts where they have never run.
Check your own environment
Read-only checks:
# Linux: show effective sshd forwarding settings (needs root)
sudo sshd -T | grep -i -E 'allowtcpforwarding|permittunnel|gatewayports'
# Linux: current SSH client connections and owning processes
ss -tnp | grep ssh
# Windows PowerShell: processes connecting out that are often used for forwarding
Get-NetTCPConnection -State Established |
ForEach-Object { $p = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
[pscustomobject]@{Process=$p.ProcessName; Remote=$_.RemoteAddress; Port=$_.RemotePort} } |
Where-Object { $_.Process -in 'plink','ssh','netsh' }
Checklist:
- Which servers can open outbound SSH to the internet?
- Is SSH forwarding enabled on hosts that only need a shell?
- Do you baseline per-process traffic volume, including upload to download ratio?
- Can management interfaces on ESXi hosts reach the internet?
Quick check
Why is SSH tunneling hard to spot from the outside?
The outer layer is a normal encrypted SSH session. MITRE notes tunneling can blend in with existing traffic and add its own layer of encryption, so you need process and flow-shape signals, not content.
Name two flow signals MITRE lists for Windows tunneling detection.
Large asymmetric data flows and port usage mismatches, along with anomalous process-to-network relationships from tools like plink.exe, ssh.exe or netsh.exe.
Which hosts should be able to run outbound SSH?
Only the ones with a documented need. Everything else should be blocked by egress filtering, which removes the easiest tunneling path.
