Pwning with Responder – A Pentester’s Guide

[Nytro]

May 3, 2017

Overview:

Responder is a great tool that every pentester needs in their arsenal. If a client/target cannot resolve a name via DNS it will fall back to name resolution via LLMNR (introduced in Windows Vista) and NBT-NS. Now, assuming we have Responder running we will essentially say ‘yeah, this is me’ to all of the LLMNR and NBT-NS requests that we see, and then traffic will be directed to us. Great. In this brief overview we shall be touching on a couple of the common uses as well as new functionality recently introduced by @pythonresponder.

Targeting specific host(s):

If you want to target a specific IP/range of IPs, you can edit Responder.conf and change the RespondTo argument. This is extremely useful when you have a specific target in sight and don’t want to potentially cause network-wide disruption. Additionally, it is also possible to specify the NBT-NS/LLMNR name by altering the RespondToName argument, although this is something I have yet to fully experiment with. In the following screenshot we have limited attacks to the host 192.168.10.17.

Listen only mode:

You can use Responder in listen only mode, i.e. analyse, but don’t actively respond to any requests. This can be achieved using the -A parameter and again this is a useful feature to see how chatty the network is without actively targeting any hosts.

Active attacks:

In the following example the attacking IP address is 192.168.10.206 and we are targeting a single host 192.168.10.17 via SMB. This is a common scenario in which a user mistypes the name of a server, hence the DNS lookup fails and name resolution falls back to NBT-NS and LLMNR.

From the above Wireshark output it’s possible to see that 192.168.10.17 sends a NBNS query to the broadcast address 192.168.255.255, and the attacking host 192.168.10.206 immediately replies stating that it is in fact file-share-123 and returns it’s own IP within the response.

It is also possible to see within the Wireshark capture that immediately after the NBNS request/response the same process happens over LLMNR but using the registered multicast address of 224.0.0.252. The keen eyed readers will also see that this process is also performed over IPv6 and the Multicast address of FF02::1:3 is used (details also available from the above link).

The outcome of this is that the victim now believes that we are indeed file-share-123 and attempts to establish communications over SMB (TCP 445). From here we can continue to  steal the NTLMv2 hash for the affected user (in this instance a local user called default) for offline cracking.

And this is the SMB negotiation viewed through Wireshark…

There’s plenty more to play and experiment with in Responder, but for now we’re going to move onto some of the more recent features added to this project.

Multi-relay attacks:

This is one of the newer features that @pythonresponder introduced towards the end of 2016. Using this tool we can relay our NTLMv1/2 authentication to a specific target and then, during a successful attack, execute code. Before we get into the nitty gritty of this attack it should be stated that only privileged users are targeted by default (good reasoning behind this) and the target cannot have SMB signing in place. A nice script RunFinger.py has been packaged within the tools directory of Responder and this allows us to verify the latter on our target(s) before actively targeting any hosts (it will become clear why we are targeting 192.168.11.17 with RunFinger.py instead of 192.168.10.17 shortly).

In preparation of this attack we need to disable the SMB and HTTP servers used by Responder otherwise we’ll get some conflicts between this and Multi-relay (example shown below).

For this following example we’ll disable these specific services within the Responder.conf file by changing the relevant service to “Off”. Job done.

Again, running Responder with default options it is possible to see that these two services are now disabled.

We are now going to poison responses for the victim 192.168.10.17 (as in previous examples), but we are also now going to relay our session authentication to a 2nd host 192.168.11.17.

The syntax for this tool is show below, where the IP is the address to which you want to relay authentication and hopefully obtain shell access:

python MultiRelay.py -t 192.168.11.17 -u ALL

In the following example the host is a default installation of Windows 10 and the victim user currently authenticated to 192.168.10.17 is a local administrator user named default.

Within the below output it’s possible to see that this user is whitelisted (we specified -u ALL as a parameter), but access to the relayed host 192.168.11.17 is denied. Multi-relay is doing us a favour here and doesn’t continue to attempt to authenticate to the host which could potentially lock accounts out very quickly. Nice touch. Spoiler; both 192.168.10.17 and 192.168.11.17 have the same account/credentials configured.

Viewing this in Wireshark reveals the following (heavily condensed view).

So we have an administrative user (who actually has valid credentials on the host), but it’s not the default administrator account with RID 500. Let’s run the attack again, but this time we’ll target the local administrator account with RID 500.

Ah, success! So we have successfully relayed authentication for the default RID 500 from the victim 192.168.10.17 and gained shell access on 192.168.11.17 as both hosts use the same local administrator account credentials. It should also be mentioned that both are domain members and not standalone workgroup based systems.

The following Wireshark output shows only the smb traffic involved within this initial relay communication where we can clearly see the relay route 192.168.10.17 (poisoned victim) > 192.168.10.206 (attacker) > 192.168.11.17 (relay target).

Multi-relay functionality:

This is where Multi-relay now comes into its own. At the end of March this year @pythonresponder alongside @gentilkiwi added Mimikatz integration (amongst a few other fun tools) that makes obtaining credentials/hashes a breeze.

Let’s experiment with these; we currently have a Multi-relay shell on 192.168.11.17 and we can easily invoke standard Mimikatz functions by using the mimi command (or mimi32 if we’re targeting a 32-bit host).

Other useful functionality includes the super quick SMB scanner that can be used to find other potential targets within the network. A example of this is shown in the following screenshot from which a /16 range was supplied (our example network is a 192.168.0.0/16 with each 192.168.X.0/24 range having identical systems for student lab work).

Let’s play with one last feature of Multi-relay and use this tool to spawn every pentesters favourite shell, Meterpreter. Firstly we’ll need to configure an appropriate listener in msf and for this example we will be using exploit/multi/script/web_delivery. Without going into specific detail about this exploit, this will be hosted on our attacking system 192.168.10.206, some basic options have been set and PowerShell has been configured as the target.

Returning to the Multi-relay shell we can now run our favourite IEX command and hopefully pop some more shells. Notice that we’re not expecting any output here so the “something went wrong…” output can generally be ignored in this specific case.

Returning to the msf web_delivery exploit we see some action and once the shell has landed we can use built-in Meterpreter tricks and/or post modules/functionality from within the msf framework as desired.

Prevention & remediation activities:

To tighten the security of your Windows systems the following tweaks can be made.

Responder

• Disable LLMNR via group policy
  • Open gpedit.msc and navigate to Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution and set to Enabled

• Disable NBT-NS
  • This can be achieved by navigating through the GUI to Network card > Properties > IPv4 > Advanced > WINS and then under “NetBIOS setting” select Disable NetBIOS over TCP/IP

• • Alternatively this task can be accomplished through modifying the registry by navigating to the following key and changing the value to 2 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\{$InterfaceID}\NetbiosOptions

Multi-relay

• Enable SMB signing via group policy
  • More details of SMB signing and the various values that can be defined can be found within the following links (a couple selected from a vast sea of information available from a quick Google search). It goes without saying that configurations will need to be thoroughly tested to ensure communication is unaffected and in a secure state.

 

Sursa: https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/