Windows Privilege Escalation via Unquoted Service Paths

Windows PrivEsc has always been difficult for me but this method is pretty straightforward and very successful.

This already assumes you have a shell on the box. I start up Empire, start a listener and generate a Powershell payload

1

2

Then run the payload.

runps

An agent then spawns on the target

3

I then select the agent

4

And then run the privilege escalation check module

5

6

What’s important in the results here is that the WebEx service is started by LocalSystem, but can be restarted by everyone. When some services restart, all they do is execute a binary/exe, in this case it’s ‘WebExService.exe’. This is a huge vulnerability because as a less privileged user, we can overwrite the existing WebExService.exe with our own, custom .exe, then restart the service. Since LocalSystem is the one that executes the restart, LocalSystem is essentially executing our custom executable.

To do this, I then create a malicious executable via msfvenom.

7

And replace the executable

replace

I then start up my multi/handler

8

And then restart the service

service

then…

9

And privileges have been escalated to SYSTEM. However, the attack isn’t over. Staying in the same process your shell was made in is a bad idea. For several persistance and opsec reasons, it’s necessary then to migrate to another process. Winlogon.exe is usually a great choice.

10

11

Now even if AV kills my initial shell process, I still remain on the target as I’m now operating out of winlogon.exe.

From here, I would then load kiwi and dump the credentials in LSASS via creds_all

12

 

3 Comments

  1. Your clarity of thought and report writing is truly amazing.
    As newbie who isn’t even at ‘Script Kiddle’ level – this has opened my eyes to wider world of pentesting as my passion is all things Active Directory related.

Leave a comment