Microsoft Evolving the Windows 11 User Model – A Look to the Past

Early in 2024, the MORSE team investigated the new Administrator protection (AP) feature in Windows. Believing context is important to understand the decisions that shape the Windows security model, MORSE committed to sharing our thoughts on this new and compelling feature.

From its earliest days, Windows was designed around the concept that a computer and its user were indistinguishable entities, freely sharing all resources within the system and its configuration. On single-user systems such as this, the user was free to manipulate the system in any way they saw fit. In other words, the machine, its primary user, and its administrator were one and the same – a paradigm common to other operating systems at that time. Features seen commonly today such as user accounts and file access privileges simply did not exist in 16-bit Windows. In fact, these features would not be seen until over fifteen years following the release of Windows 1.0. In the first of this two-part series, we will revisit the history of Windows and its user model to better understand how the OS evolved and to contextualize the decisions made by Microsoft from the mid-80s to today.

Even someone with a basic knowledge of computer security can see the issues inherent in running a system with full administrator privileges and no user isolation. Yet, even with the eventual introduction of features such as user account types, discretionary access controls (DAC), and User Account Control (UAC), decisions made in the interest of application compatibility and user experience would have long-lasting, negative impacts on the security of Windows. In the second part, we will introduce how Microsoft addresses the limitations of past designs, by diving into some of the technical details of Windows’ new Administrator protection feature, how it differs from UAC, and how AP paves the way forward to a more secure future.

Early History of Windows​

Windows 1.0 was the first major release of the operating system, designed as a graphical shell over MS-DOS, becoming available in 1985. Designed as a 16-bit, single-user operating system and somewhat rudimentary in its design, the user was often required to tinker with system files manually to configure their system. Microsoft would continue Windows development upon this same model, through Windows 3.11 in 1993, until the release of its new 32-bit operating system – the eponymous Windows 95.

While Windows 95 would prove to be a major commercial success, it did not deviate much from its single-user origins, despite added support for “user profiles”, which contained desktop layouts, Start menu shortcuts and other personalized settings. Yet, no isolation mechanisms existed to prevent users from accessing each other’s files and settings. Microsoft would continue to iterate across major releases, mostly focused on the user experience, from Windows 95 to Windows 98 and finally to Windows ME. In parallel, however, Microsoft was developing its first true multi-user operating system.

A New Multi-User Model​

Windows NT versions, later rebranded as Windows 2000, were targeted as an enterprise-level operating system and included isolated user accounts by design. In addition, it offered a “standard user” type account, which limited the actions available to the user such as the inability to install software or modify system files, to complement the omnipotent “Administrator” account, which behaved much more like the traditional Windows single-user systems. Standard user accounts also allowed for administration via immutable system policies. All such isolation mechanisms were made possible by the adoption of the NTFS file system which provided access control lists (ACL) on files and directories. NTFS ACLs allowed system and configuration files to only be writable to an Administrator and for standard users to protect their files from other non-Administrator accounts. However, it would still be a couple of years before these changes found their way into a consumer-facing Windows product.

In 2001, Microsoft released Windows XP to much critical acclaim. As a product, it unified enterprise and consumer Windows to a single NT kernel-based platform. This unification brought strict user accounts to the consumer Windows experience for the first time, including the ability to run without administrator privileges. The transition was not without challenges, however, as the Windows application ecosystem was largely designed around the old single-user model. Attempts to run or even install the average Windows 9x application on XP as a standard user would often prove to be a difficult endeavor. Given users would rightly expect their software to work seamlessly from Windows 9x to XP, Microsoft made the decision to default all user accounts to Administrator – a decision that would have major security ramifications over the following decades.

Administrator Everywhere​

As the vast majority of consumer desktops ran with most or all users as administrator accounts, third party developers were not incentivized to migrate their legacy applications to standard user accounts. Further, with the near-immediate commercial success of Windows XP, new software products, from both third parties and Microsoft themselves, defaulted to the full-administrator status quo. For enterprise users, the story was much the same: employees running as standard user were often unable to operate their PC. Simple operations, such as opening the system clock required a superfluous, upfront front administrator check, normally only required when changing the time. The challenges of running as a standard user resulted in many IT teams allowing exceptions for employees to run completely unmanaged as full Administrators.

In the rare case malware could not gain system-wide control via exploitation of network-facing applications such as browsers, instant messengers, or email clients, it could leverage the large local attack surface for privilege escalation within the many processes running within the Administrator context of a user. In fact, third-party application developers often took advantage of this paradigm by having their software surreptitiously download and install additional, unrelated programs. This environment led to a proliferation of adware, bloatware, and root-kit-level malware.

