Solved Admin protection: Hardening security

I know brink posted this here, but I think it deserves its own article.

Evolving the Windows User Model – Introducing Administrator Protection​

spoofy
Microsoft
Jan 28, 2025
Previously, in part one, we outlined the history of the multi-user model in Windows, how Microsoft introduced features to secure it, and in what ways we got it right (and wrong). In the final part of this series, we will describe how Microsoft intends to raise the security bar via its new Administrator protection (AP) feature.

Core Principles for Administrator Protection​

As the main priority, Administrator protection aims to provide a strong security boundary between elevated and non-elevated user contexts. There are several additional usability goals that we will cover later, but for security, Administrator protection can be summarized by the following five principles:

1. Users operate within the Principle of Least Privilege
2. Administrator privileges only persist for the duration of the task for which they were invoked
3. Strong separation between elevated and non-elevated user accounts, except for paths of intentional access
4. Elevation actions must be explicit (e.g. no silent elevations)
5. Allowing a more granular use of elevated privileges by applications, rather than the “up-front” elevation practice common in User Account Control (UAC)

Specifically, principles two and three represent major changes to the existing design of the Windows user model, while principles one and four are intent on fulfilling promises of previous features (standard user and, to a lesser extent, UAC) and rolling back changes which degraded security (auto-elevation), respectively.

What Does Administrator Protection Fix and How?​

Administrator protection is nearly as much about what it removes as to what it adds. Recall, beginning with Windows Vista, the split-token administrator user type was added to allow a user to run as both standard user and administrator depending on the level of privilege required for a specific task. It was originally seen to make standard user more viable for wide-spread adoption and to enforce the Principle of Least Privilege. However, the features did not fully live up to expectations as UAC bypasses were numerous following the release of Windows 7.

As a refresher, when a user was configured as a split-token admin, they would receive two access tokens upon logon – a full privilege, “elevated” administrator token with admin group policy set to “Enabled” and a restricted, “unelevated” access token with admin group policy set to “DenyOnly”. Depending on the required run level of an application, one token or the other would be used to create the process.

Administrator protection changes the paradigm via System Managed Administrator Accounts (SMAA) – a local administrator account which is linked to a specific standard user account. Upon elevation, if a SMAA does not exist already it is created. Each SMAA is a separate user profile and member of the Administrators group. It is a local account named via the following scheme utilizing extra digits in the unlikely event of a collision:

• Local Account: WIN-ABC123\BobFoo
• SMAA: WIN-ABC123\admin_BobFoo

Or on collision:

• Local Account: WIN-ABC123\BobFoo (the account to be SMAA-linked)
• Local Account: WIN-ABC123\admin_BobFoo (another standard user account, oddly named)
• SMAA: WIN-ABC123\admin1_BobFoo

Similarly, for domain accounts, the scheme remains the same, except the SMAA will still be a local account:

• Domain Account: Redmond\BobFoo
• SMAA: WIN-ABC123\admin_BobFoo

To ensure these accounts can’t be abused, they are created as password-less accounts with additional logon restrictions to ensure only specific, SYSTEM processes are permitted to logon as the SMAA. Specifically, following an elevation request, a logon request is made via the Local Security Authority (LSA), and the following conditions are checked:

• Access Check. Call NtAccessCheck, including both an ACE for the SYSTEM account and a SYSTEM IL mandatory ACE with no read up, no write up, and no execute up. The access check must pass.
• Process Path. Call NtOpenProcess with the caller’s PID to obtain a process handle, then check the process image path via QueryFullProcessImageName. Compare the path to the hardcoded allow-list of binaries that are allowed to logon SMAA accounts.

The astute reader may notice that process path checks are not enforceable security boundaries in Windows; rather, the check is a defense-in-depth measure to prevent SYSTEM processes such as WinLogon or RDP from exposing SMAA logon surface to the user. In fact, Process Execution Block (PEB) spoofing was a class of UAC bypass in which a trusted image path was faked by a malicious process. However, in this case the PEB is not queried, but instead the kernel EPROCESS object is used to query the image path. As such, the process path check will be used alongside an allowlist to prevent current and future system components from misusing SMAA.

Splitting the Hive​

A major design compromise made with the split-token administrator model was that both “halves” of the user shared a common profile. Despite each token being appropriately restricted in its use, both restricted and admin-level processes could access shared resources such as the user file system and the registry. As such, improper access restrictions on a given file or registry key would allow a restricted user the ability to influence a privileged process. In fact, improper access controls on shared resources were the source of many classic UAC bypasses.

As an example, when the Event Viewer application, “eventvwr.exe”, attempts to launch “mmc.exe” as a High Integrity Level (IL) process, it searches two registry locations to find the executable path (1):

• HKCU\Software\Classes\mscfile\shell\open\command
• HKCR\mscfile\shell\open\command

In most circumstances, the first registry location does not exist, so the second is used to launch the process. However, an unprivileged process running within the restricted user context can create the missing key; this would then allow the attack to run any executable it wished at High IL. As a bonus for the attacker, this attack was silent as Event Viewer is a trusted Windows application and allows for “auto-elevation” meaning no UAC prompt would be displayed.




Similarly, the Windows Task Scheduler – which configures processes to run periodically – could be exploited to run arbitrary commands or executables in an elevated context. These attacks worked similarly in that they used writable local environment variables to overload system variables such as %WINDIR% to allow an attack to execute arbitrary applications with elevated privileges – with SilentCleanup being a particular favorite (2). Such attacks were attractive as an unprivileged process could also trigger the scheduled task to run at any time.



