PowerUp — Experience
References:
PowerShellMafia // Github
PowerUp: A Usage Guide // harmj0y
Advanced PowerUp.ps1 Usage // Matt Hales
Lab Setup:
Windows 10 VM // Microsoft
Setup Script // Tib3rius
I used Tib3rius’ Windows Privilege Escalation Udemy Course Setup Script. I recommend supporting and buying the course.
For my certification prep I wanted to document some experience using different tools, starting with PowerUp.
PowerUp is a PowerShell program that enables the user to enumerate, and potentially exploit, privilege escalation opportunities against Windows macines. My experience with PowerUp up until writing this blog has been running Invoke-Allchecks and, with that as a baseline, I have decided to investigate what else is possible.
Setup
First, we want to get a reverse shell on our Windows Lab. Let’s assume we don’t have remote desktop access and use a netcat reverse shell. We’ll transfer over nc.exe from our Kali machine to our Windows lab and create the connection.
When we have our shell we will run:
powershell -ep bypassWe should now be using PowerShell in our reverse shell.
Next, we will import the module:
Import-Module C:\Users\user\Documents\PowerUp\PowerUp.ps1We are now setup to run PowerUp, we will start with Invoke-AllChecks.
Invoke-AllChecks
Invoke-AllChecks is a function that runs all the checks included in the module. The function outputs results of the checks in a useful format and offers us suggestions for where to look regarding privilege escalation.
We run the following from our shell:
Invoke-AllChecks
We are returned a list of results from the checks and suggested possible PowerUp attacks. We will look at each of these one by one.
Path 1: Unquoted Paths
Looking at our results from Invoke-AllChecks we can see a check for unquoted service paths has found the following:
We can see that the service name is unquotedsvc, the suggested abuse function is Write-ServiceBinary and CanRestart is true. With this we can add a new administrator user by exploiting the unquoted service path.
First, let’s check our current administrator users on our Windows Lab machine:
net localgroup administrators
We can see that there are currently three users in the administrators group.
Let’s try exploiting the service to add a new administrator user:
Write-ServiceBinary -Name 'unquotedsvc' -Path 'C:\Program Files\Unquoted Path Service\Common.exe' -Username badmin1 -Password p4ssw0rd123 -Verbose This will exploit the unquoted service path to create an executable called ‘Common.exe’ which will add a new user called ‘badmin1’ with the password ‘p4ssword123’ to the administrators group.
We run the command:
And start the service, which will cause a system error because it’s running our executable:
net start unquotedsvc
Now, when we check the administrators group again, we can see our admin user has been added:
If the target has remote desktop enabled we will be able to login as our new user from our kali machine:
xfreerdp /u:badmin1 /p:p4ssw0rd123 /v:<target IP>
Path 2: File-Permissions
Looking at our results from Invoke-AllChecks we can see a check for service executable and argument permissions has found the following:
We can see that the service name is filepermsvc, we can see we have permissions to modify the file, we can see a suggested abuse function and that restarting the service is set to true.
From here we can run the following to replace the binary with our own executable that will add an admin user. I didn’t have much success with the Install-ServiceBinary option, but considering the permissions available, we can use Write-ServiceBinary again. This time we used badmin2 for the username and p4ssword123 for the password:
Write-ServiceBinary -Name 'filepermsvc' -Path 'C:\Program Files\File Permissions Service\filepermservice.exe' -Username badmin2 -Password p4ssword123 -Verbose
Now we can start the service:
net start filepermsvc
And we should have a new admin user:
net localgroup administrators
We can see that we do so despite the suggested abuse function not working out for us there may still be ways to use PowerUp’s other options to escalate privileges.
We can now login to the target machine as badmin2:
xfreerdp /u:badmin2 /p:p4ssword123 /v:<target IP>
Path 3: Service Permissions
Looking at our results from Invoke-AllChecks we can see a check for service permissions has found the following:
We can see that the service name is daclsvc and the abuse function is Invoke-ServiceAbuse, we can also stop and start the service.
Under these conditions we can use the following command in PowerShell to replace the service executable with one of our own that will add a user called badmin3 to the administrators group with the password p4ssword123:
Invoke-ServiceAbuse -Name 'daclsvc' -Username badmin3 -Password p4ssword123
Now we can start the service:
net start daclsvc
And we should have our new admin user:
net localgroup administrators
We can now login to the target machine as badmin3:
xfreerdp /u:badmin3 /p:p4ssword123 /v:<target IP>
Path 4: AlwaysInstallElevated
From Invoke-AllChecks we can see that we have a check for AlwaysInstallElevated and a suggested abuse funtion of Write-UserAddMSI:
The process for this in PowerShell is slightly different from the previous examples. We will need to have established a remote desktop instance for to interact with the forms the Installer generates. So, having gone through the setup process again, we wil use the PowerShell command line on our Windows machine to run:
Write-UserAddMSI
This creates the UserAdd.msi installer in our directory. We can then run the installer and after everything has completed we have a input form that will allow us to add a user and password of our choice to the administrators group. In our example we have called the user badmin4 and set the password to p4ssword123:
After we click create we can see that our user has been added to the administrators group:
net localgroup administrators
And we could now login as the user through remote desktop:
xfreerdp /u:badmin4 /p:p4ssword123 /v:<target IP>
This is just a very brief overview looking at some of the extended features of PowerUp. All of these examples can also be done manually, replacing service executables can do something different like send a shell as System back to our listener but for that kind of thing has been covered in specific ‘Windows Privilege Escalation for OSCP & Beyond!’ by T1berius and ‘Windows Privilege Escalation for Beginners’ by The Cyber Mentor.
