WSUS Exploitation - All you need to know

Windows Server Update Services Introduction

Windows Server Update Services (WSUS) is a Windows Server role that allows administrators to manage the deployment of updates to Microsoft products within their organization. It acts as a local update repository, caching updates from Microsoft Update and distributing them to client machines, reducing bandwidth consumption and providing more control over the update process. WSUS is a free tool available for various Windows Server and client operating systems, and it is typically used by small to medium-sized businesses. This service also allows system administrators to control which updates are pushed over the network by approving them, they also have the power to create custom ones for specific machines and deploy them via the WSUS server.

How is WSUS deployed?

WSUS is deployed via GPO, and this will affect the registries of the machines to which the policy applies. To check if your machine is part of the WSUS clients, you can query the following registry:

From the output above you can see that the WSUS server is configured to be WSUS.kapla.lab and will periodically or manually check for new updates, download and execute them.

How can WSUS be abused?

There are different exploitation cases depending on the scenario, position we start from and WSUS server version.

note: The WSUS server in this lab is on one of the latest version of 2024 (10.0.20348.2849).

This blog will cover the following attack techniques:

• ARP Spoofing to force a client to download updates from a malicious WSUS server

• Malicious Update using a legitimate WSUS server

• Local Privilege Escalation: From WSUS Administrator to full system Administrator

• OPSEC Considerations and methods for uploading custom payloads to bypass AV/EDR

• NTLM Relay Attacks to LDAP for domain privilege escalation, RBCD (Resource-Based Constrained Delegation) and ADCS ESC08

First Attack: ARP Spoofing

Before any attack is a good idea to scan for targets, and most importantly identify the WSUS server, for this I used NetExec

Prerequisites for this attack to work:

• The client needs to be in the same local network as the attacker

• WSUS is configured to use HTTP and not HTTPS

This tool leverages the ARP spoofing technique, where the attacker responds to ARP requests with their own MAC address, effectively impersonating the legitimate WSUS server. In this case, we trick the victim machine into believing that the IP address of the real WSUS server (e.g., .4) is associated with our attacker machine’s MAC address.

Since ARP operates at Layer 2 (Data Link Layer) of the OSI model and relies on MAC addresses for local delivery, this attack is only feasible when the victim is on the same local network as the attacker.

By default, wsuks creates a local user with a random password on the machine by spawning an elevated PowerShell process with PsExec.

With the -t we specify the target client and with the --WSUS-Server flag the legitimate server

then on the KAPLADC01 machine we can check for updates

This will cause the client to download the WSUS update from our malicious server, which will create a local user on the system.

Sadly enough, the updated exited with this error

As you can see from the error this is caused by the user password which isn't meeting the password policy configuration in the domain, to fix this I created a hardcoded password and also changed the powershell command to add the newly created user to the local admins

I ran the tool again and got another user, this time Administrator:

Second attack: WSUS Administrator

In this second attack, we will abuse the privileges of the WSUS Administrator account. By default, this account does not have local administrator rights on the WSUS server, but it does have full control over update creation and approval. If we manage to gain access as a local administrator or a WSUS Administrator on the server, we can directly deploy a malicious update from the legitimate WSUS server itself. In this case, even if WSUS is configured to use HTTPS, it will not mitigate the attack.

Please note that by default WSUS only allows Microsoft signed binaries to be uploaded and approved, any binary that does not meet the signing requirements will not be executed by the client and will fail with error (0x800b01109) or similar

For this attack, I will use SharpWSUS, this tool automates the process of update creation and approval

Note: I found this tool to be inconsistent when approving updates, so I will use it only to create the update and perform the approval manually. In a real red team engagement, the following steps should be executed from a C2 framework.

To create the update you can use the following command, in this case I will create the kapla_evil user and add him to the local Administrator group

After the update is created, you can open the Windows Server Update Services console and navigate to All Updates, then filter by Approval: Unapproved and Status: Any. You should be able to see your update there:

Now you can right-click on the update and approve it for all computers and groups

Then, using the Domain Administrator account, I triggered a check for updates on the AD Domain Controller and observed that the kapla_evil account was successfully created.

Third Attack: LPE

As mentioned earlier, WSUS Administrators do not have administrative privileges over the WSUS server itself. This role is intentionally limited to managing updates through the WSUS console only. Typically, WSUS is deployed via Group Policy (GPO), and if the client GPO is linked to an Organizational Unit (OU) that includes the WSUS server, then the server becomes a client of WSUS as well. Since we already have access to the server (e.g., via RDP), we can manually trigger an update check instead of waiting for the default 24-hour interval or relying on another user to check in.

To check if the server is part of the clients, we can query the following registries

This can also be done via GUI from the console

From here the attack is the same as we did previously, create the update -> Approve it -> Download & execute

After you have approved the update for the WSUS server, you can check for updates via the GUI

Even though the update is approved, it fails to install because the WSUS server cannot locate the PsExec.exe binary. Initially, I suspected the issue was due to using a local Administrator account instead of a WSUS Administrator, but the problem persisted. The likely cause is that PsExec.exe is not present in the WSUS content directory (C:\WSUS\WsusContent), preventing the server from serving the file to the client.

