Reduce multi-hop proxy risk by limiting where proxy chaining is allowed, restricting outbound egress, and logging proxy-to-proxy connections. Require authentication on proxy services, block unauthorised tunnelling tools, and watch for repeated relays across internal and external hosts. Segmentation and content filtering make it harder for attackers to obscure command-and-control traffic or bypass inspection.
How to reduce the attack surface of proxy chaining
Multi-hop proxy becomes risky when users or malware can freely chain proxy services to hide origin, stretch trust across boundaries, or move traffic through places that were never meant to relay it. The first mitigation is to make proxy chaining a controlled exception, not a normal network pattern. That means defining where chaining is allowed, then enforcing that policy at the network edge and on proxy servers themselves.
Restricting outbound egress is equally important because multi-hop relay depends on flexible departure paths. If only approved destinations and protocols can leave the environment, attackers lose much of the room they need to bounce traffic across internal and external hosts. For broader command-and-control context, see the Command and Control (C2) Guide, which covers egress filtering, beaconing and tunnelling patterns that often overlap with proxy abuse.
Authentication on proxy services should be mandatory, not optional, because unauthenticated relays are easy to conscript into an attack path. When a proxy can only be used by known users, systems or workloads, you get a much smaller trust boundary and a better audit trail. Content filtering and protocol inspection add another layer by making covert relays harder to blend into ordinary web or DNS traffic.
What to monitor when proxy traffic crosses multiple hops
Logging proxy-to-proxy connections gives defenders the evidence needed to spot repeated relays, unusual hop chains and traffic that keeps changing its apparent source. The useful signal is not just volume, but path structure: a normal business workflow usually has a stable pattern, while multi-hop abuse tends to create chains that are longer, flatter or more repetitive than expected.
That matters because adversaries use proxy chains to obscure command-and-control paths, relay stolen access, or route around inspection points. If internal hosts start behaving like transit nodes rather than endpoints, the issue has moved beyond simple browsing privacy and into trust abuse. A second useful reference is the CISA cyber threat advisories, which help teams correlate suspicious relay behaviour with broader active-threat patterns.
Segmentation also improves detection quality. If a subnet should never forward traffic for another subnet, any proxy-to-proxy relay inside that zone becomes easier to flag. That makes the detection problem more about exceptions than about trying to inspect every packet in the enterprise.
How to make multi-hop proxy abuse harder to sustain
The practical goal is to remove easy relay options before an attacker can use them as persistence. Block unauthorised tunnelling tools, deny unapproved proxy software, and prevent unmanaged systems from becoming relay points. If a tool is designed to forward traffic in a way your environment does not need, it should not be allowed to operate by default.
Strong network segmentation is the other half of that control. When internal zones cannot freely talk through intermediate hosts, multi-hop routing becomes noisy and fragile. That does not eliminate every bypass, but it raises the cost of abuse and makes the attacker rely on weaker, easier-to-detect paths.
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 proxy is a proxy-based evasion and relay pattern. |
| Recommendation — Detect chained proxying and pivot activity that indicates proxy abuse. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Restricting proxy paths and egress is a network-control hardening task. |
| Recommendation — Limit approved proxy routes and enforce controlled outbound traffic paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Network integrity is protected against unauthorized modifications, connections, and access | Proxy chaining changes trust boundaries and requires access-path control. |
| Recommendation — Constrain unauthorized relay paths and monitor for abnormal network connections. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Proxy chaining is a boundary-crossing problem that boundary controls should constrain. |
| AU-2 — Event Logging | Proxy-to-proxy connections need audit events for detection and investigation. | |
| Recommendation — Enforce boundary protections that restrict unauthorized proxy and relay traffic. Log proxy relay events with source, destination and hop context for review. | ||
Practitioner Guidance
What to prioritise: Start with the proxy tiers that can reach the internet or sensitive internal services, then verify whether they are allowed to relay only for explicit business use cases. If a proxy can authenticate upstream and downstream without a documented need, treat that as an architectural exception.
What to verify: Confirm that logs show the original client, the proxy chain and the final destination, not just a collapsed “allowed” event. If your telemetry cannot distinguish direct access from chained relay, you will miss the behaviour that makes multi-hop proxy dangerous.
Decision rule: If a proxy path is being used to cross trust boundaries, inspect and restrict it even when the traffic content looks benign. The risk is often in the path itself, not only in the payload.
Practitioner takeaway: The best mitigation is not to chase every relay after the fact, but to make proxy chaining visible, rare and policy-bound so abuse is easier to detect than to hide.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org