D3-RPA Relay Pattern Analysis: Spotting Internal Hosts That Relay Attacker Traffic

An attacker who controls one internal host can turn it into a relay, so traffic from outside reaches deeper systems, or data leaves the network, through a machine that looks like any other internal client. MITRE D3FEND names the countermeasure Relay Pattern Analysis (D3-RPA), with the synonym Relay Network Detection, and defines it as "The detection of an internal host relaying traffic between the internal network and the external network." It sits under the Detect tactic as a child of Network Traffic Analysis and analyzes the Outbound Internet Network Traffic artefact. This card covers how relay detection works, which ATT&CK techniques D3FEND relates to it, the host and network evidence that supports it, how to test it and where it breaks. It is for detection engineers and threat hunters; the attacker side is covered in the T1090 Proxy Defensive Guide.

Key takeaways

• A relay mirrors traffic. D3FEND's analytic compares sessions across hosts: a relay receives on one side and sends on the other, so its inbound and outbound sessions have closely matching byte counts, start times, packet sizes and arrival patterns.
• Timing variance is the tell. D3FEND's analysis of its reference patent notes that relayed connections show a high degree of variance in inter-packet arrival times compared with ordinary client-to-server connections.
• Encapsulation breaks it. D3FEND warns that complex intranet VPNs, routing encapsulation, dropped packets and packets added at the relay all complicate detection.
• Host evidence closes the gap. Network pattern analysis finds candidate relays; host artefacts such as port proxy rules, enabled IP forwarding and per-process network events confirm them.
• The ATT&CK links are inferred. D3FEND relates D3-RPA to command and control, proxy and exfiltration techniques through Outbound Internet Network Traffic; they show where relay analysis can help, not guaranteed coverage.

D3-RPA at a glance

How it works

D3FEND explains that a relay can use proxying, forwarding or routing to bridge a protected network and an external network. The analytic compares network sessions among multiple hosts: hosts with nearly matching network statistics may form a relay. The statistics named are bytes sent to and from, session start time, packet size and packet arrival time.

D3FEND's analysis of the Vectra patent describes the threat model: an attacker outside the organisation takes control of an internal host and uses it as a source of attacks against other internal targets, or to move data out. Session metadata is extracted from packet captures, sessions are categorised using known relay behaviours, and when enough evidence of relay behaviour builds up for one internal host, that host is flagged and an alert is raised.

A practical relay analytic looks for pairs of sessions on the same internal host where:

• Time aligns: an inbound or internal session and an outbound internet session start within a short window of each other and stay open together.
• Volumes mirror: bytes received on one leg roughly match bytes sent on the other, in both directions, allowing for protocol overhead.
• Timing jitters: inter-packet arrival times on the outbound leg vary more than for the same host's normal client traffic, because each packet waits on the other leg.
• Role does not fit: the host is a workstation, server or appliance that has no business acting as a proxy, gateway or jump host.

Host evidence that confirms a relay

Network correlation produces candidates. Host artefacts turn a candidate into a finding. The table lists documented settings and events; collect them before you need them.

The Volt Typhoon advisory also describes the external side of the same pattern: compromised end-of-life SOHO routers and virtual private servers used to proxy command and control, and multi-hop proxies as a long-standing habit. See the Volt Typhoon Threat Actor Profile.

ATT&CK techniques D3FEND relates to D3-RPA

Relationship type: inferred only. D3FEND relates these techniques to D3-RPA because D3-RPA analyzes Outbound Internet Network Traffic, which these techniques produce (D3FEND 1.6.0, checked November 2026). Rows with sub-technique IDs come from D3FEND's table; D3FEND lists the parent techniques in the second table by name only, and their IDs were added from ATT&CK. Every ID was checked against ATT&CK v20.

For the channel techniques, see the T1572 Protocol Tunnelling Defensive Guide and T1567 Exfiltration Over Web Service.

Implementation steps

