toolsmith: Kansa vs Operation Cleaver – PowerShell IR tactics

Prerequisites

Windows operating system with Windows Management Framework (includes PowerShell) 4.0. WMF 2.0 and 3.0 work but 4.0 is recommended.

Introduction

First of all, Happy New Year! I’m looking forward to a great 2015 and really appreciated your readership and support during the 2014 schedule.
I am both proud and humbled to announce that this is the ISSA Journal’s 100^th toolsmith, and 100 consecutive columns at that. It’s really hard to think back to October 2006 and imagine what toolsmith would become; it’s helped shape my career, my personal philosophy, and I believe it has contributed to the improvement of information security practices for numerous individuals and organizations. Nothing makes me happier than hearing from readers with success stories and wins using the numerous and invaluable tools we’ve discussed on these pages. To that end, I’m pleased to cover Kansa for this 100^th toolsmith. In his own words, Dave Hull’s Kansa is a modular framework for doing incident response (IR) data collection, analysis and remediation written in PowerShell that takes advantage of Windows Remote Management in order to scale up to thousands of systems. It evolved from a few PowerShell scripts that Dave had written for IR work. Through trial and error and some advice from Lee Holmes (@Lee_Holmes), Dave was able to convert those old scripts into a tool that relies on network logons using PowerShell’s default non-delegated Kerberos authentication. This ensures that the incident responder’s credentials aren’t as exposed to harvesting by common adversary tooling such as Mimikatz. This assumes one-hop scenarios (work station to server). In two-hop scenarios (workstation to server to server) the risk remains, as dictated by the necessity for CredSSP, where PowerShell performs a “Network Clear-text Logon”. Understand the risks and pitfalls and stick to one-hop scenarios easily supported by Kansa with its Target parameter, where you can run against numerous systems from a single list.

Per Dave, “Kansa is frequently used across enterprises to investigate thousands of systems relatively quickly. It can do lots of great things on its own, but also has the ability to push third-party binaries to remote hosts so more sophisticated tooling can be brought to bear – consider the Get-RekallPslist.ps1 module, that installs the WinPMem kernel mode driver on remote hosts and uses it to collect the list of running processes from a live system similar to the way Volatility does against a collected memory image, completely bypassing the Windows API. Because it’s written in PowerShell, extending existing modules or creating new ones is relatively easy and Kansa can even be used to clean up systems for tactical containment and remediation.”

Dave’s written his own excellent Kansa overview and usage guide for PowerShell Magazine, which is a true “must read” for you, do nothing else before doing so. We’ll take a more tactical, scenario-based approach to our use of Kansa here so as to provide a different perspective. To that end, Stuart McClure’s Cylance group recently published their Operation Cleaver (#OPCLEAVER) report, also a must-read, an in-depth study of an Iranian hacker collective’s tools, tactics, and procedures (TTPs). A number of indicators of compromise (IOCs) are included in the report, amongst which are included MD5 hashes for specific malware types including TinyZBot and Lagulon. As described in the report, there are numerous references to “cleaver” inside the namespaces of the collective’s custom code, including TinyZBot, thus the name Operation Cleaver. For the best reference material specific to TinyZBot in the report, see the Persistence section starting on page 47. We’ll focus on using Kansa to find one of the Lagulon keylogging samples.   

Tuning Kansa

Kansa is really meant for use across many systems, this one target scenario is a bit trite on my part. You’ll need to imagine the horsepower you see working for this one compromised host across hundreds or thousands of similarly buggered hosts.

On your target servers, script execution needs to be enabled for Kansa use. If you’re not familiar with Powershell, that’s as easy as:

1)      Right-click the Windows PowerShell shortcut.

2)      Select Run as administrator.

3)      Choose Yes when the UAC window appears.

4)      Use the Set-ExecutionPolicy cmdlet; enter and execute Set-ExecutionPolicy unrestricted.

5)      You’ll also want to run ls -r *.ps1 | Unblock-File to unblock the scripts.

You may also need to execute winrm quickconfig and/or Register-PSSessionConfiguration -Name Microsoft.PowerShell to overcome remote connection errors you may see written to the Kansa output directory if it can’t connect to the target host. You may also need to work around Windows firewall issues for PowerShell remoting if any of your network connection profiles are set to Public. You can run Get-NetConnectionProfile on Windows 8 or Server 2012 and later to see how your connections are configured then run the likes of Set-NetConnectionProfile -InterfaceIndex 25 -NetworkCategory Private to reset the culprit to Private. You’ll modify –InterfaceIndex to the correct number matching your Public connection(s).

