Kansa

What Kansa does

Live response and endpoint triage

Kansa is a modular, PowerShell-based incident response framework for Windows environments. It uses PowerShell Remoting to execute collection modules on one or more Windows systems and return the results to a central investigation workstation.

• Collect live state
  Processes, connections and selected Windows artefacts from authorised endpoints.
• Find persistence
  Review evidence of persistence and other incident-response indicators.
• Hunt consistently
  Run reviewed collectors across multiple systems and compare them with a baseline.

Kansa is primarily a live-response and triage framework. It is not intended to replace forensic disk imaging, memory acquisition or full endpoint monitoring platforms.

Authorisation required

Only run Kansa against systems that you own or are authorised to examine. Kansa can remotely execute PowerShell code and collect information from target systems.

Choose your journey

01Install Kansa

Prepare PowerShell, obtain Kansa and review the execution boundary.

Complete when the source and version are recorded.Beginner · Windows workstation · 10–20 min 02Prepare remoting and modules

Test the authorised boundary and identify exactly which collector will run.

Complete before any remote collection.Guided · Isolated Windows lab · 20–30 min 03Collect and analyse processes

Run the focused demonstration, inspect TSV output and interpret process context.

Complete when one lead is bounded and reviewable.Beginner · Local collection · 20–35 min 04Collect from remote systems

Use an explicit target list and stage the workflow across authorised endpoints.

Continue only after the local workflow succeeds.Intermediate · Two endpoints · 25–45 min 05Preserve and troubleshoot

Retain output, hashes and errors, then diagnose Kansa or WinRM failures.

Apply throughout every collection.Evidence handling · 15–25 min 06Go hands-on

Type commands in the browser simulation or complete the two-endpoint Full Lab.

Complete when another analyst can review the result.Guided beginner · Two alternative routes

Recommended beginner path

Complete journeys 1–3 in order, review evidence handling, then try the Interactive Lab. Start the Full Lab only after both authorised endpoints pass the remoting checks.

How Kansa Works

• Runner
  The main kansa.ps1 collection script.
• Collectors
  Individual PowerShell collection modules.
• Analysis
  Optional scripts for reviewing returned data.
• Scope
  Configuration files that control which modules execute.

A typical workflow is:

1Investigator workstation›2PowerShell Remoting›3Target endpoint›4Collection module›5Timestamped output

Output structure

Kansa writes collected data into a timestamped directory. Separate subdirectories are created for the modules that were executed, and data from each target is written to its own file.

Interpretation limit

Kansa records what Windows and PowerShell interfaces returned at collection time. A compromised host may hide or alter information, so corroborate important observations with another collection method or evidence source.

Kansa Compared with Other DFIR Tools

Tool	Primary purpose	Live system	Offline evidence
Kansa	PowerShell-based endpoint triage and remote collection	Yes	Limited
KAPE	Rapid artefact collection and processing	Yes	Yes
Velociraptor	Enterprise-scale endpoint collection and threat hunting	Yes	Yes
Volatility	Memory forensics	No	Memory image
Zimmerman Tools	Windows artefact parsing and analysis	Limited	Yes

Good operational fit

Kansa is especially useful when:

• PowerShell Remoting is already enabled
• an agent cannot be installed
• a small number of artefacts must be collected quickly
• analysts want to create or modify their own PowerShell collectors
• a lightweight one-to-many collection method is required

Where Kansa fits

Best fit

Focused, repeatable Windows live-response collection across one or many explicitly authorised endpoints.

Collection model

PowerShell Remoting executes selected modules and writes per-host results into timestamped output folders.

Important limit

Results are live-system observations. A compromised host or user-contributed module can return incomplete or misleading data.

Kansa is particularly useful when an analyst needs the same focused question answered across several Windows systems. It is not a disk imager, memory acquisition tool or substitute for independent corroboration. Although Kansa modules are conventionally collection-focused and use Get- names, that convention is not a technical safety boundary: review every script before use.

Evidence workflow

1Case question›2Explicit targets›3Reviewed module›4Remote execution›5Per-host output›6Corroborated finding

The timestamped directory, module configuration, target list and error log are part of the evidence context, not housekeeping. Preserve them with the returned rows so a reviewer can identify what ran, where it ran and which hosts failed.

Before you begin

Authority and targets

Confirm the authorised endpoint list and start with one disposable test system.

Remoting and module

Validate the narrowest authenticated remoting boundary and review every collector before execution.

Output and context

Prepare controlled storage and retain the target list, module configuration, timestamps and errors.

Do not confuse reach with confidence

Running the same collector across many hosts can reveal useful differences, but it also increases the impact of a configuration mistake. Start with one disposable endpoint, then a small canary group. Never allow a missing target list or module configuration to broaden the collection unintentionally.

Analyst decisionYou need to compare running processes on two authorised lab endpoints. What is the defensible starting point?

Run every module against every reachable Windows hostReview one process module, save the two-host target list and test it first on one disposable endpointUse whichever command completes fastest and document it afterwards

Select the action that preserves scope and attribution.