Prepare remoting and review modules¶
Configure the smallest authorised remoting boundary, test it, and review the module configuration before running a collection.
Name each permitted endpoint and the collection question before changing WinRM or firewall settings.
Record the network profile, authentication method, listener and trust boundary used by the lab.
Use an explicit module path or reviewed `modules.conf`; do not rely on broad defaults.
Preparing PowerShell Remoting¶
Kansa uses PowerShell Remoting and Windows Remote Management, commonly called WinRM, to create sessions on target systems.
Even when collecting from the local computer, the Kansa framework expects PowerShell Remoting to be available.
Check the Current Network Profile¶
Run:
Review the NetworkCategory value.
Example:
Name : Network
InterfaceAlias : Ethernet0
InterfaceIndex : 9
NetworkCategory : Public
DomainAuthenticationKind : None
IPv4Connectivity : Internet
IPv6Connectivity : NoTraffic
If an isolated test VM uses a Public profile and the remoting configuration requires a Private profile, change it only when appropriate for that lab:
Warning
Do not change the network category on a production or managed system without confirming the security and networking requirements.
If the lab already uses a suitable profile, leave it unchanged and continue to Step 6.
Enable PowerShell Remoting¶
Run the following command from an elevated Windows PowerShell session:
This starts and configures WinRM, creates a PowerShell session configuration and enables the required firewall rules.
Check the WinRM service:
Expected result:
Test the local WinRM configuration:
A successful response should display WinRM identity and protocol information.
Test PowerShell Remoting¶
Create a temporary local PowerShell session:
Verify that the session was created:
Remove the test session:
When this test succeeds, Kansa should be able to establish a local collection session.
Reviewing Kansa Modules¶
Kansa modules are stored under:
List the module categories:
List all available PowerShell modules:
Common module categories include:
| Category | Example information |
|---|---|
Process |
Processes, Prefetch and recently executed applications |
Net |
Network connections, routes, interfaces and DNS cache |
ASEP |
Services, scheduled tasks and other persistence mechanisms |
Log |
Event logs and activity records |
Disk |
File and disk-related information |
Config |
System configuration information |
Modules may also be executed independently of the main Kansa framework.
Reviewing Modules.conf¶
The following file controls Kansa's default module selection:
Display the active configuration:
Lines beginning with # are comments and are not executed.
Example:
Process\Get-PrefetchListing.ps1
Process\Get-WMIRecentApps.ps1
Net\Get-Netstat.ps1
Net\Get-DNSCache.ps1
Process\Get-ProcsWMI.ps1
ASEP\Get-SchedTasks.ps1
Warning
Running Kansa against the entire Modules directory can execute numerous collectors and produce a large amount of output. Some collectors may require third-party binaries or take significant time to finish.
For the demonstration below, run only one process-collection module.
Remoting is an investigative change
Enabling WinRM, changing firewall rules or adding TrustedHosts changes the
endpoint. Record each change and reverse it during cleanup. TrustedHosts
does not authenticate a remote computer; avoid broad or wildcard values and
prefer the lab's established authenticated trust where available.