SYSTEM via WAC: How a Permissions Oversight in Windows Admin Center Leads to Full Host Compromise

by ddos · December 18, 2025

Cymulate Research Labs has uncovered a local privilege escalation vulnerability in Microsoft Windows Admin Center (WAC) version 2.4.2.1, affecting all WAC installations up to version 2411. The issue stems not from an obscure logic flaw, but from a mundane yet dangerous configuration error: the directory C:\ProgramData\WindowsAdminCenter is writable by any standard user. At first glance, this appears to be a routine permissions oversight, but the contents of this directory are handled by components running as a SYSTEM-level service—turning write access into a direct avenue for privilege escalation.

In effect, any organization using WAC to manage servers or infrastructure implicitly inherits this risk. An attacker needs only filesystem access on the host where WAC is installed. Cymulate emphasizes that the vulnerability is agnostic to industry verticals: any deployment involving the WAC Gateway, integrated extensions, privileged administrative workflows, or Windows Server hosts with WAC installed is exposed. The researchers demonstrated that misconfigured permissions enable reliable exploit chains, allowing escalation from low privileges to SYSTEM and effectively breaching Windows’ security boundary.

The first exploitation path revolves around the extension removal mechanism. The researchers posed a simple question: which actions are almost guaranteed to execute with elevated privileges while still interacting with user-controlled content? Installation and removal are the obvious answers. Since WAC is a .NET application, the team used dnSpy to quickly locate the uninstallation logic. The code constructs a path to an uninstall directory, enumerates all .ps1 files within it, and executes them via PowerShell using the AllSigned execution policy. In practice, this means WAC implicitly trusts any PowerShell script placed in that directory.

Because the parent directory is writable by all users, a standard user can plant a payload there—with one caveat: the script must be digitally signed. Cymulate stresses that this is not a trivial “drop any ps1 and win” scenario; an attacker must either abuse an existing signed script or create and sign one themselves.

For demonstration purposes, the researchers signed a simple script that executed whoami and wrote the output to C:\Users\Public, clearly showing that the code ran in an elevated context. The full attack chain was straightforward: create the directory structure C:\ProgramData\WindowsAdminCenter\Extensions\<ExtensionName>\uninstall, place the signed malicious script inside it, and trigger the extension removal via the UI or API. The payload then executed with NETWORK SERVICE or even SYSTEM privileges.

The second exploitation path targeted the update mechanism and leveraged classic DLL hijacking. The team examined WindowsAdminCenterUpdater.exe and discovered that it loads DLLs from C:\ProgramData\WindowsAdminCenter\Updater. Since this directory is also world-writable, the setup naturally invites DLL hijacking: place a malicious library and wait for a privileged process to load it. Initial testing nearly succeeded, but the DLL failed to execute; Event Viewer revealed that the library was rejected due to a missing digital signature—the process performed signature verification.

A critical detail emerged, however: signature validation occurs inside the WindowsAdminCenter process, which then launches WindowsAdminCenterUpdater.exe afterward. This opened the door to a TOCTOU (time-of-check, time-of-use) attack. The researchers wrote a PowerShell script that, as a normal user, monitored for the creation of the WindowsAdminCenterUpdater.exe process and, the moment it appeared, rapidly copied a malicious user32.dll into the Updater directory—after the signature check but before the DLL load.

In their proof of concept, the team used Register-WmiEvent to react to process creation and copy the DLL into place. According to the researchers, the technique worked flawlessly: the DLL executed with SYSTEM privileges, and the entire chain was triggered by an unprivileged user. For the PoC, they built a user32.dll that simply wrote a file to C:\Users\Public\test.txt, configured monitoring for the updater’s launch, planted the DLL in the Updater directory, and initiated the update via the /api/update endpoint—achieving SYSTEM-level code execution.

Microsoft has confirmed the vulnerability, assigned it the identifier CVE-2025-64669, and awarded the researchers a bounty of $5,000.