Multi-hop Proxy (T1090.003) is what happens when one relay is not enough. It is a command and control technique for ESXi, Linux, macOS, Network Devices and Windows, and a sub-technique of Proxy.
How attackers use it
MITRE says adversaries may chain multiple proxies to disguise the source of malicious traffic. A defender can typically identify the last proxy the traffic crossed before it entered the network, and may not be able to identify earlier ones. Tracing the original source means walking through several proxies.
The page lists several ways this is done:
- Onion routing networks, such as the publicly available Tor network, carrying encrypted C2 traffic.
- Operational relay box (ORB) networks made of virtual private servers, Internet of Things devices, smart devices and end of life routers, used to obfuscate operations.
- Compromised network devices chained together. By patching a router's system image, adversaries may add custom code that implements onion routing between nodes. MITRE says this depends on the ability to cross the protected network boundary of the Internet perimeter into the WAN. Protocols such as ICMP may be used as transport.
- Peer to peer and blockchain oriented infrastructure used to route between a decentralized network of peers.
How to detect it
MITRE's strategy (DET0359) lists:
- Windows: suspicious processes, such as Tor clients, relays or unknown binaries, with sustained encrypted outbound traffic to known anonymity infrastructure, possibly relaying onward through reverse proxying, ICMP tunneling or socket forwarding.
- Linux: tools such as tor, nglite, proxychains, chisel or custom daemons repeatedly opening sessions to multiple nodes before the final destination. MITRE says this is abnormal for Linux services outside of VPN, monitoring or CDN relay contexts.
- macOS: LaunchAgents or LaunchDaemons starting persistent Tor or relay processes with encrypted outbound connections, possibly with unsigned executables using SOCKS proxies.
- ESXi: encrypted traffic from the hypervisor shell or a VM backdoor to relays on VPS infrastructure, especially across multiple nodes, where captures show non-VM communication paths.
- Network devices: encrypted traffic or ICMP tunneling from border routers to internal routers or unknown external IPs, with consistent hop to hop relaying that does not match configured VPN or expected topology.
Because the full chain is hidden, local evidence matters most. Capture which process and which device sent the traffic, and compare against what that system is supposed to do.
How to reduce the risk
MITRE lists Filter Network Traffic. Traffic to known anonymity networks and C2 infrastructure can be blocked with network allow and block lists. MITRE notes this may be circumvented by other techniques such as domain fronting.
In practice that means blocking what you can, and still logging everything else. Where possible, deny all traffic that is not on an allow list, and watch ICMP volume and size on border devices.
Check your own environment
- Is traffic to known Tor entry points blocked or at least alerted at your egress?
- Do border routers have verified, signed images, and who can change them?
- Do you collect firewall and NetFlow data from border devices?
On Linux, a read-only search for common relay tools in the process list:
ps aux | grep -i -E 'tor|proxychains|chisel' | grep -v grep
The match may include harmless names, so check each result.
Quick check
What can a defender usually identify in a multi-hop chain?
Typically the last proxy before traffic enters the network, but not necessarily earlier hops.
What does MITRE say about the Filter Network Traffic mitigation?
It can block known anonymity networks and C2 infrastructure, but may be circumvented by techniques such as domain fronting.
Sources
- MITRE ATT&CK, T1090.003 Multi-hop Proxy: https://attack.mitre.org/techniques/T1090/003/