You should have read Dave’s PowerShell Magazine article already but I will remind you that any binaries you may wish to utilize on target hosts, such as autoruns.exe or handle.exe from the Sysinternals collection, should be stored in the .\Modules\bin\ directory. Beware possible EULA issues with the Sysinternals tools. Even though the Kansa Get-Handle script passes handle.exe /accepteula –a, handle.exe hung on me in my test scenario.

A successful pre-infection Kansa run on my intended victim system, as spawned by .\kansa.ps1 -Target localhost -Pushbin –Verbose, is seen in Figure 1.

Figure 1 – Kansa test run

Kansa vs. Cleaver

I acquired a few samples as described in Cylance’s Operaration Cleaver report from @VXShare, as always, my favorite repository. After investigating the run-time behaviors of a few of them, I found a specific sample, a Lagulon variant, that was a good representative for Kansa use as it hit marks for a few of the IOCs mentioned in the report. The sample, MD5: 53230e7d5739091a6eb51298a50eb616, is discussed generally on page 58 in the report as part of the wndTest analysis, observed attempting to impersonate Adobe Report Service.

After executing the sample on my victim system (I had to pwn a real Windows image as the malware didn’t run in a VM environment) I re-ran Kansa and collected results from the Output directory. I then went on a subsequent search for all things Adobe related and uncovered more than a few IOCs. As all output files are TSV by default, they play nicely in Excel. The first hit came from the Get-Autorunsc module, the results from which I filtered by infection date to reduce the noise. The output as seen in Figure 2 shows that adbreport.exe has been configured to run at logon via C:\Users\malman\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup.

Figure 2 – Kansa uncovers an autorun entry

The next hit came from the Get-Handle module, the results from which I sorted alphabetically by Process Name to key on adbReport.exe. As you can see in Figure 3, adbReport.exe, as identified by Process ID 3396, has open handles on a number of files and registry entries.

Figure 3 – Kansa pivots on adbreport.exe handles

Note the \Device\KsecDD entry in Figure 3 as well, indicating direct device communication via the KsecDD driver.

More related IOCs were noted via the Get-ProcsWMI module which, per its own synopsis, “acquires various details about running processes, including command-line arguments, process start time, parent process ID and MD5 hash of the process image as found on disk”, the results of which you can see in Figure 4.

Figure 4 – Kansa closes the circle with the adbreport.exe MD5 hash

You’ve likely come to the conclusion that the hash referenced in Figure 4 is in fact that associated with the malicious binary acquired from VirusShare, thus closing the circle of discovery and incident enumeration with Kansa.

That said, again, single host scenarios with Kansa are cute, but it’s made to shine at scale. Viewing individual TSV files in Excel is definitely not a scale solution. How about viewing and parsing results via Log Parser? Better right? Integrate with SQL-based storage and you’re really off to the races. The Kansa Analysis folder includes a number of analysis-centric scripts to work with the results. They’re most often frequency analysis-oriented to work across a body of results from a plethora of hosts. Sadly my examples will only be from my one wee victim system, but you get the point.

 As an example in Analysis\Process you can use Get-HandleProcessOwnerStack.ps1 to pull frequency from all collected Get-Handle data based on Process Name and Owner. While I only collected one result set, .\Get-HandleProcessOwnerStack.ps1 | findstr "adbReport" tell me that adbReport.exe has 48 handles open as seen in Figure 5.

Figure 5 – Kansa frequency analysis across results

Had there been one or 1000 Get-Handle results in the working directory where Get-HandleProcessOwnerStack.ps1 was run from, it would count and sort ALL handles by process and owner.

If you need a frequency count of all instances of adbReport.exe via an MD5 hash match across all results from all hosts, you need only run Get-ProcsWMICLIMD5Stack.ps1. My favorite is sorting the same data set by creation date. This helps while conducting timeline analysis and will tell you when a process was created across all targets, the like of which is seen in Figure 6.

Figure 6 – Kansa determines creation dates across results

Response capabilities, analysis of the results, and even the premise of remediation via Kansa for the adventurous and innovative amongst you, all built into to one tidy PowerShell framework. For modern Windows environments, consider Kansa a must have in the IR toolkit.

In Conclusion

Come what may, in light of attacks as discussed in the Operation Cleaver report, tool frameworks such as Kansa help you leverage the real Windows workhorse that is PowerShell in order to better respond and analyze. Keep an eye on the Kansa Github site for updates and news and follow @davehull on Twitter. Dave and I also both follow @Lee_Holmes who we both consider to be the Don of the PowerShell family.

Remember to vote for your favorite tool of 2014, through January 15, 2015. I’ll announce a winner soon thereafter. Please vote and tell your friends and coworkers to do the same.

Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec).

Cheers…until next month.

Acknowledgements

Dave Hull (@davehull), Kansa developer and project lead