Power Posing with PowerOPS
ADVISORY: The techniques and tools referenced within this blog post may be outdated and do not apply to current situations. However, there is still potential for this blog entry to be used as an opportunity to learn and to possibly update or integrate into modern tools and techniques.
As described in my last blog post, Powershell Without Powershell – How To Bypass Application Whitelisting, Environment Restrictions & AV (sheeesh…it’s been a bit!), we are seeing more environments in which the execution of PowerShell Scripts are being detected or prevented. One way around those restrictions is to use a C# wrapper program to load the PowerShell scripts and execute them directly in the context of the .NET Framework. It is typically the case, however, that the wrapper has to be modified each time you run a new script. At the very least, you will likely need to modify some sort of config file that is read by the wrapper. This process can be a bit tedious and increases the chances of making a mistake. It would be nice to have all of the scripts consolidated into a single, compact framework. Introducing: PowerOPS Framework (https://github.com/fdiskyou/PowerOPS).
The PowerOPS Framework is the work of numerous people (none of whom is me) and their names are listed at the bottom of the GitHub page. Effectively, the framework is a collection of PowerShell scripts that are commonly used during the post-exploitation phase. Some of the scripts include: PowerView, Invoke-Mimikatz, Invoke-PSExec, and many others. Each script is embedded within the C# code itself so that you don’t need to tote around and load in the scripts. All you have to do is compile the code, run the executable, and enjoy the awesome PowerShell-style interface that enables you to run the script functions with simple commands. You can also run normal PowerShell commands from the interface. This is all done without actually calling the powershell.exe binary.
So how do you get going with it? Well, let’s walk through that process now. The one caveat is that you will need to have .NET Framework 4.0 or greater installed on the target system. For this example, I just installed Microsoft Management Framework 4 (https://www.microsoft.com/en-us/download/details.aspx?id=40855). Next, grab down the PowerOPS project from the GitHub link in the first part of this blog post. Extract the zip file after the download completes.
Next, open up a command prompt and compile the project by using the following command (making sure to change the directory to match the location of your download):
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /unsafe
/reference:"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Management.Automation
\v4.0_3.0.0.0__31bf3856ad364e35\System.Management.Automation.dll"
/reference:"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.IO.Compression.dll"
/out:C:\users\fmc\Desktop\PowerOPS_x64.exe /platform:x64
"C:\Users\fmc\Downloads\PowerOPS-master\PowerOPS-master\PowerOPS\*.cs"
If everything went well, you should now have an executable named PowerOPS_x64.exe on your desktop (or wherever you decided to put it).
Note that the command given was to compile for an x64 architecture. If you need to target x86 instead, use the following command (again, making sure to change the directory names to match your system):
C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe /unsafe /reference:"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.0__31bf 856ad364e35\System.Management.Automation.dll" /reference:"C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.IO.Compression.dll" /out:C:\users\fmc\Desktop\PowerOPS_x86.exe /platform:x86 "C:\Users\fmc\Downloads\PowerOPS master\PowerOPS-master\PowerOPS\*.cs"
To run the PowerOPS binary, just double-click on it. You should be greeted with a command interface.
You can see a list of the modules that are currently available by typing show into the interface.
The commands that are present in each module are already imported for you. To see which commands are available in a module, you can type:
get-command -module <module_name>
For instance, to see the commands for the PowerUp module you would type:
get-command -module PowerUp
Let’s go ahead and run the Invoke-AllChecks command by simply typing:
Invoke-AllChecks
What about if a command needs arguments and you can’t remember what they are? No worries! As previously mentioned, you can still use normal PowerShell commands in this framework. Let’s say that we want to run Invoke-ShareFinder but can’t quite remember how. We can get examples for it by typing the following:
Get-Help Invoke-ShareFinder -examples
I bet by now some of you have noticed the Invoke-Mimikatz function and are wondering, “does it work?” Well, yes but it might have a weird glitch. Close down PowerOPS and re-run it as an Administrator.
Attempt to run Mimikatz by typing:
Invoke-Mimikatz
You might get the output pictured below.
I am not quite sure what the issue is here, but by virtue of complete dumb-luck I found that it seems to work if I first run Invoke-Mimikittenz before running Invoke-Mimikatz. I tried running a few other modules first and it didn’t seem to fix the issue. I plan on looking at this more later…but for now it is fun to run kittenz before katz.
Invoke-Mimikittenz Invoke-Mimikatz
So, what does AV have to say about this? We recently had our annual Sacred Cash Cow Tipping AV-Bypass webcast (WEBCAST: Sacred Cash Cow Tipping 2016). Sadly, a few AV vendors were feeling left out and they quickly contacted us to let us know…and let us know they did. Don’t worry folks, it’s nothing personal. We just don’t have enough time to include everybody. Lucky for some of you, I will do double-duty and make the time to include you here!
The first AV engine that I tested this against was ESET. ESET, admittedly, has a pretty snazzy interface with lots of cool bells and whistles. I turned on all of them (short of firewalling everything), updated the database, and attempted to run PowerOPS. No alert was given on the initial execution. Next, I ran the Invoke-Mimikatz function and…success! I also did a manual scan on the executable and nothing was reported.
Kaspersky though…what about Kaspersky? I installed Kaspersky and also enabled all of the features, with the exception of whitelisting and locking down everything on the firewall. Honestly, if you’re implementing a whitelisting-based approach in your environment then hats off to you! That is a test for another blog post. Here, we are just looking at the detection capabilities. I scanned the executable with Kaspersky and it stated that everything was good. I ran PowerOPS and issued the Invoke-Mimikatz command. The result? Success! At least…so I thought….
The Invoke-Mimikatz call did succeed. After running it again so that I could grab a screenshot for this blog post, however, Kaspersky told me that it had detected the activity and was going to remove the file.
So, what gives? Did it write a new signature? Did its behavioral analysis engine learn something from the program executing? No, nothing quite that cool. It turns out that Kaspersky was taking a while to fully load. It’s unclear if this is due to my VM (4GB, 2 cores, on an PCIe-SSD…) or if it is just the nature of the program. It doesn’t appear that Kaspersky’s detections are effective during this loading window. I just happened to run my test during that time frame and it resulted in the Invoke-Mimikatz function not being detected.
Dang, what to do now… On recent engagements, I have been skipping the use of Mimikatz on target systems since it does seem to get detected more frequently now. I have typically been using the PowerShell Procdump script (http://poshcode.org/4751) to dump the lsass process of the target machine. I take that dump file offline and then run Mimikatz against it. But for this test, I went ahead and grabbed that script and made some slight modifications. After the script executed the code to perform the process dump, I added a sleep time of 10 seconds. The sleep time is to help ensure that the dump routine has completed. After the sleep, I added the following code:
Invoke-Mimikatz -Command “`“sekurlsa::minidump $dmp`” `”sekurlsa::logonPasswords`”
The previous command tells Mimikatz to run against the dump file that was created rather than attempting to scrape the memory directly. Here’s what the snippet of code now looks like in the PowerShell Procdump script:
Now, we need to add this into the PowerOPS Framework. The authors made this process quite simple. The first step is to convert the Procdump script to a Base64-encoded form. I just copied and pasted the script into an online converter.
Next, copy the Base64 code and open the PowerOPS.cs file in the PowerOPS directory. Notice the functions that are already present and mimic their structure in order to add the new script. This just involves creating a new function, naming it what you want (ProcDump, in this case), decoding the Base64 version of your script, and returning that decoded string. The snapshot below shows what this looks like. Your Base64 code just goes in between the set of double-quotes.
The next step is to open the Program.cs file in the PowerOPS folder. Find the portion in the code that has the series of pipeline.Commands.AddScript calls. Add in a call to the function that you created. You can see the addition in the following screenshot.
The final step is needed to get our new functionality to display when we type the show command in the PowerOPS prompt. Go towards the top of the script and find the DisplayModules function. I went ahead and added the Get-ProcessDump string to the last Console. Write call. You can see this in the screenshot below.
Finally, it’s time to recompile the program. Issue the compilation command that we used earlier. Run the PowerOPS executable as an Administrator. Type the show command to see that the function has been added.
Kick off the process dump and Mimikatz invocation against the lsass process by typing the following:
Get-ProcessDump (ps lsass)
And…success! For real this time though!
Successful Dump of Lsass and Password Extraction
In conclusion, I’ve given an overview of the awesome PowerOPS framework and how to get started with it. Having many of the common PowerShell scripts in a single utility is very convenient. Plus, you are given the ability to run these scripts without the direct usage of powershell.exe. It appears to bypass some AV vendors as-is. For others, we had to take a bit of a side-adventure in order to work around their detection methods. This framework also has built-in application-whitelisting bypass techniques that I did not detail here but will do so in future blog posts. PowerOPS is a tool that could very handy for pentesters and I highly encourage you to check it out! ______ Follow Brian on Twitter @fullmetalcache
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
