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 100th
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
