Collect from remote systems¶

Continue only after the local process collection succeeds and every target is explicitly covered by the lab authority.

Targets

Use a saved list containing only the authorised endpoint names; retain it with the case.

Canary

Test one disposable endpoint, then a small group, before increasing the collection scope.

Credentials

Use an approved account, avoid embedding secrets in scripts and record which security context performed the collection.

Optional Demonstration: Collect Network Connections¶

Kansa includes a module for collecting network connection information.

Confirm that the module exists:

Test-Path ".\Modules\Net\Get-Netstat.ps1"

Run the module through Kansa:

.\kansa.ps1 `
    -Target localhost `
    -ModulePath ".\Modules\Net\Get-Netstat.ps1" `
    -Authentication Default `
    -OutputFormat TSV `
    -Verbose

Locate the newest output directory:

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

List the generated TSV files:

Get-ChildItem -Path $KansaOutput.FullName -Filter *.tsv -Recurse

Network results can help identify:

listening services
active outbound connections
unexpected destination addresses
unusual ports
processes associated with network activity

Collecting from a Remote Windows System¶

Requirements¶

Remote collection normally requires:

PowerShell Remoting enabled on the target
WinRM connectivity
appropriate firewall rules
administrator privileges on the target
compatible authentication and trust configuration
authorisation to collect information from the system

Test connectivity before running Kansa:

Test-WSMan -ComputerName "HOSTNAME"

Test a remote PowerShell session:

$Session = New-PSSession -ComputerName "HOSTNAME"

Remove the test session:

Remove-PSSession $Session

Run the process module against the remote system:

.\kansa.ps1 `
    -Target "HOSTNAME" `
    -ModulePath ".\Modules\Process\Get-ProcsWMI.ps1" `
    -OutputFormat TSV `
    -Verbose

Using Alternate Credentials¶

Prompt for credentials:

$Credential = Get-Credential

Run Kansa with those credentials:

.\kansa.ps1 `
    -Target "HOSTNAME" `
    -Credential $Credential `
    -ModulePath ".\Modules\Process\Get-ProcsWMI.ps1" `
    -OutputFormat TSV `
    -Verbose

Warning

Authentication behaviour differs between domain, workgroup and cross-forest environments. Do not add broad TrustedHosts entries unless the security implications have been considered.

Using a Target List¶

Create a plain-text target list:

@"
HOST01
HOST02
HOST03
"@ | Set-Content ".\targets.txt"

Run Kansa against the systems in the list:

.\kansa.ps1 `
    -TargetList ".\targets.txt" `
    -ModulePath ".\Modules\Process\Get-ProcsWMI.ps1" `
    -OutputFormat TSV `
    -Verbose

Use fully qualified domain names where required:

HOST01.example.local
HOST02.example.local
HOST03.example.local

Start with one test endpoint before expanding the collection to multiple systems.

Control the blast radius¶

One-to-many collection multiplies both value and risk. Confirm the target count before execution, watch the first jobs, and stop if error rates or endpoint load depart from the lab plan. Preserve Error.Log and distinguish not collected from collected with no matching row; those outcomes have different meanings.

Scale checkpointThe single-host test succeeds, but the two-host run returns an access error for one endpoint. What should you do?

Select the response that keeps failure visible.