Critical WSUS Vulnerability Lets Attackers Compromise Enterprise Endpoints

Key Takeaways

• A critical vulnerability chain impacts Windows Server Update Services (WSUS) configurations that utilize external SQL Server databases.
• Attackers can leverage NTLM relay attacks to gain unauthorized access to the WSUS database.
• Malicious “updates” can be forged and deployed to enterprise endpoints, leading to arbitrary code execution due to a signature bypass flaw.
• The flaw specifically affects setups where the WSUS server and its SUSDB are on separate machines.
• While no CVE ID has been assigned, SpecterOps has provided tools for detection and mitigation.

Attackers Can Turn WSUS into Backdoor Factories

A sophisticated attack chain has been uncovered that allows threat actors to compromise Windows Server Update Services (WSUS) infrastructure, a cornerstone of patch management in enterprise environments. This novel technique could enable adversaries to distribute malicious updates to domain-joined endpoints, effectively transforming trusted update servers into mechanisms for widespread compromise.

The research, conducted by SpecterOps researcher Beyviel David, highlights a significant operational risk for organizations that host their WSUS instances with an external SQL Server database. The attack demonstrates how local network access can be leveraged to coerce authentication, hijack a database session, and then craft and deploy malicious updates that target endpoints will automatically trust and execute.

Exploiting External SQL Server Deployments

Enterprise WSUS deployments often deviate from the default Windows Internal Database configuration, instead opting to host the SUSDB database on a separate Microsoft SQL Server instance. This architectural choice, while common, introduces a critical exposure when combined with NTLM authentication coercion techniques.

An attacker can exploit this setup using tools such as PetitPotam to force the WSUS server’s computer account to authenticate over SMB to a hostile machine. This authentication can then be relayed directly to the remote SQL Server database via tools like Ntlmrelayx. Since the WSUS computer account inherently possesses the necessary permissions to establish a session on the SUSDB instance, this maneuver grants the attacker an authenticated database foothold without requiring valid domain user credentials.

Maintaining vigilant oversight of these relay vectors is paramount for safeguarding Active Directory security across corporate networks, as demonstrated by this vulnerability.

Forging Malicious Updates via Stored Procedures

Upon gaining initial database access through NTLM relaying, the attacker is typically placed in the restricted webService role. This role initially lacks direct SELECT, UPDATE, or DELETE permissions on core database tables. However, the SpecterOps researchers discovered that the permissions granted to execute specific stored procedures are sufficient to weaponize the update workflow.

By chaining together native SQL stored procedures—specifically spImportUpdate, spSaveXmlFragment, spSetBatchURL, spCreateTargetGroup, and spDeployUpdate—an attacker can meticulously forge a complete Windows update package. This package can contain arbitrary metadata, file hashes, and execution instructions. As detailed in the SpecterOps research report, this sequence of stored procedure calls allows an attacker to construct valid update metadata directly within the database. Because the database interprets these commands as originating from the trusted WSUS computer account, the forged updates bypass internal validation mechanisms and are subsequently dispatched to targeted endpoint groups. Securing update infrastructure is a critical component of comprehensive Windows server security management.

Bypassing Digital Signature Validation

Under normal operational parameters, WSUS mandates that all delivered binaries possess a valid digital signature from a trusted Microsoft certificate, with payloads exclusively downloaded via the Background Intelligent Transfer Service (BITS) protocol. However, SpecterOps researchers reverse-engineered the Microsoft.UpdateServices.ContentSyncAgent.dll library using dnSpy and uncovered a critical logic flaw within its file-verification routine.

The verification logic specifically checks if a payload filename concludes with either .txt or .esd. If either of these extensions is detected, the routine skips digital signature validation entirely. This flaw permits an attacker to rename any executable payload, for example, to “Ghost.txt,” host it on a BITS-compliant web server, and then trigger WSUS to download and execute the unverified binary on target endpoints. This vulnerability facilitates unauthenticated code execution across client machines.

Furthermore, if the target environment’s Group Policy is configured to automatically download and schedule update installations, the malicious payload deploys without any user interaction. Should the payload process be terminated, the malicious update automatically re-executes, establishing a persistent foothold on the victim host.

To assist security teams in understanding and defending against this threat, SpecterOps has released two open-source projects:

• ludus_wsus: An Ansible-based lab environment designed for deploying vulnerable WSUS instances, enabling security professionals to test and analyze the attack chain in a controlled setting.
• NotWSUSpicious: A Python utility that automates the SQL stored-procedure chaining process. It comes bundled with a custom BITS server and a modified mssqlclient.py, streamlining the exploitation for research and testing purposes.

What You Should Do

• Enforce Extended Protection for Authentication (EPA): Implement EPA on the SQL database server hosting SUSDB. This measure is crucial for blocking NTLM relay attacks that form the initial vector of this attack chain.
• Network Segmentation: Restrict network access to your WSUS database. Ensure that only authorized WSUS servers and designated administrative management hosts can establish connections to the database.
• Monitor Stored Procedure Invocations: Regularly audit SQL execution logs for any suspicious or anomalous calls to stored procedures such as spCreateTargetGroup, spDeployUpdate, or spSetBatchURL, especially if they involve references to .txt or .esd files.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.