Microsoft would eventually release Service Pack 2 to address many of the security issues plaguing the OS. However, despite introducing security features that would have made Windows XP the most secure consumer operating system available, with nearly all users still running as Administrator, many of the benefits of the updated security model were negligible in practice.

UAC and Other Improvements​

Windows Vista arrived in the various customer segments over a two-month period beginning in late 2006, releasing with a major focus on security. While the public reception was mixed, primarily due to user experience concerns, it introduced several impactful security features including user account control (UAC), user interface privilege isolation (UIPI), and mandatory integrity controls (MIC). Vista truly represented the security leap forward that Windows XP Service Pack 2 intended to be.

Mandatory Integrity Controls​

Prior to Vista, there was no concept of trust levels among applications running under the same user account; if an account was an Administrator, then all processes running within the context of that user also had Administrator privileges. “Integrity levels (IL)” were introduced to processes (and other securable objects) to define a minimum level of trust a user must have to access the process (or, again, other securable objects). Windows defined five integrity levels as seen in Figure 1.


Figure 1: 5 Integrity levels

Examples of how a Vista system ran under MIC were system and service accounts such as Local System, Local Service, and Network Service running applications at System level integrity; Administrators and Backup Operators running at High IL; and authenticated standard users running at Medium IL. Low and Untrusted IL were reserved for Everyone (World) and Anonymous user accounts, respectively.

While MIC didn’t directly address the widespread use of overpowered user accounts, it did provide a necessary tool for making the standard user account useable – enter UAC.

User Account Control​

User Account Control is a feature all Windows users have interacted with at one point or another –the ubiquitous consent prompt that appears when an administrator-level action is requested. Intended as a feature to prevent the installation of unwanted software and changes to critical system settings that plagued XP, UAC allowed users to operate as standard users during normal usage, selectively “elevating” to an administrator context when required and without the need to switch to another account.


Figure 2. Access flow for UAC and standard user

Split-User Tokens​

Under the hood, UAC worked by providing a user with two access tokens: a low-privilege, restricted token and a full-privilege, administrator token. When a process was created by a user, the user’s token was provided to define the security context within which the process would run. When the process attempted to access a securable object, such as a file, a registry key, or even another process, the access token would be compared to the “security descriptor” of the securable object to determine if access is granted or denied.

Since split-token users were granted two tokens, they could choose which context they wished to run a given process. Most applications would run under the restricted token, defaulting to a Medium IL, and denying any access that required administrator privileges. However, two paths existed for an application to run within an administrator context or “elevated”: 1) the application would request an elevated context upon startup via its process manifest or 2) the user would explicitly choose to “Run as Administrator”. Such elevated processes would run as High IL, which, due to security boundaries implemented by MIC, guaranteed they could not be tampered with by less-than-High IL processes, even when running under the same user context.

The UAC Consent Dialog​

As mentioned, the UAC consent dialog is how most users experience the feature. When an application requested an elevated context, again, either via the application manifest or explicitly by the user, a dialog would be shown. The dialog would show information about which application was requesting the elevation along with the publisher, file location, and a colored banner that indicated the signature type for a binary: blue for OS-signed, green for trusted publishers, yellow for unknown or unsigned binaries, and red for known bad publishers (along with a “block” dialog). By default, all UAC consent dialogs were displayed on the secure desktop, a separate desktop from the user’s interactive desktop, and accessible only to SYSTEM processes, thus preventing Medium IL malware from spoofing the prompt. Lastly, users could opt via policy to “Always Notify” and to “Never Notify” upon elevation request – a de facto on/off switch for the feature.

Criticisms​

Overall, critical reception to UAC was mixed. While UAC proved to be extremely successful in moving the Windows application ecosystem towards running as standard user, some consumers criticized the high number of consent prompts which resulted from the feature. Often, users would be confronted with multiple prompts for seemingly mundane tasks such as changing the time. Yet, UAC, combined with several other security features of Vista, led to a drastic reduction in the volume of malware compared to Windows XP.

Alongside the user experience issues, there were concerns that the feature itself was not sufficiently robust. Following its public release, security researchers debated the utility of UAC, with some even questioning the necessity of UAC's existence altogether. Microsoft’s stance was more explicit: UAC was a security feature but not a security boundary. In fact, the company would publicly remind users on multiple occasions that UAC was never intended to be more than a convenience feature to allow more users to run as standard user. Given it was not a hard boundary, reported UAC bypasses to MSRC would not receive fixes or be factored into bug case severity judgements.

