Windows Administrator Protection Bypass: Exploiting UI Access for Privilege Escalation

By [Cybersecurity Journalist]

Key Findings

Security researcher James Forshaw has disclosed technical details of five critical vulnerabilities in Microsoft's UI Access implementation that allowed attackers to bypass Windows Administrator Protection. All nine bypasses identified during Forshaw's research—including the five detailed in this analysis—have now been patched by Microsoft.

The flaws stem from the UI Access feature, originally introduced in Windows Vista to support accessibility tools like screen readers. By abusing this functionality, attackers could achieve arbitrary code execution in a High integrity UI Access process, compromising Administrator Protection's security boundary without user interaction.

Technical Background: UI Access and UIPI

The Evolution of Window Interaction Security

Prior to Windows Vista, any process running on a user's desktop could control any window created by another process—including privileged ones—via window messages. This behavior was exploited in so-called Shatter Attacks, where a limited user could manipulate privileged UI components to elevate privileges. Microsoft mitigated this by removing UI elements from privileged code.

With the introduction of User Account Control (UAC) in Windows Vista, processes began running at different privilege levels on the same desktop. To prevent cross-privilege window manipulation, Microsoft implemented User Interface Privilege Isolation (UIPI), leveraging Mandatory Integrity Control (MIC) to restrict process interactions. UIPI blocks a process from sending window messages or using hooks to interact with windows created by a higher-integrity process.

For example:

• A limited user process (Medium integrity) cannot send messages to an administrator process (High integrity).
• UIPI also prevents other UI functionality, such as windows hooks, from being used across integrity levels.

The Accessibility Dilemma

UIPI's restrictions created a significant problem for accessibility tools like screen readers. These applications, running as limited users, could no longer interact with administrator processes—blocking them from reading window contents or performing actions like clicking buttons. To resolve this, Microsoft introduced the UI Access flag.

When set on a process's access token during initialization, the UI Access flag grants special permissions to bypass many UIPI restrictions. Enabling this flag requires the SE_TCB_NAME privilege, which is only available to system services. As a result, creating a UI Access process involves a system service—typically the UAC service—via the RAiLaunchAdminProcess RPC call.

UI Access Process Creation Flow

To prevent misuse, the UAC service enforces strict checks on the executable file before enabling the UI Access flag:

1. Manifest Requirement: The executable must have an embedded manifest with the uiAccess attribute set to true.
2. Code Signing: The file must be signed by a code signing certificate trusted by the local machine's root certificate store.
3. Secure Location: The executable must reside in an administrator-only location on the system drive, such as:
   • Program Files directory
   • Windows directory (excluding known writable locations)
   • System32 directory (excluding known writable locations)

If these criteria are met, the UAC service:

• Takes a copy of the caller's access token.
• Enables the UI Access flag.
• Increases the integrity level based on the caller:
  • Limited user of a UAC administrator: Sets integrity to High.
  • Administrator: Sets integrity to High (typically a no-op).
  • Normal user: Sets integrity to the caller's integrity + 16, up to a maximum of High.

Important Note: The UI Access flag only permits bypassing a limited set of operations, such as sending window messages to higher-integrity processes. It does not allow the use of windows hooks, which could enable code injection.

Exploiting UI Access in Administrator Protection

The Core Vulnerability

Administrator Protection, a newer Windows feature, was designed to create a secure boundary for UAC by separating the limited user from the shadow administrator. However, Forshaw discovered that UI Access processes could undermine this boundary:

• When a limited user creates a UI Access process via RAiLaunchAdminProcess, the process runs under the caller's token (the limited user) but with the UI Access flag enabled and integrity set to High.
• A High integrity process can compromise any other High integrity process on the same desktop, even if it runs as a different user.
• Since the UI Access process runs as the limited user, there is no profile separation—a key improvement in Administrator Protection.
• The elevation to High integrity is silent, allowing attackers to break the security boundary without prompting the user.

Achieving Arbitrary UI Access Execution

Forshaw identified multiple methods to achieve arbitrary code execution in a High integrity UI Access process. While Microsoft had previously indicated that these issues were not a priority for fixing, several have since been patched. The techniques fall into three main categories:

1. Bypassing the Secure Application Directory Check

The UAC service's AiCheckSecureApplicationDirectory method validates that the executable resides in a secure location. Forshaw discovered several ways to bypass this check:

• NTFS Named Streams: In 2017, Forshaw reported a bypass where an attacker could write an NTFS named stream to a directory writable by a limited user. For example, the C:\Windows\tracing directory is writable but excluded from the secure check. By writing a named stream (e.g., C:\Windows\tracing:file.exe), the file would be considered secure because the path appears to be within C:\Windows. This issue was resolved in a later Windows version.

• Writable Files/Directories in Secure Locations: Attackers could overwrite an existing writable file in a secure location with a malicious executable. The CreateProcessAsUser API used by the UAC service does not require a specific file extension, allowing any file to be executed. Alternatively, attackers could copy an executable into a writable directory within a secure location.

• MSIX Installer Abuse: In recent research, Forshaw found that the Windows installer could place MSIX files into C:\Program Files\WindowsApps, a directory not excluded by the secure check. Windows 11 permits installing signed MSIX files without administrator privileges by default. By packaging a UI Access executable into an MSIX installer and signing it with an arbitrary certificate, attackers could place the executable in a secure location. This issue has since been fixed by excluding the WindowsApps directory.

2. Additional Historical Bypasses

Forshaw also referenced other historical methods for achieving arbitrary UI Access execution, including:

• DLL Planting: Hijacking legitimate executables in secure locations by planting malicious DLLs.
• COM Abuse: Exploiting COM components that use message-only windows to compromise processes without displaying UI.

Impact Analysis

The vulnerabilities described in this research pose a significant risk to Windows systems with Administrator Protection enabled:

• Privilege Escalation: Attackers could elevate privileges from a limited user to High integrity, effectively bypassing Administrator Protection's security boundary.
• Silent Exploitation: The elevation to High integrity occurs without user interaction, making detection difficult.
• Arbitrary Code Execution: Once arbitrary code execution is achieved in a High integrity UI Access process, attackers can compromise any other High integrity process on the same desktop.
• No Profile Separation: The lack of profile separation undermines one of Administrator Protection's core security improvements.

Recommendations

Security professionals and system administrators should take the following steps to mitigate risks associated with these vulnerabilities:

1. Apply Patches: Ensure all Windows systems are updated with the latest security patches from Microsoft to address the fixed bypasses.
2. Monitor UI Access Processes: Implement monitoring for unusual UI Access process creation, particularly those running at High integrity.
3. Restrict Access to Secure Locations: Limit write access to directories like Program Files, Windows, and System32 to administrators only.
4. Audit Code Signing Certificates: Review and restrict the code signing certificates trusted by the local machine's root certificate store to prevent abuse.
5. Disable Unnecessary Accessibility Features: Disable UI Access for applications that do not require it, reducing the attack surface.

Conclusion

James Forshaw's research highlights the ongoing challenges in securing Windows' privilege escalation mechanisms. While UI Access was designed to support accessibility, its implementation introduced significant security risks that could be exploited to bypass Administrator Protection. Microsoft has addressed the vulnerabilities described in this analysis, but the research underscores the importance of rigorous security testing and proactive monitoring to defend against similar threats in the future.

For further technical details, refer to Forshaw's original blog post on Project Zero.