Reduce this risk by blocking unauthorised proxy use and forcing traffic through approved egress controls. Restrict proxy configuration changes, watch for unexpected proxy settings in browsers and system tools, and inspect outbound traffic for relays that hide the real destination. Remove unused proxy software and credentials.
How External Proxy abuse works
External proxy abuse is a traffic-relay problem: an unauthorised proxy becomes the path between a client and the internet, so the organisation loses visibility into the real destination and may inherit a trust boundary it did not approve. The practical issue is not just browsing through a proxy, but covert redirection of outbound traffic through infrastructure the defender did not intend to trust.
That matters because proxy abuse can be used to bypass egress policy, hide command-and-control style relays, or make sanctioned controls look like they are working when they are actually being bypassed. The same pattern also shows up when software silently adds proxy settings, when local tools honour attacker-controlled environment variables, or when users install helpers that alter network routing.
In practice, the security question is whether outbound requests are being forced through approved inspection points or quietly diverted around them. A good defensive model is to treat proxy configuration as a controlled network path, not a convenience setting that endpoint users or applications can freely change.
Controls that reduce proxy abuse
The most effective mitigation is to make approved egress the default and anything else an exception. Block unauthorised proxy use at the network and endpoint layers, lock down who can change proxy settings, and prevent applications from honouring arbitrary proxy configuration unless the business case is explicit and audited.
Complement that with integrity checks on the places attackers tend to tamper with first: browser proxy settings, system proxy settings, startup scripts, shell profiles, service configuration, and enterprise management policies. If proxy use is legitimate, centralise it so the expected proxy, certificate trust path, and logging point are consistent across managed devices.
Detection also matters. Inspect outbound traffic for relays, unusual destination chaining, and proxy-like patterns that do not match standard user or application behaviour. When traffic is leaving through an approved proxy, the control should still preserve observability into where the session is actually going.
When proxy abuse signals a broader compromise
Proxy abuse often appears alongside persistence and concealment activity. If an endpoint suddenly begins using a new proxy, or if a service starts sending traffic through an unexpected relay, assume the change may be deliberate until proven otherwise. Remove unused proxy software and review whether any credentials, tokens, or management accounts tied to proxy tooling were exposed or abused.
Failure mechanism: an attacker or unauthorised user changes proxy settings, installs proxy-capable software, or abuses an existing relay so outbound traffic is redirected away from normal monitoring and policy enforcement. That creates a blind spot, weakens destination verification, and can preserve access even after the initial foothold should have been removed.
Impact: traffic can be exfiltrated, command-and-control can be masked, policy can be bypassed, and incident responders may lose the source-to-destination trail they need to confirm what happened and scope the exposure.
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 SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1090 — Proxy | Proxy abuse is the core mechanism for relaying outbound traffic and hiding the real destination. |
| Recommendation — Map unexpected proxy use to T1090 and hunt for relay activity in endpoint and network telemetry. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | External proxy abuse is a boundary-enforcement problem that redirects information flow outside approved paths. |
| CM-6 — Configuration Settings | Proxy abuse often depends on unauthorized changes to browser or system proxy configuration. | |
| AU-12 — Audit Generation | Detecting covert proxies depends on auditable outbound traffic and configuration changes. | |
| Recommendation — Enforce AC-4 to constrain outbound traffic to approved egress paths and inspection points. Apply CM-6 to lock proxy configuration and restrict who can change it. Use AU-12 to generate logs for proxy changes and outbound relay patterns. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Approved egress and least-privilege path control are central to resisting proxy-based path abuse. |
| Recommendation — Apply Zero Trust principles to require explicit trust and verification for outbound connections. | ||
Practitioner Guidance
What to verify: Confirm which endpoints, browsers, and managed applications are allowed to use a proxy, and verify that those paths are enforced centrally rather than by user choice. If a system can reach the internet through a proxy that your team cannot observe or control, treat that as a control gap.
Decision rule: If proxy settings are user-editable, shift to policy-enforced egress and remove local freedom; if proxy use is operationally required, narrow it to approved software and authenticated infrastructure only. When abuse is suspected, prioritise restoring trusted egress and collecting traffic evidence before making broad endpoint changes.
Practitioner takeaway: The key judgement is whether outbound traffic is still ending where your controls expect it to end. If you cannot verify the relay, you do not really control the path.
Related resources from NHI Mgmt Group
- Guide: Command and Control (C2) Guide
- How should teams reduce the risk of exposed AI credentials being abused?
- What is the difference between prompt injection risk and identity abuse in agents?
- How should teams reduce risk from malicious npm package installs?
- How should security teams reduce initial access risk from phishing campaigns that abuse cloud redirectors and external file shares?
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 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org