Two Steps Forward, One Step Back​

By the time Windows 7 had rolled around, Microsoft had determined it needed to address perceived usability issues around UAC by eliminating unnecessary elevation prompts and fixing paths that generated multiple prompts. Microsoft implemented these changes in three ways 1) auto-elevation, 2) expanded notification levels, and 3) refactoring high-volume prompts. However, the first two would result in a greatly expanded universe of UAC bypasses, eroding whatever unofficial security gains were made previously by the introduction of UAC.

Auto-Elevation​

In Windows Vista any application which requested elevation would display a UAC prompt, even for built-in applications like Control Panel and Explorer. Administrator users who wanted to change system settings or move files around in protected directories would often see multiple consecutive UAC prompts while doing so. Windows 7 introduced the concept of “auto-elevation” for trusted applications, allowing them to start fully elevated without a UAC prompt.

Windows would consider an application “trusted” if it met the following criteria:

• Signed by a certificate authority in the Trusted Publisher certificate store
• An application manifest which declared the “autoElevate” attribute set to “true”
• An executable located in a trusted directory, writable only by an Administrator, such as Windows\System32 or Program Files. Not all directories under Windows\System32 are considered secure, for example System32\Spool and System32\Tasks are explicitly denied

Importantly, auto-elevation would also work for applications trying to activate high privilege COM classes. If the COM class was marked for auto-elevation, and the above criteria were met, the application would be allowed to activate the COM class as fully elevated.

Notification Levels​

Windows 7 would also add two additional notification levels to work alongside auto-elevation, giving users more options for how often UAC prompts are displayed:

• Notify me only when programs try to make changes to my computer
• Notify me only when programs try to make changes to my computer, without using the Secure Desktop

The two options skip UAC prompts for applications approved for auto-elevation. The latter option would also change any prompts that were displayed to be on the user’s interactive desktop instead of the secure desktop. Windows 7 retained the “Always notify” level, which would continue to show UAC prompts for elevation requests even if the application was allowed to auto-elevate. However, the default notification level would change from “Always notify” to “Notify me only when programs try to make changes to my computer”.

UAC Exploitation​

While auto-elevation was intended to provide a middle ground for users who wanted more control over the frequency of UAC notifications, it also had the side effect of creating holes in the elevation design. Attackers would find numerous ways to abuse the auto-elevation paths to elevate their privileges without showing a UAC prompt to the user.

Attack methods varied, but most malware relied on the use of unprivileged, Medium IL processes to trick an auto-elevating COM interface into performing some privileged operation on its behalf. In particular, the IFileOperation COM interface was highly abused. As a result of compatibility and user experience choices made in Vista for MIC, a process could interact with any other process of the same or lower integrity level within the same user context. Consequently, trusted applications like "explorer.exe" ran at Medium Integrity Level (IL) but could auto-elevate through IFileOperation COM activation. This resulted in these applications becoming prime targets for malware. In such attacks, the trusted process would be attacked from Medium IL via a code injection attack such as process hollowing to run malicious code which abused the silently elevated IFileOperation interface to drop additional malicious files across a user’s system in order to further escalate or gain persistence, often via “DLL hijacking” attacks. From the COM broker’s perspective, the tampered process would appear as “explorer.exe” or whatever trusted application was targeted, which fulfils all auto-elevation requirements despite the fact the actual in-memory code has been modified. Additional variations of this attack would evolve over time such that anti-virus detection was much more difficult.

New attacks would continue to be uncovered through Windows 8 and up to the current Windows 11. While auto-elevated COM interfaces remained a highly abused target, other attacks such as registry key manipulation, environment variable expansion, and token manipulation would be discovered and refined to the point that UAC bypasses became unremarkable – and with it, UAC becoming highly ineffective at whatever incremental security gains it had introduced. In fact, the UACME GitHub repo contains some 79 examples of UAC bypass affecting one or more versions from Windows 7 to current. According to MITRE data, at least seven identified and one unidentified threat groups have been observed using UAC bypasses during in-the-wild exploitation. MITRE also identifies over 40 specific malware variants utilizing such bypasses.

In our next blog post, we will discuss how Administrator protection aims to provide a strong security boundary between elevated and non-elevated user contexts and dig into some of the technical specifics regarding how the feature works.