Reversing User Account Control and Bypassing Tricks

User Account Control (UAC) protection is a security defense designed to prevent malware from gaining administrator privileges. In this chapter, we will reverse-engineer UAC design to understand the internal workflow of UAC protection and learn the techniques used by threat actors to bypass UAC design for privilege elevation.

This chapter is based on the author’s Duplicate Paths Attack: Get Elevated Privilege from Forged Identities presented at Hackers In Taiwan Conference (HITCON) 2019 and Playing Win32 Like a K!NG ;) at Students’ Information Technology Conference (SITCON) 2020. These presentations describe the complete reverse engineering of the UAC protection for Windows 10 Enterprise 17763, and present UAC privilege elevation techniques for all versions of Windows from 7 to 10, based on the path normalization exploit. Interested readers can search for the presentations and full videos of the two sessions.

In...

UAC overview

The Windows XP operating system was not properly controlled for privileges, which led to the rise of malware. Microsoft forced a set of privilege separation protection designs called UAC into the system after Vista and later versions. It was designed to give unfamiliar or untrusted programs lower privileges during execution; only specific services built into the system can have the privilege elevation process to disregard the UAC protection.

Note

The author’s research on UAC reverse engineering is based on Windows 10 Enterprise LTSC (10.0.17763 N/A Build 17763), only for you to understand the design of UAC protection from a reverse engineering perspective. In the future, Microsoft may still make significant structural adjustments or corrections to the UAC protection, and the results of your experiments on your own computers may differ from those discussed by the author.

In Windows, you can right-click on a program and select Run as System Administrator...

RAiLaunchAdminProcess callback

In the previous section, we mentioned a very important point: when anyone tries to create a privilege elevation process from a low-privilege program, the UAC privilege service will be notified and will confirm whether to delegate privileges or not. If the elevation request is granted, the UAC privilege service will then proceed to hatch the low-privilege program with high privileges.

At this point, the UAC privilege service must have a callback function that is responsible for receiving requests, validating them, and delegating the privileges while generating the process. This callback function is the RAiLaunchAdminProcess function located in appinfo.dll.

Figure 10.5 shows a screenshot of the dynamic analysis of the UAC privilege service by the well-known binary decompiler IDA and the dynamic debugging of its RAiLaunchAdminProcess callback function breakpoints. We will now explain this entirely in terms of IDA-generated pseudocode and dynamic debugging...

Two-level authentication mechanism

When UAC protection was first introduced in Windows Vista, all privilege elevation requests that were initiated and processed by RAiLaunchAdminProcess needed to pop up the consent.exe screen to indicate whether to elevate or not and then create the privilege elevation child process.

However, this mechanism was too annoying. As a result, the UAC protection in Windows 7 onward has been designed with two levels of trust privilege elevation authentication. This means that there are two levels of authentication—if a privilege request is passed with both levels of authentication, then the UAC interface will not pop up when consent.exe is called to ask whether the user is authorized and will automatically agree to the privilege elevation process creation request. This means that when a trusted process is called, consent.exe will still wake up, but the user approval request window will not pop up.

In this section, we will introduce the authentication...

Elevated privilege conditions

We summarize the preceding reverse engineering results for Windows 10 Enterprise LTSC (10.0.17763 N/A Build 17763) and can derive the following conditions for automatic privilege elevation for UAC design:

• The program must configure itself as Auto Elevation
• The program should have a valid digital signature
• The program is run from a trusted system directory

In fact, you will soon understand that there are many services and tools in the system that are directly privileged on wakeup in order to allow users to use them smoothly without having to agree to frequent authorizations. So, if we can hijack these privileged processes, wouldn’t we be able to elevate our malware as well? A few common examples are as follows:

• The DLL module paths or commands used by a high-privileged system program are improperly stored in the registry, *.xml, or *.ini files on disk
• The privileged service has exported a public COM interface to...

Examples of bypassing UAC

In the DLL side-loading example section in Chapter 5, we briefly introduced the DLL side-loading technique, which allows us to hijack the execution process by simply dropping a DLL module into the same directory as the program. You must have guessed, if we could find a vulnerable high-privilege system program that could drop a malicious DLL module into the same directory, wouldn’t that allow the privilege-elevated program to automatically mount our DLL file, allowing us to act maliciously as a privilege-elevated process?

In practice, it is not that easy. As mentioned earlier, basically, the system programs that can be automatically privileged in the complete UAC authentication process must be located in C:\Windows\System32 or C:\Windows\SysWOW64. These two system directories are the directories where files cannot be written without privileging. However, if we don’t have high-privilege write access, is it possible to borrow from a high-privilege...

Summary

UAC protection plays an important role in modern Windows. Many Windows security measures are based on UAC protection as a security perimeter to work properly – for example, Windows firewall protection. In this chapter, we presented a complete analysis of Windows 10 UAC protection, the authentication process, and several known attacks in a reverse-engineered way. However, as the battle for Windows security continues, it is possible that these problems will be fixed in the future and that other new attack scenarios will emerge.