Windows Admin Center privilege escalation shows trust-boundary gaps

At a glance

What this is: This is a local privilege-escalation analysis showing that Windows Admin Center trusted a user-writable directory, enabling standard users to reach SYSTEM through two separate abuse paths.

Why it matters: It matters because infrastructure-management tools often sit beside privileged workflows, and one writable path can turn a workstation-level issue into administrative compromise across server estates.

Context

Windows Admin Center is a management plane, so its security depends on clear separation between standard-user write locations and privileged execution paths. When a product stores executable or scriptable content in a directory that ordinary users can modify, the control failure is not the vulnerability alone but the broken trust boundary around that content.

The article shows a classic local privilege-escalation pattern: untrusted filesystem state is later consumed by a privileged service. That matters for IAM and PAM teams because administrative tools, break-glass workflows, and endpoint management utilities often rely on service accounts, elevated tokens, and unattended execution in the same trust zone.

Key questions

Q: What breaks when a management tool trusts user-writable paths?

A: A writable path turns a storage location into an execution surface if a privileged process reads scripts or DLLs from it. The failure is not just local access, but privilege amplification. Standard users can shape content that SYSTEM later consumes, so the control gap is usually path integrity, not authentication.

Q: Why do writable update or uninstall directories create escalation risk?

A: They create escalation risk because maintenance logic usually runs with higher privilege than normal application code. If the directory that feeds that logic is writable by standard users, an attacker can influence what the privileged process runs, even without compromising a password or token. That is a governance failure in privilege separation, not just a file-permission mistake.

Q: What signs show a local privilege-escalation path is hiding in a management tool?

A: Look for privileged services that load DLLs, scripts, installers, or extension files from directories standard users can reach. A second warning sign is a validation step that happens before a privileged process starts, while the actual file load happens later. That timing gap can turn an apparently safe check into a raceable control failure.

Q: How should teams govern local privilege escalation in infrastructure management software?

A: They should treat management-plane software as part of the privileged access surface, not just as an admin console. That means aligning filesystem ACLs, service-account privileges, update workflows, and script execution paths under one control model. If a standard user can influence a privileged execution path, the software is outside acceptable governance boundaries.

Technical breakdown

Writable program data becomes a privilege boundary failure

Windows Admin Center placed operational content under C:\ProgramData\WindowsAdminCenter, but that location was writable by standard users. That matters because privileged services commonly assume program-data paths contain trusted inputs, scripts, or binaries. Once a low-privileged user can alter the folder, the service is no longer operating on controlled state. The core failure is not simply directory writability, but the collapse of the trust boundary between user-controlled filesystem content and SYSTEM-level execution. In managed environments, this kind of design turns configuration drift into an elevation primitive.

Practical implication: treat any user-writable path consumed by privileged services as an escalation surface and restrict it before deployment.

Extension uninstall flows can turn administrative logic into code execution

The uninstall path enumerated PowerShell scripts and executed them with elevated privileges, which made a maintenance workflow into an attack path. This is a common design trap: installers, uninstallers, and updater routines often run with more privilege than day-to-day application logic, yet they still consume files from application directories. If those directories are writable by standard users, attackers can influence what the privileged process loads or runs. Signed scripts reduce some risk, but they do not remove the architectural problem when the source location itself is not trustworthy.

Practical implication: separate privileged maintenance logic from user-accessible content and verify the trust of every script source, not just the script signature.

Updater DLL hijacking abuses time-of-check and time-of-use gaps

The updater process loaded DLLs from its working directory, which created a classic DLL hijacking condition. The article also shows a TOCTOU race: validation occurred before process launch, but the malicious DLL was swapped in after the check and before loading. That pattern matters because defenders often validate the file they see at one moment, while the privileged process actually consumes a different file at runtime. This is the same structural weakness that appears in many local privilege-escalation cases, where path trust, process timing, and loader behaviour are misaligned.

Practical implication: lock down DLL search paths, remove writable update directories, and validate the exact artifact at load time rather than only before launch.

Threat narrative

Attacker objective: The attacker wants SYSTEM-level control on the host through a management product that should have enforced a hard user-to-admin boundary.

1. Entry occurs through a standard user who already has filesystem access to the Windows Admin Center program-data directory.
2. Credential or privilege abuse follows when privileged WAC routines trust files from that writable location and execute or load them as SYSTEM.
3. Impact is full local privilege escalation from a low-privileged account to SYSTEM, breaking the Windows security boundary.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Privilege boundary failures in management tooling are more dangerous than ordinary local misconfigurations. The issue is not just that a folder was writable, but that privileged Windows Admin Center components later trusted content from that folder. That pattern converts filesystem access into administrative execution and creates a broader governance lesson for PAM and endpoint teams. The practitioner conclusion is simple: any management plane that mixes user-writable state with elevated execution has an identity-bound trust problem.

