Attackers use a Proxy Auto-Config file to redirect traffic through a malicious proxy, capture credentials, or selectively bypass security controls. If they can alter the file or the server hosting it, they can change how browsers and some clients choose proxies. Defenders should monitor PAC file integrity, control distribution sources, and investigate unexpected proxy changes or authentication prompts.
How PAC files become an attack path
A PAC file is a browser and client-side routing rule set. Attackers abuse it by changing which proxy a client trusts, so outbound web traffic can be diverted through infrastructure they control, inspected, or made to skip the intended security path. That makes the PAC file itself part of the trust boundary, not just a convenience setting.
The practical danger is that the PAC logic is often evaluated automatically and quietly. If an attacker can modify the file, the hosting server, or the distribution path, they can influence traffic selection without changing the browser configuration in an obvious way. That can affect web filtering, logging, authentication flow, and which destinations are actually reached.
In environments that rely on explicit proxying, secure web gateway and web filtering guidance matters because PAC behavior can determine whether policy is enforced or bypassed at the client edge.
What attackers do after they control PAC logic
Once a malicious PAC file is in place, attackers can steer some destinations to a proxy under their control and leave other traffic untouched to avoid immediate detection. That selective behavior helps them harvest credentials, observe browsing activity, or route only high-value requests through the malicious path while normal traffic appears unchanged.
Attackers also use PAC manipulation to create selective bypasses. For example, they may force traffic for security tools, update servers, or inspection endpoints to go direct, while sending sensitive user traffic through the rogue proxy. This kind of selective routing is useful because it preserves access while weakening monitoring and control points.
Where proxy steering is part of the architecture, the broader SASE and SSE guide helps explain why client-side proxy decisions can undermine centralized inspection if the PAC source is not tightly governed.
A PAC compromise is often paired with credential capture. If the malicious proxy triggers authentication prompts or sits in the middle of normal sign-in traffic, the attacker can collect reusable credentials, session data, or tokens exposed by weak client handling. The PAC file is then not just a routing artifact, it becomes a delivery mechanism for downstream access abuse.
Why PAC abuse is hard to notice
PAC abuse can look like a routine connectivity change, which is why it is attractive to attackers. A user may only see slower browsing, intermittent proxy prompts, or strange site-specific failures, while the real issue is that the client is being instructed to use an attacker-controlled proxy or to evade the intended inspection path.
Because PAC logic can be cached or fetched from a central location, compromise can persist even after the endpoint itself is cleaned. If the hosting service remains altered, clients will continue to retrieve hostile routing rules until the source is corrected and the trust chain is re-established.
For teams that want the root-cause lens on common web abuse patterns, the CWE Top 25 Guide is useful for mapping misconfiguration and externally controlled configuration problems to their broader weakness classes.
Risk and Threat Considerations
PAC files sit in a sensitive control plane because they can decide which traffic is inspected, proxied, or bypassed. If an attacker changes that logic, the result is not just traffic redirection, it can be loss of visibility, credential interception, and policy evasion at scale across every client that trusts the PAC source.
Failure mechanism: The attacker alters the PAC file, the PAC hosting location, or the distribution mechanism so the client resolves proxies from hostile logic instead of approved policy. That allows selective routing, proxy impersonation, or direct-connection bypass of security controls.
Impact: Web traffic may be diverted to malicious infrastructure, credentials may be captured, and logging or filtering may miss the real destination or the real path taken by the session.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | PAC files are configuration logic that can redirect or bypass traffic controls. |
| Recommendation — Harden and monitor PAC distribution sources and review changes as configuration drift. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | PAC compromise depends on unauthorized changes to routing configuration or hosting. |
| SI-4 — System Monitoring | Unexpected proxy changes and altered routing are detectable security events. | |
| AU-2 — Event Logging | PAC and proxy changes need audit trails to support incident review and attribution. | |
| Recommendation — Restrict who can modify PAC files and their hosting locations. Monitor PAC updates, proxy selection changes, and related anomalies for investigation. Log PAC file changes and proxy-resolution events for later investigation. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | PAC files and proxy sources are security-relevant configuration items. |
| Recommendation — Control and review PAC configuration changes through formal change management. | ||
Practitioner Guidance
What to verify: Confirm where the PAC file is hosted, who can change it, how clients fetch it, and whether the file is protected by integrity checks or configuration management. Treat unexpected PAC edits or new PAC distribution paths as security-relevant changes, not routine admin noise.
What to prioritize: Investigate unexplained proxy prompts, sudden routing changes, or any case where users report that some sites behave differently from the rest of their traffic. Those are often the most visible signals that the PAC source, not the endpoint, has been manipulated.
Practitioner takeaway: The key question is whether the PAC source is a trusted policy artifact or an externally mutable dependency, because once attackers control it, they can shape traffic flow before most endpoint and network controls ever see the session.