Home Hacking User Account Control(UAC) Bypass Techniques-Part 2

User Account Control(UAC) Bypass Techniques-Part 2


In continuation to Part-1 where we discussed basics around UAC, auto-elevate, etc., in this article, we will take a look at the techniques which uses the features described in Part-1.

It is advised that readers understand the basics described in the part of this series. In this part of series, we will investigate 2 techniques that can be used to bypass UAC.

Before we investigate the techniques, it is essential to know about registry hives: HKCR, HKLM and HKCU and the relation between them because more often the existing relationship between these hives paves the way for UAV bypass.

HKEY_Local_Machine(HKLM): Contains settings that are applied to all users on the system.

HKEY_Current_User(HKCU): Contains settings that are applied to only the current user.

HKEY_CLASSES_ROOT: This HIVE merges the view of HKLM and HKCU where the user-specific settings can override the default system settings.

Keeping the above points in mind, just imagine what if we found some high integrity process to fiddle with processes under local user hive which were supposed to be under medium/low integrity.

So, let’s jump into the first technique where we will how UAC can be bypassed using App Paths (App Paths were discussed in Part 1). Also, Part 1 discussed the auto-elevate feature of Microsoft binaries due to their manifest. SDCLT.exe is one such binary which has the auto-elevate feature in Windows 10 whereas, in Windows 7, it is set to AsInvoker which means users with low privileges cannot automatically elevate it.

In Windows 10

In Windows 7

Sdclt.exe eventually starts the control panel. An important point to note is that the control.exe is started with HIGH integrity level.

Let’s see how SDCLT.exe finds out control.exe file in the system. As we can see below, it turns out that that SDCLT looks out for control.exe in the following location.

What is so interesting in the above pattern of SDCLT opening control.exe? Well if you have noticed the pattern we have a high integrity process which is querying the HKCU (which is under current user context and under normal circumstances can only raise processes with medium integrity). It is imperative to note the sequence in which the sdclt.exe is looking for control.exe. Since HKCU is queried earlier, it means that even a medium integrity process can change the behavior of loading the control.exe from sdclt.exe.

So, let’s create a new App Path for control.exe but instead of spawning control.exe, let’s spawn powershell.exe and then run the SDCLT.exe

Note that the Registry path is read by sdclt.exe and powershell.exe is also spawned

We can see that we have a powershell.exe spawned with the HIGH integrity level.

So, since we now know that how App Paths can be misused to load another process, let look at another example of it. However, before we proceed further, an important point to note above is that once the attacker can hijack the respective registry key, with this attacker will not be able to pass on some parameters with the spawned binary. Thus, with what we know so far, the attacker needs to drop a binary on the infected machine to carry out further exploit. (We can do it with sdclt, but I will save it for next article).

In the next example, we will look at eventvwr.exe binary which also has auto-elevate enabled to it. Below is the screenshot which shows auto-elevate feature

After running Eventvwr.exe, it spawns mmc.exe to load snapins. This mmc.exe is launched at HIGH integrity level.

Now below are the paths that eventvwr.exe looks to launch MMC (for loading snap-in). Look out for the below query path order

As we can see HKCU is queried before HKCR to look out for mmc.exe in their respective path and since there is nothing in HKCU, the search continues to HKCR.

Following the same approach as discussed in the previous example, let’s create the directory structure as is needed by the eventvwr.exe

Moreover, then rerun the eventvwr.exe and spot the differences.

Note the Path and the PID of the launched process

Now we can see that the binary was able to retrieve the exe from the HKCU(powershell.exe) in this case and same can be observed with the Process Explorer as well.

Notice that the PID matched with the child of PPID 2880 and spawned powershell.exe is of HIGH integrity level. This example in many terms is similar to the previous example discussed, but with this, we can also pass the parameters to the spawned process to cause further exploitation. This will make this attack fileless and thus makes it difficult for endpoint solutions to detect it.

So, in this article, we have seen 2 techniques which can be used to bypass UAC. In the next article of this series, we will investigate more ways in which UAC can be bypassed.



Please enter your comment!
Please enter your name here