Signed-code checks do not compensate for an untrusted source location. The uninstall flow shows that elevated processes can still be steered through user-controlled paths even when PowerShell execution policy is restrictive. This is a control gap in lifecycle handling, not in a single binary. For identity programmes, the lesson is that privilege is governed by both who can act and where the action source lives. The practitioner conclusion is to treat source-path trust as part of privileged access control.

Windows Admin Center illustrates a named concept: trust-boundary drift. When management services, update logic, and plugin workflows all pull from the same writable directory, the boundary between operational convenience and privilege control erodes. That drift is especially relevant to NHI and service-account governance because automated processes often inherit filesystem assumptions that no human reviewer notices. The practitioner conclusion is to audit every administrative workflow for where trust is implicitly granted, not just where authentication occurs.

Local privilege escalation in infrastructure tools is an identity problem as much as an operating-system problem. WAC is a management layer, so its execution paths inherit the authority of administrators, service accounts, and backend workflows. Once those paths accept user-writable content, the identity model fails at issuance time rather than at login time. The practitioner conclusion is to align service-account privilege, filesystem permissions, and process loading rules under one governance model.

Attackers do not need exotic techniques when control-plane design leaves writable execution surfaces. The article shows two different escalation paths from the same underlying issue, which means defenders should look for structural reuse of trust assumptions across update, uninstall, and plugin code. The practitioner conclusion is to map all privileged maintenance paths to the same control standard and remove any path that still depends on writable shared directories.

From our research library:

• 83% of privilege escalation incidents involved no CVE exploitation, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: Active Directory and Entra ID Hardening Guide

What this signals

Trust-boundary drift: management tools often fail when operational convenience and privileged execution are built on the same writable filesystem paths. Once that happens, directory permissions become an access-control issue, not a housekeeping issue, and the control has to move to source ownership and execution context.

For IAM and PAM programmes, the deeper lesson is that privilege is not only about who can authenticate. It is also about what a service account, updater, or maintenance routine is allowed to consume, load, and execute. That means filesystem ACLs, service identity, and process loading behaviour need to be governed together.

For practitioners

• Harden Windows Admin Center program-data permissions Remove standard-user write access from C:\ProgramData\WindowsAdminCenter and any child directories that feed privileged services, update flows, or extension workflows.
• Separate privileged maintenance paths from user-writable content Move uninstall, update, and plugin execution logic to directories that ordinary users cannot modify, and make the privileged process consume only immutable or administrator-owned artifacts.
• Validate update and uninstall sources at load time Do not rely only on pre-launch checks or signatures. Confirm that the exact script or DLL consumed by the privileged process is the one that was approved.
• Test management-plane exposure with realistic attack scenarios Use exposure validation or equivalent adversary simulation to verify whether writable-path abuse, DLL hijacking, or uninstall-script execution still produces SYSTEM-level access.

Key takeaways

• The vulnerability shows that a writable management directory can collapse a local trust boundary and expose SYSTEM execution paths.
• The article describes two escalation routes from the same underlying issue, which demonstrates that path trust, not just binary trust, must be controlled.
• The clearest preventive control is to remove user-writable content from any directory consumed by privileged maintenance or update logic.

Key terms

• Trust Boundary Drift: Trust boundary drift is the gradual shift of where users and systems decide something is legitimate. In fraud and identity environments, that boundary can move from checkout to search, ads, or account recovery, which creates new opportunities for impersonation and abuse.
• Time-Of-Check To Time-Of-Use Gap: The time-of-check to time-of-use gap is the security window between when software is inspected and when it is later executed. In supply-chain security, a package may appear safe during build validation but become malicious, be reclassified, or behave differently once running in production.
• Privileged File Load: A process that reads scripts, libraries, or configuration from a location and then executes or imports them with elevated rights. If the source directory is writable by lower-privileged users, the load path itself becomes an attack surface.
• Local Privilege Escalation Amplifier: A host condition where a local vulnerability becomes far more dangerous because the affected machine already has access to valuable systems. The escalation may be technically local, but the impact becomes organisational when the host can reach signing, deployment, or cloud control planes.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect privilege control, service accounts, and operational workflows to the security model that actually governs them.