Traffic diversion is the redirection of network or application traffic away from its intended path to another destination or route. In security and operations, it can be used for load balancing, failover, inspection, sinkholing, or malicious interception through DNS, routing, proxy, or man-in-the-middle techniques.
What Traffic Diversion Means in Security and Operations
Traffic diversion changes where packets, requests, or sessions go, so the same mechanism can support legitimate operational goals or an attack path. It sits at the boundary between routing, proxying, DNS resolution, and inspection, which is why it matters to both availability engineering and interception risk.
In benign use, diversion helps send traffic to a healthier path, a security control, or a sinkhole. In hostile use, the same redirection can quietly move users or systems to a fake endpoint, a monitoring proxy, or an attacker-controlled service without changing the original user intent.
How Traffic Diversion Happens
Traffic can be diverted at several layers. DNS changes can point a name to a different destination, routing changes can steer flows through another network segment, and proxy insertion can terminate or relay sessions before forwarding them onward. Each method alters the trust boundary in a different way.
Because the redirection may happen before the application sees the request, diversion can preserve normal-looking behaviour while changing the actual path. That makes it useful for load balancing and inspection, but also for stealthy interception when the operator of the new path is untrusted.
Why Traffic Diversion Matters for Control and Trust
The security significance is not the redirection itself, but the authority to change routing, resolution, or proxy handling. If those controls are weak, an attacker can impersonate a legitimate destination, downgrade transport assurances, or place a monitoring point between a client and a service.
It also affects resilience. Well-managed diversion can support failover, isolation, and containment, but poorly governed changes can create outage loops, split-brain behaviour, or silent data exposure if traffic is sent to the wrong enclave or inspection point.
Common Security Uses and Abuse Patterns
Defenders use diversion for sinkholing malicious domains, quarantine routing, TLS inspection in controlled environments, and traffic shifting during incident response. Those uses work because the destination is intentionally changed under policy and monitored as part of the control plane.
Attackers use the same pattern through DNS poisoning, route hijacking, proxy abuse, or man-in-the-middle positioning. The practical danger is that users often continue normal workflows while credentials, tokens, or sensitive content are observed, altered, or replayed along the diverted path.
Risk and Threat Considerations
Traffic diversion becomes risky when control-plane changes are easy to make, hard to verify, or invisible to the people relying on the path. The same redirection that enables containment can also enable interception, credential capture, or traffic loss if the new destination is not trusted.
Failure mechanism: An attacker or misconfiguration alters DNS, routing, or proxy behaviour so traffic is silently sent through an unintended path, where it can be observed, modified, or dropped.
Impact: The result can be session theft, data exposure, service degradation, failed failover, or a prolonged loss of trust in the path used by users and systems.
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 NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Monitoring for anomalies and events | Traffic diversion is often detected through unexpected path and destination changes. |
| PR.DS-04 — Data-in-transit is protected | Diversion can expose traffic unless the transit path is strongly protected. | |
| PR.AA-05 — Network integrity is protected | This term centers on trust in the integrity of routing and delivery paths. | |
| Recommendation — Monitor for unexpected DNS, routing, and proxy changes that indicate diverted traffic. Protect traffic in transit so diverted paths cannot disclose or alter sensitive sessions. Enforce network integrity controls that restrict unauthorized path changes and interception. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Traffic diversion changes network boundaries and the trust placed in intermediate paths. |
| AU-12 — Audit Record Generation | Diversion events need traceable records for post-incident review and accountability. | |
| IA-2 — Identification and Authentication (Organizational Users) | Path changes are often triggered through administrative access that must be strongly authenticated. | |
| Recommendation — Apply boundary protections to control and inspect traffic only through approved paths. Generate audit records for DNS, routing, and proxy changes that affect traffic paths. Require strong authentication for users who can alter traffic diversion controls. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Traffic diversion changes the trust boundary and reinforces never trust, always verify path decisions. |
| Recommendation — Verify each redirected request and do not assume the path remains trustworthy. | ||
| MITRE ATT&CK | T1090 — Proxy | Proxy-based diversion is a common technique for relaying and obscuring traffic paths. |
| T1565.001 — Stored Data Manipulation: Data Manipulation | Redirection can be used to alter content or responses during transit. | |
| Recommendation — Hunt for proxy relays and route traffic through inspected, approved intermediaries only. Detect altered responses and compare observed traffic with expected destinations and content. | ||
Practitioner Guidance
Why practitioners should care: Traffic diversion is a control-plane issue, not just a network-path issue. Treat every redirection method as a change to trust, because the security outcome depends on who can trigger it, validate it, and detect unauthorized changes.
What to watch for: Unexpected DNS answers, unexplained route changes, new proxy dependencies, and destination mismatches between intended and observed endpoints are the clearest warning signs. When those signals appear, verify both the control source and the on-path destination before assuming the traffic is still following policy.
Related resources from NHI Mgmt Group
- When should organisations block anonymous network traffic at login?
- How should teams rotate JWT signing keys without breaking production traffic?
- What is the difference between securing V2X traffic and securing automotive identities?
- What is the difference between routing traffic and governing identity at the edge?
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 November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org