Recent developments show there are 52 different ways to bypass Windows UAC, which can be found at https://github.com/hfiref0x/UACME. This project is primarily focused on reverse engineering malware. All the source code is written in C# and C; this will require attackers to compile the code and then perform the informed attacks.

Microsoft introduced security controls to restrict processes from running at three different integrity levels: high, medium, and low. A high integrity process has administrator rights, a medium-level process runs with a standard user's rights, and a low integrity process is restricted, enforcing programs do minimal damage if they are compromised.

To perform any privileged actions, a program must run as an administrator and comply with the UAC settings. The four UAC settings are as follows:

• Always notify: This is the most stringent setting and it will prompt the local user whenever any program wants to use higher-level privileges.
• Notify me only when programs try to make changes to my computer: This is the default UAC setting. It does not prompt the user when a native Windows program requests higher-level privileges. However, it will prompt if a third-party program wants elevated privileges.
• Notify me only when programs try to make changes to my computer (don't dim my desktop): This is the same as the default setting, but it does not dim the system's monitor when prompting the user.
• Never notify: This option reverts the system to pre-Vista days. If the user is an administrator, all programs will run with high integrity.

Therefore, immediately after exploitation, the tester (and attacker) wants to know the following two things:

• Who is the user that the system has identified?
• What rights do they have on the system?

This can be determined using the following command:

C:> whoami /groups

Here, a compromised system is operating in a high-integrity context, as shown by the Mandatory LabelHigh Mandatory Level Label in the following screenshot:

If Label is Mandatory LabelMedium Mandatory Level, the tester will need to elevate from standard user privileges to administrator rights for many of the post-exploit steps to be successful.

The first option to elevate privileges is to run exploit/windows/local/ask from Metasploit, which launches the RunAs attack. This will create an executable that, when invoked, will run a program to request elevated rights. The executable should be created using the EXE::Custom option or encrypted using Veil Framework to avoid detection by the local antivirus.

The disadvantage of the RunAs attack is that the user will be prompted that a program from an unknown publisher wants to make changes to the computer. This alert may cause the privilege escalation to be identified as an attack, as shown in the following screenshot:

If the system's current user is in an administrator's group, and if the UAC is set to the default Notify me only when programs try to make changes to my computer (it will not work if set to Always Notify), an attacker will be able to use the Metasploit exploit/windows/local/bypassuac module to elevate their privileges.

In the following screenshot, we can see that the 192.168.0.119 (victim) IP has been successfully compromised and has a HTTPS reverse shell on 8443 to our attacker's IP, which is 192.168.0.120 (the Kali attackbox):

To ensure that you are able to control the remote machine completely, we must be able to obtain administrative-level access. Attackers typically utilize getsystem to escalate their current capability to system privileges.

Typically, if the exploit was successful at the context of the user, we might receive an error message from the Meterpreter session, as shown in the following screenshot:

The bypassuac module creates multiple artifacts on the target system and can be recognized by most antivirus software. Note that this will work only when the user is a local administrator. Let's now use the Windows local exploit to bypass the UAC as shown in the following screenshot:

Once the SESSION is set to an active session, attackers will now be able to bypass the UAC set by the Windows operating system as shown in the following screenshot:

A successful bypass will provide the attackers with another meterpreter session with system-level privileges, as shown in the following screenshot:

Another local exploit module, exploit/windows/local/bypassuac_fodhelper for windows 10 UAC, hijacks a special key in the Registry under the current user hive, and inserts a custom command that will get invoked when the Windows fodhelper.exe application is launched. It does not touch the hard disk, minimizing the opportunity for detection by antivirus software.

Some limitations when attempting to bypass the UAC controls are as follows:

• Windows 8 and Windows 10 remain vulnerable to this attack. If it is attempted, the user will be prompted to click on an OK button before the attack can obtain elevated privileges, which is hardly a stealthy attack. Attackers can modify the attack by choosing to use exploit/windows/local/ask, which will improve the chance of success.
• When considering system-to-system movement (horizontal/lateral escalation), and if the current user is a domain user with local admin privileges on other systems, you can use the existing authentication token to gain access and bypass UAC. A common attack to achieve this is the Metasploit exploit/windows/local/bypassuac.
• Another module that works for Windows 10-based systems is exploit/windows/local/bypassuac_sluihijack.