PAC distributed via WPAD DNS discovery
medium
WPAD clients look for wpad.<suffix>, strip one label and retry up to wpad.<tld>. If no internal record answers, a registered public wpad name can supply the PAC. Own the name, block the walk at the resolver, prefer explicit configuration.
Why it matters
A client in pc.eng.corp.example asks for wpad.eng.corp.example, then wpad.corp.example,
then wpad.example. The last steps leave the organisation’s namespace; several public
wpad.<tld> names have been registered and the 2016 US-CERT alert on WPAD name collision
documents the hijack. The discovery URL is also always plain http (PAC-D001). Mitigations:
make sure every internal suffix has an authoritative wpad record (or an explicit NXDOMAIN
via RPZ), block wpad.* resolution to the internet at the resolver, and distribute the PAC
URL explicitly through GPO/MDM so that discovery is not needed at all.
How to fix
Distribute the PAC URL explicitly (GPO/MDM); block wpad.* queries beyond your own zones at the resolver; disable WPAD where it is not needed.
Examples
Good
# explicit AutoConfigURL from GPO/MDM; WPAD disabled
https://pac.corp.example/proxy.pac
Related rules
- PAC served over plain HTTP PAC-D001
- PAC URL distributed via DHCP option 252 PAC-D008