Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

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

This detection strategy is tied to adversary use of multi-hop proxying: routing command-and-control traffic through chained relay nodes, onion-style paths,...

EnterpriseDET0359Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This detection strategy is tied to adversary use of multi-hop proxying: routing command-and-control traffic through chained relay nodes, onion-style paths, or tunnels so the organization only sees the last visible hop. The business issue is not just anonymous traffic; it is reduced confidence in source attribution, slower incident scoping, and harder decisions about blocking, escalation, and third-party coordination during an intrusion.

Executive priority

Treat this as a resilience and SOC-readiness question: can the organization recognize suspicious command-and-control paths when the apparent source is only a relay? Leaders should ask whether network monitoring, proxy/DNS/VPN logging, and incident response playbooks support fast containment decisions without relying on true origin identification. Because the related ATT&CK technique covers ESXi, Linux, macOS, and network devices, coverage discussions should include infrastructure and appliance telemetry, not only user endpoints.

Technical view

ATT&CK provides no official detection text for DET0359, but the relationship states it detects T1090.003 Multi-hop Proxy under command-and-control. SOC and detection teams should validate whether they can correlate inbound and outbound network sessions, proxy logs, DNS activity, tunnel/VPN indicators, and network-device logs to identify traffic patterns consistent with relay chaining or last-hop proxy use. IR teams should assume the visible source may be incomplete and preserve evidence needed to reconstruct paths across network boundaries.

Likely telemetry

  • Network flow records and firewall connection logs
  • Proxy, secure web gateway, and egress filtering logs
  • DNS resolver query and response logs
  • VPN, tunnel, and remote access logs where present
  • Network device logs from routers, gateways, and edge infrastructure

Detection direction

  • Validate correlation across time, source asset, destination, protocol, and session volume rather than relying only on IP reputation for a last-hop proxy.
  • Tune for suspicious relay-like behavior while accounting for legitimate privacy tools, business VPNs, content delivery networks, security scanners, and managed service provider access paths.
  • Confirm monitoring coverage for the related platforms listed by ATT&CK: ESXi, Linux, macOS, and network devices.
  • Build triage logic that treats the apparent external IP as a possible relay and preserves context needed for IR escalation.
  • Document blind spots where encrypted tunnels, limited flow retention, NAT, or unmanaged network devices prevent path reconstruction.

Mitigation priorities

  • Prioritize egress control and logging so unauthorized outbound tunnels and proxy-like traffic are visible and governable.
  • Maintain an approved inventory of VPNs, proxies, remote access paths, and network tunnels to reduce false positives and accelerate investigations.
  • Harden and monitor network devices and infrastructure platforms that can participate in or observe command-and-control paths.
  • Ensure incident response procedures include evidence preservation for network flows, DNS, proxy, and device logs before retention windows expire.
  • Use detection validation exercises to confirm that chained-proxy scenarios generate actionable alerts and investigation context.
Analyst notes and limits

DET0359 is a detection strategy object with no official ATT&CK description or detection text supplied. The practical interpretation comes from its explicit relationship to T1090.003 Multi-hop Proxy, whose ATT&CK description emphasizes adversaries chaining proxies to obscure the source of malicious traffic and complicate tracing.

Platforms and tactic are not specified on the DET0359 object itself; platform and tactic references come from the related T1090.003 technique. This take does not assert active exploitation, attribution, or guaranteed detection. Local architecture, log retention, encryption, and approved proxy/VPN usage determine actual coverage.

Official MITRE ATT&CK definition

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

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Techniques used

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1090.003 Multi-hop Proxy Sub-technique This object detects Multi-hop Proxy.
Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
ec94451203548f95...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle ec9445120354…
Raw source

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 references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0359
    Open source URL
Source and licensing

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.