Windows Privilege Escalation
Common Windows Privilege Escalation
All credits to https://github.com/0xJs/RedTeaming_CheatSheet/blob/main/windows_security.md
Table of Contents
- Using BloodHound
- General Tips
- Tools
- Manual Enumeration
- Check the Current User
- Check the Current Privileges
- Check the Current Groups
- Check All Users
- Check the Local Administrator Group Members
- Check Hostname
- Check Operating System and Architecture
- Get Installed Patches
- Check Running Processes
- Check Running Services
- Check Current Privileges
- Check Networking Information
- Check Open Ports
- Enumerate Firewall
- Enumerate Scheduled Tasks
- Installed Applications and Patch Levels
- Readable/Writable Files and Directories
- Device drivers and kernel modules
- Binaries that auto elevate
- Check the architecture
- Check for drivers
- Check the driver files for version etc and check if it’s vulnerable
- List disks
- Check permission on file
- Privilege escalation techniques
- Search for powershell history and transcript
- Kernel exploits
- Service Exploits
- Weak service permissions
- Unqouted Service Path
- Executables with AlwaysInstallElevated Registry Setting
- Insecure service executables
- DLL Hijacking
- Always Install Elevated
- SC Manager Abuse
- Registry
- Autoruns
- AlwaysInstallElevated
- SC Manager Abuse
- Passwords
- Registry
- Saved Credentials
- Configuration Files
- SAM
- Scheduled Tasks
- Insecure GUI Apps
- Startup Apps
- Installed Applications
- Hot Potato
- Token Impersonation
Using BloodHound
Remote BloodHound
Python BloodHound Repository or install it with pip3 install bloodhound
On Site BloodHound
General Tips
- Check if Windows Scheduler is running (
tasklist
)- Go to
C:\Program Files\SystemScheduler\Events
and check the logs to see if anything is running every x minutes. - Check if we have write permissions.
- Go to
- Administrative command execution tips:
- Use
msfvenom
for shells if we can execute something with admin privileges: - RDP:
- Admin to System:
- Use
- Can also use
icacls.exe
orGet-acl
to check permissions on directories/files instead ofaccesschk.exe
.
Other Great Sources
Tools
Privescheck
Powerup & SharpUp
Seatbelt
winPEAS
accesschk.exe
AccessChk is an old but still trustworthy tool for checking user access control rights. You can use it to check whether a user or group has access to files, directories, services, and registry keys. The downside is more recent versions of the program spawn a GUI “accept EULA” popup window. When using the command line, we have to use an older version which still has an /accepteula command line option.
Always do first:
Manual Enumeration
Check the Current User
Check the Current Privileges
Check the Current Groups
Check All Users
Check the Local Administrator Group Members
Check Hostname
Check Operating System and Architecture
Get Installed Patches
Check Running Processes
Check Running Services
Check Current Privileges
if SeImpersonatePrivilege is set (PrintSpoofer or juicypotato)
Check Networking Information
Check Open Ports
Enumerate Firewall
Enumerate Scheduled Tasks
Installed Applications and Patch Levels
Readable/Writable Files and Directories
Device drivers and kernel modules
Binaries that auto elevate
Check status of AlwaysInstalledElevated registery setting (if yes then craft a MSI)
Check the architecture
Check for drivers
Check the driver files for version etc and check if it’s vulnerable
List disks
Check permission on file
Privilege escalation techniques
- Run automation scripts and if it find something fuzzy use these techniques to exploit it.
History
Search for powershell history and transcript
Kernel exploits
Kernels are the core of any operating system. Think of it as a layer between application software and the actual computer hardware. The kernel has complete control over the operating system. Exploiting a kernel vulnerability can result in execution as the SYSTEM user.
- Enumerate Windows version / patch level (systeminfo)
- Find matching exploits (Google, ExploitDB, Github)
- Compile and run
Finding kernel exploits
- https://github.com/bitsadmin/wesng
- https://github.com/rasta-mouse/Watson
- Pre compiled Kernel exploits
Get systeminfo
Run on kali
Cross-reference results with compiled exploits + run them
https://github.com/SecWiki/windows-kernel-exploits
Service Exploits
Services are simply programs that run in the background, accepting input or performing regular tasks. If services run with SYSTEM privileges and are misconfigured, exploiting them may lead to command execution with SYSTEM privileges as well.
Check services access
Query the configuration of a service:
Query the current status of a service:
Modify a configuration option of a service:
Start/Stop a service:
Weak service permissions
Each service has an ACL which defines certain service-specific permissions. Some permissions are innocuous (e.g. SERVICE_QUERY_CONFIG, SERVICE_QUERY_STATUS). Some may be useful (e.g. SERVICE_STOP, SERVICE_START). Some are dangerous (e.g. SERVICE_CHANGE_CONFIG, SERVICE_ALL_ACCESS).
If our user has permission to change the configuration of a service which runs with SYSTEM privileges, we can change the executable the service uses to one of our own. Potential Rabbit Hole: If you can change a service configuration but cannot stop/start the service, you may not be able to escalate privileges!
Confirm with accesschk.exe
Check the permissions on modifieable service
Check the current configuration
Check current status
Reconfigure the service
Change the start + object
Start service
Unqouted Service Path
Executables in Windows can be run without using their extension (e.g. “whoami.exe” can be run by just typing “whoami”). Some executables take arguments, separated by spaces, e.g. someprog.exe arg1 arg2 arg3… This behavior leads to ambiguity when using absolute paths that are unquoted and contain spaces.
Consider the following unquoted path: C:\Program Files\Some Dir\SomeProgram.exe
To us, this obviously runs SomeProgram.exe
. To Windows, C:\Program
could
be the executable, with two arguments: Files\Some
and Dir\ SomeProgram.exe
Windows resolves this ambiguity by checking each of the possibilities in turn. If we can write to a location Windows checks before the actual executable, we can trick the service into executing it instead.
Find service with unqoutes service paths
Confirm this using sc:
Check for write permissions:
Copy the reverse shell executable and rename it appropriately:
Start a listener on Kali, and then start the service to trigger the exploit:
- accesschk.exe:
Overwriting Registry Key Values
To overwrite the value of a registry key and point it to our reverse shell executable:
Triggering the Exploit
Start a listener on Kali, and then start the service to trigger the exploit:
Insecure Service Executables
If the original service executable is modifiable by our user, we can simply replace it with our reverse shell executable. Remember to create a backup of the original executable if you are exploiting this in a real system!
Checking Executable Writability
Creating a Backup
Copying the Reverse Shell Executable
Triggering the Exploit
Start a listener on Kali, and then start the service to trigger the exploit:
DLL Hijacking
Often a service will try to load functionality from a library called a DLL (dynamic-link library). Whatever functionality the DLL provides, will be executed with the same privileges as the service that loaded it. If a DLL is loaded with an absolute path, it might be possible to escalate privileges if that DLL is writable by our user.
A more common misconfiguration that can be used to escalate privileges is if a DLL is missing from the system, and our user has write access to a directory within the PATH that Windows searches for DLLs in. Unfortunately, initial detection of vulnerable services is difficult, and often the entire process is very manual.
Checking for a Writable Directory in PATH
Start by enumerating which of these services our user has stop and start access to:
Confirming Vulnerable Services
Generating a Reverse Shell DLL
On Kali, generate a reverse shell DLL named hijackme.dll:
Triggering the Exploit
Copy the DLL to the Windows VM and into the C:\Temp directory. Start a listener on Kali and then stop/start the service to trigger the exploit:
Always Install Elevated
This policy allows standard users to install applications that require access to directories and registry keys that they may not usually have permission to change. This is equivalent to granting full administrative rights and even though Microsoft strongly discourages its use, it can still be found.
Searching for Always Install Elevated
Creating MSI for Privilege Escalation
To exploit this, you can package a payload into an MSI installer that will be installed and executed with SYSTEM privileges. You can use tools like PowerShell scripts or Cobalt Strike Beacon to generate such MSI files.
SC Manager Abuse
Displaying Permissions for Service Creation
Converting Permissions
Creating a Service
Restarting the Machine
Registry
Autoruns
Windows can be configured to run commands at startup, with elevated privileges. These “AutoRuns” are configured in the Registry. If you are able to write to an AutoRun executable, and are able to restart the system (or wait for it to be restarted), you may be able to escalate privileges.
Enumerating Autorun Executables
Checking Executables Manually
Checking All Autoruns
Copying Reverse Shell to Autorun Directory
Triggering the Exploit
Copy the reverse shell executable to overwrite the autorun executable:
AlwaysInstallElevated
MSI files are package files used to install applications. These files run with the permissions of the user trying to install them. Windows allows for these installers to be run with elevated (i.e., admin) privileges. If this is the case, we can generate a malicious MSI file which contains a reverse shell.
Manually Checking for AlwaysInstallElevated
Creating MSI with Reverse Shell
SC Manager Abuse
Displaying Permissions for Service Creation
Converting Permissions
Creating a Service
Restarting the Machine
Passwords
Registry
Plenty of programs store
configuration options in the Windows Registry. Windows itself sometimes will store passwords in plaintext in the Registry. It is always worth searching the Registry for passwords. The following commands will search the registry for keys and values that contain “password”.
Searching Registry for Passwords
Spawning Shell Using Credentials
Saved Credentials
Manually Checking for Saved Credentials
Using Saved Credentials
Configuration Files
Manually Searching
SAM
Copying SAM and SYSTEM Files
Running creddump pdump.py
Cracking with hashcat
Pass the Hash Login
Scheduled Tasks
Listing All Scheduled Tasks
Insecure GUI Apps
If you can open a file with this app, navigate to the explorer and fill in the path to cmd.exe or PowerShell.exe:
Startup Apps
Each user can define apps that start when they log in, by placing shortcuts to them in a specific directory. Windows also has a startup directory for apps that should start for all users: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp If we can create files in this directory, we can use our reverse shell executable and escalate privileges when an admin logs in.
Note that shortcut files (.lnk) must be used. The following VBScript can be used to create a shortcut file.
Using VBScript to Create a Shortcut
Running the Script using cscript
Starting Listener if Admin Logs in
Installed Applications
Most privilege escalations relating to installed applications are based on misconfigurations we have already covered. Still, some privilege escalations result from things like buffer overflows, so knowing how to identify installed applications and known vulnerabilities is still important.
Enumerating All Running Programs
Hot Potato
Hot Potato is the name of an attack that uses a spoofing attack along with an NTLM relay attack to gain SYSTEM privileges. The attack tricks Windows into authenticating as the SYSTEM user to a fake HTTP server using NTLM. The NTLM credentials then get relayed to SMB in order to gain command execution. This attack works on Windows 7, 8, early versions of Windows 10, and their server counterparts.
- Copy the potato.exe exploit executable over to Windows.
- Start a listener on Kali.
- Run the exploit:
- Wait for a Windows Defender update or trigger one manually.
Token Impersonation
Service Accounts
The original Rotten Potato exploit was identified in 2016. Service accounts could intercept a SYSTEM ticket and use it to impersonate the SYSTEM user. This was possible because service accounts usually have the “SeImpersonatePrivilege” privilege enabled.