Reduce the risk by detecting local proxying, remote control tools, and unexpected network relays on endpoints and mobile devices. Attackers may use a compromised device to relay traffic, hide command-and-control activity, or reach internal services. Limit administrative privileges, inspect outbound connections, and alert on unusual tunnelling or forwarding behaviour.
How Proxy Through Victim Works in Practice
proxy through victim is not just a hidden channel, it is a control-bypass pattern. The attacker turns an endpoint or mobile device into a relay so traffic appears to come from a legitimate user or device, which can mask command-and-control, access internal services, or blend in with normal business traffic. That makes the relay path itself the object you need to detect and contain.
The practical challenge is that the victim device may still look healthy at a glance. Remote support tools, local proxy processes, forwarding rules, VPN-like relays, and browser or system settings can all be abused to move traffic through the device without obvious malware symptoms. The risk rises when the endpoint has broad network reach, trusted network placement, or credentials that let the attacker pivot beyond the initial compromise.
Detection has to focus on behaviour, not just binaries. Unusual listener ports, unexpected outbound tunnels, DNS or HTTP requests that do not match the user's normal profile, and proxy settings that change outside approved management workflows are all signals worth correlating with endpoint telemetry and network logs.
What Mitigations Actually Reduce the Relay Path
The most effective mitigation is to shrink the amount of trust the endpoint can lend to anything running on it. Restrict local administrator rights, harden browser and system proxy configuration, and deny unauthorised remote-control and tunnelling tools where business need does not exist. That reduces the chance that a compromised device can be repurposed as a relay.
Network controls should be aligned to the same goal. Inspect outbound connections for unusual CONNECT behaviour, proxy chaining, and traffic patterns that do not fit the device role. If a workstation is suddenly forwarding traffic to an internal service or to an unfamiliar external endpoint, the issue is not merely connectivity, it is likely a sign of hostile use of the device as a transport layer.
For mobile devices, the same principle applies but the control surface shifts. Review MDM policy for proxy settings, VPN profiles, app permissions, and any tooling that can create forwarding or remote-access paths. If the device can bridge trusted and untrusted networks, treat that capability as a security function that must be explicitly approved, logged, and monitored.
When Patching Alone Is Not Enough
Proxy-through-victim cases often persist even after the initial foothold is removed, because the attacker may have left behind altered network settings, remote admin tools, service persistence, or cached access tokens. A clean patch does not necessarily remove the relay path if the configuration change remains or the device was used to reach other systems before detection.
That means mitigation needs a containment mindset as well as a remediation mindset. Validate whether the proxying behaviour involved credential use, session hijacking, or access to internal services, then decide whether you need to rotate exposed secrets, invalidate sessions, or reimage the endpoint. If the device acted as a bridge into privileged environments, scope the review to lateral movement and internal reconnaissance, not just the endpoint itself.
Risk and Threat Considerations
Proxying through a victim is attractive because it turns a trusted device into cover. The attacker benefits from the victim's network position, reputation, and reach, while defenders may mistake the resulting traffic for routine user activity or sanctioned remote access.
Failure mechanism: The compromise survives as a transport layer, through local proxy settings, remote-access tooling, forwarding rules, or tunnel creation that redirects traffic without changing the visible business function of the endpoint.
Impact: The attacker can hide command-and-control, reach internal resources, evade IP-based blocking, and extend access beyond the original compromise. In mature environments, this can become a path to internal reconnaissance and lateral movement if the relay device has privileged reach.
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 NIST CSF 2.0, CIS Controls v8 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 traffic-relay technique. |
| Recommendation — Detect proxying and relay behaviour, then hunt for tunneled command-and-control and pivot paths. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potentially adverse events | The mitigations rely on monitoring relay, tunnel, and abnormal outbound network behaviour. |
| Recommendation — Monitor outbound traffic and relay patterns for anomalous tunnelling or forwarding. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Proxy settings, forwarding rules, and remote-access tools need hardened approved configurations. |
| Recommendation — Harden endpoint and mobile proxy-related settings and remove unauthorised remote-access tooling. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Limiting admin rights reduces the ability to install or abuse proxy and tunnelling tools. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Reviewing logs is central to spotting abnormal proxy use and relay activity. | |
| Recommendation — Restrict administrative privileges that could enable covert relay tooling. Review endpoint and network logs for unusual proxying and forwarding events. | ||
Practitioner Guidance
What to verify: Confirm that endpoint and mobile telemetry can distinguish approved remote support from unauthorised proxying. The practical test is whether you can explain every forwarding or relay event by policy, ticket, or managed tool inventory.
Decision rule: If the device can authenticate to internal services, relay traffic for others, or carry administrative reach, treat unexplained proxy behaviour as a high-priority security event and not as a benign networking issue.
What practitioners underestimate: The most dangerous relay is often quiet and short-lived. A brief tunnel, temporary proxy setting, or one-off remote-control session can be enough to create exposure, so the investigation should preserve network and endpoint evidence before cleanup begins.
Practitioner takeaway: The goal is not just to block malware, it is to prevent a compromised endpoint from becoming a trusted transport path that can conceal access, amplify reach, or move an attacker deeper into the environment.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org