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 100th 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.
|Figure 1 – Kansa test run|
|Figure 2 – Kansa uncovers an autorun entry|
|Figure 3 – Kansa pivots on adbreport.exe handles|
|Figure 4 – Kansa closes the circle with the adbreport.exe MD5 hash|
|Figure 5 – Kansa frequency analysis across results|
|Figure 6 – Kansa determines creation dates across results|