Remote Execution and Kansa – Still One of the Most Underrated IR Tools

Whenever I talk about incident response or large-scale data collection, one feature that never fails to amaze me is how PowerShell handles remote execution. It’s built right into Windows, it’s fast, secure, and surprisingly flexible. And trust me — once you understand how powerful remote execution can be, tools like Kansa start to make a lot more sense.

Let’s start with the basics.

PowerShell Remoting – The Foundation for Scalable Response

One of the most useful features of PowerShell is its native support for running commands on remote systems. That’s exactly what makes PowerShell such a gem for incident responders.

It uses Windows Remote Management (WinRM), which in turn relies on WS-Management (WSMAN) — a protocol that runs over HTTP/S and uses SOAP and XML for communication.

If you’ve ever used

Enter-PSSession <computername>

you already know how easy it is to jump into an interactive remote shell. And unlike RDP or PSExec, PowerShell doesn’t leave your credentials lying around on the remote system. That’s a huge win for security.

But the real magic happens when you use

 Invoke-Command

With this cmdlet, you can push commands or even entire scripts to one or multiple remote systems — simultaneously. No loops, no complexity. Just one command, and you’re executing across potentially hundreds or even thousands of machines.

You might think, “Alright, but won’t that take forever?”

Actually, no., WMI loop across 100 systems took six hours, while Invoke-Command did it in just 15 seconds. When scaled up to 1,000 systems, it will finish in just over two minutes. That’s the level of efficiency PowerShell brings to the table.

So why am I talking so much about PowerShell remoting?

Because that’s exactly what powers Kansa, one of the most beautifully simple yet powerful tools I’ve ever used in my incident response toolkit.

-----------------------------------------------------------------------------------------------------------

Let’s Talk About Kansa

Now, I’ll be honest — Kansa isn’t actively maintained by Dave Hull anymore. But even without updates, it’s still one of the most solid, reliable PowerShell-based IR frameworks out there. If you ask me personally,

I’d say I prefer KAPE for many use cases, especially for its modular speed and portability. But when I first saw how simple and effective Kansa is, I couldn’t help but dive into it.

What Makes Kansa Awesome

Kansa leverages PowerShell Remoting to run user-defined modules across multiple systems. Whether you’re performing an incident response, threat hunt, or building an environmental baseline — Kansa’s got you covered.

Here’s what it does under the hood:

• If you don’t give it a list of targets, it’ll automatically query Domain Controllers to find systems.

• It manages errors and logs everything neatly to a central file.

• It runs modules in parallel, up to 32 systems at a time by default.

• It organizes the output beautifully — one file per host per module.

• And it uses a Modules.conf file where you decide which scripts to run and in what order.

That last point is really smart. The configuration follows the Order of Volatility, meaning it prioritizes collecting fast-changing data like DNS cache, ARP tables, or Prefetch information first, before moving on to less volatile artifacts. You just move the module names up or down in the file to control the order.

Kansa was built for scale — you can gather data from hundreds (or even thousands) of hosts at once, as long as two things are true:

1. WinRM is enabled on your targets, and

2. You’ve got local admin access.

That’s it. No fancy setup, no third-party dependencies.

-------------------------------------------------------------------------------------------------------------

Setting Up and Using Kansa

Getting started is simple — you just grab it from GitHub (https://github.com/davehull/Kansa) and extract it anywhere you like. Inside the repository, you’ll find:

• A Modules folder — this is where the data collection scripts live, grouped by type.

• An Analysis folder — which contains PowerShell scripts for post-collection analysis.

If you plan to use the analysis scripts, make sure to drop logparser.exe into your system path (it’s not included by default).

The good part is — Kansa’s output is tab-separated text, so you can load it into Excel, a database, or even feed it into Logparser for custom queries.

And here’s what makes it even better:

You don’t have to run the full suite — each of Kansa’s PowerShell scripts can be executed separately. This flexibility means you can use it like a mini collection toolkit. Run just what you need, when you need it.'

Honestly, some of the Kansa scripts are among the best-written PowerShell scripts I’ve seen in the IR space. They’re clean, modular, and incredibly easy to adapt.

---------------------------------------------------------------------------------------------------------

Getting Started with Kansa

A simple command to kick off data collection using Kansa looks like this:

PS C:\tools\Kansa> .\kansa.ps1 -TargetList .\hostlist -Pushbin

Here’s what each parameter means:

• -TargetList .\hostlist → Specifies the list of systems you want to collect data from. The file should contain one host per line.

  • If you omit this parameter, Kansa automatically queries Active Directory for all systems.

  • To use AD querying, make sure the Remote Server Administration Tools (RSAT) module is installed.

  • You can also limit the scope using -TargetCount to test with a smaller subset before scaling up.

• -Pushbin → Tells Kansa to push any required third-party binaries to the target systems before running the collection scripts.

Understanding the Kansa Folder Structure

Kansa’s folder structure is simple and modular:

Kansa
│
├── kansa.ps1             # Main launcher script
├── Modules               # Contains PowerShell collectors
│   ├── bin               # Third-party binaries
│   ├── Get-Autorunsc.ps1
│   ├── Get-CertStore.ps1
│   └── ...
└── Output                # Collection results (auto-created)

All collection results are saved in the Output folder. Each module’s results are written into its own subfolder, and most modules output data in TSV (Tab-Separated Values) format, making it easy to parse and analyze.

Adding Third-Party Binaries

While PowerShell is powerful, some modules depend on third-party tools. Kansa supports this through a simple mechanism called a binary dependency directive.

For example, the Get-Autorunsc.ps1 module includes the following line:

# BINDEP .\Modules\bin\Autorunsc.exe

This line tells Kansa to copy Autorunsc.exe to the target machine before running the script. The binaries are copied by default to %SystemRoot% (usually C:\Windows).

If you want Kansa to clean up after itself, use the -Rmbin argument to remove these binaries once collection completes.

Some modules that rely on third-party binaries include:

• Get-Autorunsc.ps1

• Get-CertStore.ps1

• Get-FlsBodyfile.ps1

• Get-Handle.ps1

• Get-ProcDump.ps1

• Get-RekalPslist.ps1

Kansa at Enterprise Scale

Originally, Kansa was designed for small to mid-scale collections (150 systems or fewer at a time). However, in 2020, Jon Ketchum transformed it into a truly enterprise-scale tool capable of handling data collection across 150,000+ systems.

Why Kansa Matters

Kansa bridges the gap between manual data collection and enterprise-grade visibility. It allows responders to:

• Gather forensic artifacts quickly from multiple endpoints.

• Integrate PowerShell and third-party tools into a single workflow.

• Scale investigations without complex infrastructure.

Whether you're running an investigation on 10 systems or 10,000, Kansa adapts to your operational tempo.

Real Talk: The Trade-offs

Of course, like any live response framework, Kansa isn’t immune to being tricked by rootkits. Since it relies on Windows APIs (just like WMI, .NET, or system commands), a well-built rootkit could theoretically hide its presence. But in the real world, that’s rare.

You’re trading off a bit of forensic depth for speed and scale, and that’s usually worth it when you’re dealing with hundreds of endpoints. You can always follow up with a deep dive on a smaller set of systems once you’ve used Kansa to get the bigger picture.

Conclusion

Kansa remains one of the most underrated tools in incident response. It combines the flexibility of PowerShell with the structure of a modular framework — perfect for both rapid triage and deep forensic collection.

If you’re building your own IR toolkit, Kansa deserves a top spot on your list.