Kansa: A modular live response tool for Windows enterprises

Folks who follow me on Twitter, @davehull, have seen chatter from me about a side-project I've been working on, Kansa, in preparation for my presentation at the SANS DFIR Summit in Austin in June. While the Github page for the project contains a Readme.md that gives a little information about what the project is and does, I thought a series of blog post was in order.

A look at the Readme.md today says Kansa is a modular rewrite of another script in my Github repro called Mal-Seine. Mal-Seine was a Powershell script I hacked together for evidence collection during incident response.

Mal-Seine worked, but had issues. First, the 800 pound gorilla in the room. Andrew Case raises an excellent point about relying on Powershell for live response work:

He's right. Users of live response tools relying on the Windows API must remain cognizant that adversaries may use malware to subvert the Windows API to prevent discovery. In plain English, when attackers compromise a computer, they can install malicious software that can lie about itself and its activities. A comprehensive incident response strategy must include other tools, some that get off the box entirely, a la network security monitoring, and some that subvert the Windows API themselves. Clicking the image above will take you to the Twitter thread on this subject.

My response to Case's absolutely correct claim, is two-fold.

1. I've already mentioned, any investigator using tools on live systems that rely on the Windows API must keep in mind their tools may be lied to and therefore may provide incomplete or inaccurate information.
2. As I replied to Case on Twitter, "not every threat actor is hooking" [the Windows API]. "If you can't find it with a first pass, go deep," meaning a tool like Mal-Seine can run relatively quickly across hosts and may not require you to push agent software to every node. If you don't find what you're looking for, you may need to push agents to each node and dig deeper.

To which the grugq smartly replied:

 

Based on this conversation, I sought data about the percentage of malware known to subvert the Windows API. The lack of response from the big players in the anti-malware community was disappointing. One anti-malware group engaged in the conversation and they couldn't provide numbers, but said that API hooking is a capability that generally runs in a small number of malware families and that based on the data I was collecting via Mal-Seine, it was unlikely that there would be very many families that could hide themselves completely.

 

That said, one is too many and in the cat-and-mouse-game that is information security, it's only a matter of time before every piece of malware has these capabilities. We absolutely need more tools in the defensive arsenal that are as advanced as the most advanced malware. Mal-Seine and its successor, Kansa, are not these advanced tools.

 

Potential Kansa users, I implore you to keep in mind this significant caveat. It's right there in the Readme.md.

 

Having said that, do I think it can still be a useful tool? Yes. If you're in a Windows 7 or later enterprise environment and your systems are configured for Powershell remoting, it can be a powerful way to collect data from hundreds, thousands, tens of thousands of systems in a relatively short amount of time.

 

Aside from this API subversion issue, which persists in Kansa, the issue with Mal-Seine was that it wasn't written to take advantage of Powershell's remoting capabilities, therefore it didn't scale well and more importantly, because it called binaries from a share and wrote its data to a share, it required CredSSP. What's the issue with CredSSP? From Microsoft's TechNet:

 

 

The issue is highlighted. Because the script was calling binaries from a share, writing data to a share and being run remotely, it required the user's credentials be fully delegated to each system where it was running, so those remote systems could authenticate to the bin and data shares as that user. This unconstrained delegation meant that the user's credentials were exposed for harvesting by adversaries on every node where the script was run. That's bad. During IR we want to mitigate risk, not increase it. CredSSP was increasing risk.

 

Another short-coming of Mal-Seine was that it was monolithic. The logic for all the evidence to be collected from remote systems was contained in one file. If a user wanted to only collect a subset of the evidence or wanted to add new data for collection, they would have to modify the script.

 

When I set out to rewrite Mal-Seine, I had three goals in mind:

1. It needed to obviate CredSSP.
2. It needed to take full advantage of Powershell's remoting capability to make it more scalable.
3. It needed to be modular.

I'm happy to say that with the help of folks like @jaredcatkinson,  @scripthappens, @JosephBialek and no small amount of hand-holding by @Lee_Holmes, items one and two from the list were brought to fruition.

 

For goal three, I turned to the grand-daddy of all modular forensics tools for inspiration, @keydet89's, RegRipper. As a result, Kansa is modular with the main script providing the following core functionality:

• If the user doesn't supply their own list of remote systems, targets, Kansa will query Domain Controllers and build the list automatically
• Error handling and transcription with errors written to a central file and transcription optional
• Powershell remote job management -- invoking each module on target systems, in parallel, currently using Powershell's default of 32 systems at a time
• Output management -- as the data comes in from each target, Kansa writes the output to a user specified folder, one file per target per module
• A modules.conf file where users can specify which modules they want to run and in what order, lending support to the principal of collecting data in the order of volatility

There is more work to be done on the project and I'm actively maintaining a ToDo list on the Github site.

 

In addition to this core functionality, there are the modules, or collectors as I like to think of them. Today there are 18 collectors. For the most part, the collectors are stand-alone Powershell scripts, two current exceptions are Get-Autorunsc.ps1 and Get-Handle.ps1, which each require Sysinternals binaries, Autorunsc.exe and Handle.exe, respectively, to be in the $env:SystemRoot path of each target, which corresponds to the Windows ADMIN$ share, so if you want to use those two collectors, first push those binaries to the ADMIN$ shares of your targets. If your environment supports Windows Remoting, you can accomplish this with a foreach loop and Copy-Item; thousands of hosts in a relatively short order.

 

If you want to play around with Kansa, download the project, skim the code (the code is always the most accurate documentation, if not the most readable :b), ensure your target(s) support(s) Windows Remoting, covered elsewhere, Bing it. I recommend building a target list by putting the names of a couple test systems in a text file, below mine is called "hostlist", the -TargetCount argument is optional, my hostlist file contains dozens of systems, but I only want to run it on a couple.

 

Here's a sample command line:

 

.\kansa.ps1 -ModulePath .\Modules -OutputPath .\Output\ -TargetList .\hostlist -TargetCount 2 -Verbose

 

 In a future post, I'll cover more details about Kansa and its modules. The script enables data collection and data collection is easy compared to analysis. So, I've added an Analysis folder to the project and have provided some sample scripts therein. Most of these will require logparser. My goal is to automate analysis as much as possible. When dealing with data from many systems, automation is essential.

 

Thanks for reading, for trying out Kansa and for any feedback or contributions!