Preserve evidence and troubleshoot Kansa

Retain collection context and errors alongside the results so another analyst can reproduce the workflow and understand its limitations.

Provenance

Retain the case question, target list, Kansa revision, PowerShell version, module and command.

Integrity

Preserve the timestamped output, working-copy identity, hashes and `Error.Log` files.

Finding

Separate observation, interpretation, confidence, limitations and the next corroborating action.

Evidence Handling

Kansa performs live collection. The resulting files should be handled as investigation data.

Record collection details

Record:

• investigation or case reference
• analyst name
• collection date and time
• Kansa version or Git commit
• collection workstation
• target hostname
• target IP address
• modules executed
• commands used
• output directory
• errors encountered

Example investigation note:

Tool: Kansa
Collection host: SUSA
Target: WIN11-LAB
Collection time: 2026-07-27 14:30 NZST
Module: Modules\Process\Get-ProcsWMI.ps1
Output format: TSV
Output directory: C:\Tools\Kansa\Output_20260727143015
Purpose: Collection of running-process information following a test alert

Hash the collected output

Create a SHA-256 inventory of the output files:

Get-ChildItem -Path $KansaOutput.FullName -File -Recurse |
    Get-FileHash -Algorithm SHA256 |
    Export-Csv `
        -Path "$($KansaOutput.FullName)\SHA256SUMS.csv" `
        -NoTypeInformation

Display the inventory:

Import-Csv "$($KansaOutput.FullName)\SHA256SUMS.csv" |
    Format-Table -AutoSize

Note

Hashes help demonstrate that the collected files have not changed since the hash inventory was created. They do not prove that the original live system was uncompromised.

Preserve a working copy

Where evidence-handling procedures require it:

1. Preserve the original Kansa output.
2. Create a verified working copy.
3. Perform filtering and analysis on the working copy.
4. Retain investigation notes and generated reports separately.
5. Document any transformations made to the collected data.

Troubleshooting

Script execution is disabled

Example error:

running scripts is disabled on this system

Check the policies:

Get-ExecutionPolicy -List

Apply a temporary process-level policy:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Unblock the scripts:

Get-ChildItem -Path . -Filter *.ps1 -Recurse | Unblock-File

WinRM is not enabled

Test WinRM:

Test-WSMan -ComputerName localhost

Enable PowerShell Remoting:

Enable-PSRemoting -Force

Confirm that the service is running:

Get-Service WinRM

Kansa cannot create a local session

When targeting localhost, explicitly set the authentication method:

.\kansa.ps1 `
    -Target localhost `
    -Authentication Default `
    -ModulePath ".\Modules\Process\Get-ProcsWMI.ps1" `
    -Verbose

Also verify that a normal session can be created:

$Session = New-PSSession `
    -ComputerName localhost `
    -Authentication Default

Remove-PSSession $Session

Access is denied

Confirm that:

• PowerShell was opened as Administrator
• the account has appropriate permissions
• the target permits remote administration
• endpoint security controls are not blocking the operation
• the selected module does not require additional permissions

Do not disable endpoint protection merely to make the collection work unless this is authorised and required by the controlled lab procedure.

Output contains an Error.Log

Locate the newest output directory:

$KansaOutput = Get-ChildItem -Path . -Directory -Filter "Output_*" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -First 1

Read the error log:

Get-Content "$($KansaOutput.FullName)\Error.Log"

Some modules may fail while others complete successfully. Review the result directories as well as the error log.

A module requires an external binary

Some Kansa modules depend on third-party utilities. Kansa does not necessarily distribute these binaries.

Review the module for a BINDEP directive:

Select-String `
    -Path ".\Modules\*.ps1", ".\Modules\*\*.ps1" `
    -Pattern "^BINDEP"

The required binary is normally placed beneath:

C:\Tools\Kansa\Modules\bin

Only obtain third-party tools from trusted sources and verify their integrity before use.

The complete module set takes too long

Do not initially run:

.\kansa.ps1 -Target localhost -ModulePath ".\Modules"

Instead, specify one module:

.\kansa.ps1 `
    -Target localhost `
    -ModulePath ".\Modules\Process\Get-ProcsWMI.ps1" `
    -Authentication Default `
    -Verbose

Expand the collection only after confirming that the initial module works correctly.

Cleanup

Close the test application

Stop Notepad:

Get-Process notepad -ErrorAction SilentlyContinue |
    Stop-Process

Disable PowerShell Remoting in an isolated lab

When PowerShell Remoting was enabled solely for this local demonstration and is no longer required:

Disable-PSRemoting -Force

Review the WinRM service:

Get-Service WinRM

Warning

Do not disable PowerShell Remoting on managed or production systems without confirming that it is not required for administration, monitoring or security operations.

Disable-PSRemoting prevents remote access to PowerShell session configurations, but it does not reverse every change made by Enable-PSRemoting; for example, WinRM service, listener and firewall configuration can remain. For a disposable lab, reverting to a known snapshot is the clearest rollback. Otherwise, restore the documented system baseline rather than assuming this single command returns the host to its previous state.

Close PowerShell

The temporary execution policy configured with -Scope Process is automatically removed when the current PowerShell process closes.

Summary

In this procedure, Kansa was used to:

1. prepare Windows PowerShell and WinRM
2. examine the available collection modules
3. launch a known test process
4. collect running-process information from localhost
5. locate and import the resulting TSV
6. identify the test process in the collected results
7. review the information for suspicious paths, command lines and parent-child relationships
8. create a SHA-256 inventory of the output

Kansa provides a lightweight and customisable method of collecting live-response information from Windows systems. Its modular design makes it useful for targeted incident-response collections, small-scale threat hunting and learning how Windows endpoint artefacts can be gathered with PowerShell.

For larger environments or continuous endpoint visibility, Kansa should generally complement rather than replace platforms such as Velociraptor, EDR or centralised logging.

Interpret failures before retrying

Use the failure location to choose the next check:

Failure point	Check first	Preserve
Before connection	target spelling, authority, name resolution and network profile	target list and connectivity result
During authentication	account context, trust path and permitted remoting method	exact error without exposed secrets
During module execution	module dependency, bitness, permissions and endpoint load	module revision, parameters and Error.Log
After collection	delimiter, schema, truncation, time zone and host attribution	original output plus a hashed working copy

Evidence checkpointOne endpoint produces an empty TSV and an `Access is denied` entry. How should it be reported?

No suspicious activity was presentCollection was unsuccessful for that endpoint; preserve the empty output and error, resolve the access boundary and do not infer absenceDelete the failed endpoint from the result set

Select the statement that distinguishes absence from failure.

PreviousCollect from remote systemsNextKansa Hands-on Labs