We begin on the Domain Controller, where the Group Policy setting “Network security: Restrict NTLM: NTLM authentication in this domain” is initially set to Disabled. This allows NTLM-based authentication to proceed – opening the door for potential relay attacks.
On the attacker machine (running Kali Linux), the Responder and Impacket’s ntlmrelayx tools are launched. Once a network authentication attempt is triggered, the attacker successfully relays the NTLM authentication to another host, gaining access as CQURE\Administrator. From there, the attacker can enumerate hosts, check privileges, and simulate further connections — all using the relayed credentials.
Next, we tighten security by switching the Group Policy to “Deny All”, effectively disabling NTLM across the domain. When the same attack sequence is repeated, the relay attempt fails — the target returns “status not supported.” Authentication now requires Kerberos, which is not vulnerable to NTLM relay in the same way.
This demonstration clearly shows the real-world impact of disabling NTLM: the attack surface for NTLM relay disappears.
However, phasing out NTLM completely requires careful planning, monitoring, and identification of systems or applications that still depend on it.
For a deeper dive, check out the CQURE NTLM Phase-out Guide for Active Directory Environments – and start preparing your organization for a more secure, NTLM-free future.
And if you’re hungry for more cybersecurity knowledge, we’ve opened the registration for our 6-weeks Advanced Windows Security Course 2026, ensuring you’re prepared for the threat landscape of the next year!
Check out the Advanced Windows Security Course for 2026 offer >>
Transcript of the video:
Hi and welcome back to another episode of CQURE Hacks.
In this video, I’m going to demonstrate how NTLM relay attacks work and what happens when NTLM is disabled.
We start on the domain controller, checking the Group Policy.
We look at the setting:
Network Security → Restrict NTLM: NTLM authentication in this domain.
As you can see, it is currently set to Disabled.
Now on our attacker machine (Kali Linux), we will launch the tools.
First, we start Responder.
Next, in a second window, we set up the NTLM relay with the Impacket ntlmrelayx tool.
The tool initializes its servers and is ready for the attack.
Now we’re going to run \\test\123 just to trigger it.
There we go — back on Kali.
We immediately see the relay succeed.
The tool reports a connection and authenticates to the target as CQURE\Administrator.
That credential can be used for further actions.
Now that we have it, let’s try the connection.
As you can see, we have 11001, and we can pull full details about the hosts listed.
That lets us see what privileges we currently have while leveraging this attack.
In this context, we can also simulate connections to those hosts.
Now, whenever we get in here — as you can see, many poisoned responses — those are expected in verbose mode.
Next, we return to the domain controller and enforce a much stricter policy.
We change Restrict NTLM — NTLM authentication in this domain — from Disabled to Deny All.
Then NTLM version 2 will no longer be in place.
Let’s quickly apply the policy, then test whether these attacks still work so you can see the real-world effect.
On Kali, we restart our attack.
First, Responder is relaunched,
and then the ntlmrelayx tool is started again — ready to catch and relay authentication attempts under the new policy.
We are waiting for these authentications to happen so that we can grab that response.
Yep, we can do the same part — \\test\12345, whatever.
We capture the authentication attempt,
but the initial authentication to the target fails.
So, at this point, we no longer have the ability to authenticate using NTLM.
If we try to test with SMB netexec using the captured credential (for example, supplying the captured password),
the attempt fails — the target returns “status not supported.”
But if we check it with Kerberos, as you can see, we’ve got the possibility to get in.
So, at the end, it really depends on how we are doing this spray — how that activity is processed.
And in the end, you’ve got the possibility to compare what it means to have NTLM disabled or not.
Ultimately, this deprecation is about gathering information on which sources, applications, and services still rely solely on NTLM version 2.
That’s the key issue.
Basically, we can add exceptions, and those are applied directly within the policy.
And just for reference — this was a quick introduction because many people are concerned about one key question:
How do we actually phase out NTLMv2?
As you can see, the process is fairly simple —
but of course, don’t forget the monitoring component.
That’s crucial once you apply it in the field.
All right, if you’re interested in this topic and want to dive deeper,
our team has prepared a dedicated document:
NTLM Phase Out – Guiding Active Directory Environments.
You’ll find the link in the description, and I definitely encourage you to check it out.
Thank you so much for watching CQURE Hacks.
Hopefully, you enjoyed the content!
Don’t forget to subscribe to our channel and follow what we do on social media.
The post CQURE Hacks #68: NTLM Relay Attacks Explained and Why It’s Time to Phase Out NTLM appeared first on CQURE Academy.
Login
