kali-pentest

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.

| Available | Mode | Command pattern | |-----------|------|-----------------| | Kali is the local system | Local (direct) | {command} (no wrapper needed) | | SSH credentials | SSH (preferred for remote) | ssh {CONNECT_CMD} "{command}" | | Running container | Docker exec | docker exec {CONTAINER} {command} | | Docker only | Docker persistent container | Create or start kali-pentest, then run docker exec kali-pentest {command} |

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:

| Requirement | Preferred environment | Rule | |-------------|----------------------|------| | Full assessment, internal LAN, raw sockets, service daemons, database-backed tools | SSH to a full Kali VM/server | Prefer SSH when available | | CLI-only reconnaissance, web testing, basic scanning, reporting | Persistent Docker container | Acceptable if tools and network reachability are verified | | Wireless monitor mode, USB adapters, hardware-dependent tests | Physical/VM Kali over SSH | Do not use Docker | | GPU password cracking | Full Kali with GPU access | Verify hashcat -I before planning GPU work | | GVM/OpenVAS, Neo4j/BloodHound, ZAP daemon, Metasploit database | Full Kali preferred | Docker is acceptable only if the service stack is already configured |

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

| Depth | Use when | Coverage | |-------|----------|----------| | Quick | User needs a fast scan or connectivity check | Low-noise discovery, top ports, basic web fingerprinting, no intrusive checks | | Standard | Default for authorized assessments | Service enumeration, vulnerability scanning, web crawling, common protocol checks, reportable evidence | | Deep | User explicitly wants maximum coverage and accepts time/risk | Full ports, selected UDP, authenticated checks, larger wordlists, GVM/OpenVAS, deeper brute-force or exploitation workflows |

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

| Phase | Reference | Start here when... | |-------|-----------|---------------------| | Information Gathering | references/information-gathering/ | Need to discover hosts, ports, subdomains, or OSINT | | Vulnerability Analysis | references/vulnerability/ | Need to enumerate services or find vulnerabilities | | Sniffing & Spoofing | references/sniffing-spoofing/ | Need ARP spoofing, MITM, credential sniffing, DNS spoofing, or packet crafting | | Web Testing | references/web/ | Target is a web application, API (GraphQL, OpenAPI/REST, gRPC, WebSocket) | | Exploitation | references/exploitation/ | Vulnerabilities are confirmed and exploitation is authorized | | Password Attacks | references/password/ | Have hashes to crack or credentials/services to test | | Wireless | references/wireless/ | Target is a wireless network | | Cloud-Native | references/cloud-native/ | Target is cloud accounts, Kubernetes, containers, registries, or Docker hosts | | RFID/NFC | references/rfid-nfc/ | Target is RFID/NFC, Proxmark3, PC/SC, smart cards, or physical credentials | | VoIP-ICS | references/voip-ics/ | Target is VoIP, SIP/IAX, ICS, OT, PLCs, or Modbus | | Reverse Engineering | references/reverse-engineering/ | Need binary analysis, disassembly, firmware extraction, or mobile app decompilation | | Forensics | references/forensics/ | Analyzing disk images, memory dumps, traffic captures, or logs | | Post-Ex