Welcome to the first of a new series of blogs we’ll be publishing with information about the scenarios we write for our platform. Our intention is to provide information about security threats with enough technical data to satisfy those of you that are curious and want to understand the inner workings of the threat techniques we implement.
This series of posts are not meant to be the latest and greatest of our creations, just some details about popular scenarios in our library that we think might be of some interest for the people out there. Some of these will be kept high level and in others, we will go into greater technical details. We’ll always try to be as clear as possible on how we implement our philosophy "Think Bad, Do Good" by creating techniques that mimic the same TTPs followed by threat actors while keeping things safe for our customers
Without more delay, welcome to the first post in this series.
User Account Control (UAC) is a Windows feature that helps to prevent unauthorized changes to the system. This blog will show how a threat actor can silently execute privileged actions that modify the system while bypassing this security control. UAC has been present since Windows Vista and Windows Server 2008 with the goal to make the user aware when relevant system changes are triggered. It works by showing a popup window which asks for user interaction in order to accept some requested system changes, specifying which program name and publisher that are trying to carry out these changes. Also, the rest of the screen is usually dimmed to make the users more aware that this popup is really important, so they should pay attention.
This feature is very helpful to users so they can discern the relevance of the system changes that they perform, but also can be helpful in detecting when another application or malware is trying to modify the system. Bypassing the UAC is a well known attack technique, which is categorized as Defense Evasion and Privilege Escalation techniques on the MITRE ATT&CK matrix.
Since UAC is a security measure that can prevent malware, unwanted users or applications from changing relevant system configurations, threat actors are always looking for new ways to bypass UAC with the goal of performing privileged system changes without alerting the legitimate user. Different methods to bypass UAC exist, but this blog post is focused on registry modification techniques.
The chosen technique relies on modifying the registry key for a specific system utility application, which privileges are auto-elevated by design, and the ability to execute other applications and give them privileges. Three parameters are necessary to execute this technique. Two of them are directly related to the bypass technique, and the last one is the target command to execute with privileges while bypassing UAC:
For example, the UAC Bypass technique that we will explain for Windows 7 takes advantage of the eventvwr.exe application. This privileged application works like a shortcut to the Microsoft Management Console (MMC).
When eventvwr.exe starts, it will check if a specific binary is used to provide the functionality of the MMC snap-in for event viewer. To do that it looks for the specific binary location at the registry key “HKEY_CURRENT_USER\Software\Classes\mscfile\shell\open\command”. Then it executes the binary at this path if it exists. Otherwise the default MMC snap-in for the windows event viewer will be loaded. The content of this registry key is the one that can be used to execute binaries while bypassing UAC.
Due to Windows updates and security fixes, the privileged application and the registry key can be different for distinct Windows versions. Since there is not a bypass technique that shares the same privileged application and registry key at the time of this writing, we will show parameters that are valid for Windows 7. Other parameters are valid for Windows 10. Now, let’s demonstrate how these techniques work for both, one at a time.
The Windows 7 technique is based on the following parameters:
To replicate this technique, the first step is to modify the registry key with the target application to execute. In this case we have chosen “C:\Windows\System32\cmd.exe”:
Now that the registry key has been set, executing the eventvwr.exe process will execute the content of this registry key instead of loading itself:
Finally it is possible to check that the new spawned process is running with High Integrity, which allows the new process to access to several privileged and protected system resources:
The Windows 10 technique has the same parameter types, but with different values:
The first step is to modify the registry key as in the previous technique. We have chosen “C:\Windows\System32\cmd.exe” as the target application again:
Once the registry key has been set, the next step is to execute “sdclt.exe”. This process will start the command line application instead of loading itself, which is the same behaviour seen in the Windows 7 technique:
Finally we can check that the integrity level of the new spawned process is High, just as expected:
Our research team is working on writing scenarios that are capable of testing if there are security controls preventing this kind of attack, in addition to many other different attacks used by threat actors. This is achieved by using AttackIQ scenarios which can be very specific, such as this one, or they can be as generic as needed to modify user provided registry keys. With these generic scenarios everybody is able to test any kind of attack based on registry modifications.There are also many other generic scenarios such as executing system commands, modifying files, exfiltrating files, discovering network assets, using different persistence techniques, etc.
Since both techniques rely on the same principle, the mitigation for them is also the same. It is as simple as setting the UAC level to Always Notify.
A different protection approach can be used for those environments where it is not desirable to set the UAC level to Always Notify (however, having a different level is not recommended from the system’s security perspective). This approach consists in monitor and prevent registry changes on the following registry keys:
Along with these mitigations, it is also recommended to use unprivileged accounts whenever it is possible.