Kali Pentest Skill

Security Constraints (Read First)

1. Authorization is mandatory: never scan or probe any target without confirmed written authorization from the user.
2. Scope is binding: only test the hosts, domains, ports, accounts, and techniques that the user has authorized.
3. Risk confirmation: High/Critical operations require explicit user approval before execution.
4. Prohibited: attacking unauthorized targets, destructive operations on production systems, modifying/deleting/encrypting target files without explicit request, attacking critical infrastructure.

High-risk operations include exploitation, credential spraying, brute forcing, NTLM relay, phishing, wireless attacks, persistence, data exfiltration, DoS-like scans, and intrusive vulnerability checks.

Step 1: Determine Execution Environment

Check the user's message for connection details. If not provided, ask the user.

Environment initialization:

• New task: mkdir -p /tmp/kali-pentest-state/<target>/ on the Agent's host. Read references/environment/state-files.md for naming rules and file formats.
• Continuing task: re-read existing state files to recover progress.
• Before starting any testing, update Kali tools: apt-get update && apt-get upgrade -y.

Capability Check

Use the environment that matches the task:

If the selected task requires unsupported capabilities, stop and explain the limitation instead of forcing the tool to run.

Before heavy work, run the readiness checks for the selected environment:

• Local mode: references/environment/local-mode.md
• Full Kali/server mode: references/environment/server-mode.md
• Docker mode: references/environment/docker-mode.md

Missing optional tools are not an environment failure. Install the required package after selecting the playbook, or choose an alternative from the category README.

SSH Patterns

ssh {CONNECT_CMD} "whoami && uname -a" # verify connection
ssh {CONNECT_CMD} "nohup {cmd} </dev/null > /tmp/{task}.log 2>&1 & echo \$!" # background task
scp {USER}@{HOST}:/tmp/{output_file} /tmp/ # retrieve results

Docker Mode

Use Docker only as a persistent Kali execution environment. Do not use one-shot temporary containers for assessments.

Read references/environment/docker-mode.md first. Read references/environment/docker-mode-persistent-container.md only when creating, starting, or installing tools into the container. Read references/environment/docker-mode-networking.md only for raw-socket behavior, Docker Desktop limitations, or reachability/routing problems.

Step 2: Plan

2.1 Scope Confirmation

1. Clarify target: IP, domain, CIDR range, application URL, wireless SSID, image file, or account set.
2. Confirm authorization: explicitly verify with the user. This is mandatory.
3. Identify test type: black-box, white-box, gray-box, authenticated, unauthenticated, internal, external, wireless, or forensic.
4. Ask about constraints: time limits, excluded hosts/ports, rate limits, lockout policy, maintenance windows, compliance requirements.
5. Set risk gates: agree which High/Critical actions require a second confirmation during execution.

2.2 Select Depth

Do not run Deep or intrusive checks by default unless the user explicitly requests it. Otherwise, start from Standard and escalate to Deep only when results justify it and the user consents to the upgrade.

Depth mapping from natural language:

• "full assessment", "comprehensive", "deep", "maximum coverage" → Deep
• "quick scan", "fast check", "connectivity test" → Quick
• No depth qualifier or ambiguous → Standard
• Mixed signals in a compound request → use the highest depth implied; if ambiguous, ask the user

2.3 Select Playbook

See the decision tree in references/playbooks/README.md to select the correct playbook.

If no playbook fits, follow the standard lifecycle: information gathering -> vulnerability analysis -> web or exploitation -> post-exploitation -> reporting.

Step 3: Execute

Reference Reading Order

Follow this 4-layer reading sequence:

1. references/playbooks/README.md — select the correct playbook from the decision tree (at task start, or when switching playbooks mid-task).
2. references/playbooks/<playbook>.md — follow the scenario workflow for the current phase.
3. references/<category>/README.md — use Golden Path and Decision Tree to select suitable tools for the current phase.
4. references/<category>/tools/<toolname>.md — read only for the tool you are about to run.

When a playbook hands off to another playbook, restart this sequence from layer 2 for the new playbook. Do not pre-read materials for phases you have not reached.

Tool Categories