There are already some great resources out there explaining vulnerabilities linked to the Web Proxy Auto-Discovery Protocol (WPAD) and Link-Local Multicast Name Resolution (LLMNR) protocol. In this post I will demonstrate an example using WPAD poisoning and Brute Force.
Basically, WPAD is an auto-discovery protocol used by web browsers to search the local network for a proxy auto configuration (PAC) file named wpad.dat. This file is served either by the DHCP server or hosts named “wpad” and contains proxy servers that the web browser should use for different URL’s.
LLMNR on the other hand is a name-resolution component used by Windows operating system. If a DNS query fails because the hostname could not be resolved, LLMNR will take over and query again for the same host on the local network. Let’s say for example when a user mistypes an UNC path (\\mysharre).
Using tools such as Responder, it is possible for an attacker to set up false replies using both of these protocols (Man in the middle attack). This will give the attacker IP addresses, hostnames, usernames and NTLMv2 hashes of the user accounts being spoofed.
The sketchy thing about this is, specifically for the WPAD protocol, is that most modern web browsers have this setting enabled by default, given that they are picking up the default setting from Windows 10 OS (which is enabled).
This includes Edge, Google Chrome and Firefox. Internet Explorer is replicating this setting from Windows 10 settings, so you can turn if off either in IE or in Windows settings.
Windows 10 default proxy settings. 
Internet Explorer. Linked to Win 10 default settings. 
Firefox. Linked to Win 10 default settings.
Demonstration of WPAD poisoning attack using Responder and cracking the hash
Note: This setup was a lab for white-hat testing purposes only.
Responder has been set up with the internal VM interface eth1 and wpad flags. Once a user opens the web browser (Google Chrome in this case), Responder has poisoned the clients request when asking for the PAC (wpad.dat) file. Responder is returning some interesting information:
So we know the user is named JohnDoe on a computer named CLIENT1 with an IP address of 172.28.1.10. The hash itself can now be cracked using either a Brute Force attack or with a wordlist. In this case the hash was saved to a .txt file and bruteforced using hashcat64.
This took about 2-3 mins on a GTX1080 GPU. Pretty fast. Now that we got the credentials, we can perform all sorts of post exploitation activities.
Next article: The dangers of WPAD and LLMNR – Protect your network