T1090.003: Multi-hop Proxy
Adversaries may chain together multiple proxies to disguise the source of malicious traffic. Typically, a defender will be able to identify the last proxy traffic traversed before it enters their network; the defender may or may not be able to identify any previous proxies before the last-hop proxy. This technique makes identifying the original source of the malicious traffic even more difficult by requiring the defender to trace malicious traffic through several proxies to identify its source.
For example, adversaries may construct or use onion routing networks – such as the publicly available Tor network – to transport encrypted C2 traffic through a compromised population, allowing communication with any device within the network.CitationOnion Routing Adversaries may also use operational relay box (ORB) networks composed of virtual private servers (VPS), Internet of Things (IoT) devices, smart devices, and end-of-life routers to obfuscate their operations.CitationORB Mandiant
In the case of network infrastructure, it is possible for an adversary to leverage multiple compromised devices to create a multi-hop proxy chain (i.e., Network Devices). By leveraging Patch System Image on routers, adversaries can add custom code to the affected network devices that will implement onion routing between those nodes. This method is dependent upon the Network Boundary Bridging method allowing the adversaries to cross the protected network boundary of the Internet perimeter and into the organization’s Wide-Area Network (WAN). Protocols such as ICMP may be used as a transport.
Similarly, adversaries may abuse peer-to-peer (P2P) and blockchain-oriented infrastructure to implement routing between a decentralized network of peers.CitationNGLite Trojan
Security context for executives and security teams
Multi-hop Proxy matters because it hides where command-and-control traffic really comes from. Defenders may only see the final relay entering the network, while earlier hops may be Tor, leased VPS infrastructure, compromised IoT/SOHO routers, network devices, or decentralized peer networks. For leaders, the decision issue is not attribution; it is whether the organization can recognize suspicious relay-style traffic, enforce useful ingress/egress boundaries, and preserve enough network evidence for incident response when the source is deliberately obscured.
Executive priority
Prioritize this where business operations depend on exposed services, WAN connectivity, cloud or data platforms, managed service access, or network devices that are difficult to monitor. The supplied ATT&CK relationships show broad use across campaigns, groups, and software, so this is a resilience and investigation-readiness problem rather than a single-threat problem. Executives should ask whether firewall policy, egress control, network logging, and incident response procedures can support decisions when the visible IP address is only a last-hop proxy and not a reliable actor identifier.
Technical view
This is a command-and-control sub-technique of Proxy affecting ESXi, Linux, macOS, Network Devices, and Windows. ATT&CK provides no official detection text, but a related detection strategy, DET0359, is named for relay node chaining, onion routing, and network tunneling. SOC and IR teams should validate whether they can identify unusual inbound or outbound relay behavior, repeated connections through known or suspicious anonymization infrastructure, unexpected tunneling patterns, and protocol use inconsistent with the asset role, including possible ICMP transport in network-infrastructure scenarios. For network-device cases, pay attention to edge routers, WAN paths, and signs that compromised devices or altered system images could participate in proxy chains.
Likely telemetry
- Firewall, router, and network appliance ingress/egress logs
- Proxy, secure web gateway, and network filtering logs where deployed
- NetFlow or equivalent flow records across perimeter, WAN, and internal network boundaries
- Endpoint network connection telemetry from ESXi, Linux, macOS, and Windows systems
- Network device configuration, firmware/system image integrity, and administrative change records
Detection direction
- Do not treat the observed source IP as the true origin by default; tune triage workflows to preserve last-hop evidence while looking for relay-chain indicators.
- Validate DET0359-style coverage for relay node chaining, onion routing, and network tunneling against the platforms and network segments in scope.
- Baseline which assets are expected to communicate with anonymization networks, VPS providers, external relays, or peer-oriented infrastructure, then review deviations by asset role and business need.
- Correlate perimeter flows with endpoint and network-device telemetry so C2-like traffic is not evaluated only at the firewall.
- Review blind spots around network devices, SOHO/IoT-adjacent infrastructure, WAN links, encrypted traffic, and protocols that may not be deeply inspected.
Mitigation priorities
- Implement M1037 Filter Network Traffic: enforce ingress and egress filtering with firewall rules and protocol-based restrictions appropriate to each asset role.
- Restrict public-facing services to authorized sources where business operations allow, especially for administrative interfaces and high-value applications.
- Limit outbound connectivity from servers, network devices, and sensitive environments to approved destinations and required protocols.
- Harden and monitor network devices, including configuration control and system image integrity, because the ATT&CK description highlights router compromise and patched images as proxy-chain enablers.
- Preserve network-flow and device logs long enough to support incident response when tracing cannot go beyond the last-hop proxy without external coordination.
Additional notes and limits
Relationship context links this technique to many campaigns, groups, and software, including ORB-network and router-focused activity. Use that context to justify defensive validation, not to infer that any specific organization is targeted. The most valuable local analysis is usually asset-role context: which systems should ever relay traffic, which network devices are observable, and which egress paths bypass normal controls.
ATT&CK does not provide official detection guidance for this object, and the supplied fields do not include specific indicators, tools, or guaranteed analytic logic. Detection and mitigation quality depends on local network architecture, logging depth, approved proxy/VPN usage, and visibility into network devices and WAN boundaries.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Multi-hop Proxy
Adversaries may chain together multiple proxies to disguise the source of malicious traffic. Typically, a defender will be able to identify the last proxy traffic traversed before it enters their network; the defender may or may not be able to identify any previous proxies before the last-hop proxy. This technique makes identifying the original source of the malicious traffic even more difficult by requiring the defender to trace malicious traffic through several proxies to identify its source.
For example, adversaries may construct or use onion routing networks – such as the publicly available Tor network – to transport encrypted C2 traffic through a compromised population, allowing communication with any device within the network.CitationOnion Routing Adversaries may also use operational relay box (ORB) networks composed of virtual private servers (VPS), Internet of Things (IoT) devices, smart devices, and end-of-life routers to obfuscate their operations.CitationORB Mandiant
In the case of network infrastructure, it is possible for an adversary to leverage multiple compromised devices to create a multi-hop proxy chain (i.e., Network Devices). By leveraging Patch System Image on routers, adversaries can add custom code to the affected network devices that will implement onion routing between those nodes. This method is dependent upon the Network Boundary Bridging method allowing the adversaries to cross the protected network boundary of the Internet perimeter and into the organization’s Wide-Area Network (WAN). Protocols such as ICMP may be used as a transport.
Similarly, adversaries may abuse peer-to-peer (P2P) and blockchain-oriented infrastructure to implement routing between a decentralized network of peers.CitationNGLite Trojan
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.