Google Project Zero’s James Forshaw has pulled back the curtain on a subtle, multistage weakness that could have let attackers sidestep Microsoft’s new Administrator Protection model and silently obtain administrator privileges — and the discovery exposes how decades-old Windows behaviors can undermine even carefully rethought security models. Forshaw’s analysis shows nine distinct vulnerability paths that, in combination with legacy kernel behaviors and token semantics, could enable a limited user to hijack an elevated process’s view of the C: drive and force code execution at administrator privilege. Microsoft has already pushed fixes — some delivered in the optional KB5067036 preview and others folded into subsequent security bulletins — but the episode is an important reminder that new defenses must be validated against the operating system’s long tail of inherited design decisions.
Administrator Protection is Microsoft’s successor-style approach to User Account Control (UAC): instead of relying on split tokens that belong to the same user account, Windows creates a separate, hidden “shadow” administrator account to host elevated processes. The idea is straightforward and powerful: keep day-to-day processes running with least privilege, and only spawn ephemeral, strongly authenticated elevated sessions for tasks that require administrative rights. That model reduces exposure to credential-stealing and token-theft attacks because the interactive user’s credentials are not directly reused for elevated processes.
But safely implementing that model in a legacy-rich OS requires ironclad assumptions about how tokens, logon sessions, kernel object namespaces, and access controls interact. Forshaw’s Project Zero write-up demonstrates how a combination of three long-standing Windows behaviors — lazy creation of per-logon DOS device directories, kernel-side creation calls that temporarily bypass access checks, and token-owner semantics that kick in during object creation — can be chained into a practical privilege escalation under Administrator Protection.
Put plainly: Administrator Protection changes how elevation tokens are produced and when unique logon sessions are created. In that new flow, a limited process can sometimes manipulate kernel object creation logic so that an administrator logon session’s DOS device namespace is created with an attacker-controlled owner, enabling drive-letter redirection (notably C
and subsequent hijack of DLL loads or file references inside the elevated process.
This is not a single simple bug. It is a choreography of five separate, legitimate OS behaviors that together create an exploitable pathway. Forshaw reports nine related vulnerabilities in total, of which a particularly notable Logon Sessions bypass was reconstructed and responsibly disclosed. Microsoft responded and shipped mitigations in preview and security updates.
Microsoft’s rollout model for Administrator Protection has been cautious. The feature was introduced to Insiders and rolled out via optional preview updates to broaden testing; administrators can enable the feature through policy or OMA-URI in managed environments. The research highlighted that the Administrator Protection model was not yet widely available in generally available (GA) builds and was still being exercised in Canary/Insider channels when Forshaw performed his tests — a fact that likely reduced the real-world exposure window while patches were prepared.
The important operational takeaway is that Microsoft applied mitigations that target the kernel object creation pathway and limited the circumstances under which per-logon DOS device directories can be created when impersonation is in effect. Those mitigations close the door on the specific exploitation technique Forshaw demonstrated, but they also illustrate the complexity of defending a decades-old platform when large behavioral changes are introduced at higher layers.
This work also underscores the ongoing need for:
The good news is twofold: first, the bypass results from a narrow, well-understood interaction of legacy behaviors, not a fundamental impossibility of the shadow-admin model. Second, Microsoft implemented targeted mitigations quickly once the issues were disclosed. The company’s approach — iterating in the Insider canal, responding to researcher reports, and refining behavior before broad GA rollout — follows a sound risk-management pattern.
That said, defenders must remain pragmatic. New security models layered on long-lived OS semantics require continuous validation, and operations teams need to accelerate patching and testing cycles for feature-flagged security changes. For security-conscious organizations, Administrator Protection is a technology to embrace — but only as part of a comprehensive endpoint hardening strategy that includes patch discipline, monitoring, and least-privilege operations.
Source: theregister.com Old Windows quirks help punch through new admin defenses
Background / Overview
Administrator Protection is Microsoft’s successor-style approach to User Account Control (UAC): instead of relying on split tokens that belong to the same user account, Windows creates a separate, hidden “shadow” administrator account to host elevated processes. The idea is straightforward and powerful: keep day-to-day processes running with least privilege, and only spawn ephemeral, strongly authenticated elevated sessions for tasks that require administrative rights. That model reduces exposure to credential-stealing and token-theft attacks because the interactive user’s credentials are not directly reused for elevated processes.But safely implementing that model in a legacy-rich OS requires ironclad assumptions about how tokens, logon sessions, kernel object namespaces, and access controls interact. Forshaw’s Project Zero write-up demonstrates how a combination of three long-standing Windows behaviors — lazy creation of per-logon DOS device directories, kernel-side creation calls that temporarily bypass access checks, and token-owner semantics that kick in during object creation — can be chained into a practical privilege escalation under Administrator Protection.
Put plainly: Administrator Protection changes how elevation tokens are produced and when unique logon sessions are created. In that new flow, a limited process can sometimes manipulate kernel object creation logic so that an administrator logon session’s DOS device namespace is created with an attacker-controlled owner, enabling drive-letter redirection (notably C
and subsequent hijack of DLL loads or file references inside the elevated process.This is not a single simple bug. It is a choreography of five separate, legitimate OS behaviors that together create an exploitable pathway. Forshaw reports nine related vulnerabilities in total, of which a particularly notable Logon Sessions bypass was reconstructed and responsibly disclosed. Microsoft responded and shipped mitigations in preview and security updates.
Why this matters: rethinking UAC vs Administrator Protection
UAC was never a security boundary
User Account Control was always intended as a usability mechanism: a consent/approval surface that reduces the frequency of accidental admin usage. Because UAC’s split-token model kept an administrator’s linked token as part of the same user account, early design choices and compatibility concessions left numerous “backdoors” or bypass patterns available to attackers. Over time Microsoft de-emphasized UAC as a hard security boundary; some bypasses remained low priority because they mainly impacted a feature Microsoft chose not to treat as an absolute barrier.Administrator Protection tries to be a true boundary
Administrator Protection takes a more defensive posture. By provisioning a separate, ephemeral shadow admin account and forcing strong in-band authentication (Windows Hello/PIN/biometric) to grant just-in-time administrative rights, Microsoft aims to make elevation a true security boundary. When implemented correctly, the shadow model significantly raises the bar for credential theft and lateral escalation attacks that rely on tokens or persistent elevated processes.But the OS has a long memory
Windows is a complex stack built across decades. Kernel object semantics, legacy innards like the DOS device object directory, and nuances in token impersonation levels are not easy to rework without breaking compatibility. Forshaw’s work shows how older behaviors can remain meaningful attack surfaces even when higher-level models are rearchitected. Administrator Protection is a substantial step forward, but it must be validated against the OS’s established runtime semantics — including places where kernel creation APIs disable access checks for legitimate reasons.Deep dive: the technical chain that made a bypass practical
The vulnerability class Forshaw describes rests on a sequence of kernel and token behaviors. Below is a distilled, step-by-step technical narrative of how the bypass works in practice.Key technical concepts
- Logon session: a kernel-visible construct that represents an authentication instance for a user. Each session has a unique 64-bit authentication ID (LUID).
- DOS device object directory (\??): where kernel-level drive-letter symbolic links (for example, C are represented. Windows keeps per-logon-session directories under \Sessions\0\DosDevices\<auth-id> and a global \GLOBAL?? directory. The kernel checks the session-specific directory first, then falls back to the global namespace.
- ZwCreate vs NtCreate semantics: certain kernel calls (the Zw-prefixed variants) disable user-mode access checks when invoked in kernel context unless specific flags force access checking.
- Token impersonation levels: tokens can be used at different impersonation levels (identification, impersonation, etc.). Identification-level tokens allow some limited operations such as querying or constructing kernel objects, but not full access.
- CREATOR OWNER inheritable ACL: directories under \Sessions\0\DosDevices have a DACL that grants ownership-based access; when a kernel call creates a child object with a CREATOR OWNER ACE, the owner is replaced based on the token context at creation time.
The exploitation choreography
- Administrator Protection creates unique shadow admin logon sessions. Unlike UAC-linked tokens that reuse an existing linked administrator session, Administrator Protection authenticates and instantiates a new shadow admin instance with its own unique logon session, and therefore its own DOS device object directory path — which is not yet created because directories are created lazily on first access.
- The kernel lazily creates per-logon DOS device directories using ZwCreateDirectoryObject. Because creation happens on demand, the kernel code that creates the directory runs with disabled access checking — a legitimate behavior required to initialize the environment even when the kernel cannot predict the caller’s admin status.
- If you can obtain an identification-level handle to the shadow admin token, impersonate it, and then trigger the kernel to create the DOS device directory while impersonating, access-checking is bypassed and the resulting directory inherits ownership fields in a way that can be manipulated. Forshaw notes the ability to obtain a token handle via NtQueryInformationToken with TokenLinkedToken and then to adjust the token’s owner SID before impersonation — a permitted token operation — so the final directory owner becomes the attacker’s SID.
- Once owned by the attacker, the session-specific DOS device directory can contain a C: symbolic link pointing somewhere under attacker control. Because the kernel checks the session directory first, the elevated process will resolve C: to the attacker-influenced path when it opens files or loads DLLs.
- If the elevated process hasn’t yet accessed files under C:, the attacker can resume the suspended admin process (created, for example, suspended by system services) and cause it to load attacker-controlled resources. Certain system mitigations exist to stop exactly this — for instance, kernel behavior that ignores impersonated DOS device directories when the caller is SYSTEM and accessing the C: drive — but Administrator Protection’s per-token session creation and the timing of when directories are created make a narrow window exploitable.
The disclosure and Microsoft’s response
Forshaw reported nine related issues to Microsoft in December. According to the analysis he published, Microsoft fixed the most critical behaviors by preventing DOS device object directory creation while impersonating a shadow administrator token at the identification level. Some fixes were integrated into the optional preview update KB5067036 and others were addressed in subsequent security bulletins and Patch Tuesday updates.Microsoft’s rollout model for Administrator Protection has been cautious. The feature was introduced to Insiders and rolled out via optional preview updates to broaden testing; administrators can enable the feature through policy or OMA-URI in managed environments. The research highlighted that the Administrator Protection model was not yet widely available in generally available (GA) builds and was still being exercised in Canary/Insider channels when Forshaw performed his tests — a fact that likely reduced the real-world exposure window while patches were prepared.
The important operational takeaway is that Microsoft applied mitigations that target the kernel object creation pathway and limited the circumstances under which per-logon DOS device directories can be created when impersonation is in effect. Those mitigations close the door on the specific exploitation technique Forshaw demonstrated, but they also illustrate the complexity of defending a decades-old platform when large behavioral changes are introduced at higher layers.
Strengths of Microsoft’s approach — and why Administrator Protection is still a win
- Design direction is sound. Moving from split tokens within the same user account to an external, ephemeral shadow admin model is a principled security improvement. It reduces the attack surface for credential theft and token replay, and forces explicit re-authentication for sensitive actions.
- Quick remediation and responsible disclosure pipeline. Project Zero reported the issues, and Microsoft implemented fixes in the preview channel and in security bulletins. That response cycle — researcher discovery, responsible disclosure, and vendor patching — is functioning as intended.
- Defense-in-depth preserved. Administrator Protection does not rely on a single mechanism; it pairs with existing mitigations like VBS, LSASS protections, and access-control improvements to create layered resistance to common privilege escalation vectors.
- Explicit tradeoffs acknowledged. Microsoft deliberately accepts more frequent consent prompts and compatibility wrinkles in exchange for a stronger security model — a healthy stance for enterprise-grade defense.
Risks, limitations, and open questions
- Legacy behaviors are a persistent liability. The root cause of the bypass was not a brand-new API; it was historical kernel behavior (lazy creation and Zw call semantics) and token owner semantics. Fixing modern security features without re-auditing the entire kernel-object lifecycle risks leaving subtle interactions exploitable.
- Complex chains multiply audit difficulty. The vulnerability required five independent behaviors to align. That complexity makes it far harder for both vendors and researchers to test exhaustively. It also makes formal verification impractical in many sections of the OS.
- Compatibility-driven design choices can reintroduce risk. Administrator Protection intentionally preserved some legacy compatibility behaviors (for example, continuing to return an identification token from TokenLinkedToken) to avoid breaking applications. Those compatibility allowances were precisely what enabled Forshaw’s exploit to become practical. Vendors must balance compatibility and security; this is a vivid example of where compatibility increases attack surface.
- Patch surface is broad and subtle. The fix applied by Microsoft blocks a specific creation scenario, but attackers may find other sequences — perhaps unrelated to DOS device directories — where the new per-elevation logon session semantics interact poorly with legacy kernel behaviors. Continued vigilance and follow-up hardening is required.
- Operational exposure depends on deployment cadence. Many organizations defer optional preview updates. While Microsoft shipped mitigations quickly for Insider and preview channels, production exposure will depend on when the fixes are rolled into mandatory updates and when administrators apply them. The usual operational lag in enterprise patching can leave windows of vulnerability.
Practical recommendations for administrators and power users
- Treat Administrator Protection as an important security control — and test before enabling broadly. The feature model is a positive architectural shift. If you manage devices, enable Administrator Protection in a test ring first and validate critical applications and drivers against it.
- Keep systems patched. Apply the fixes Microsoft published that address Administrator Protection issues. Because some mitigations were delivered in optional preview packages and others in monthly security bulks, confirm cumulative updates are applied to production systems as soon as feasible.
- Limit attack surface on endpoints. Continue to enforce application allowlisting, minimize local administrator accounts, and reduce the presence of software that runs with persistent elevated privileges. Administrator Protection reduces risk, but does not replace sound endpoint hygiene.
- Monitor for suspicious local privilege escalation activity. Given the exploit pattern involves manipulating tokens, impersonation, and creation of symbolic links in kernel-visible directories, watch for anomalous process creation patterns, token usage anomalies, and odd accesses to system namespaces from low-privileged processes.
- Audit service behaviors that create elevated processes suspended. The exploit requires timing around starting elevated processes suspended and resuming them before they access files. Any system or service that creates elevated processes in a paused/suspended state could be a vector; review such services and consider hardening or monitoring them.
- Educate help desk and desktop support teams. Administrator Protection changes the behavior of elevation and may increase prompts or change workflows. Prepare help desk scripts and user guidance so legitimate actions aren’t misinterpreted as attacks when users encounter new consent flows.
Why researcher insight like this is valuable for long-term platform security
Forshaw’s write-up is a textbook example of what responsible, deep-dive vulnerability research should look like. Rather than a single-shot exploit, the analysis maps a web of legitimate OS behaviors and shows how attack paths can emerge at their intersections. That’s the level of rigor needed when hardening a mature platform: testing simple assumptions about object creation and token semantics, and ensuring that subtle timing and lifecycle semantics cannot be abused.This work also underscores the ongoing need for:
- Continuous red-team style testing of new platform features,
- Stronger heuristics or formal checks around kernel object creation and ownership semantics, and
- Threat modeling that anticipates how legacy behavior can be repurposed in novel elevation models.
Final analysis: progress with caveats
Administrator Protection is a substantial evolution of Windows’ privilege model. It can materially reduce the usefulness of stolen credentials and make local privilege escalation more difficult for adversaries who rely on token theft or persistent admin sessions. Project Zero’s findings, however, are a timely reminder that those gains are only as strong as their weakest compatibility concession.The good news is twofold: first, the bypass results from a narrow, well-understood interaction of legacy behaviors, not a fundamental impossibility of the shadow-admin model. Second, Microsoft implemented targeted mitigations quickly once the issues were disclosed. The company’s approach — iterating in the Insider canal, responding to researcher reports, and refining behavior before broad GA rollout — follows a sound risk-management pattern.
That said, defenders must remain pragmatic. New security models layered on long-lived OS semantics require continuous validation, and operations teams need to accelerate patching and testing cycles for feature-flagged security changes. For security-conscious organizations, Administrator Protection is a technology to embrace — but only as part of a comprehensive endpoint hardening strategy that includes patch discipline, monitoring, and least-privilege operations.
What to watch next
- Monitor Microsoft’s cumulative updates for the inclusion of all Administrator Protection fixes into the mandatory update stream.
- Watch for follow-up research: complex, multi-behavior exploit chains often inspire additional variants; continued scrutiny by independent researchers is likely.
- Track compatibility notes and telemetry reports from Microsoft when Administrator Protection rolls into broader production channels; watch for prospective regressions or app-compat exceptions that could affect deployment.
- Evaluate endpoint telemetry for any patterns of unusual token queries or symbolic link creation attempts in object namespaces such as \Sessions\0\DosDevices.
Source: theregister.com Old Windows quirks help punch through new admin defenses