This PowerShell command retrieves Application log events with ID 364 (typically Windows Update errors) and gives the output back:

we can then copy the PsExec binary to that location and try the download again:

now we need to approve the update again AND click on retry download

and check all:

And we will receive a system shell back

Fourth Attack: OPSEC Considerations & Deploying custom payloads

Using WSUS to push malicious updates is powerful, but tools like PsExec are noisy and often flagged by EDRs. For better OPSEC, it’s smarter to avoid obvious binaries and use stealthier methods. This section explores alternatives that are less likely to trigger alerts while still giving us code execution on target machines. Specifically, how to upload your own custom binary (e.g beacon payload)

For more information, check out this post from elastic security

In some cases businesses might choose to create their own custom updates, this means that they will not be Microsoft signed, rather they will use a certificate they own signed by a private CA, this can be done with ADCS for example. To make this possible, a setting in the WSUS client GPO needs to be enabled "allow signed updates from an intranet Microsoft update service location"

To check if this configuration is enabled in your environment, you can query the following registry:

• 1 -> clients accept any trusted cert

• 0 -> clients require Microsoft signatures

Check for ADCS in your environment using NetExec

If you have enough privileges you can request a code signing certificate (In my environment the WSUS Administrator can)

With the enrolled certificate, we can sign the payload

I then used pywsus to host the payload, as you can see after the initial request reverse.exe is downloaded and executed

After I checked for updates on the kapladc01 machine I got a reverse shell in the context of the Domain Admin (This is because the update check was done manually and didn't required elevated context)

Fifth Attack:NTLM Relay attacks to RBCD, AD privilege escalation and ADCS ESC08

Resource based constrained delegation attack:

RBCD allows a service to impersonate users to a specific machine, but it's the target machine that controls who is allowed to delegate to it. This is managed via the msDS-AllowedToActOnBehalfOfOtherIdentity attribute, which contains the list of computer accounts trusted to act on behalf of users.

By default, machines can write this attribute on themselves. An attacker can exploit this by creating a computer account (e.g KAPLA$)in the domain. If they can relay an HTTP NTLM authentication from the victim computer (WKSTN01$) to LDAP, they can modify the attribute on WKSTN01$ to include their rogue computer (KAPLA$). Once added, using the controlled computer (KAPLA$) account credentials, they can request a service ticket for any domain user.

The following code attempts to authenticate to an HTTP-protected endpoint using the credentials of the context in which it is executed: The code was signed before deployment

Then I created the computer account: Any domain user can by default

Before launching any attack, I enumerated the MachineAccountQuota to check if I could add a machine account to the domain

After that, I hosted my C# code and waited for the machine (WKSTN01) to check for updates. Once the code runs, it authenticates to my HTTP ntlmrelayx endpoint, which then relays the authentication to the Domain Controller, adding the KAPLA$ account to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of WKSTN01$.

We can now request a service ticket (ST) for the Administrator account on the CIFS (SMB) service and use it to authenticate.

Important Note: Like most NTLM relay attacks, self-relaying (relaying to the same machine) is not possible. For example, if the authentication originates from the Domain Controller itself, the relay will fail because LDAP on the same machine (e.g., KAPLADC01) won’t accept it.

Relaying a privileged account:

What if, instead of a machine account, we relayed a privileged AD user like a Domain Administrator? In that case, ntlmrelayx can add the specified account to the Enterprise Admins group, giving us the ability to perform a DCSync attack and replicate the domain.

The machine is now in the Enterprise Admins group and can DCSYNC

Targeting ADCS ESC08 abuse

ESC08 is a vulnerability in Active Directory Certificate Services (ADCS) that arises when Certificate Web Enrollment is enabled—a common default in most ADCS setups. This feature allows users and machines to request certificates through the CA’s web interface at http://ADCS-SERVER/certsrv.

Why is this a problem? Unlike many other protocols (e.g. LDAP), HTTP does not support signing, which means any NTLM authentication s can be relayed by an attacker to this endpoint to request certificates for a user or machine template, effectively impersonating them.

ADCS ESC08 enumeration:

We can enumerate the server for this misconfiguration using certipy-ad with the following command:

For this attack, I’m abandoning the C# code because it requires manual signing, which isn’t always possible in some engagements. Instead, I’ll use Procmon.exe, a Microsoft-signed Sysinternals tool and can be uploaded to WSUS without problems.

So, how do NTLM coercion attacks happen? By default, Windows automatically tries to authenticate to any endpoint that requests like \\smb-server\test. This behavior is built into all Windows systems and is what attackers exploit.

This is an example of how Procmon can be used to initiate authentication

On another window, I have the certipy-ad server listening for incoming connections. Once authentication is initiated, it’s relayed to the ADCS web enrollment endpoint to request the user certificate template for whoever started the Windows update (In this case, domain Administrator).

Closing thoughts and remediation

As seen in this blog WSUS is a critical component in an Active Directory environment, this is why securing it is crucial, firstly WSUS administrative access or Administrative access to the WSUS server should be limited as much as possible, secondly HTTPS should always be used instead of HTTP, this prevents the usage of a malicious WSUS server such as pywsus, because when a client request to the HTTPS endpoint it will fail due to an invalid certificate and this will close the connection preventing any malious update being installed on the victim machine.