Kansa’s Stafford release: More capable, more forensically sound, more flexible

Over the last few months significant changes have been pushed to Kansa’s next branch. Those changes were very recently pushed to master, then packaged into the Stafford release. I mentioned in the release notes I would have a longer post here about the changes. There have been more than 130 commits since the previous release, I won’t cover all of them, but let’s hit the major changes.

Kansa.ps1 has a handful of new parameters and command line switches:

This is an optional parameter that takes an argument specifying the format for Kansa’s output. Those familiar with Kansa know that individual collectors used to specify their own output format. Some collectors would return CSV, some would return CLIXML, some would return binary data. Now all collectors return data in a common format with CSV being the default. Valid arguments to -OutputFormat are CSV, JSON, TSV and XML. With the exception of JSON, all of these were previously supported. Support for binary and zip formats has been removed.

You may be wondering how Kansa returns binary data since it can be used to collect arbitrary files and memory dumps. In previous releases, those data types were returned as binary files. With the Stafford release, those data elements are serialized and stored as object properties, those objects are then returned and stored as CSV or whatever output you specify. So a binary file is now a serialized property on an object. The serialization is base64 encoded, gzipped bytes of the original binary file.

Obviously you need a way to deserialize this data in order to analyze it. There’s a new analysis script for this in Analysis\Deserialize-KansaField.ps1. More details on this in a later post.

Another optional parameter that takes an int32 argument. Because we’ve added support for JSON, we had to add a parameter for specifying the depth of JSON’s serialization. The default for Kansa is 10, which is sufficient for many things, but if you need to go deeper, you can.

If this optional switch is present, Kansa.ps1 will call New-PSSession with the -UseSSL switch and remote sessions will use Secure Sockets Layer, iff you’ve done the legwork to push certificates. More on this in a later post.

Previous releases of Kansa only supported Kerberos (non-delegated, network) authentication, which is the safest authentication mechanism, if you’re concerned about credential theft when running investigations across large numbers of hosts, which is something you should be concerned about. The trouble with only supporting Kerberos authentication is that it meant Kansa could not work in many scenarios, like authenticating against a local administrator account in cases where you either don’t want to use a forest admin credential or you’re investigating a machine that is not domain joined.

-Authentication is an optional parameter, acceptable arguments are “Basic”, “CredSSP”, “Default”, “Digest”, “Kerberos”, “Negotiate” and “NegotiateWithImplicitCredential”. Remember, some of these will put your credentials at risk for harvesting by attackers. The default is still Kerberos.

And finally, for those running with PowerShell endpoints on alternate ports, you can use this optional parameter with an argument to specify the remote management port to use on the remote host(s).

The first change above related to Kansa’s output, makes the framework more forensically sound because we’ve eliminated a few cases where Kansa would previously write data to disk on remote hosts, potentially overwriting deleted data on those systems.

The second set of changes, relating to authentication and transport make the framework more capable for non-domain scenarios. One thing I can now do with the framework that I couldn’t do before is run it against Azure VMs to collect data from the cloud… fluffy, fluffy clouds.

There are lots of other changes in Stafford as well and not all of them were committed by me. @z4ns4tsu made significant contributions to this release, including Modules\Disk\Get-MasterFileTable.ps1, a tool for parsing the MFT from target systems. Because it uses Win32 device namespace to access the file system in the raw, it bypasses file locks, attributes and access control lists.

@JValdezjr1 also contributed changes, including some code in kansa.ps1 that will save target lists to a file when Kansa builds the target list dynamically by querying AD for the list of hosts in the domain.

Kansa is maturing and this release is the most capable version yet. Please give it a try and if you run into problems, I’m the primary developer, so I’m sure there are bugs, open an issue at and let me know what problems you’re encountering.

I’ll be following up in a few days with a post that demonstrates some of the new features in this release.

Happy hunting!

*** This is a Security Bloggers Network syndicated blog from trustedsignal -- blog authored by davehull. Read the original post at: