Windows Service Privilege Escalation

Now you have gained initial foot hold on the network and you almost certain the end user is low privilege user. Yes, you need to elevate the privilege to local administrator or maybe to system level or if you in luck domain admin.

So what we talk about here you may ask? Privilege escalation; a privilege escalation happens when a low level user requires access to a user or a service to increase privilege on compromised workstation/server etc.

Hacker thoughts and Post exploitation Assumptions:

  • Initial intrusion could start from anywhere, a phishing attack, a guest account a local authenticated user?
  • Living of the land, build in windows tools such as windows binary and PowerShell to come rescue?
  • Windows Services & Third party applications leverage and exploit it to our advantage and escalate low user to admin and or system.
  • Exploiting Weak Folder Permissions and mount and redirect  folder.
  • Classic dll hijacking and gain elevated privilege.

Steps to exploit weak services and binary implants

Assume we compromised an end user windows 10 fully patched workstation and the compromised user is as expected low level user (Authenticated user) no special permissions or rights.

There are different and easy ways to elevate privilige from low level user to all the way to  domain admins in less security conscious environment e.g The GPP Vulnerability  extracting cpassword filed in SYSVOL Groups.xml file etc

Here, we will be looking at different attack vector often overlooked  (Windows and third party services) often windows/third party service binary run under the System or high integrity level, any vulnerability in a service could result in privilege escalation.

Windows Services is  vast subject link for your further unsupervised read  here

Naturally, i go for quick powershell one liner to list all the potential vulnerable services in C:\ drive.  Get-WMIobject win32_service to look for services running outside of c:\windows folder   and the -eq “auto” is to check if the services out started, finally we check the  if the services running under the localsystem privilege account and we output the path is located.



Figure 1 we identified  c:\Users\lowuser\Desktop\AwesomeService\Secure.exe  path sits on user desktop with localsystem intergity level.

Icacls Microsoft  native binary to list  security descriptors on folders and files –  (F) indicates lowuser has full control over the Secure.exe binary. Obvious fail but this does happen all the time.

Service_1Figure 2    Lowuser has full control of the folder

Security descriptor definition language (SDDL) in windows world used to define access and protect objects for example, folders, shares, active directory objects, windows event logs etc.   SC sdshow lists access list against AwesomeService a.k.a to identify which user groups have access and make etc

service_03Figure 3 AwesomeService a.k.a Secure.exe SDDL

Brilliant description with SDDL breakdown here:

You might have notices you from SDDL output Authenticated User is not part of the SDDL,we can add our lowuser account to specific access.




Figure 4 Interactive user but not Authenticated User e.g. lowuser account

In order to add lowuser account to the list of SDDL we need the user Security Descriptor, we can identify user SID in the following locations:



Figure 5 low user sid

Whoami /all is also another way to list user SID


Figure 6  whoami /all cmd.exe

SC sdset to set the Authenticated User Read Property and Write Property


Figure 6 SetServiceObjectSecurity successfully set.


Figure 7 authenticated user is set and part of sddl.

Privilge escalation steps:

  • Lowuser has full control of the t C:\Users\lowuser\Desktop\AwesomeService\ folder
  • We can modify ,change, delete, replace
  • Build empire executable and replace the Secure.exe with our own call back agent
  • Reboot the service
  • Elevate Privillige from lowuser to SYSTEM integrity level


Compiled Empire agent executable and named it Secure.exe and copied to our Target Service location ( Replaced the legitimate Secure.exe service with our own executable)


Figure 8 compiled Empire callback and named it Exactly the same as Secure.exe


As expected we got shell from the victim machine with SYSTEM privilege successfully elevated from lowuser to SYSTEM user.


Figure 9 Secure Process Shell with integrity level SYSTEM.


Final couple of words,  log log log everything from your end user workstations, ensure third party services not running under HIGH/SYSTEM integrity.

I hope this has been informative

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s