Kali tool workflows should preserve attributable results beyond an open terminal session. Record the task question, original output, evidence retention and untested coverage.
Sources, review date and section shortcuts
Key claims reviewed: October 19, 2026. Eight workflow groups contain more than eight programs; tool output remains evidence to interpret.
Primary documentation · Evidence notes and backups
Go straight to: Decision check · Main workflow · Further detail
Open the Kali: Tool-workflow handoff for this guide’s task-specific fields and next action.
Keep session persistence separate from evidence retention
A tmux session can remain available after detaching while its server and processes continue running. This is not protection against a host restart, storage loss or a broken target connection. Keep relevant commands and output in files with target and time context, then preserve those files through an independent recovery method. Use the rest of the tool list by a specific question, not as a promise that installing every program establishes coverage. Source and scope.
Choose the tool that answers your next question, then save enough evidence to explain the result. A terminal session, an open port, a successful login and a highlighted privilege escalation lead establish different things. Treating them as interchangeable can send a practice session in the wrong direction.
This documentation-based guide covers eight tool groups for authorized training environments. The last group contains two programs, linPEAS and pspy. It reports no benchmark, personal exploitation story or guaranteed completion time. Sources checked October 16, 2026. Availability and flags depend on the installed release; check its help and the rules of the exercise before running anything.
Start with a small evidence record
Write the authorized target, question, tool version, relevant settings, observation, limitations and next step. Keep output filenames distinct so a repeat run does not overwrite the earlier result. Store credentials and sensitive captures separately with appropriate access controls. A useful record distinguishes “not observed” from “tested and absent.” If the underlying VM or network is unreliable, work through the Kali lab infrastructure checks before repeating tests.
1. tmux: preserve a terminal session, not a broken network
The tmux getting-started guide describes a background server managing programs and clients attaching to it. Detaching a client can leave those programs running while that server and its host remain alive. Reattachment restores access to that existing session.
Where tmux runs matters. A session on a remote lab machine can outlive the client’s SSH disconnection, provided the remote server and processes survive. A local tmux pane containing an SSH client does not preserve a remote shell when that SSH connection ends. tmux also cannot repair a VPN, restore a rebooted host’s processes or guarantee that a network-dependent command continues after a connection failure.
For a basic local practice session, tmux new -s lab creates a named session. With default bindings, press Ctrl+b, then d to detach. tmux attach -t lab reconnects to that session if it still exists. Keep important output in files too; terminal scrollback is not an independent backup.
2. Nmap: record coverage before judging completeness
Write the target, transport, port range, discovery assumptions and result file. A result from selected TCP ports says nothing definitive about untested TCP ports or UDP services. A filtered result is also different from a confirmed closed port. Service identification produces evidence to investigate rather than proof that a particular vulnerability exists.
Nmap’s timing documentation explains that --min-rate requests a sending-rate floor, while --max-rate sets an upper rate for host discovery and port scanning. An excessive minimum can reduce accuracy or increase retransmissions. It is not a universal “safe speed” setting, and a port-scan rate limit does not govern every other Nmap feature.
Start with the exercise’s permitted target and traffic limits. Expand coverage deliberately and save the exact command and output. Separate initial port discovery from chosen service checks; review any script before including it. Unexpected timeouts or inconsistent results justify investigating the path and load before simply increasing speed.
3. ffuf: compare responses before filtering them away
Content discovery needs a known response to an existing path and to a deliberately nonexistent path on the authorized application. Some applications return the same status or template for both. A response status, size or redirect is a clue to inspect, not proof of a reachable administrative feature or exploitable endpoint.
The ffuf project documentation describes matching, filtering, calibration, output and execution limits. Choose a small relevant input list, an approved request rate and a stop condition. A filter that suppresses a common response can also hide an interesting result; retain enough baseline information to explain the choice and manually inspect representative matches.
Keep total requests distinct from concurrent work and requests per second. A concurrency setting alone is not a request-rate cap. A run stopped by a time limit has incomplete coverage; record that limitation rather than calling the application fully enumerated.
4. Burp: compare a baseline with one controlled change
Use a dedicated testing browser and the intended application account. Preserve a baseline request and response, then change one relevant element in Repeater. Check whether session state, changing tokens, redirects or dynamic content could explain the difference before attributing it to a vulnerability. Avoid replaying actions that create purchases, delete data or otherwise change state without an approved test plan.
PortSwigger’s scope documentation describes how target scope supports filtering and interception choices. Scope is not a network firewall. Review the separate Repeater redirect settings; automatically following a redirect can send another request, potentially to a different destination. Check destination and cookie behavior before proceeding.
5. NetExec: distinguish authentication from permission
Use only explicitly authorized accounts, hosts and protocols. Before any authentication attempt, establish the account format, domain or local context, lockout policy, attempt budget and stopping condition. A login accepted by one protocol on one host does not establish administrator rights, remote command execution or access to another host.
The NetExec password-spraying documentation warns about account lockouts and explains how username and password lists can produce multiple combinations. Do not turn a known credential pair into a subnet-wide sweep by default. Record the specific result without copying passwords into a general run log. A failed attempt may require checking account context and service policy, not more guesses.
6. chisel: verify each tool’s actual connection path
A working browser proxy does not establish that another program uses the same path. Record which endpoint listens, which initiates the connection, the intended destination and the application’s proxy configuration. Verify a benign connection to an in-scope service from the actual tool you plan to use.
The chisel project documentation describes tunneling, authentication and server fingerprint validation. Review these controls before use. Automatic reconnection does not restore every application’s prior connection or prove that DNS and all traffic types follow the intended route. ProxyChains-NG wraps supported TCP connections in dynamically linked applications; raw SYN scans and ICMP do not become proxied simply by prefixing a command. It can complement a tunnel rather than replace one. Keep listening interfaces and permitted destinations narrow, and remove temporary access under the exercise’s cleanup plan.
7. Hashcat: define a bounded offline experiment
Work only with hashes you are authorized to test. Identify the format and relevant parameters before choosing a candidate strategy. Distinguish offline hash testing from online login attempts; they have different operational effects. A format accepted by a tool is not independent confirmation that the hash was identified correctly.
The Hashcat reference documents attack modes, sessions, runtime limits and restoration options. Wordlists, rule-based mutations and masks describe different candidate strategies. Choose one from an explicit hypothesis, and consider its candidate count and the observed speed for the actual hash format. Record the mode, input identity, candidate strategy and stopping point. Report whether the run completed, stopped early or recovered a value. There is no general promise that a mask or wordlist finishes within a few minutes, or that an exhausted candidate set proves a password cannot be recovered.
8. linPEAS and pspy: gather leads, then validate the mechanism
PEASS-ng searches for possible local privilege escalation paths. Its highlighted output is a lead requiring review of ownership, permissions, execution context and whether the relevant privileged process actually uses the resource. A writable file that is never consumed by a privileged process does not establish a privilege escalation path.
The pspy project describes process observation using procfs scans triggered in part by filesystem events. It can reveal activity visible to the observing account, including short-lived processes, but a quiet observation window does not prove no scheduled job exists. Record the observation duration, visibility constraints and observed command context. Process arguments and tool output may expose secrets; handle them accordingly.
Inspect the chosen release and its behavior before running it. Automated enumeration still consumes resources and can collect sensitive information. Verify one lead using the least disruptive approved method, preserve evidence and explain any remaining uncertainty. Use the RCE, shell access and privilege escalation evidence guide to keep a possible lead separate from a demonstrated permission change.
When a practice session breaks
- Preserve existing output and write what stopped working.
- Check the relevant layer: tmux server, VPN, tunnel, application session or target service.
- Repeat one approved benign test with an expected result.
- Compare it with the last recorded baseline.
- Choose the next action that resolves a specific uncertainty.
If a necessary check has not been performed, record “not yet verified.” A fixed timer cannot guarantee a new finding or a completed machine. The goal is a reproducible decision and a clear record of what the evidence supports.
Common questions
Do I need all nine programs? No. Pick the tool group that answers the current question. Add another tool when it resolves a gap in coverage, control or evidence; collecting more output is not itself progress.
Does a tool listed here count as exam-approved? This is a practice workflow, not an exam permission list. Check the current rules for your assessment before using automation or external tools.
Should I rerun everything after a connection drop? Preserve the existing output first. Identify which process or connection failed, verify the relevant path, then repeat only the checks whose results are missing or no longer valid.
Your next step
Choose one question from your current exercise, identify the tool that can answer it and define the evidence you need before running it. Save the result and its limits, then decide what remains uncertain.
Kali: Tool-workflow handoff
Use these fields for your own task. Keep the actual conditions, evidence and unresolved questions beside the next decision.
Use the editable record below to retain the task context and unresolved questions.
Edit here, then select and copy the text to your own notes before leaving. This field has no submission or storage function; reloading resets it. Do not enter passwords, tokens or private client information. The 12,000-character limit applies to this working note.
Next action: Preserve the evidence file before relying on a persistent terminal session.
Related task: Use Kali Pentest Report Template: Markdown and PDF Workflow for that separate part of the workflow.
Worksheet change record — October 20, 2026
Added four task-specific fields, a next action and a related guide. This is a blank editorial working aid, not a completed test or validated assessment. Existing source-review dates retain their own scope; this addition is not a new verification of every statement.
Terminal persistence: retain the artifact outside the session
Illustrative example — not a performed lab test.
- Observation
- A terminal multiplexer still shows an earlier tool run, but no attributable output file can be located.
- Supported interpretation
- Session continuity preserved screen context, not necessarily a durable evidence artifact.
- Still unresolved
- Whether complete output, target scope, options and timing can be recovered after session loss.
- Next authorized check
- Save the relevant output through the intended evidence workflow and reopen it independently. Name the question and coverage beside it. Do not describe an intact terminal session as a substitute for backed-up evidence.
Practice-aid update: October 20, 2026. Added the illustrative decision case and editable note. No new VM execution or full-article revalidation is claimed.