What are the signs that a WPAD attack is active in an environment?

What an active WPAD attack looks like in telemetry

A live WPAD attack usually shows a pattern, not a single event. The strongest clue is repeated attempts to fetch a proxy auto-discovery file from places that should never serve it, along with DNS and web proxy activity that follows that discovery path. A normal client should resolve proxy discovery only inside the expected network boundary, not from public infrastructure or unfamiliar hosts.

Look for the relationship between name resolution, HTTP requests, and proxy behavior. If a host begins querying WPAD-related names and then starts sending web traffic through a different proxy chain, that sequence is more important than any one request on its own. The attack is often revealed by the environment suddenly treating an attacker-controlled proxy as the trusted path.

Operationally, the event often presents as a change in client behavior without a corresponding change request. Browser or system proxy settings may appear altered, auto-discovery may be retried repeatedly, and multiple machines may begin hitting the same suspicious discovery target. That repetition matters because WPAD abuse depends on clients trusting the discovery result more than the user would expect.

Why the discovery pattern matters more than the file itself

WPAD is risky because it turns automatic proxy discovery into an access-control and traffic-steering decision. If an attacker can influence where a client looks for credential and proxy-steering behavior in ATT&CK-style attack paths, they can redirect web sessions, intercept authentication material, or degrade visibility by forcing traffic through a malicious proxy. The attack signal is therefore a chain of discovery, resolution, and redirection.

Unexpected PAC retrievals from external addresses are especially suspicious because they imply the client accepted discovery outside the intended network. That is a stronger warning than a one-off failed lookup. In practice, repeated retrieval attempts can indicate either active exploitation or an environment that is misconfigured enough to be exploitable, and both conditions deserve immediate attention.

Where the environment relies on proxy-based inspection, the impact can extend beyond a single browser session. A successful WPAD abuse path can affect logging, web filtering, authentication prompts, and the trust boundary around outbound traffic. CISA threat advisories are useful when you need to compare the observed pattern with active campaign behavior or broader exploitation context.

How to separate benign proxy discovery from compromise

Start with the source and destination of the discovery request. A benign environment usually shows a small, predictable set of internal resolvers, standard proxy infrastructure, and stable PAC retrieval behavior. Suspicion rises when the host queries unexpected names, falls back through multiple discovery methods, or reaches an address space that does not match the client’s normal network segment.

Then validate whether the proxy result changed the actual routing path. If the endpoint begins using a new proxy IP, receives a PAC file from an unfamiliar server, or shows web sessions traversing a proxy that was not approved, treat the discovery result as actionable evidence. The key question is whether the discovery outcome changed control of outbound traffic, not whether the PAC file content looks obviously malicious.

At scale, the pattern becomes more useful than any one endpoint. Multiple hosts resolving WPAD names at the same time, or the same host repeating the behavior after reboot or network reconnect, suggests an environment-wide trust problem rather than a user error. That distinction helps decide whether you are dealing with an isolated incident, a poisoned discovery path, or a broader proxy configuration issue.

Risk and Threat Considerations

WPAD attacks are dangerous because they sit at the intersection of trust and traffic redirection. If clients can be pushed toward an attacker-controlled discovery endpoint, the attacker may see authentication handshakes, harvest session data, or steer users through a proxy that changes what the environment can observe.

Failure mechanism: The client accepts a discovery response from an unexpected source, then uses that response to route web traffic through a proxy the organisation did not intend to trust.

Impact: Web sessions can be intercepted, visibility can be reduced, and the same mechanism can be used to support credential capture, phishing, or lateral compromise inside the network.

Practitioner Guidance

What to verify: Confirm whether the suspicious request path is internal-only, whether the PAC source matches an approved proxy discovery design, and whether the affected host actually switched proxies or merely attempted discovery. A lookup alone is not enough; the routing change is what turns the signal into a response priority.

Decision rule: If the client retrieved wpad.dat from an external or unfamiliar source, treat it as active abuse or a severe trust-breach condition until proven otherwise. Contain the host, review DNS and proxy logs, and check for other endpoints showing the same pattern before assuming the event is isolated.

Practitioner takeaway: The most useful WPAD indicator is not the presence of proxy discovery traffic, but discovery traffic that escapes the expected trust boundary and changes how outbound web traffic is routed.

Related resources from NHI Mgmt Group

• What are the signs that an F5 management environment may be under active attack?
• What are the signs that a checkout skimmer is still active in a WordPress environment?
• What are the signs that identity controls are failing during an active attack?
• What are the signs that an Azure environment is failing to keep its attack surface under control?