Even if Microsoft tries its best to deprecate NTLM, this protocol remains one of the best weapons for lateral movement and privilege escalation in modern enterprise environments.
However, there is a significant gap between theory and practice. While a local pentester can easily start Responder or ntlmrelayx from a physical access, executing a successful relay through a Command & Control (C2) framework involves some complexity. This article shows a few ways of weaponizing NTLM relay in a C2 in 2026, and includes some OPSEC notes.
The Problem
Here we’ll take the scenario of a Red Team engagement where we got an initial access on a machine, and want to coerce a machine (or a user) back to us.
This would be quite easy if this first machine was running on Linux, but in most cases it’ll be a Windows server or a workstation.
We could also just coerce to the teamserver directly, but in most cases it won’t be reachable by the victim (Red Team engagements usually involve a lot of network pivoting), and it’s also bad OPSEC to do this. So we have to relay to an intermediate compromised machine, which will then relay the traffic to the teamserver.
Problem: if we want to relay/coerce something, we usually have to use port 445 on our machine (to relay to a rogue SMB server). BUT this port is already in use on Windows (by LanmanServer, which is the service used for SMB communications on a Windows host). This article will describe a few techniques to bypass this problem.
WinDivert
One of the most efficient ways to reclaim port 445 is to intercept traffic before it even reaches the Windows user-mode stack.
This is where WinDivert (Windows Packet Divert) joins the party.
WinDivert is a powerful user-mode packet interception driver. Unlike traditional packet sniffers that only “copy” traffic, WinDivert allows an application to “divert” specific packets. In our scenario, we use it to tell the Windows Filtering Platform (WFP): “If you see a packet destined for port 445, don’t give it to the system. Give it to me instead.”
Tools like PortBender or DivertTCPConn leverage this library to create a transparent redirection. By diverting inbound traffic from port 445 to an arbitrary high port (like 8445) where our C2’s relay tool is listening, we effectively “unplug” the legitimate SMB service for our own purposes without the OS even noticing.
This requires that we have a port where we can redirect the SMB traffic, without being blocked by a firewall
Here we’ll use Sliver C2 and DivertTCPConn. I also tested this technique with Cobalt Strike and PortBender.
- First, we use DivertTCPConn to install the WinDivert driver, and redirect port 445 to 8445.
|
|
Now, we have to forward this to our teamserver, where we have Responder listening.
|
|
The port redirection won’t work if your teamserver is running in a Docker container, because it will route traffic to the container’s loopback interface instead of the host
So we’re now in a position where any packet reaching port 445 on our compromised victim machine will be forwarded to its port 8445, which will be forwarded to our teamserver (where Responder or ntlmrelayx is running).
So, let’s trigger our relaying point (here we take the scenario of a user browsing to a directory that contains a malicious SearchConnector or LNK file).
Check Responder (or ntlmrelayx logs if you used ntlmrelayx):
It worked!
Now if we want to relay this, we can use proxychains to forward our authentication back to a different target in the victim network.
OPSEC
While being quite easy to implement, this trick requires to load a driver, which is usually heavily monitored by EDRs and blue teams.
For example, WinDivert is statically detected by Elastic EDR:
Just the fact that we load a new driver raises a medium-level alert too:
Disabling LanmanServer
LanmanServer is bothering us, so… let’s stop it? This great article by Nick Powers from SpecterOps shows a trick to disable LanmanServer without rebooting.
Basically, we just stop the LanmanServer, srv2 and srvnet services to unbind port 445 on our target.
Nick released a BOF for this, but it didn’t work properly for me in Havoc and Sliver, so let’s use the python version (I made a fix for the Cobalt Strike BOF here)
This time, we forward port 445, coerce, and then:
OPSEC
This method didn’t raise an alert in Elastic. However, it still requires disabling SMB on the target system, so we’d obviously not do this on a file server.
Lsarelayx
One last technique I found to forward NTLM traffic is lsarelayx, which uses a LSA authentication provider to redirect NTLM connections.
However, I don’t recommend it because this project is starting to get old, and it touches lsass.exe which is very bad OPSEC nowadays, and can cause the machine to freeze. I’m not going to PoC lsarelayx in this article.
Conclusion
In conclusion, while NTLM is an aging protocol that Microsoft is actively trying to kill, it remains a goldmine for lateral movement in modern AD environments. Weaponizing NTLM relay through a C2 framework like Sliver, Havoc or Cobalt Strike is no longer as simple as running a local script.
Whether you choose network redirection with WinDivert or a full port takeover, the key to success lies in your understanding of the host’s internal services. By mastering these two methods, a Red Teamer can effectively turn an initial breach into a complete domain compromise, even from a highly restricted workstation