Detect it by identifying victim devices that relay traffic for other systems or accounts. Watch for unusual outbound connections, proxy or tunnelling processes, unexpected port use, sustained relay activity and traffic volumes that do not match user behaviour. Review endpoint, network and identity telemetry together, and isolate devices that show proxy functions without an approved business need.
What Proxy Through Victim Looks Like in Telemetry
proxy through victim is easiest to see as a behaviour pattern, not a single indicator. The key question is whether a victim endpoint is acting as a relay for traffic that should not normally pass through it. That means looking for a mismatch between the device’s usual user activity and the volume, destinations, timing or persistence of the traffic it is carrying.
Endpoint telemetry is often the first clue because the device may run a proxy, tunnelling or forwarding process that is not part of its approved software baseline. Network telemetry then helps confirm whether the host is relaying connections for other systems, especially if the traffic pattern shows sustained forwarding rather than a short-lived remote support or admin session.
Identity context matters too, because the relay may be tied to a user, token or session that should not be able to expose other systems through that device. Pairing endpoint, network and identity views makes it easier to distinguish legitimate remote access from a compromised host being used as an intermediary.
Signals That Usually Deserve Triage
Start with unusual outbound connections from the suspected victim, especially when the destination set, ports or session duration do not align with normal application use. Unexpected listening ports, local proxy listeners, SOCKS-like behaviour, port forwarding tools and tunnelling utilities are all worth checking when they appear on a user workstation or server that has no business need for them.
Traffic shape is just as important as process names. A device that suddenly forwards a steady stream of traffic, shows repeated relays to the same upstream node, or carries traffic volumes that are disproportionate to the user’s role can indicate proxy use. If the host also shows authentication events, session reuse or other account activity that does not line up with the endpoint’s normal owner, the case is stronger.
For deeper validation, compare the candidate host against its peer group. A workstation that behaves like an edge relay, or a server that begins carrying traffic patterns associated with an access gateway, should stand out clearly when you compare it with similar assets on the same segment.
How to Confirm It and Contain the Blast Radius
Confirmation usually requires correlating process lineage, network flows and access logs. Security teams should look for the executable or script that enabled forwarding, whether the relay was established manually or through automation, and whether the traffic includes multiple internal sources or destinations that the host should not normally bridge. If the relay is active, treat the device as part of the access path, not just the endpoint.
A practical containment decision is to isolate the host first when the proxy function is not authorised. That prevents further relaying while preserving evidence. If the same account, token or remote session appears across multiple systems, widen the scope to include those sessions and related identities so you can see whether the proxy behaviour is part of a broader compromise path.
When the environment uses common offensive or dual-use relay tooling, the detection content in MITRE ATT&CK Enterprise Matrix can help map the observed relay behaviour to technique-level hunting questions, while CWE Top 25 Guide is useful when the proxy path exists because of an underlying software weakness or unsafe configuration in the affected application or service.
Risk and Threat Considerations
Proxy Through Victim is risky because it turns an ordinary host into a trust bridge. That can hide the real origin of traffic, expand an attacker’s reach into internal networks and make the victim device part of a persistence or lateral movement path. It also complicates attribution because the relay can make malicious traffic look like it came from a legitimate endpoint.
Failure mechanism: A compromised or abused endpoint accepts or forwards traffic it was not meant to carry, often through a proxy, tunnelling or port-forwarding process that creates an unauthorised relay path. If defenders only watch destination traffic and not the relaying host’s process and session behaviour, the abuse can persist unnoticed.
Impact: The relay can expose internal services, extend attacker access, distort audit trails and make containment harder because blocking the visible destination may not stop the actual access path. In a larger environment, one victim acting as a proxy can also become a reusable foothold for repeated access.
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 CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1090 — Proxy | Proxy Through Victim is a proxying and relay behaviour pattern. |
| Recommendation — Map relay activity to proxy techniques and hunt for related lateral movement. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detection depends on correlating endpoint, network and identity logs. |
| Recommendation — Centralise and review endpoint, network and identity telemetry for relay anomalies. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find events | The question is about detecting suspicious traffic relay activity in the environment. |
| Recommendation — Monitor network flows for hosts acting as unexpected relays or proxies. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Detecting proxy-through-victim requires analysis of correlated audit and flow records. |
| SI-4 — System Monitoring | Endpoint and network monitoring are central to spotting unauthorised proxy behaviour. | |
| Recommendation — Analyze audit records for unexpected relay patterns and investigate anomalies. Monitor hosts for unexpected proxy, tunnelling, and forwarding activity. | ||
Practitioner Guidance
What to verify: Confirm whether the host has an approved business need to proxy or tunnel traffic. If not, treat the behaviour as suspicious even if the device is otherwise “healthy” from an endpoint-protection perspective.
What to prioritise: Correlate endpoint process data with flow records and identity activity before deciding the event is benign. The strongest evidence is a matching picture across all three layers, not any single indicator on its own.
Decision rule: If the host is relaying traffic outside its normal role, isolate it and scope adjacent sessions or accounts immediately. If the relay is part of an approved remote-access workflow, validate the owning team, the change record and the expected traffic pattern before closing the alert.
Practitioner takeaway: Proxy detection works best when teams hunt for a role mismatch, not just a malware signature, because a victim can become a relay long before the broader compromise is obvious.