Windows Privesc
Last updated
Last updated
Use the "whoami" and "net user" commands to check your user account and group memberships, respectively.
To search for potential vulnerabilities and escalation opportunities on a Windows system, run the WinPEAS tool with the "fast," "searchfast," and "cmd" options.
Run Seatbelt and other scripts that can help identify security-related concerns and potential vulnerabilities for privilege escalation.
Take some time to review the results of your enumeration. If tools like WinPEAS uncover something interesting, take note of it. To avoid getting sidetracked, create a checklist of items necessary for the privilege escalation method to work.
Do a quick search for files on the user's desktop and other common locations, like C:\ or C:\Program Files. When you find interesting files, read through them as they may have valuable information that could help you escalate privileges.
First, try simpler methods such as registry exploits and services that don't require many steps. Look closely at admin processes and note their versions while searching for vulnerabilities. Check for internal ports that you can forward to your attacking machine.
If you still don't have an admin shell, review your entire enumeration report and highlight anything that seems unusual. This could be an unfamiliar process or file name, or even a username. At this point, consider Kernel Exploits as well.
winPEAS not only actively hunts for privilege escalation. It highlights misconfigurations for the user in the results.
It is available here:
Before running on Windows, we need to add a registry key and then reopen the command prompt in order to see colors (not necessary on Linux):
Run all checks while avoiding time-consuming searches:
Run specific check categories:
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.
PowerUp
PowerUp is available here:
To use PowerUp, open a PowerShell session and load the script using dot sourcing:
Or import module:
Execute the Invoke-AllChecks function to initiate the process of detecting common misconfigurations that can lead to privilege escalation:
PowerView tips.
PowerView commands.
SharpUp project.
SharpUp pre-compiled.
To run SharpUp, start a command prompt and run the executable:
As soon as SharpUp is executed, it will begin checking for the same misconfigurations that PowerUp looks for.
Seatbelt is a system enumeration tool that performs various checks to identify potential vulnerabilities and security-related issues.
Download from here.
To run all checks and filter out unimportant results:
To run specific check(s): .
Source available here.
To escalate from an admin user to full SYSTEM privileges, you can use the PsExec tool from Windows Sysinternals.
Finding and using kernel exploits is usually a simple process:
Enumerate Windows version / patch level (systeminfo).
Find matching exploits (Google, ExploitDB, GitHub).
Compile and run. Beware though, as Kernel exploits can often be unstable and may be one-shot or cause a system crash.
Windows Exploit Suggester:
Precompiled Kernel Exploits:
Watson is a .NET tool designed to enumerate missing KBs and suggest exploits for Privilege Escalation vulnerabilities:
(Note: These steps are for Windows 7)
Extract the output of the systeminfo command:
Run wesng on kali to find potential exploits:
Cross-reference results with compiled exploits:
Download the compiled exploit for CVE-2018-8210 onto the Windows VM:
Start a listener on Kali and run the exploit, providing it with the reverse shell executable, which should run with SYSTEM privileges:
Query the configuration of a service:
Query the current status of a service:
Modify a configuration option of a service:
Start/Stop a service:
You could also need to reboot restart the machine to restart the service:
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)
Be cautious of potential rabbit holes when attempting to escalate privileges. For instance, if you can modify the configuration of a service but are unable to start or stop it, it's possible that you may not be able to escalate privileges.
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.
Run winPEAS to check for service misconfigurations:
Note that we can modify the “daclsvc” service.
We can confirm this with accesschk.exe:
Check the current configuration of the service:
Check the current status of the service:
Reconfigure the service to use our reverse shell executable:
Start a listener on Kali, and then start the service to trigger the exploit:
You could also need to reboot the machine to restart the service:
Run winPEAS to check for service misconfigurations:
Note that the “unquotedsvc” service has an unquoted path that also contains spaces: C:\Program Files\Unquoted Path Service\Common Files\unquotedpathservice.exe
Confirm this using sc:
Use accesschk.exe to 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:
You could also need to reboot the machine to restart the service:
The Windows registry stores entries for each service. Since registry entries can have ACLs, if the ACL is misconfigured, it may be possible to modify a service’s configuration even if we cannot modify the service directly.
Run winPEAS to check for service misconfigurations:
Note that the “regsvc” service has a weak registry entry. We can confirm this with PowerShell:
Alternatively accesschk.exe can be used to confirm:
Overwrite the ImagePath registry key to point to our reverse shell executable:
Start a listener on Kali, and then start the service to trigger the exploit:
You could also need to reboot the machine to restart the service:
Run winPEAS to check for service misconfigurations:
Query the "filepermsvc" service and note that it runs with SYSTEM privileges (SERVICE_START_NAME).
Note that the “filepermsvc” service has an executable which appears to be writable by everyone. We can confirm this with accesschk.exe:
Let's check if we can start and stop the service:
Create a backup of the original service executable:
Copy the reverse shell executable to overwrite the service executable:
Start a listener on Kali, and then start the service to trigger the exploit:
You could also need to reboot the machine to restart the service:
Use winPEAS to enumerate non-Windows services:
Note that the C:\Temp directory is writable and in the PATH. Start by enumerating which of these services our user has stop and start access to:
The “dllsvc” service is vulnerable to DLL Hijacking. According to the winPEAS output, the service runs the dllhijackservice.exe executable. We can confirm this manually:
Run Procmon64.exe with administrator privileges. Press Ctrl+L to open the Filter menu.
Add a new filter on the Process Name matching dllhijackservice.exe.
On the main screen, deselect registry activity and network activity.
Start the service:
Back in Procmon, note that a number of “NAME NOT FOUND” errors appear, associated with the hijackme.dll file.
At some point, Windows tries to find the file in the C:\Temp directory, which as we found earlier, is writable by our user.
On Kali, generate a reverse shell DLL named hijackme.dll:
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:
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.
Use winPEAS to check for writable AutoRun executables:
Alternatively, we could manually enumerate the AutoRun executables:
and then use accesschk.exe to verify the permissions on each one:
The “C:\Program Files\Autorun Program\program.exe” AutoRun executable is writable by Everyone. Create a backup of the original:
Copy our reverse shell executable to overwrite the AutoRun executable:
Start a listener on Kali, and then restart the Windows VM to trigger the exploit. Note that on Windows 10, the exploit appears to run with the privileges of the last logged on user, so log out of the “user” account and log in as the “admin” account first.
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.
The catch is that two Registry settings must be enabled for this to work.
The “AlwaysInstallElevated” value must be set to 1 for both
the local machine: HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer
and the current user: HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer
If either of these are missing or disabled, the exploit will not work.
Use winPEAS to see if both registry values are set:
Alternatively, verify the values manually:
Create a new reverse shell with msfvenom, this time using the msi format, and save it with the .msi extension:
Copy the reverse.msi across to the Windows VM, start a listener on Kali, and run the installer to trigger the exploit:
The following commands will search the registry for keys and values that contain “password”:
This usually generates a lot of results, so often it is more fruitful to look in known locations.
Use winPEAS to check common password locations:
The results show both AutoLogon credentials and Putty session credentials for the admin user (admin/password123).
We can verify these manually:
On Kali, we can use the winexe command to spawn a shell using these credentials:
We can also obtain a system shell using the admin user with winexe:
Windows has a runas command which allows users to run commands with the privileges of other users. This usually requires the knowledge of the other user’s password. However, Windows also allows users to save their credentials to the system, and these saved credentials can be used to bypass this requirement.
Use winPEAS to check for saved credentials:
It appears that saved credentials for the admin user exist.
We can verify this manually using the following command:
If the saved credentials aren’t present, run the following script to refresh the credential:
We can use the saved credential to run any command as the admin user. Start a listener on Kali and run the reverse shell executable:
Some administrators will leave configurations files on the system with passwords in them.
Recursively search for files in the current directory with “pass” in the name, or ending in “.config”:
Recursively search for files in the current directory that contain the word “password” and also end in either .xml, .ini, or .txt:
Use winPEAS to search for common files which may contain credentials:
The Unattend.xml file was found. View the contents:
Found the credentials inside the file we can simply use winexe to spawn a shell as the admin user, or system
Windows stores password hashes in the Security Account Manager (SAM). The hashes are encrypted with a key which can be found in a file named SYSTEM. If you have the ability to read the SAM and SYSTEM files, you can extract the hashes.
The SAM and SYSTEM files are located in the C:\Windows\System32\config directory. The files are locked while Windows is running. Backups of the files may exist in the following directories:
C:\Windows\Repair
C:\Windows\System32\config\RegBack
Backups of the SAM and SYSTEM files can be found in C:\Windows\Repair and are readable by our user.
Copy the files back to Kali:
We can also extract a copy of the SAM and SYSTEM files using reg.exe:
Starting with secretsdump.py (recommended), which is also part of the Impacket Suite of Tools, we can dump the NL and NTLM hashes using the following command:
We can alternatively use samdump2 (not recommended) to dump the hashes the same way, the command is simply:
Run the pwdump tool against the SAM and SYSTEM files to extract the hashes:
Crack the admin user hash using hashcat:
We can use a modified version of winexe, pth-winexe to spawn a command prompt using the admin user’s hash.
Extract the admin hash from the SAM in the previous step.
Use the hash with pth-winexe to spawn a command prompt:
Use the hash with pth-winexe to spawn a SYSTEM level command prompt:
List all scheduled tasks your user can see:
In PowerShell:
Often we have to rely on other clues, such as finding a script or log file that indicates a scheduled task is being run.
In the C:\DevTools directory, there is a PowerShell script called “CleanUp.ps1”. View the script:
This script seems like it is running every minute as the SYSTEM user. We can check our privileges on this script using accesschk.exe:
It appears we have the ability to write to this file.
Backup the script:
Start a listener on Kali.
Use echo to append a call to our reverse shell executable to the end of the script:
Wait for the scheduled task to run (it should run every minute) to complete the exploit.
In earlier versions of Windows, it was possible for users to be authorized to run certain GUI applications with administrative privileges. There are typically multiple ways to generate command prompts from within GUI applications, including using built-in Windows functionality. As the parent process runs with administrative privileges, any command prompts generated will also be executed with these privileges. This technique is often referred to as the "Citrix Method" because it uses many of the same methods employed to escape from Citrix environments.
Log into the Windows VM using the GUI with the “user” account.
Double click on the “AdminPaint” shortcut on the Desktop.
Open a command prompt and run:
Note that mspaint.exe is running with admin privileges.
In Paint, click File, then Open.
In the navigation input, replace the contents with:
Press Enter. A command prompt should open running with admin privileges.
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:
Use accesschk.exe to check permissions on the StartUp directory:
Note that the BUILTIN\Users group has write access to this directory.
Create a file CreateShortcut.vbs with the VBScript provided in a previous slide. Change file paths if necessary.
Run the script using cscript:
Start a listener on Kali, then log in as the admin user to trigger the exploit.
Most privilege escalations relating to installed applications are based on misconfigurations we have already covered. Still, some privilege escalations results from things like buffer overflows, so knowing how to identify installed applications and known vulnerabilities is still important.
Manually enumerate all running programs:
We can also use Seatbelt to search for nonstandard processes:
winPEAS also has this ability (note the misspelling):
Once you find an interesting process, try to identify its version. You can try running the executable with /? or -h, as well as checking config or text files in the Program Files directory. Use Exploit-DB to search for a corresponding exploit. Some exploits contain instructions, while others are code that you will need to compile and run.
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.
These steps are for Windows 7
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.
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.
Juicy Potato works in the same way as Rotten Potato, but the authors did extensive research and found many more ways to exploit.
Juicy Potato is available here:
These steps are for Windows 7
Copy PSExec64.exe and the JuicyPotato.exe exploit executable over to Windows.
Start a listener on Kali.
Using an administrator command prompt, use PSExec64.exe to trigger a reverse shell running as the Local Service service account:
Start another listener on Kali.
Now run the JuicyPotato exploit to trigger a reverse shell running with SYSTEM privileges:
If the CLSID ({03ca...) doesn’t work for you, either check this list or run the GetCLSID.ps1 PowerShell script.:
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.
For most recent Windows builds we can user PrintSpoofer.exe instead JuicyPotato.exe.
Abuse is possible if SeImpersonatePrivilege or SeAssignPrimaryPrivilege is enabled.
Windows CLSIDs: http://ohpe.it/juicy-potato/CLSID/
PrintSpoofer.exe is available here:
Leverages the Print Spooler service to get a SYSTEM token, then run a custom command
Sometimes it is easier to run exploit code on Kali, but the vulnerable program is listening on an internal port. In these cases we need to forward a port on Kali to the internal port on Windows. We can do this using a program called plink.exe (from the makers of PuTTY).
The general format of a port forwarding command using plink.exe:
Note that the is usually local (e.g. 127.0.0.1). plink.exe requires you to SSH to Kali, and then uses the SSH tunnel to forward ports.
First, test that we can still login remotely via winexe:
Using an administrator command prompt, re-enable the firewall:
Confirm that the winexe command now fails.
Copy the plink.exe file across to Windows, and then kill the SMB Server on Kali (if you are using it).
Make sure that the SSH server on Kali is running and accepting root logins. Check that the “PermitRootLogin yes” option is uncommented in /etc/ssh/sshd_config. Restart the SSH service if necessary.
On Windows, use plink.exe to forward port 445 on Kali to the Windows port 445:
On Kali, modify the winexe command to point to localhost (or 127.0.0.1) instead, and execute it to get a shell via the port forward:
Access Tokens are special objects in Windows which store a user’s identity and privileges. Primary Access Token – Created when the user logs in, bound to the current user session. When a user starts a new process, their primary access token is copied and attached to the new process. Impersonation Access Token – Created when a process or thread needs to temporarily run with the security context of another user.
Windows allows processes/threads to duplicate their access tokens. An impersonation access token can be duplicated into a primary access token this way. If we can inject into a process, we can use this functionality to duplicate the access token of the process, and spawn a separate process with the same privileges.
You may be already familiar with the concept of a “pipe” in Windows & Linux:
A named pipe is an extension of this concept. A process can create a named pipe, and other processes can open the named pipe to read or write data from/to it. The process which created the named pipe can impersonate the security context of a process which connects to the named pipe.
The “getsystem” command in Metasploit’s Meterpreter shell has an almost mythical status. By running this simple command, our privileges are almost magically elevated to that of the SYSTEM user. What does it actually do?
The source code for the getsystem command can be found here:
Three files are worth looking through: elevate.c, namedpipe.c, and tokendup.c There are 3 techniques getsystem can use to “get system”.
getsystem was designed as a tool to escalate privileges from a local admin to SYSTEM. The Named Pipe techniques require local admin permissions. The Token Duplication technique only requires the SeDebugPrivilege privilege, but is also limited to x86 architectures. getsystem should not be thought of as a user -> admin privilege escalation method in modern systems.
Creates a named pipe controlled by Meterpreter. Creates a service (running as SYSTEM) which runs a command that interacts directly with the named pipe. Meterpreter then impersonates the connected process to get an impersonation access token (with the SYSTEM security context). The access token is then assigned to all subsequent Meterpreter threads, meaning they run with SYSTEM privileges.
Very similar to Named Pipe Impersonation (In Memory/Admin). Only difference is a DLL is written to disk, and a service created which runs the DLL as SYSTEM. The DLL connects to the named pipe.
This technique requires the “SeDebugPrivilege”. It finds a service running as SYSTEM which it injects a DLL into. The DLL duplicates the access token of the service and assigns it to Meterpreter. Currently this only works on x86 architectures. This is the only technique that does not have to create a service, and operates entirely in memory.
In Windows, user accounts and groups can be assigned specific “privileges”. These privileges grant access to certain abilities. Some of these abilities can be used to escalate our overall privileges to that of SYSTEM. Highly detailed paper:
The whoami command can be used to list our user’s privileges, using the /priv option:
whoami /priv
Note that “disabled” in the state column is irrelevant here. If the privilege is listed, your user has it.
The SeAssignPrimaryPrivilege is similar to SeImpersonatePrivilege. It enables a user to assign an access token to a new process. Again, this can be exploited with the Juicy Potato exploit.
The SeBackupPrivilege grants read access to all objects on the system, regardless of their ACL. Using this privilege, a user could gain access to sensitive files, or extract hashes from the registry which could then be cracked or used in a pass-the-hash attack.
The SeRestorePrivilege grants write access to all objects on the system, regardless of their ACL. There are a multitude of ways to abuse this privilege:
Modify service binaries.
Overwrite DLLs used by SYSTEM processes
Modify registry settings.
The SeTakeOwnershipPrivilege lets the user take ownership over an object (the WRITE_OWNER permission). Once you own an object, you can modify its ACL and grant yourself write access. The same methods used with SeRestorePrivilege then apply.
SeTcbPrivilege
SeCreateTokenPrivilege
SeLoadDriverPrivilege
SeDebugPrivilege (used by getsystem)
