MultiRelay – Responder’s Overlooked Little Brother

Laurent Gaffié’s Responder tool is a standard go-to tool in a penetration tester’s toolbox. It’s likely one of the first tools run when simulating an attacker who is trying to steal user password hashes and gain a foothold in a network. After capturing a hash, most testers assume that the only path forward requires cracking the captured password hashes. However, if the hashes prove to be uncrackable, Responder can be used with its less-well-known sidekick, MultiRelay, to automatically relay NTLMv1/v2 authentication requests to a different machine to gain authenticated access to it.

How Does Responder Work?

Responder listens on the wire for NetBIOS Name Service (NetBIOS) and Link-Local Multicast Name Resolution (LLMNR) broadcast and multicast requests for hostnames from other machines in the local subnet. It’s common for Windows machines to use these protocols when they are unable to resolve hostnames through DNS or their own local hosts file. A hostname lookup can fail for a number of reasons, such as mistyping a hostname, misconfigurations, or decommissioned DNS records. Additionally, Windows hosts that are configured to automatically detect web proxies in an environment without a web proxy will also attempt to resolve wpad via NetBIOS and LLMNR (i.e., the Web Proxy Auto-Discovery (WPAD) protocol). Other applications also try to resolve nonexistent hostnames. For example, the Chrome browser will attempt to resolve three randomized domain names every time it loads as part of a self-configuration and optimization routine.^[1]

In other words, whenever a NetBIOS or LLMNR query hits the wire, these querying machines say to the local subnet, “I’m looking for FILESVR-02. Is anyone here FILESVR-02?” While any machine can reply, under normal circumstances the true FILESVR-02 would presumably be the only machine to actually respond. However, Responder allows us to step in and answer those NetBIOS and LLMNR requests by saying, “Yeah, I’m FILESVR-02. You can totally trust me. Authenticate to me!” The querying host trusts our answer and attempts to authenticate to our testing device and, in doing so, sends its NTLMv1/v2 password hash to us.

Traditionally, Responder captures this information and stores it for us so that we can use it for offline password cracking. But what if you can’t crack the password hashes that you stole with Responder?

Using MultiRelay

What do you do when your victim organization has implemented a 15-character password requirement and you’ve exhausted all other viable avenues of gaining significant authenticated access? MultiRelay is a tool that is packaged with Responder that is perfect for this type of a situation.

When Responder is used together with MultiRelay, Responder acts like a funnel on the local subnet by tricking victim machines into initiating NTLMv1/v2 authentication requests and sending the requests to MultiRelay, which forwards the authentication requests along to a target machine in a man-in-the-middle condition. If the account that we’ve tricked into trying to authenticate has at least local administrative privileges on the target machine, we can dump local password hashes, launch shells, pivot to other devices, and also use the “reg save” Windows command to save off a copy of the SAM, SYSTEM, and SECURITY hives from the registry of the compromised box, which can be used to extract cached domain password hashes.

Also, while Responder only works within the local subnet you’re in, MultiRelay can be used to relay NTLMv1/v2 authentication anywhere in the network that you can see.

Tutorial

Server Message Block (SMB) signing protects against SMB relaying and, for SMB relaying to work, the target machine cannot be configured to require SMB signing. The victim machine also needs to be authenticating with an account (through NetBIOS or LLMNR spoofing) that has administrative access on the target machine. Another important caveat is that, since the Microsoft MS08-068 vulnerability patch, you cannot relay NTLMv1/v2 authentication to the same machine from which it came. You also cannot relay saved hashes that you’ve collected with Responder. MultiRelay can only relay NTLMv1/v2 authentication requests in real time.

First you’ll want to identify machines in the network that don’t require SMB signing. Responder has a neat tool packaged with it called RunFinger that can scan subnets for Windows devices and show if SMB signing is required, as well as show hostnames, OS versions, domain information and other details.

Note: The screenshots we’ve included are from a lab environment, and we’re ignoring that the devices are vulnerable to MS17-010 and null sessions for the sake of the tutorial.

We’ll target the Windows 7 box at 10.1.1.100, because it doesn’t require SMB signing.

We’ll need to disable SMB and HTTP in Responder.conf because MultiRelay and Responder will both want to use ports 80/tcp and 445/tcp, and we want MultiRelay to use those ports.

Start Responder with the -rv flags (-I specifies the interface to use). The -r flag will make Responder reply to NetBIOS workstation/redirect requests, and -v is verbose to show more output. When you start Responder, you should see that SMB and HTTP are disabled.

Next, start MultiRelay. You’ll need to tell MultiRelay (a) which IP address to relay NTLMv1/v2 authentication traffic to, (b) which user accounts’ NTLMv1/v2 authentication you’d like to relay and (c) an action to execute. In this example, we’re targeting the 10.1.1.100 Windows 7 machine (-t 10.1.1.100), we’re relaying all user’s NTLMv1/v2 authentication requests (-u ALL), and we have instructed MultiRelay to dump the local account password hashes (-d).

If you don’t specify an action to execute, MultiRelay will drop you into a shell on the target machine with a submenu of available options. In this example, we’ll start by dumping the local password hashes because it’s the least intrusive function and, in my experience, it works very reliably.

Now we wait for a victim to come along and request an invalid hostname such that they are redirected to MultiRelay. Since we instructed MultiRelay to accept authentication from any user account, we may see connection attempts from accounts that don’t have local administrative privileges on the target machine. MultiRelay will forward all authentication attempts, but if the attempt fails, it will prevent additional attempts by the same account to prevent lockout.

Once an account with at least local administrative privileges attempts to authenticate, MultiRelay will dump the local password hashes.

In our example above, we instructed MultiRelay to dump the local password hashes by passing the -d flag. However, if we omit that flag completely, we’ll drop into a shell on the target box. Here’s what that looks like.

At this point, we have complete administrative access over the target machine without needing to have cracked any passwords.

To defend against SMB relay vulnerabilities, you’ll want to enable the Microsoft network client: Digitally sign communications (always) and the Microsoft network server: Digitally sign communications (always) options in your Group Policy Objects (GPOs).

This SMB signing configuration will force all connections to use SMB signing regardless of if the machine is acting as a client or a server in any particular situation.

It is worth noting that if SMB signing is enabled and required on the server and disabled on the client, or vice-versa, the connection will fail and the machines won’t be able to talk over SMB. These instances of protocol mismatch should not happen if you’ve uniformly applied the GPO settings to all machines in your environment (make sure to take into account any machines not joined to the domain and therefore not receiving Group Policy).

Common misconfigurations, such as a lack of SMB signing, are frequently missed or misunderstood by system administrators, but are certainly on the radars of malicious users. This further underscores the importance of having periodic penetration testing performed to discover these weaknesses (and get them fixed) before the real bad guys do.

Should your organization require assistance performing penetration testing, reach out to Sikich’s team of cybersecurity experts and they will be more than happy to help.

*For more information about SMB signing, see https://blogs.technet.microsoft.com/josebda/2010/12/01/the-basics-of-smb-signing-covering-both-smb1-and-smb2/.

^[1] https://groups.google.com/a/chromium.org/forum/#!msg/chromium-discuss/F70-k_PGhEg/xV8B5ljikVgJ