SMB is commonly used for sharing files, printers and communication between client and server. Before one can communicate with the other, the user will be required to authenticate themselves. This is simple access control.
Although this control can help protect those important files, it can also be manipulated to allow authentication attempts to be relayed and used to access systems. It can also be abused in order to collect password hashes. This is where SMB relay comes into play.
The attacker places themselves in the middle (MiTM) and relays the attempts. Once the end server has validated the credentials, the access is granted to the attacker instead of the user.
Let’s run through a scenario and use multiple tools in order to run an SMB relay attack.
- Attacker IP: 192.168.1.158
- User IP: 192.168.1.64
- SMB Share Server: 192.168.1.65
In this case, we know the IPs and shares but if you did need to scan the network, you could use the following:
Nmap has an enumeration script which allows you to map out SMB shares.
nmap –script smb-enum-shares.nse -p445 <host>
sudo nmap -sU -sS –script smb-enum-shares.nse -p U:137,T:139 <host>
Metasploit has the SMB_EnumShares module which allows you to do a similar scan. This does require you to known the user’s credentials though as it often fails without them.
Windows Explorer can be used to find network shares. By mapping to the IP/Host, Explorer will list the available shares. You won’t need to know the credentials to view exposure shares. If they have enabled ‘Access based enumeration’, you will only be able to see folders the user has access to.
In this case, we have found an open file share which has the default “Everyone” enabled.
Everyone is often enable by default and is granted read only. That doesn’t matter however as the authentication will still be challenged.
Let’s run through the attack…
As usual Metasploit comes to hand when running this type of attack. It has a module that allows you to conduct SMB relay attacks. Worth noting though that the module only supports NTLMv1.
You will need to set the Share and SMBHost values. These are the genuine share. The SRVHost will be the attackers IP (localhost).
Once we run the exploit, we will just need to trick the user into hitting our IP.
Once we have done this, we can relay the attack and drop our payload.
As mentioned above, this will only work for NTLMv1. As of today, default settings will require v2 responses only. If the target is using legacy systems however, you might get lucky.
The screenshot below shows the version defaults and in this case, the server did had it enabled.
Impacket – SMBRelayx.py
Not to worry though as we can use SMBRelayx.py from Impacket. This supports NTLMv2.
Run the following first:
Once we have finished the setup, we can create a payload using msfvenom:
Now, let’s move to the /examples folder and run the following:
python smbrelayx.py -h [SMB share host] -e [payload location]
We will also need to use Metasploits multi/handler to gain the Meterpreter session.
If the target doesn’t have admin rights to the server, your payload will fail.
If they do have admin privileges to the server, your payload should run, and you will gain your shell. Obviously, this is dependent on the end server having poor security controls.
Once you have the Meterpreter session remember to quickly migrate to a stable process…
It doesn’t always have to be a Meterpreter session. Netcat is a simple payload that most AVs don’t see as a threat.
There is another tool that does go the extra mile. It’s called Responder and comes preinstalled with Kali and Parrot OS.
If you run the above script, Responder will be able to capture authentication requests on the services it’s poisoned. It also has capabilities to push WPAD files on the network which could pull the clients towards you. This is if they have the “automatically detect proxy” setting enabled. By default, Windows does have this ticked.
It’s also worth noting that Responder does support NTLMv2.
Once your target hits your IP, the hashes and information will be nicely displayed.
As you can see, SMB Relay attacks are very useful and can have great results. Once you have your first set of credentials, the attack can grow, and further credentials can be harvested.
You just need that one user or service to make an attempt. It doesn’t have to be a user remember. If you have a network scanner, it will be using credentials to inventory or collect information. If the attacker is on the network, SMB relay attacks can help steal those credentials without anyone knowing. This is because the service won’t know any different as it’s simply scanning an IP. These types of systems are often running with privileged accounts.
If it is a user, simple tricks can be used such as fake shortcuts.
Editing the localhost file. This attack will require you to have admin credentials to the machine so is more post exploit. If the client is shared however, you might be able to collect multiple authentication attempts.
You could look to attack the DNS server itself however, people may start to be aware of your attack quite quickly. This is because the share will stop working.
If not the above, you can simply Phish. A simple email which has a misleading link may help you trick the user into authenticating against your machine. I’ve edited the link below to look like the actual DNS name of the SMB share. The trick though is that the link points to my machine. I could setup a genuine file which won’t raise any alarms. The user may just think it was sent to the wrong person.
This attack isn’t limited to internal network. There are server exposed to the internet which can be exploited. The attacker could spinup a cloud Instance which could relay the attack over the internet. Although it would be tricky, attackers with strong enumeration skills could successfully complete the attack.