Detect multi-hop proxies by tracing traffic that relays through several intermediary systems before reaching its destination. Look for chained connections, repeated use of proxy ports, and endpoints that rarely talk directly to external services. Enforce egress controls, inspect proxy logs, and flag hosts that suddenly start forwarding traffic for other systems.
How multi-hop proxies evade simple perimeter checks
Multi-hop proxying is not just “using a proxy”, it is a relay chain. The first hop hides the client, intermediate hops obscure the path, and the final hop makes the traffic look like ordinary outbound connectivity. That means teams usually need to reason about connection shape, not just destination reputation or port number.
One useful way to spot it is to compare what the endpoint claims to do with what the network actually shows. A workstation or server that seldom reaches external services directly, then suddenly opens repeated outbound sessions through the same relay pattern, is worth closer inspection. The same is true when traffic appears to pass through several systems that have no obvious business reason to forward it.
Proxy chaining also leaves behavioural clues in logs and session metadata. Repeated proxy ports, unusual reuse of the same intermediary hosts, and long-lived relays that sit between an internal source and an external destination can all indicate an attempt to hide the true origin of traffic. That is especially important when the relay path is stable enough to support recurring command, browser, or automation traffic rather than a one-off connection.
The most reliable detections usually combine network telemetry, host telemetry, and policy enforcement. Egress controls can limit where traffic is allowed to go, while proxy logs and DNS visibility help show whether a host is acting as a forwarder, not just a client. When those layers are correlated, multi-hop behaviour becomes easier to distinguish from legitimate load balancing, corporate VPN use, or approved outbound gateways.
For defenders who already monitor command-and-control style behaviour, the same signals often apply here. NHIMG’s Command and Control (C2) Guide is a useful reference because chained relays, beacon-like repetition, and egress filtering all overlap with proxy-abuse detection patterns. If the traffic path looks deliberately flattened into a normal-looking outbound channel, treat that as a visibility problem before it becomes an incident.
Risk and Threat Considerations
Multi-hop proxies matter because they are designed to defeat attribution and delay containment. The more relays an attacker uses, the harder it becomes to tell which host is the true source, which host is only a transit point, and where to block the traffic without breaking legitimate services.
Failure mechanism: A chained proxy path can blend malicious traffic into ordinary outbound flow, especially when each hop uses common ports, standard encryption, or compromised internal hosts as relays. That can defeat naive allowlist logic and hide the system that originally initiated the connection.
Impact: Defenders may miss command-and-control, data exfiltration, or lateral movement until the relay chain is mapped manually. Containment also becomes slower because teams have to investigate multiple systems before they can isolate the true control point.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1090 — Proxy | Multi-hop proxying is an ATT&CK proxy and relay pattern used to obscure origin and route traffic. |
| Recommendation — Map chained relays to T1090 and hunt for proxy software, relay hosts, and path obfuscation. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Detecting relay paths depends on network egress policy, segmentation, and logging of intermediary traffic. |
| Recommendation — Restrict and monitor outbound paths so only approved systems can forward traffic. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | Multi-hop proxies are discovered through continuous monitoring of network connections and relay behaviour. |
| PR.AA-05 — Network Integrity Is Protected | Egress controls and path restrictions help prevent unauthorized proxy chaining and traffic forwarding. | |
| Recommendation — Correlate network telemetry to identify chained connections and suspicious forwarding. Enforce egress restrictions to block unauthorized relay paths. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Generation | Proxy logs and network records are needed to reconstruct chained connections and relay paths. |
| Recommendation — Generate and retain logs that show which hosts relay traffic and when. | ||
Practitioner Guidance
What to verify: Check whether the suspected relay hosts have a real operational need to forward traffic for other systems. If they do not, treat forwarding behaviour itself as suspicious, even if the destination looks benign.
Decision rule: If the same source repeatedly reaches external services only through a small set of intermediaries, prioritise path reconstruction over destination-based triage. If the chain includes internal systems that are not approved gateways, inspect those hosts first for compromise or unauthorized proxy software.
What good looks like: You should be able to explain every hop in the path, show why it exists, and prove that only approved systems are allowed to relay traffic. Where that is not possible, the control gap is usually in egress policy, proxy logging, or asset ownership rather than in the destination itself.
Practitioner takeaway: Multi-hop proxy detection works best when you treat proxying as a path-analysis problem, not a single-indicator problem, and force every relay to justify why it exists.