The purpose of this tool is to help security consultants identify potential weaknesses on Windows machines during penetration tests and Workstation/VDI audits. It is not intended to be used during Red Team engagements although it may still provide you with a lot of useful information.
This tool is heavily inspired from the amazing work that @harmj0y and @mattifestation put in PowerUp. The two original authors decided to switch to DotNet and are now working on the great SeatBelt project, which explains why PowerUp is no longer maintained. Although SeatBelt brings some undeniable benefits, I think that a standalone PowerShell script is still a good way to go for most pentesters, hence the motivation behind the creation of this tool.
I really like PowerUp because it can enumerate common vulnerabilities very quickly and without using any third-party tools. The problem is that it hasn't been updated for several years now. The other issue I spotted quite a few times over the years is that it sometimes returns false positives which are quite confusing.
Other tools exist on GitHub but they are not as complete or they have too many dependencies. For example, they rely on WMI calls or other command outputs.
Therefore, I decided to make my own script with the following constraints in mind:
- It must not use third-party tools such as
accesschk.exefrom SysInternals. - It must not use built-in Windows commands such as
whoami.exeornetstat.exe. The reason for this is that I want my script to be able to run in environments where AppLocker (or any other Application Whitelisting solution) is enforced. - It must not use built-in Windows tools such as
sc.exeortasklist.exebecause you'll often get an Access denied error if you try to use them from WinRM for example. - It must not use WMI because its usage can be restricted to admin-only users.
- Last but not least, it must be compatible with PowerShell Version 2.
- Third-party tools
I have no merit, I reused some of the code made by @harmj0y and @mattifestation. Indeed, PowerUp has a very powerfull function called Get-ModifiablePath which checks the ACL of a given file path to see if the current user has write permissions on the file or folder. I modified this function a bit to avoid some false positives though. Before that a service command line argument such as /svccould be identified as a vulnerable path because it was interpreted as C:\svc. My other contribution is that I made a registry-compatible version of this function (Get-ModifiableRegistryPath).
- Windows built-in windows commands/tools
When possible, I naturally replaced them with built-in PowerShell commands such as Get-Process. In other cases, such as netstat.exe, you won't get as much information as you would with basic PowerShell commands. For example, with PowerShell, TCP/UDP listeners can easily be listed but there is no easy way to get the associated Process ID. In this case, I had to invoke Windows API functions.
- WMI
You can get a looooot of information through WMI, that's great! But, if you face a properly hardened machine, the access to this interface will be restricted. So, I had to find workarounds. And here comes the Registry! Common checks are based on some registry keys but it has a lot more to offer. The best example is services. You can get all the information you need about every single service (except their current state obviously) simply by browsing the registry. This is a huge advantage compared to sc.exe or Get-Service which depend on the access to the Service Control Manager.
- PowerShellv2 support
This wasn't that easy because newer version of PowerShell have very convenient functions or options. For example, the Get-LocalGroupfunction doesn't exist and Get-ChildItem doesn't have the -Depth option in PowerShellv2. So, you have to work your way around each one of these small but time-consuming issues.