WPAD
WPAD (Web Proxy Auto-Discovery Protocol) is a protocol used by devices (especially Windows clients) to automatically detect proxy server settings on a network. It allows web browsers and other clients to locate a proxy configuration file (usually a PAC file) without user interaction.
🔧 How WPAD Works:
Client joins a network and wants to access the internet.
It tries to discover a proxy by looking for a PAC file at:
The client can find
wpad.dat
using:DHCP Option 252 (if configured)
DNS — the most common method.
If successful, the client configures itself to use the proxy defined in that file.
💀 Why Is WPAD Dangerous?
Attackers abuse WPAD for credential theft and NTLM relay attacks:
If
wpad.domain.com
is not registered, an attacker can:Register it on a public DNS (for external attacks).
Set up a fake DNS server or poison local DNS (for internal attacks).
The attacker sets up a malicious proxy server and hosts a fake
wpad.dat
.Windows clients automatically authenticate to the proxy using NTLM.
This allows the attacker to capture or relay NTLM credentials (e.g., using
ntlmrelayx.py
).
🔥 Example Attack Flow:
Attacker sets up fake DNS that resolves
wpad.company.local
to their IP.Victim connects and fetches
wpad.dat
.Victim’s system tries to authenticate via NTLM to the proxy.
Attacker captures and relays the authentication to a target (e.g., LDAP server).
If successful, attacker can escalate privileges or extract sensitive info.
✅ Mitigations:
Disable WPAD on endpoints.
Block WPAD DNS lookups for unregistered subdomains.
Configure Group Policy to prevent automatic proxy detection.
Enforce LDAP/SMB signing and disable NTLM where possible.
🏢 Active Directory Scenario: WPAD Abuse + NTLM Relay
Imagine you're on a Windows domain (AD) network — say, marvel.local
.
👥 Characters in the Scene:
Domain Controller (DC)
dc.marvel.local
192.168.138.136
Victim (domain-joined client)
victim.marvel.local
DHCP-assigned
Attacker
attacker.kali
Fake DNS & WPAD server
🧠 What Happens Normally with WPAD in AD?
A Windows client, like
victim.marvel.local
, tries to auto-discover proxy settings.It sends a DNS request:
If
wpad.marvel.local
doesn’t exist, it fails silently.
BUT...
💀 What Happens When an Attacker Exploits This?
🔓 Misconfig 1: No wpad.marvel.local
exists in DNS
wpad.marvel.local
exists in DNS🔓 Misconfig 2: Clients are allowed to auto-authenticate using NTLM
🔓 Misconfig 3: Services like LDAPS or SMB don’t require signing
💣 Attacker Steps (NTLM Relay via WPAD in AD):
Attacker sets up fake DNS or IPv6 takeover that resolves
wpad.marvel.local
to their own IP.Victim’s Windows machine auto-requests the PAC file from:
Attacker’s server responds with a malicious PAC file that says:
Victim’s browser or system sends traffic through attacker’s proxy.
Windows auto-authenticates to this proxy using NTLM.
Attacker captures the NTLM handshake.
Attacker relays NTLM credentials to the domain controller (
dc.marvel.local
) over LDAP or SMB usingntlmrelayx.py
.
🔓 If the DC doesn’t require LDAP signing:
Attacker can:
Dump user info
Add a new domain admin
Enable RDP on any machine
Persist in AD
🛡️ Defense for AD Admins:
Create a DNS A/AAAA record for wpad.marvel.local
Prevent attackers from registering or spoofing it.
Disable auto proxy discovery via GPO
Prevents clients from trying WPAD at all.
Enforce LDAP and SMB signing
Blocks NTLM relay.
Disable NTLM if possible
Eliminates the core of the attack.
Enable Extended Protection for Authentication (EPA)
Requires server identity verification.
🎯 Summary:
WPAD
Used to trick Windows into auto-authenticating
NTLM
Authentication protocol that can be relayed
ntlmrelayx.py
Tool to catch and relay the NTLM handshake
LDAP (LDAPS)
Target service that gets impersonated authentication
AD
The final victim of relayed credentials
Last updated