Skip to content

Collect and analyse process evidence

Use the preserved local demonstration to establish a working baseline before expanding the collection to another authorised endpoint.

Question

Identify the process attribute you are testing: path, parent, command line, user, hash or prevalence.

Collection

Run one reviewed process module and retain the timestamped per-host TSV plus errors.

Interpretation

Treat unusual values as leads. Corroborate them with file, event, persistence and timeline evidence.

Demonstration: Collect Running Process Information

Scenario

An endpoint alert indicates that an unusual program may be running on a Windows workstation.

The analyst wants to collect the following process information:

  • process name
  • process ID
  • parent process information
  • executable path
  • command line
  • executable hash, where available

For a safe demonstration, launch Notepad and use Kansa to verify that it appears in the process results.

Launch the Test Process

Start Notepad:

Start-Process notepad.exe

Confirm that Notepad is running:

Get-Process notepad

Example:

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
    936      42    40488     118012       2.77    864   1 Notepad

Screenshot: Example:

Leave Notepad running during the collection.

Confirm the Process Module Exists

Check for the Kansa process module:

Test-Path ".\Modules\Process\Get-ProcsWMI.ps1"

Expected result:

True

Review the beginning of the module before executing it:

Get-Content ".\Modules\Process\Get-ProcsWMI.ps1" -TotalCount 80

This is a good practice when using PowerShell scripts obtained from an external source.

Screenshot: This is a good practice when using PowerShell scripts obtained from an external source

Run the Module Independently

Before using the full Kansa framework, test the module as a standalone collector:

& ".\Modules\Process\Get-ProcsWMI.ps1"

Filter the displayed output for Notepad:

& ".\Modules\Process\Get-ProcsWMI.ps1" |
    Where-Object {
        $_.Name -match "notepad"
    } |
    Format-List *

The exact fields may vary by Kansa version, but the results should identify the running Notepad process.

Screenshot: The exact fields may vary by Kansa version, but the results should identify the running Notepad process

Run the Module Through Kansa

From the Kansa directory, run:

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

Command explanation

Parameter Purpose
-Target localhost Collects data from the local Windows system
-ModulePath Specifies the individual collection module
-Authentication Default Uses the default WinRM authentication method
-OutputFormat TSV Requests tab-separated output; the module's OUTPUT tsv directive also specifies this format
-Verbose Displays detailed execution information

Example console activity may resemble:

VERBOSE: Running module:
Get-ProcsWMI
VERBOSE: Running module on machines 0 to 1 of 1 (0.0%)
VERBOSE: Waiting for Get-ProcsWMI to complete.

Screenshot: Example console activity may resemble:

Locate the Output Directory

Kansa creates a timestamped output directory under its working directory.

List the most recent output directory:

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

$KansaOutput

Screenshot: List the most recent output directory:

Open the directory in File Explorer:

Invoke-Item $KansaOutput.FullName

The output structure should resemble:

Output_YYYYMMDDHHMMSS\
├── Error.Log
└── ProcsWMI\
    └── HOSTNAME-ProcsWMI.tsv

The exact file and subdirectory names may differ slightly depending on the Kansa version.

Screenshot: The exact file and subdirectory names may differ slightly depending on the Kansa version

Identify the Results File

Search the newest Kansa output directory for TSV files:

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

$ResultFiles | Select-Object FullName, Length, LastWriteTime

Store the process result file in a variable:

$ProcessResult = $ResultFiles |
    Where-Object {
        $_.Name -match "ProcsWMI"
    } |
    Select-Object -First 1

Display the selected file:

$ProcessResult.FullName

Import and Review the Results

Import the tab-separated result into PowerShell:

$Processes = Import-Csv $ProcessResult.FullName -Delimiter "`t"

Display the available fields:

$Processes |
    Select-Object -First 1 |
    Format-List *

Search for Notepad:

$Processes |
    Where-Object {
        $_.Name -match "notepad" -or
        $_.ProcessName -match "notepad"
    } |
    Format-List *

Depending on the version of the module, useful fields may include:

  • Name
  • ProcessId
  • ParentProcessId
  • ExecutablePath
  • CommandLine
  • CreationDate
  • Hash

The current Get-ProcsWMI.ps1 module attempts to calculate an MD5 file hash and adds user and SID context. A blank or unavailable field is not proof that no executable or user exists; access, process lifetime and module behaviour can all affect the result.

Open the TSV in Timeline Explorer

When Timeline Explorer is installed:

  1. Open Timeline Explorer.
  2. Select File.
  3. Select Open.
  4. Browse to the ProcsWMI results directory.
  5. Open the generated TSV file.
  6. Use the column filters to search for notepad.

Alternatively, open the TSV with LibreOffice Calc and select Tab as the separator when prompted:

Start-Process $ProcessResult.FullName

Interpreting Process Results

The presence of a process is not, by itself, proof of malicious activity. Review the process within the wider investigation context.

Process name

Determine whether the process name:

  • matches a known Windows process
  • resembles a legitimate process but contains a spelling variation
  • has an unexpected or misleading name
  • is associated with a known administration or attacker tool

Examples of potentially misleading names include:

scvhost.exe
svhost.exe
expl0rer.exe
chrome_update.exe

Executable path

Review whether the executable is running from an expected location.

Common legitimate locations include:

C:\Windows\System32\
C:\Windows\SysWOW64\
C:\Program Files\
C:\Program Files (x86)\

Potentially suspicious locations may include:

C:\Users\Public\
C:\Windows\Temp\
C:\Users\<username>\AppData\Local\Temp\
C:\ProgramData\<unexpected-directory>\

A legitimate process name running from an unusual directory warrants further investigation.

Command line

Command-line information may reveal:

  • PowerShell encoded commands
  • scripts launched from temporary directories
  • remote network paths
  • unusual interpreter arguments
  • renamed utilities
  • suspicious download or execution activity

Examples requiring additional review include:

powershell.exe -EncodedCommand <data>
cmd.exe /c C:\Users\Public\update.bat
rundll32.exe C:\Users\Public\unknown.dll,EntryPoint
wscript.exe C:\Users\<username>\AppData\Local\Temp\update.vbs

Parent-child relationships

Review whether the process was launched by an expected parent.

Examples that may warrant investigation include:

WINWORD.EXE
└── powershell.exe
excel.exe
└── cmd.exe
services.exe
└── executable from a user-writable directory
w3wp.exe
└── powershell.exe

Parent-child relationships should be assessed alongside command-line, path, user and timestamp information.

File hashes

When a file hash is available, it may be used to:

  • compare the executable against known-good software
  • search internal threat-intelligence repositories
  • compare the file across multiple endpoints
  • identify systems running an identical binary

Do not upload organisationally sensitive files or hashes to public services unless permitted by policy.

From row to finding

1Validate host2Collect process row3Check path and parent4Correlate hash and events5Record confidence

Process names are weak identifiers. Record the full path, parent, command line, user, collection time and host before deciding whether a row is relevant. A missing row is also not proof that a process never ran: it may have exited, been hidden from the queried API or fallen outside the collector's visibility.

Analysis checkpointKansa returns `chrome_update.exe` from `C:\Users\Public` with `powershell.exe` as its parent. What does that establish?