Escaping the Confines of Port 445
Jul 24 2025
By: Costa Papadatos • 10 min read
TL;DR NTLM relay attacks on SMB restrict lateral movement to port 445/TCP capabilities. To extend beyond, leverage the Service Control Manager (SCM) remotely to initiate the Webclient service. This approach allows integration with computer account takeover methods such as shadow credentials or resource-based constrained delegation (RBCD), enhancing attack flexibility through the LDAP service targeting domain controllers (DCs).
Introduction
Before we dive in, let me clearly state this blog post will not reveal some groundbreaking new attack techniques regarding NTLM relay attacks. Instead, it will detail some of the typical constraints and limitations you may encounter when performing an NTLM relay attack specifically targeting the SMB service and describe potential ways to overcome these limitations.
The Problem
When performing an NTLM relay attack targeting the SMB service of a remote host, the actions you can take on that host are limited to those that can be executed solely through port 445/TCP. For example, you can’t establish a connection to the remote host using Windows Management Instrumentation (WMI), as this protocol also requires port 135/TCP, which is used for RPC. Most resources I’ve seen explain overcoming this restriction by extracting the SAM and SYSTEM registry hives containing the NT hashes for local user accounts on the remote host. With the NT hash of the built-in Administrator account, you are no longer limited to actions involving only port 445/TCP; you can also authenticate to other protocols, such as WMI, RDP, and WinRM, to name a few. While this may be feasible for assessments where stealth and evasion are not a concern, I’ve found that this technique results in one of the following outcomes:
- Dumping the NT hashes is successful, but triggers an alert
- Dumping the NT hashes fails due to EDR blocking the action outright and triggers an alert.
This got me thinking: if stealth or evasion is a concern, how can you take advantage of a system that does not require SMB signing? Is this technique, which was once the “bread and butter” of my early pen testing days, completely unfeasible now?
This blog post will detail my journey to answer these questions while facing this challenge during a recent assessment. It is important to note that by the time I found a solution, the assessment had already concluded. However, by taking the time afterward to further explore the issue, I now feel much more prepared if I encounter this scenario again.
Finding a Solution
My objective was straightforward: to gain administrative access to a specific file server. After conducting reconnaissance, I found that this system did not enforce SMB signing, which made it vulnerable to an NTLM relay attack. I also discovered another computer account in the domain configured as a member of the local Administrators group on the target file server. I thought, well, this is going to be easy; by simply coercing authentication from the host that was a local administrator using something like PetitPotam or PrinterBug, I could perform an NTLM relay attack targeting the SMB service of the target file server, dump its local accounts’ NT hashes, and use those to move laterally using a technique that is not restricted to port 445/TCP.
Remaining undetected for this assessment wasn’t required, but a well-tuned endpoint detection and response (EDR) solution continuously blocked and alerted on many of my actions thus far. Foolish as I was, I tried the default behavior of ntlmrelayx.py, which attempts to dump the local NT hashes from the SAM and SYSTEM registry hives, which, as expected, didn’t work.
I knew I could authenticate with an administrative context to the target file server through an NTLM relay attack. However, I was unsure of the actions I could perform that would:
- Lead to complete compromise of the host
- Not be prevented by EDR (and, ideally, not trigger an alert)
- Only require use of port 445/TCP
I decided to go to my home lab and test various methods to see what would work.
To the Lab
In my lab environment, I configured ntlmrelayx.py to relay all captured authentication attempts to the SMB service of a server that didn’t enforce SMB signing. I also set up ntlmrelayx.py to keep the relayed authentication session open by using the—socks flag. If you’re not familiar with how the SOCKS feature of ntlmrelayx.py works, take a look at this blog from a colleague of mine that explains it much better than I ever could.
TLDR: The -socks flag in ntlmrelayx.py keeps the relayed authentication session open for use with Proxychains or Proxifier, allowing reuse of the authentication context and eliminating the need for repeated NTLM relay attacks.
I configured it this way in my lab to quickly test different actions without having to execute the NTLM relay attack repeatedly. I also observed the debugging information related to which ports were necessary for the various techniques I was trying. After recreating the scenario in my lab, my ntlmrelayx.py output looked like this:
Note: I’m intentionally omitting the details of how I established the administrative session seen above because it isn’t relevant for the purposes of this blog. The purpose of this blog isn’t to discuss how to perform an NTLM relay attack; instead, it’s to share some additional techniques that can be utilized alongside an NTLM relay attack, which I believe are frequently overlooked. Whether you conducted an LLMNR poisoning attack or used authentication coercion, the key point is that you have a session in an administrator context on port 445/TCP of a remote host, established using an NTLM relay attack.
As mentioned, using the SOCKS feature of ntlmrelayx.py would also inform me whether the action I was attempting to take required an additional port aside from 445/TCP. For example, observe what happens when I attempt to use wmiexec.py through the previously established authentication context achieved from the NTLM relay.
As you can see, wmiexec.py tries to open a connection to port 135/TCP through the SOCKS proxy of ntlmrelayx.py; however, ntlmrelayx.py only has a session for port 445/TCP.
I initially experimented with different Impacket scripts to determine which ones required only port 445/TCP. Although this approach wasn’t perfect and felt a bit lazy, it revealed that the services.py Impacket script only needed administrative access to port 445/TCP.
If you’re unfamiliar, services.py is an Impacket script that interacts with a remote host’s Service Control Manager (SCM) to create, start, stop, and modify Windows services. There are multiple ways to manipulate the SCM on a remote host to facilitate lateral movement and, depending on the exact technique, evade detection by EDR systems. I won’t elaborate on all the ways to exploit Windows services for lateral movement, but in my opinion, the most common method is to upload a malicious dynamic-link library (DLL) to the target’s filesystem and start a service that executes it upon startup (i.e., DLL Hijacking). The following blog is an excellent resource for more information on this technique.
While this technique works with access limited to port 445/TCP, it still limits how to move laterally. I was really looking for a way to abuse the NTLM relay over SMB to eventually open the door to a broader range of lateral movement techniques; not just those tied to port 445/TCP.
Like many of the tools in Impacket, services.py is heavily signatured and likely to trigger alerts. So, I decided to take things further by proxying native Windows tools such as the services.msc MMC snap-in and sc.exe—through the SOCKS proxy in ntlmrelayx.py. These tools can perform the same actions as services.py, but with a much lower chance of setting off alerts.
I started by setting up a local port forward from port 1080/TCP on my Kali Linux host, where ntlmrelayx.py ran its SOCKS proxy, to port 1080/TCP on my Windows attacker machine.
Next, I configured Proxifier to use localhost port 1080/TCP as its proxy server and created a rule to route all traffic targeting port 445/TCP on the relay victim (i.e., 10.2.10.12) through the proxy.
Finally, I used runas to spawn a command prompt that runs in the context of the relayed account, which in this case is HOGWARTS\SCCM-SITESRV$.
Note: When prompted for a password, I just pressed Enter. If everything is set up correctly, authentication should be handled through ntlmrelayx.py’s SOCKS proxy.
To ensure everything was working, I used sc.exe to query the status of the Webclient service on the relay victim, and it was successful, indicating that I hadn’t messed up my proxy settings somewhere.
At this point, I have confirmed that I can manipulate remote services through the SOCKS proxy of ntlmrelayx.py using both services.py and native Windows tools, all facilitated by an NTLM relay targeting SMB.
As mentioned earlier, there are several ways to abuse Windows service manipulation, each with its own OPSEC trade-offs. By this point, my assessment was already complete, and my focus had shifted to figuring out how to reliably interact with the relay victim over any protocol, not just SMB, in the future. The goal was to enable a broader range of lateral movement techniques. The answer was something I’d done plenty of times before, just never as part of an attack chain that started with an NTLM relay targeting SMB: starting the Webclient service.
If you are unfamiliar with how the Webclient service can be abused in conjunction with NTLM relay attacks targeting the LDAP service, the resources below do a fantastic job of explaining it, but I will try my best to summarize.
- https://posts.specterops.io/the-renaissance-of-ntlm-relay-attacks-everything-you-need-to-know-abfc3677c34e
- https://redfoxsec.com/blog/an-in-depth-exploration-into-webclient-abuse/
A key limitation of authentication coercion (i.e., PetitPotam, PrinterBug) is that the captured NetNTLMv2 hash comes within an SMB packet, which cannot be relayed to LDAP or LDAPS (unless the target DC is missing several years of patches, or the hash is NetNTLMv1).
However, if the coercion target has the Webclient service running, you can perform authentication coercion so that the NetNTLMv2 hash is sent via the WebDAV protocol instead, which is essentially just a wrapper for HTTP. This allows using authentication coercion to perform an NTLM relay targeting LDAP because WebDAV authentication can be relayed to LDAP, making it possible to perform a computer account takeover via either a RBCD or Shadow Credentials attack.
Another key misconfiguration must be present for this attack to work, LDAP signing or channel binding must not be enforced on the target DC you’re relaying to. While LDAP signing and channel binding enforcement is becoming more common, it’s still relatively rare in my experience. In most of my engagements, NTLM relay attacks targeting the LDAP service are still very much in play.
To further validate that this was possible, I enabled the Webclient service remotely on the relay victim, ensuring all authentication was being handled through the previously established SOCKS proxy of ntlmrelayx.py
Conclusion
When targeting SMB with an NTLM relay attack, your lateral movement options are limited to what’s possible over port 445/TCP. To break out of that limitation, you can use the Service Control Manager (SCM) on a remote host to start the Webclient service. Doing so opens the door to more flexible movement by combining a computer account takeover technique, like Shadow Credentials or RBCD, with an NTLM relay attack targeting the LDAP service of a DC.
