Lateral Movement
NTLM Relaying Over C2
One of the prerequisites of conducting a NTLM relaying attack is having a device that can directly route into the target network (having direct line of sight), and allowing ntlmrelayx to listen on the same intranet. This usually comes in different forms:
Plugging a laptop directly into LAN via ethernet.
Connecting over VPN connection.
Deploying a bridged Linux Virtual Machine within the internal network.
However, when performing Red Team Operations over any C2 remotely, the scenario above is no longer applicable as our attacker’s ntlmrelayx listener will not be within the intranet.
Doing it the old way
A possible way of conducting NTLM relay over a C2 is to funnel SMB traffic through the compromised host and then out into the ntlmrelayx listener. This requires the ability to re-route all SMB traffic on tcp/445 on the compromised host to an arbitrary port which is then port-forwarded to the ntlmrelayx listener.
Step 1: SMB Port Redirection (Local Admin Required)
By default, the Windows kernel is bound to tcp/445 on startup, which prevents you from forwarding the port directly.
As a workaround, a kernel driver WinDivert must be loaded in accordance with PortBender to perform this port redirection for SMB traffic.
Step 2: Port Forwarding
Next, port forward tcp/8445 on the compromised host over to tcp/445 on your attacker machine to form a tunnel. At the same time, enabling socks proxy will allow ntlmrelayx to reach the relay target later on.
Step 3: Setup Listener
With ntlmrelayx listening on tcp/445, you can then relay this to the relay target through the socks proxy!
If everything goes right, you should see client communications flowing through when performing a coercion.
Doing it the safer (not risk free) way
As you can imagine, loading a kernel driver on client’s environment could easily result in a BSOD. Not to mention, couple of Windows hardening such as Driver Signature Enforcement (DSE) and Patch Guard (PG) had made loading an unsigned driver harder.
Through recent reverse engineering efforts, there is now a known method to unbind tcp/445 from the kernel by just disabling a user-land service, srvnet, thereby removing the need to load any kernel driver into the compromised host.
The good thing about this method is, disabling and re-enabling the service does not require the machine to be rebooted!
Step 1: Unbind TCP/445 (Local Admin Required)
Use the compiled BOF to stop the srvnet service.
Step 2: Port Forwarding
From this point onwards, it’s generally the same steps as the PortBender method. However, instead of port forwarding from an arbitrary port (e.g. tcp/8445) on the compromised host, you can now directly forward tcp/445 on the compromised host to tcp/445 on your attacking machine.
rportfwd 445 localhost 445
Step 3: Setup Listener
Rinse and repeat…
Word of Caution
Be aware of the role/type of server you’re trying to unbind. If the target server is a large file server or a Domain Controller, disabling or redirecting SMB traffic on it will cause issues on file sharing and connections from other clients.
Last updated