PowerUp v1.1 – Beyond Service Abuse

Edit: I gave a short firetalk on PowerUp at BSidesBoston 2014– the slides are posted here.

The public reaction for PowerUp has been awesome and unexpected. I wanted to expand the script to move beyond just vulnerable service abuse, and include several other Windows privilege escalation vectors. There is a ton of great information out there on a variety of privesc techniques, and I drew from what I could find to implement the new functionality in PowerUp. I highly recommend checking out FuzzySecurity’s awesome post on the subject, as well as checking out @mubix‘s and @carnal0wnage‘s presentation “AT is the new Black”. While you’re at it, you should check out Parvez Anwar’s various posts on escalation techniques. The InsomniaSec presentation “ENCYCLOPAEDIA OF WINDOWS PRIVILEGE ESCALATION” is an awesome resource as well. This post will cover how these new techniques implemented into PowerUp.

DLL search order hijacking has been spoken about several times before, usually as a mechanism for malware persistence, but it can occasionally be used for privilege escalation in certain cases. The order that DLLs are loaded for executable is specified here– the important thing to note is that the directory where an executable is loaded from is the first location a DLL is checked for. If a DLL is loaded by a process, and is not in the KnownDLLs cache nor the directory the executable loaded from, an attacker is presented with a hijacking opportunity. Mandiant has an excellent detailed blog post about this whole process, and they published a C program that finds all hijacking opportunities on a system.

The new PowerUp function Invoke-FindDLLHijack will find hijacking opportunities and return the executable, hijackable DLL path, and current owner for the associated process. It does this by checking the path and loaded modules for all accessible running process, and returns any base “exe path + loaded module name” that doesn’t exist. The flags -ExcludeWindows and -ExcludeProgramFiles will exclude paths from C:\Windows\* and C:\Program Files\* respectively, and -ExcludeOwned will exclude processes owned by the current user. In addition, this function doesn’t need to call AdjustTokenPrivileges() with SE_PRIVILEGE_ENABLED like the Mandiant program does, meaning you can run it without needing administrative privileges.

Invoke-FindPathDLLHijack uses the technique described here to find possible service .dll hijacking opportunities. If a folder from the standard %PATH% is writable by the current user (i.e. C:\Python27\), you might be able to place a malicious .DLL in particular locations to escalate privileges.

Get-RegAlwaysInstallElevated will check the Windows registry for the AlwaysInstallElevated key. If this is enabled, MSI installers will always run with elevated privileges. There’s a Metasploit module (always_install_elevated.rb) that exploits this same behavior. Write-UserAddMSI will write out an MSI installer file that when run, prompts for a user account to add to the local administrators.

Get-RegAutoLogon will check if the AutoAdminLogon registry key is set, and will pull out any plaintext credentials if it is.

Get-UnattendedInstallFiles will check for the existence of several leftover unattended/sysprep files that often have plaintext administrative credentials.

Finally, Invoke-AllChecks will run all escalation checks and output a short status report on what it finds.

If anyone has any other ideas for reliable Windows privilege escalation techniques to implement, hit me up on twitter (@harmj0y) or at harmj0y on freenode (#veil and #armitage).


Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.