1. Get both legs in view. A relay is only visible if the same data set holds the internal leg (user segment, server segment or VPN) and the internet leg. Place sensors or collect flows at both internal choke points and the egress, and synchronise time on all sources.
2. Inventory legitimate relays. Record approved proxies, NAT gateways, jump hosts, load balancers, VPN concentrators and developer tunnels. These are the peer group that should relay; everything else should not.
3. Build the session pairing analytic. Pair sessions on the same host by time overlap, then score volume mirroring and timing variance. Start with long-lived sessions, where the pattern is clearest.
4. Add host signals. Collect Windows port proxy configuration and Sysmon Event ID 3, Linux forwarding settings and firewall NAT rules, and use them to confirm or dismiss network candidates.
5. Pilot in alert-only mode. Expect early hits from undocumented tunnels, remote support tools and developer port forwarding. Each one is either documented as approved or removed.
6. Write the response. A confirmed relay means a compromised or misused host. Isolate it, capture its configuration and connection tables, identify what reached it from inside and what it reached outside, and rotate any credentials used through it.
7. Roll back safely. The analytic is detective; rollback means disabling or re-thresholding it. Containment actions follow the incident process, not the analytic.

Where identity fits

Relays carry authentication as well as data. A relay host in front of a domain controller, database or management interface lets an outside operator use stolen service account passwords and tokens as if from inside the network, which defeats IP-based allow lists. When a relay is confirmed, treat every credential that crossed it, including service accounts and API keys, as exposed. See the MITRE ATT&CK T1550 Use Alternate Authentication Material Guide.

How to verify it works

• Lab relay test: on an isolated test host, configure an approved port forward and send traffic through it from a test client to a test internet endpoint. Confirm the analytic pairs the sessions and names the host.
• Purple team exercise: include an authorised relay or proxy step in adversary emulation and record whether it was detected and how long it took.
• Host signal test: create a harmless port proxy rule on a test Windows host and enable forwarding on a test Linux host; confirm both changes are collected and alerted.
• Coverage review: list network segments where only one leg is visible; these are blind spots for D3-RPA.

Limits, bypasses and failure patterns

• Encapsulation and VPNs: D3FEND notes that complex intranet VPNs and routing encapsulation affect the analytics; traffic inside a tunnel cannot be paired by size or timing as easily.
• Traffic shaping at the relay: D3FEND also notes that unwanted packets may not be forwarded and extra packets may be added, which breaks volume mirroring. Batching or padding on the relay has the same effect.
• Single-sensor visibility: an egress-only sensor sees the outbound leg but not the internal one, so relays look like ordinary clients.
• Approved tools hide unapproved use: remote support tools and developer tunnels relay by design. If they are excluded wholesale, an attacker using the same tool is excluded too.
• Edge devices outside telemetry: compromised routers and appliances relay traffic without endpoint agents, and their logs are often not collected. See the VPN and Firewall Log Detection Guide.
• Internal-only relays: D3-RPA is defined for internal-to-external relays. Internal pivoting between segments (Internal Proxy, T1090.001) needs east-west analytics.

Framework mapping

The matching ATT&CK mitigations are covered in M1037 Filter Network Traffic and M1031 Network Intrusion Prevention.

Related countermeasures

• Protocol Metadata Anomaly Detection (D3-PMAD): broader outlier analysis on the same metadata. See D3-PMAD Protocol Metadata Anomaly Detection.
• Network Traffic Community Deviation (D3-NTCD): flags a host that stops behaving like its peers. See D3-NTCD Network Traffic Community Deviation.
• Remote Terminal Session Detection (D3-RTSD): finds remote terminal sessions, often the operator's path to a relay host. See D3-RTSD Remote Terminal Session Detection.
• Network Access Mediation (D3-NAM): limits which hosts may reach the internet at all. See D3-NAM Network Access Mediation.

Practitioner checklist

• Keep a register of approved relays: proxies, NAT gateways, jump hosts, VPN concentrators and tunnels.
• Collect sessions or flows at internal choke points and at egress, with synchronised time.
• Pair sessions on the same host by time overlap and score volume mirroring and timing variance.
• Collect Windows port proxy configuration and enable Sysmon Event ID 3 for relevant hosts.
• Alert when Linux IP forwarding is enabled on hosts that are not routers.
• Bring edge device and SOHO router logs into the same data set.
• Test with an approved lab relay every quarter.
• Treat credentials that crossed a confirmed relay as exposed and rotate them.

Standards and references

• MITRE D3FEND: Relay Pattern Analysis (D3-RPA)
• MITRE ATT&CK: T1090 Proxy
• CISA: Cybersecurity Advisory AA24-038A on Volt Typhoon
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• Microsoft Learn: Netsh interface portproxy commands
• Microsoft Learn: Sysmon
• Linux kernel documentation: IP sysctl

Related NHI Mgmt Group resources: T1090 Proxy Defensive Guide · NDR Guide · Command and Control (C2) Guide · Volt Typhoon Threat Actor Profile · MITRE D3FEND Guide