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.
Figure 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
Figure 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