As separate-but-linked accounts, each with its own profile, registry hives are no longer shared. Thus, classic UAC bypasses, such as the registry key manipulation and environment variable (like many things in Windows, environment variables are backed in the registry) overloading attacks are mitigated. As an added benefit administrator tokens can now be created on-demand and discarded just as quickly, thus limiting exposure of the privileged token to the lifetime of the requesting process.

Rolling Back Auto-Elevations​

When auto-elevation was added in Windows 7, it was primarily done so to improve the user experience and allow simpler administration of a Windows machine. Unfortunately, despite several restrictions placed on applications allowed to auto-elevate, the feature introduced a huge hole in the Windows security model and opened a number of new avenues for UAC bypass.

Most prevalent of these bypasses were those which exploited the auto-elevating COM interface IFileOperation. Attackers would leverage this interface to write malicious DLLs to secure locations – a so-called “DLL Hijacking” attack. The attack would work whenever a process met all of the conditions for auto-elevation but ran at the Medium Integrity Level (IL). The malicious process would inject code into the target process and request the DLL payload be written to a secure path via IFileOperation. Whenever the DLL was loaded by an elevated process, the malicious code would be run, giving the attacker full privileges on the system.

With Administrator protection, auto-elevation is removed. Users will notice an increase in consent prompts, though many fewer than the Vista days as much work has been done to clean up elevation points in most workflows. Additionally, users and administrators will have the option to configure elevation prompts as “credentialed” (biometric/password/PIN) via Windows Hello or simply confirmation prompts. This simple change trades some user convenience for a reduction in attack surface of roughly 92 auto-elevating COM interfaces, 11 DLL Hijacks, and 23 auto-elevating apps. Of the 79 known UAC bypasses tested, all but one are now fully or partially mitigated. The remaining open issue around token manipulation attacks has been assigned MSRC cases and will be addressed.

It should be noted that not all auto-elevations have been removed. Namely, the Run and RunOnce registry keys found in the HKEY_LOCAL_MACHINE hive will still auto-elevate as needed. Appropriately, these keys are ACL’d such that only an administrator can modify them.

Improving Useability​

Administrator protection is not limited to security-focused changes only – improved useability is also a major focal point of the feature. Chief amongst the areas targeted for improvement is the removal of unnecessary elevations and “dead-ends”. Specifically, dead-ends occur when a functional pathway which requires administrator privileges does not account for a user operating as a standard user and thus presents no elevation path at all, resulting in the user interface either displaying the setting as disabled or not at all. In such cases, a so-called “over-the-shoulder” elevation is required – the same underlying mechanism used when elevating to the SMAA user in AP. Such scenarios represent huge inconvenience for non-Administrator accounts in both AP and non-AP enabled configurations.

One example of this scenario was the group policy editor (gpedit.exe). When launching as a standard user, an error prompt would be displayed, and the app would be launched in an unusable state.

Figure 1: Error Dialog


Figure 2: GPEDIT.exe in an error state

More Work To Be Done​

Administrator protection represents a huge jump in the security of the Windows OS. However, as always, there is more work to be done. While AP has mitigated large classes of vulnerabilities, some remain, albeit in a diminished state.

DLL hijacking attacks prior to AP primarily relied on abusing the auto-elevating IFileOperation COM interface to write a malicious DLL to a secure path. As auto-elevation has been removed, this path no longer exists. However, situations where an unsigned DLL is loaded from an insecure path still represent a potential AP bypass. Note that the user will still be prompted for elevation in such a scenario but may not be aware that a malicious DLL is being included in the process.

Token manipulation bypasses such as those shown by James Forshaw and splinter_code, while specifically patched now, remain a class of potential exploitation. Elevation prompts are shown only before creation of an elevated token, not use. Therefore, should additional pathways be discovered where an elevated token can be obtained by a malicious process, AP would not be positioned to stop it from silently elevating. However, MSRC cases for known variants of token manipulation/reuse attack have been filed and fixes are currently in-development.

Lastly, attacks which rely on obtaining a UIAccess capability from another running process are partially mitigated by AP. Previously, UAC bypass attacks would launch an auto-elevating app, such as mmc.exe, and then obtain a UIAccess-enabled token — a token which gives a lower-privileged process the ability to manipulate the UI of a higher-privileged process, typically used for accessibility features. With AP enabled, all attempts to launch an elevated process would be met with a consent prompt which an attacker would be unable manipulate with a UIAccess token alone. However, in situations where a user has previously elevated a running process, an attack would be able to obtain a UIAccess token and manipulate the UI with no additional consent prompts.

This list is not exhaustive, it is likely edge cases will pop up which will require attention. Fortunately Administrator protection is covered by the Windows Insider Bug Bounty Program and internal efforts by MORSE and others will continue to identify remaining issues.

A Welcome Security Boundary​

We In MORSE review quite a few features in Windows and are big fans of Administrator protection. It addresses many gaps left by UAC today and adds protections which for all intents and purposes simply did not exist before. The feature is far from complete, usability improvements are needed, and there are some remaining bugs which will take time to resolve. However, the short-term inconvenience, is worth long term security benefit to users. While Administrator protection will certainly experience some growing pains, even in its current state, it’s a leap forward for user security.

Going forward, we encourage those users who prioritize strong security to give Administrator protection a try. If you encounter an issue, send us feedback using the feedback tool. Lastly, for app developers, we ask they update their applications to support Administrator protection, as it will eventually become the default option in Windows.