Cross-source coverage

T1090.003 / ATT&CK

Proxy: Multi-hop Proxy

14 rules across 5 sources.

1 deprecated hidden · include

Showing atomic-IOC rules · back to the default

From MITRE ATT&CK 19.2

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. 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.

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.

Platforms
ESXi · Linux · macOS · Network Devices · Windows
Telemetry
WinEventLog:Sysmondns:queryauditd:SYSCALLNSM:FlowNetfilter/iptablesmacos:unifiedlogmacos:osqueryesxi:esxupdateesxi:vmkernelNSM:Firewallnetworkdevice:syslog

How MITRE says to detect it DET0359

Multi-hop Proxy Behavior via Relay Node Chaining, Onion Routing, and Network Tunneling

Windows Analytic 1020

Suspicious processes (e.g., Tor clients, relays, unknown binaries) launch with sustained encrypted outbound traffic to known anonymity infrastructure (e.g., Tor, I2P), and may relay to additional internal systems via reverse proxying, ICMP tunneling, or socket forwarding.

  • WinEventLog:Sysmon EventCode=3, 22
  • WinEventLog:Sysmon EventCode=1
  • dns:query Outbound resolution to hidden service domains (e.g., `.onion`)

Linux Analytic 1021

Tools such as `tor`, `nglite`, `proxychains`, `chisel`, or custom daemons repeatedly initiate outbound sessions to multiple nodes before final destination. This behavior is abnormal for Linux services outside of VPN, monitoring, or CDN relay contexts.

  • auditd:SYSCALL execve for proxy tools
  • NSM:Flow conn.log + ssl.log with Tor fingerprinting
  • Netfilter/iptables Forwarded packets log

macOS Analytic 1022

LaunchAgents or LaunchDaemons initiate persistent Tor or relay processes that make encrypted outbound connections. May be paired with sandbox bypasses or unsigned executables communicating over SOCKS proxies.

  • macos:unifiedlog process, socket, and DNS logs
  • macos:osquery process_events + launchd
  • macos:unifiedlog forwarded encrypted traffic

ESXi Analytic 1023

Outbound encrypted traffic initiated from hypervisor shell or via VM backdoor mechanisms to relays in VPS infrastructure, especially if traversing multiple nodes before reaching Internet destination. Packet captures or firewall logs show non-VM communication paths.

  • esxi:esxupdate /var/log/esxupdate.log or /var/log/vmksummary.log
  • esxi:vmkernel /var/log/vmkernel.log
  • NSM:Flow Relay patterns across IP hops

Network Devices Analytic 1024

Encrypted traffic or ICMP tunneling from border routers to internal routers or unknown external IPs. Forwarded traffic shows consistent hop-to-hop relaying without matching configured VPN or expected network topology.

  • NSM:Flow Relayed session pathing (multi-hop)
  • NSM:Firewall Outbound encrypted traffic
  • networkdevice:syslog Custom firmware or routing changes

View on attack.mitre.org ↗

chronicle/detection-rules

5 rules
Detection Severity Format
google_safebrowsing_file_contacts_tor_exit_node Critical YARA-L
vt_relationships_file_contacts_tor_ip Critical YARA-L
aws_guardduty_tor_network_activity_detected High YARA-L
gcti_benign_binaries_contacts_tor_exit_node High YARA-L
gcti_tor_exit_nodes High YARA-L

SigmaHQ/sigma

3 rules
Detection Severity Format
DNS Query Tor .Onion Address - Sysmon High Sigma
Query Tor Onion Address - DNS Client High Sigma
Tor Client/Browser Execution High Sigma

splunk/security_content

3 rules
Detection Severity Format
Cisco SA - Access to Anonymizer Services Undefined SPL
TOR Traffic Undefined SPL
Windows TOR Client Execution Undefined SPL

elastic/detection-rules

2 rules
Detection Severity Format
ProxyChains Activity Medium Elastic TOML
Suspicious Utility Launched via ProxyChains Medium Elastic TOML

socfortress/Wazuh-Rules

1 rule
Detection Severity Format
Tor proxy service start detected (potential anonymizing proxy usage) High Wazuh XML

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.