Skip to content

Session Management

Melvin PETIT edited this page Jun 17, 2026 · 1 revision

Session Management

A session groups all output from one engagement under a single directory. Every module writes into the active session, and the report aggregates across it. Session handling lives in lib/session.sh.

Choosing a session at startup

On launch Kraken shows a preview of existing sessions (name, size, file count) and offers three modes:

Mode Description
1 – Create new named session Prompts for a descriptive name. Reuses the directory if the name already exists (with confirmation).
2 – Continue existing session Lists sessions with size / file count / last-modified date; pick by number.
3 – Auto-generate Names the session session_YYYYMMDD_HHMMSS. Also the default for any unrecognised choice.

Name sanitisation

Custom names are normalised: spaces become underscores and any character outside [A-Za-z0-9_-] is stripped. An empty result is rejected. Suggested naming conventions:

client_acme_initial_scan
webapp_pentest_2025
internal_network_audit

Where sessions live

Sessions are created under the base directory, kraken_output/ by default. Override it with the KRAKEN_BASE_DIR environment variable:

KRAKEN_BASE_DIR=/data/engagements ./kraken.sh

The default kraken_output/ is gitignored, so results never end up in version control. See Configuration and Output Structure.

Resuming a session

Selecting Continue existing session (or creating one whose name already exists) reuses the directory. New module runs add subdirectories alongside the old ones, and kraken.log is appended to, preserving a continuous audit trail across sittings.

Connectivity test

test_connectivity sends a single ICMP echo (ping -c 1 -W 2) before recon and scan runs. It is advisory only, a host that blocks ICMP still gets scanned; Kraken just warns that it may be unreachable.

Clone this wiki locally