Privilege escalation: Windows

If you started hacking on Linux, Windows can be frustrating and weird. But that's what most networks are running, from desktops to domain controllers. So you just have to get used to it.

Also, if you're doing a red team exercise and not just messing around on a lab machine or pen test, think long and hard about whether you need to privesc because it can alert the blue team. Even system enumeration commands like whoami and hostname might be detected because the average user isn't asking themselves this shit in between emails.

Gathering system information

Be warned, these commands will generate an overwhelming amount of information.

System information

Find out some basic information about the host:

systeminfo
systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
hostname
echo %username%
net users
net user user1

Output from the systeminfo command is useful for passing into script-based exploit suggesters (see below).

Active network connections

netstat -ano

Firewall settings

Scheduled tasks

Running processes

Running processes linked to services:

Running services:

Installed drivers

Installed patches

Program permissions

Check if a program has insecure permissions (e.g. anyone can read/write):

Interesting files

Search for files that contain ‘password’ in the filename:

Search for the keyword ‘password’ in files with the .txt extension:

Check for mapped drives (not gonna lie, you can pop a whole network by mining shared drives):

Unquoted service path

This is a common vulnerability for installed programs that don't put quotes around the file path to the executable:

When Windows tries to locate the program, it guesses and tries to execute any word before a space. For example, in the unquoted service path above, Windows will try:

An attacker could exploit this behaviour by putting a malicious program earlier in the file path so that Windows executes it before the legitimate one. In order for this to be successful, these conditions must be true:

  1. There is a service with an unquoted binary path containing one or more spaces in the path

  2. The current user has Write permissions for the folders containing spaces

  3. There is a way to reboot the system or service in order to execute a payload

List all services with an unquoted service path:

If this returns a an unquoted service path, use icacls to check permissions on each directory in the path:

If you can write to this directory, you can replace the executable with malicious one called Some.exe. This principle also applies to higher folders in the directory structure, if you have write permissions ('C:' and 'C:\Program Files'.

You can create a malicious .exe that sends a reverse shell to your machine with Metasploit (assuming there is no antivirus, haha):

Then restart the service:

If you don't have permission to restart the service, you'll have to wait for a system reboot or a more privileged user to restart it.

If you're super lazy you can just use this Metasploit module: exploit/windows/local/trusted_service_path

Modifying binary service path

Similar to the unquoted service path vulnerability, you can attempt to modify the file path of a service and point it to a malicious executable in a writable directory.

Windows has a tool called named accesschk.exe which checks permissions. To display services which can be modified by an authenticated user:

A service with write permissions for an authenticated user looks like this:

Show the service properties:

This is where you can find out the BINARY_PATH_NAME value. Change the binary path on a particular service:

If the service is disabled when you type in sc qc [service name] you can enable it using sc config SSDPSRV start= auto - note that there is a space between the = and the option.

Common errors include ftp-ing nc.exe without using the binary command first and using the wrong " in the path. If you're working with Windows XP, you'll need to download this version. Also, the Administrator shell fired using this method will not last, so you should send yourself another shell immediately with a different port:

You can also add a new user and grant administrator rights using the binary path:

Again, if you're super lazy here's a Metasploit Module: exploit/windows/local/service_permissions

AlwaysInstallElevated setting

Windows registry has a setting that allows non-privileged users to install Microsoft Windows Installer Package Files (MSI) with elevated system permissions. There are 2 registry entries which have to be set to 1 to enable this setting.

Check the values of the registry keys:

If AlwaysInstallElevated is enabled in the registry entries you can create an installer payload with msfvenom (again assuming there is no antivirus):

Generate a payload with a reverse shell:

Then use the following command to execute the msi installer file:

A summary of these flags:

  • /quiet will bypass User Account Control (UAC)

  • /qn specifies not to use a GUI

  • /i is to perform a regular installation of the package

For the lazy, here's a Metasploit module: exploit/windows/local/always_install_elevated

Unattended Installs

Unattended Installs allows administrators to deploy Windows in a hands-off way. However, if they don't clean up after this process, an XML file called Unattend is left on the local system, full of configuration settings and possibly local account configurations (e.g. Administrators).

Unattend files are often found in these folders:

Common filenames:

Passwords in these files may be base64 encoded, decode them here or in Burp Decoder.

And if you're lazy, a Metasploit module: post/windows/gather/enum_unattend

BypassUAC Metasploit module

If you have a meterpreter shell and getsystem isn't working, you can try this method, which uses the trusted publisher certificate through process injection. It will spawn a second shell that has the UAC flag turned off.

First background your meterpreter session:

Then set the UAC bypass module:

Set the session ID and the listening host IP:

This will spawn a second shell with UAC disabled, which might help you get NT/AUTHORITY\SYSTEM

Scripts

Windows Exploit Suggester

Windows Exploit Suggester is a tool to identify missing patches and associated exploits on a Windows host. It uses the output of systeminfo and compares it against the Microsoft vulnerability database, which is automatically downloaded and stores as a spreadsheet. Based on the output, the tool lists public exploits (E) and Metasploit modules (M).

If you don't have it, you can clone the git repository:

You may need to install the python-xlrd dependency for parsing Excel spreadsheets:

Change the working directory to the Windows Exploit Suggester directory and run the updater:

At that point, you should run systeminfo on the victim machine and save the contents as a text file:

Then run Windows Exploit Suggester to find vulnerabilities:

As with any script-based exploit suggester, there are false positives and junk data. To reduce the output to local vulnerabilities, add the --local option

Similarly, to filter output to remote vulnerabilities use --remote:

WMI hotfixes

If can't retrieve installed hotfixes from systeminfo you can find installed patches using the WMI command-line (WMIC) utility:

Store the output in a file named and run Windows Exploit Suggester with the following options:

Metasploit local exploit suggester

If you have a Meterpreter shell running, you can discover local exploits:

The output is okay, but there seem to be a lot of false positives and incorrect versions.

Powersploit Privesc

This one might also be useful but I haven't tried it yet:

PowerSploit Privesc

If you have a Windows exploit written in python, you can create an executable by installing PyWin32 and then extracting and running the pyinstaller module:

Further reading

Last updated