Bypassing Windows Administrator Protection

Title: Bypassing Windows Administrator Protection - Project Zero

URL Source: https://projectzero.google/2026/26/windows-administrator-protection.html

Markdown Content: # Bypassing Windows Administrator Protection - Project Zero

[Project Zero](https://projectzero.google/)

* * *

- [x] * [blog archive](https://projectzero.google/archive.html) * [bug reports](https://project-zero.issues.chromium.org/savedsearches/7162405) * [about](https://projectzero.google/about-pz.html) * [Working at PZ](https://projectzero.google/working-at-project-zero.html) * [0day: spreadsheet](https://projectzero.google/0day.html) * [0day: Root Cause Analyses](https://googleprojectzero.github.io/0days-in-the-wild/rca.html) * [vulnerability disclosure policy](https://projectzero.google/vulnerability-disclosure-policy.html) * [reporting transparency](https://projectzero.google/reporting-transparency.html) * search

# Bypassing Windows Administrator Protection

[2026-Jan-26](https://projectzero.google/2026/26/windows-administrator-protection.html "Permalink to this post")James Forshaw

A headline feature introduced in the latest release of Windows 11, 25H2 is [Administrator Protection](https://blogs.windows.com/windowsdeveloper/2025/05/19/enhance-your-application-security-with-administrator-protection/). The goal of this feature is to replace User Account Control (UAC) with a more robust and importantly, securable system to allow a local user to access administrator privileges only when necessary.

This blog post will give a brief overview of the new feature, how it works and how it’s different from UAC. I’ll then describe some of the security research I undertook while it was in the insider preview builds on Windows 11. Finally I’ll detail one of the nine separate vulnerabilities that I found to bypass the feature to silently gain full administrator privileges. All the issues that I reported to Microsoft have been fixed, either prior to the feature being officially released (in optional update [KB5067036](https://support.microsoft.com/en-gb/topic/october-28-2025-kb5067036-os-builds-26200-7019-and-26100-7019-preview-ec3da7dc-63ba-4b1d-ac41-cf2494d2123a)) or as subsequent security bulletins.

_Note: As of 1st December 2025 the Administrator Protection feature has been disabled by Microsoft while an application compatibility issue is dealt with. The issue is unlikely to be related to anything described in this blog post so the analysis doesn’t change._

## The Problem Administration Protection is Trying to Solve

UAC was introduced in Windows Vista to facilitate granting a user administrator privileges temporarily, while the majority of the user’s processes run with limited privileges. Unfortunately, due to the way it was designed, it was quickly apparent it didn’t represent a hard security boundary, and Microsoft downgraded it to a security feature. This was an important change as it made it no longer a priority to fix bypasses of the UAC which allowed a limited process to silently gain administrator privileges.

The main issue with the design of UAC was that both the limited user and the administrator user were the same account just with different sets of groups and privileges. This meant they shared profile resources such as the user directory and [registry hive](https://www.tiraniddo.dev/2017/05/exploiting-environment-variables-in.html). It was also possible to open an administrators process’ access token and [impersonate it](https://www.tiraniddo.dev/2017/05/reading-your-way-around-uac-part-1.html) to grant administrator privileges as the impersonation permission […]

[… 23,429 Zeichen — nächste Zone: keyword-dense paragraphs …]

Fast forward to today, and along comes Administrator Protection. For reasons of compatibility Microsoft made calling ```plaintext NtQueryInformationToken ``` with the ```plaintext TokenLinkedToken ``` information class still returns an identification handle to the administrator token. But in this case it’s the shadow administrator’s token instead of the administrator version of the user’s token. But a crucial difference is while for UAC this token is the same every time, in Administrator Protection the kernel calls into the LSA and authenticates a new instance of the shadow administrator. This results in every token returned from ```plaintext TokenLinkedToken ``` having a unique logon session, and thus does not currently have the DOS device object directory created as can be seen below:

* The Administrator Protection feature changes to the ```plaintext TokenLinkedToken ``` query generates a new logon session for every shadow admin token. * The per-token DOS device directory is lazily initialized for each new logon session meaning when the linked token is first created the directory does not currently exist. * The kernel creates the DOS device directory when it’s accessed by using ```plaintext Zw ``` functions, which disables access checking. This allows a limited user to impersonate the shadow admin token at identification level and create the directory by opening ```plaintext \?? ``` . * If a thread impersonates a token at identification level any security descriptor assignment takes the owner SID from the primary token, not the impersonation token. This results in the limited user being granted full access to the shadow admin token’s DOS device object directory. * The DOS device object directory isn’t already created once the low-privileged user gets access to the process token because of the security mitigation which disables the impersonated DOS device object directory when opening files from the ```plaintext C: ``` drive in a ```plaintext SYSTEM ``` process.

A good repository of known bypasses is the [UACMe](https://github.com/hfiref0x/UACME) tool which currently lists 81 separate techniques for gaining administrator privileges. A proportion of those have been fixed through major updates to the OS, even though Microsoft never officially acknowledges when a UAC bypass is fixed.

The logon session is added as a reference in the […]

The […]

[… 22,625 Zeichen — nächste Zone: tail …]

As for my views on Administrator Protection as a feature, I feel that Microsoft have not been as bold as they could have been. Making small tweaks to UAC resulted in carrying along the almost 20 years of unfixed bypasses which manifest as security vulnerabilities in the feature. What I would have liked to have seen was something more configurable and controllable, perhaps a proper version of [sudo](https://www.tiraniddo.dev/2024/02/sudo-on-windows-quick-rundown.html) or Linux capabilities where a user can be granted specific additional access for certain tasks.

I guess app compatibility is ultimately the problem here, Windows isn’t designed for such a radical change. I’d have also liked to have seen this as a separate configurable mode rather than replacing admin-approval completely. That way a sysadmin could choose when people are opted in to the new model rather than requiring everyone to use it.

I do think it improves security over admin-approval UAC assuming it becomes enabled by default. It presents a more significant security boundary that should be defendable unless more serious design issues are discovered. I expect that malware will still be able to get administrator privileges even if that’s just by forcing a user to accept the elevation prompt, but any silent bypasses they might use should get fixed which would be a significant improvement on the current situation. Regardless of all that, the safest way to use Windows is to never run as an administrator, with any version of UAC. And ideally avoid getting malware on your machine in the first place.

Make zeroday hard.