Demistifying Responder WPAD Authentication module:

One of the most successful modules in Responder is the WPAD server.

The WPAD functionality can be boiled down this way, there's two issues:

• WPAD MITM: Anyone on an ISP (like qc.ca) plugged direcly into the modem (WAN), and therefore on the internet, will be vulnerable if someone creates a wpad.qc.ca domain and serve a wpad.dat file to the people looking for it.

  The Web Proxy Autodiscovery Protocol is looking for WPAD.domain.name by default, if there's no answer then it will fall back to Multicast LLMNR and if that fails it will go to broadcast NBT-NS.

•  WPAD file retrieval: Responder is exploiting the fact that in the Web Proxy Autodiscovery Protocol, HTTP authentication is allowed and supported. Therefore if a workstation is looking for "WPAD" via LLMNR or NBT-NS and someone answers it (multicast/broadcast) using a rogue HTTP authentication server, that workstation will send transparently its sets of credentials.

If a workstation boots up, the machine credentials will be sent. If a user opens up IE on that workstation, Responder will get the encrypted sets of credentials transparently, with obviously no user interaction and no logs. Therefore, no logs no crime, right?
What I just described is the stealthiest way of exploiting and getting encrypted sets of credentials on any workstations ranging from Windows 2000 to 2012R2.