As the gatekeeper between users and potentially dangerous system modifications, User Account Control (UAC) serves as a strong defender, acting as a barrier between users and potentially damaging system changes. However, like every security solution, it is not immune to exploitation.
Interestingly enough, Microsoft doesn’t consider UAC a security boundary but rather a simple convenience to the administrator to avoid unnecessarily running processes with administrative privileges. In that sense, the UAC prompt is more of a reminder to the user that they are running with high privileges rather than impeding a piece of malware or an attacker from doing so. Since it isn’t a security boundary, any bypass technique is not considered a vulnerability to Microsoft, and therefore some of them remain unpatched to this day.
User Account Control (UAC) is a Windows security feature that requires all new processes to execute in the security context of a non-privileged account by default. This policy applies to any processes initiated by any user, including administrators themselves. The point is that we can’t only rely on the user’s identity to decide whether certain behaviours should be permitted.
Although this may appear illogical, consider the scenario in which user BOB unintentionally downloads a malicious application from the Internet. If BOB is a member of the Administrators group, any application he runs will inherit the access token privileges. So, if BOB decides to open the malicious application when UAC is deactivated, the infected application will get administrator capabilities immediately. When UAC is enabled, the malicious application will only be granted a non-administrative access token.
UAC Elevation
If an administrator is required to perform a privileged task, UAC provides a way to elevate privileges. Elevation works by presenting a simple dialogue box to the user to confirm that they explicitly approve of running the application in an administrative security context:
Integrity Levels and Filtered Token
UAC is a Mandatory Integrity Control (MIC), which is a system for distinguishing users, programs, and resources by assigning an Integrity Level (IL) to each. In general, people or processes with higher IL access tokens can access resources with lower or equivalent ILs. MIC takes precedence over standard Windows DACLs ( discretionary access control list), thus you may be approved to access a resource based on the DACL, but it will be ineffective if your IL is insufficient.
There are mainly 4 Integrity Levels (visit Hacktricks for more) :
- Low: Generally used for interaction with the Internet (i.e. Internet Explorer). Has very limited permissions.
- Medium: The default level for most activities, is assigned to standard users, and members of the Administrators group operate at this level by default.
- High: Used by Administrators’ elevated tokens if UAC is enabled. If UAC is disabled, all administrators will always use a high IL token.
- System: The highest operational level for the Windows kernel and core services. Reserved for system use.
Filter Token
To accomplish this separation of roles, UAC treats regular users and administrators in a slightly different way during logon:
- Non-administrators will receive a single access token when logged in, which will be used for all tasks performed by the user. This token has Medium IL.
- Administrators will receive two access tokens:
– Filtered Token: A token with Administrator privileges stripped, used for regular operations. This token has Medium IL.
– Elevated Token: A token with full Administrator privileges, used when something needs to be run with administrative privileges. This token has High IL.
Administrators will use their filtered token unless they specifically request administrative privileges through UAC.
When a user requires elevation, the following happens:
- The user requests to run an application as an administrator.
- A ShellExecute API call is made using the runas.
- The request gets forwarded to Appinfo to handle elevation.
- The application manifest is checked to see if AutoElevation is allowed.
- Appinfo executes consent.exe, which shows the UAC prompt on a secure desktop.
- If the user gives consent to run the application as administrator, the appinfo service will execute the request using a user’s Elevated Token. Appinfo will then set the parent process ID of the new process to point to the shell from which elevation was requested.
To read more in-depth read this article
GUI based bypasses
- msconfig: Our goal is to reach a High IL command prompt without passing through UAC.
– First Let’s open msconfig.
– Then navigate to Tools > Command Prompt > launch.
– If we click Launch, we will obtain a high IL command prompt without interacting with UAC in any way.
2. azman: As with msconfig, azman.msc will auto-elevate without requiring user interaction. If we can find a way to spawn a shell from within that process, we will bypass UAC. Note that, unlike msconfig, azman.msc has no intended built-in way to spawn a shell. We can easily overcome this with a bit of creativity.
1) First, let’s open azman.msc
2) To run a shell, we will abuse the application’s help. Navigate to Help >
Help Topic.
3) On the help screen, we will right-click any part of the help article and select View Source.
4) This will spawn a notepad process that we can leverage to get a shell. To do so, go to File->Open and make sure to select All Files in the combo box on the lower right corner. Go to C:\Windows\System32 and search for cmd.exe and right-click to select Open.