Windows 11 Administrator Protection Bypass: Critical Vulnerability in New Security Feature
Security researcher discovers method to silently bypass Windows 11 25H2's Administrator Protection, gaining full admin privileges. All reported flaws now patched by Microsoft.
Windows 11 Administrator Protection Bypass Discovered in 25H2 Release
Security researcher James Forshaw has identified a critical vulnerability in Microsoft's new Administrator Protection feature, introduced in Windows 11 version 25H2. This flaw allowed attackers to silently bypass the security mechanism and gain full administrator privileges. All reported vulnerabilities have since been patched by Microsoft, though the feature remains disabled as of December 2025 due to unrelated compatibility issues.
Technical Details of the Bypass
Background: Administrator Protection
Microsoft designed Administrator Protection to replace the aging User Account Control (UAC) system, which has long been criticized for its weak security boundaries. Unlike UAC, which shared profile resources (e.g., registry hives, user directories) between limited and administrator accounts, Administrator Protection leverages a shadow administrator account with a separate logon session. This approach prevents:
- Profile resource sharing between accounts
- Token impersonation attacks
- Auto-elevation of Microsoft binaries
However, Forshaw's research uncovered nine distinct bypass techniques, one of which exploited a complex interaction between logon sessions and DOS device object directories.
The Vulnerability: Logon Session Hijacking
The most notable bypass (detailed in Project Zero Issue 432313668) stemmed from how Windows handles logon sessions and DOS device object directories. Key technical components included:
- Logon Session Isolation: Each shadow administrator token in Administrator Protection receives a unique logon session, unlike UAC's shared session model.
- Lazy Initialization: DOS device object directories (e.g.,
\Sessions\0\DosDevices\X-Y) are created on-demand when accessed, not during logon. - Access Check Bypass: The kernel's
SeGetTokenDeviceMapfunction usesZwCreateDirectoryObjectwithout enforcing access checks (OBJ_FORCE_ACCESS_CHECKflag), allowing creation of directories even when impersonating an identification-level token. - Owner SID Assignment: When creating objects under an identification-level token, Windows uses the primary token's owner SID (the limited user) rather than the impersonated token's SID, granting unintended access.
- SYSTEM Process Mitigation: A security feature preventing
SYSTEMprocesses from accessing impersonated tokens' DOS device directories delayed directory creation until after process startup, enabling the race condition.
Exploitation Steps
Forshaw's proof-of-concept required chaining these behaviors:
- Spawn a suspended shadow admin process via
RAiProcessRunOnce(e.g.,runonce.exe). - Open the process token before it accesses any file resources.
- Duplicate the token as an identification-level token.
- Force directory creation by accessing
\??while impersonating the shadow admin token. - Create a malicious symlink in the new DOS device directory to hijack the
C:drive. - Resume the process, forcing it to load attacker-controlled DLLs.
Impact Analysis
Security Implications
- Silent Privilege Escalation: Attackers could gain administrator privileges without user interaction, bypassing the intended security boundary.
- Legacy Bypass Persistence: Several of the nine reported flaws were variations of long-standing UAC bypasses (e.g., loopback Kerberos abuse), demonstrating how incremental improvements can inherit historical weaknesses.
- Complex Attack Surface: The vulnerability required chaining five distinct OS behaviors, highlighting how subtle design interactions can create critical flaws.
Microsoft's Response
Microsoft addressed all reported issues prior to the feature's official release in KB5067036 (October 2025). The primary fix:
Prevents creation of DOS device object directories when impersonating shadow administrator tokens at identification level.
No CVE was assigned to this specific bypass, as it was remediated before public disclosure.
Recommendations for Security Teams
-
Patch Management:
- Ensure systems are updated with KB5067036 or later.
- Monitor for future security bulletins related to Administrator Protection.
-
Configuration Best Practices:
- Disable legacy UAC modes if Administrator Protection is enabled (mutually exclusive).
- Restrict local administrator group membership to minimize attack surface.
- Audit elevation prompts to detect potential coercion attacks.
-
Monitoring and Detection:
- Watch for unusual DOS device directory creation (e.g.,
\Sessions\0\DosDevices\*paths). - Alert on process token duplication attempts targeting shadow admin tokens.
- Log suspended process creation followed by rapid token access.
- Watch for unusual DOS device directory creation (e.g.,
-
Defensive Architecture:
- Avoid running as administrator for daily tasks (the most effective mitigation).
- Implement application whitelisting to block unauthorized executables.
- Use Windows Defender Application Control (WDAC) to enforce code integrity policies.
Final Assessment
While Administrator Protection represents a significant security improvement over UAC, Forshaw's research demonstrates that incremental changes to legacy systems can introduce unexpected attack vectors. The feature's reliance on shadow accounts and logon session isolation—while more secure—created new edge cases that required careful hardening.
Microsoft's rapid response to these vulnerabilities suggests the company is treating Administrator Protection as a true security boundary, a departure from its historical approach to UAC bypasses. However, security teams should remain vigilant, as:
- Malware will likely adapt to target this new mechanism.
- Further design iterations may be needed to address compatibility and security trade-offs.
- The feature's temporary disablement (as of December 2025) underscores ongoing stability challenges.
For now, organizations should treat Administrator Protection as an evolving security control and prioritize its deployment once Microsoft resolves the current compatibility issues.