# Bypassing Windows Administrator Protection

James Forshaw bypassed Windows 11 25H2 Administrator Protection by forcing creation of a shadow admin's DOS device directory via an identification-level token, hijacking C: to load a malicious DLL and gain silent admin.

- Payout: Research
- Severity: high
- Program: Windows
- Credited: James Forshaw
- Disclosed: 2026-01-26
- Write-up quality: 9/10
- Original: https://projectzero.google/2026/26/windows-administrator-protection.html
- Library page: https://bugbountylibrary.com/r/blog%3Aprojectzero-google-2026-26-windows-administrator-protection-html
- Tags: domain:desktop impact:privesc kind:research platform:research sev:high tech:windows technique:chained technique:race-window technique:source-review vuln:auth-bypass vuln:privilege-escalation

**Target:** UAC service (appinfo.dll) / kernel DOS device object directory
**Root cause:** SeGetTokenDeviceMap lazily creates the per-logon-session DOS device directory with ZwCreateDirectoryObject (access checks disabled), and when impersonating an identification-level token the kernel assigns the primary token's owner SID, granting the limited user full control of the shadow admin's directory.
**Steps:**
1. Spawn a shadow admin process via `RAiProcessRunOnce` (runs runonce.exe from C:).
2. Race to open the new process before it touches a file; query its primary token.
3. Duplicate the token to an identification-level impersonation token.
4. Impersonate it and call `NtOpenDirectoryObject` on `\??` to force creation of `\Sessions\0\DosDevices\<authid>`.
5. Create a `C:` symlink in the new DOS device directory pointing to an attacker-controlled path.
6. Resume the process; a redirected DLL loads, executing attacker code as shadow admin.
**How found:** Forshaw had long known the DOS device directory creation quirk as a theoretical UAC bypass but couldn't exploit it because the admin directory was always pre-created. Administrator Protection's per-token shadow logon sessions made the directory absent, and the SYSTEM C:-drive mitigation prevented the UAC service from creating it during CreateProcessAsUser, reopening the race.
**Exploitation:** Attacker with a limited token races the silently-launched elevated process, forces creation of its DOS device directory while impersonating its token at identification level, plants a C: drive symlink, and waits for the elevated process to load a hijacked DLL from the redirected path.
**Escalation:** Chains five OS behaviors: per-token logon session, lazy directory init, Zw access-check bypass, identification-token owner fallback, and the SYSTEM C:-drive mitigation that prevents early directory creation.
**Insight:** When a feature changes token/logon-session semantics, revisit old 'theoretical' quirks you filed away: lazy kernel object creation under impersonation plus owner-SID fallback for identification tokens can hand you write access to a privileged namespace.