| name | kali-pentest-zh |
| description | 通过 SSH 或 Docker 使用 Kali Linux CLI 工具执行授权渗透测试。
覆盖：信息收集、漏洞分析、嗅探与欺骗、Web/API 渗透、漏洞利用、密码攻击、无线、云原生安全、RFID/NFC、VoIP/ICS、逆向工程、取证分析、后渗透/C2、报告生成。
|
| user-invocable | true |
Kali Pentest Skill
安全约束（首先阅读）
- 授权是强制性前提：未经用户确认的书面授权，不得扫描或探测任何目标。
- 范围具有约束力：仅测试用户已授权的主机、域名、端口、账号和技术手段。
- 风险确认：High/Critical 级别操作需用户明确批准后方可执行。
- 禁止操作：攻击未授权目标、对生产系统执行破坏性操作、未经明确要求修改/删除/加密目标文件、攻击关键基础设施。
高风险操作包括漏洞利用、凭据喷洒、暴力破解、NTLM 中继、钓鱼、无线攻击、持久化、数据外传、近似 DoS 的扫描和侵入式漏洞检查。
第一步：确定执行环境
检查用户消息中的连接信息。若未提供，向用户询问。
| 可用信息 | 模式 | 命令模式 |
|---|
| 当前系统为 Kali | 本地（直接执行） | {command}（无需包装） |
| SSH 凭据 | SSH（远程首选） | ssh {CONNECT_CMD} "{command}" |
| 已运行的容器 | Docker exec | docker exec {CONTAINER} {command} |
| 仅有 Docker | Docker 持久化容器 | 创建或启动 kali-pentest，再运行 docker exec kali-pentest {command} |
环境初始化：
- 全新任务：在 Agent 本地主机上执行
mkdir -p /tmp/kali-pentest-state/<target>/。命名规则和文件格式见 references/environment/state-files.md。
- 继续任务：重新读取已有状态文件以恢复进度。
- 开始测试前，更新 Kali 工具：
apt-get update && apt-get upgrade -y。
能力检查
根据任务选择匹配的环境：
| 需求 | 首选环境 | 规则 |
|---|
| 完整评估、内网 LAN、原始套接字、服务守护进程、数据库支撑工具 | 通过 SSH 连接完整 Kali VM/server | 有 SSH 时优先使用 |
| CLI 侦察、Web 测试、基础扫描、报告生成 | 持久化 Docker 容器 | 工具和网络连通性验证后可用 |
| 无线监听模式、USB 适配器、硬件相关测试 | 通过 SSH 连接物理机/虚拟机 Kali | 不使用 Docker |
| GPU 密码破解 | 具备 GPU 访问能力的完整 Kali | 规划 GPU 任务前验证 hashcat -I |
| GVM/OpenVAS、Neo4j/BloodHound、ZAP daemon、Metasploit 数据库 | 首选完整 Kali | Docker 仅在服务栈已配置时可用 |
如果选定任务需要当前环境不支持的能力，停止并说明限制，不要强行运行工具。
执行重型任务前，按所选环境运行就绪检查：
- 本地模式：
references/environment/local-mode.md
- 完整 Kali/服务器模式：
references/environment/server-mode.md
- Docker 模式：
references/environment/docker-mode.md
缺少可选工具不代表环境失败。选择 playbook 后安装所需软件包，或从分类 README 中选择替代工具。
SSH 模式
ssh {CONNECT_CMD} "whoami && uname -a"
ssh {CONNECT_CMD} "nohup {cmd} </dev/null > /tmp/{task}.log 2>&1 & echo \$!"
scp {USER}@{HOST}:/tmp/{output_file} /tmp/
Docker 模式
仅将 Docker 作为持久化 Kali 执行环境使用。不要用一次性临时容器执行评估。
先读取 references/environment/docker-mode.md。仅在创建、启动容器或向容器安装工具时读取 references/environment/docker-mode-persistent-container.md；仅在处理原始套接字行为、Docker Desktop 限制或可达性/路由问题时读取 references/environment/docker-mode-networking.md。
第二步：规划
2.1 范围确认
- 明确目标：IP、域名、CIDR 范围、应用 URL、无线 SSID、镜像文件或账号集合。
- 确认授权：与用户明确确认。这是强制要求。
- 测试类型：黑盒、白盒、灰盒、认证、未认证、内网、外网、无线或取证。
- 了解约束条件：时间限制、排除的主机/端口、速率限制、锁定策略、维护窗口、合规要求。
- 设置风险门槛：约定哪些 High/Critical 操作在执行中需要二次确认。
2.2 选择深度
| 深度 | 适用场景 | 覆盖范围 |
|---|
| Quick | 用户需要快速扫描或连通性检查 | 低噪声发现、Top 端口、基础 Web 指纹，不做侵入式检查 |
| Standard | 授权评估的默认选择 | 服务枚举、漏洞扫描、Web 爬取、常见协议检查，采集可纳入报告的证据 |
| Deep | 用户明确要求最大覆盖并接受时间/风险 | 全端口、选定 UDP、认证检查、更大字典、GVM/OpenVAS、更深入的爆破或利用流程 |
仅在用户明确要求时才直接运行 Deep 或侵入式检查。否则应该默认从 Standard 开始，在结果证明有必要升级深度时，征得用户同意后升级为 Deep。
自然语言到深度级别的映射：
- "全面评估"、"深度渗透"、"最大覆盖"、"full assessment"、"comprehensive"、"deep" → Deep
- "快速扫描"、"连通性检查"、"quick scan"、"fast check" → Quick
- 未指定深度或含义模糊 → Standard
- 复合请求中包含混合深度信号 → 使用隐含的最高深度；如有歧义，询问用户
2.3 选择 Playbook
查看 references/playbooks/README.md 中的决策树以选择正确的 playbook。
如果没有匹配的 playbook，按标准生命周期推进：信息收集 -> 漏洞分析 -> Web 或漏洞利用 -> 后渗透 -> 报告。
第三步：执行
参考文档读取顺序
遵循以下 4 层读取顺序：
references/playbooks/README.md — 新任务开始或中途切换 playbook 时，从决策树中选择正确的 playbook。references/playbooks/<playbook>.md — 按当前阶段执行场景工作流。references/<category>/README.md — 利用 Golden Path 和决策树为当前阶段选择合适的工具。references/<category>/tools/<toolname>.md — 仅在即将运行某个工具时读取。
当 playbook 切换到另一个 playbook 时，从第 2 层重新启动此序列。不要预先阅读未到达阶段的材料。
工具分类
| 阶段 | 参考文档 | 适用场景 |
|---|
| 信息收集 | references/information-gathering/ | 需要发现主机、端口、子域名或 OSINT |
| 漏洞分析 | references/vulnerability/ | 需要枚举服务或查找漏洞 |
| 嗅探与欺骗 | references/sniffing-spoofing/ | 需要 ARP 欺骗、MITM、凭据嗅探、DNS 欺骗或数据包构造 |
| Web 渗透 | references/web/ | 目标是 Web 应用或 API（GraphQL、OpenAPI/REST、gRPC、WebSocket） |
| 漏洞利用 | references/exploitation/ | 漏洞已确认且已授权利用 |
| 密码攻击 | references/password/ | 有哈希待破解，或有凭据/服务待测试 |
| 无线安全 | references/wireless/ | 目标是无线网络 |
| 云原生 | references/cloud-native/ | 目标是云账户、Kubernetes、容器、镜像仓库或 Docker 主机 |
| RFID/NFC | references/rfid-nfc/ | 目标是 RFID/NFC、Proxmark3、PC/SC、智能卡或物理凭据 |
| VoIP/ICS | references/voip-ics/ | 目标是 VoIP、SIP/IAX、ICS、OT、PLCs 或 Modbus |
| 逆向工程 | references/reverse-engineering/ | 需要二进制分析、反汇编、固件提取或移动应用反编译 |
| 取证分析 | references/forensics/ | 分析磁盘镜像、内存转储、流量包或日志 |
| 后渗透 | references/post-exploitation/ | 已获初始访问，需提权、跳板转发、分析 AD 或检查二进制文件以辅助提权 |
| 报告 | references/reporting/ | 测试完成，需生成报告 |
关键检查项使用多个互补工具。单个工具结果为空不能证明目标安全。
跨服务交互测试： 当同一主机上运行多个服务时，测试共享资源——共享文件系统（在一个服务上传的文件可通过另一个服务访问）、共享数据库（一个应用的凭据可访问另一个应用的数据）、反向代理关系（通过直接访问后端绕过 WAF）以及不同端口服务间的会话/凭据共享。
执行规范
- 自动化工具优先：在每个阶段，先运行 playbook 和分类 README 推荐的自动化扫描器，再进行手工测试。不要静默地用手工脚本替代自动化工具——手工测试无法匹配专用扫描器的覆盖率。
- 工具优先于脚本：当 Kali 工具可以完成任务时，使用工具——必要时通过签名代理或包装器——而非编写等效的自定义代码。自定义脚本仅用于现有工具无法覆盖的目标专属逻辑。将标准工具适配到自定义协议的代理或包装器是工作流的一部分，不是跳过工具的理由。
- 新攻击面：发现新子域名、主机或服务后，在进入手工测试前对每个可达目标运行相关自动化扫描。
- 检查可用性：
which {tool} || apt-get install -y {tool}。如果工具不在 apt 仓库中（如 katana、httpx、naabu），查阅工具参考文件获取 go install 或 pip install 等替代安装方式。
- 非交互模式：使用
-y、--batch、--no-interaction 或等效参数防止挂起。
- 长时间任务：输出重定向到任务专属日志，例如
nohup {cmd} </dev/null > /tmp/{task}.log 2>&1 & echo \$!。
- 不要复用日志：每个长时间运行工具使用唯一日志文件名。
- 取回文件：SSH 使用
scp，Docker 使用 docker cp。
- 记录命令：保留命令行、开始/结束时间、目标、输出文件和重要错误，供报告使用。
- 确认扫描结果：高速扫描可能因丢包而遗漏端口。使用低速、高重试扫描对发现的端口进行确认，再继续后续步骤。
- 不得跳过未识别服务：对
unknown、tcpwrapped 或带 ? 后缀的服务进行探测，方可标注为未能识别。
- 逐服务系统化测试：识别出服务类型只是测试的起点，不是终点。对每个服务，完成版本识别、CVE 评估、信息泄露检查、访问与认证测试、协议探测、凭据测试、TLS 配置检查和服务配置审计。明确记录阴性结果。
产物与状态管理
状态文件保存在 Agent 本地主机 /tmp/kali-pentest-state/<target>/。工具原始输出保留在远程 Kali 环境（/tmp/）。
每个全新任务开始前，应该先创建临时目录，用于保存状态文件：
mkdir -p /tmp/kali-pentest-state/<target>/
此命令直接在 Agent 宿主机上运行——不在 docker exec 或 ssh 内执行。
每次工具执行后，将关键发现提取到宿主机状态目录：
- Docker 模式：
docker cp kali-pentest:/tmp/<file> /tmp/kali-pentest-state/<target>/
- SSH 模式：
scp user@host:/tmp/<file> /tmp/kali-pentest-state/<target>/
规则：
- 不要依赖对话记忆——状态文件是唯一能在上下文压缩后存活的数据。
- 每个新阶段开始前，重新读取状态文件以确认当前进度。
- 切换 playbook 时，将返回点写入
/tmp/kali-pentest-state/<target>/ 目录下的 todo.txt。返回原 playbook 时，读取 todo.txt 以便在正确阶段恢复并处理延迟项。
- 不要仅在远程环境内保存状态文件——它们必须存在于 Agent 宿主机上以便恢复。
文件格式和命名规则见 references/environment/state-files.md。
输出管理
大型工具输出（全端口扫描、包含数千模板的漏洞扫描器）可能超出 Agent 的处理能力。将输出重定向到文件，提取相关发现，不要读取完整输出。具体输出参数和提取命令见各工具文档。
错误处理
- 工具未找到且安装失败：尝试替代安装方式，或切换为分类 README 中的替代工具。没有可行替代方案时再报告用户。
- 参数或语法错误：先运行
{tool} --help 或 {tool} -h 确认参数和格式，再重试。
- 命令超时或挂起：终止进程，缩小范围，降低并发，然后重试。
- 输出为空：验证可达性（
ping、curl、nc 或协议专项检查），确认工具支持目标类型。
- SSH 断连：重连并用
ps aux | grep {tool} 检查后台任务是否仍在运行。
- 警告信息：区分信息性警告和扫描阻断问题。例如模板警告可以记录，目标不可达则需要连通性排障。
第四步：分析与迭代
- 解析输出并提取关键发现：开放端口、版本、漏洞、凭据、配置错误、可达路径。
- 将发现链式推进到下一步：开放 445 -> SMB 枚举；Web 登录页 -> 认证测试；SQL 注入 -> sqlmap；AD 信号 -> AD playbook。
- 跨主机凭据测试： 在一台主机上发现凭据时（配置文件、数据库转储、路径遍历），不仅测试当前主机的服务，还要测试所有授权范围内的主机和服务。跨主机凭据复用是常见的横向移动向量。
- 重要发现先用第二个工具或手工协议检查交叉验证，再作为已确认发现报告。每个已确认发现必须包含可重现的完整命令及其实际输出作为证据。
- 发现 Critical/High 漏洞时停止： 立即通知用户，等待明确确认后再进行进一步利用或升级。
- 利用失败时，带着更窄的假设回到枚举阶段，不要重复运行同一工具。
- 发现新主机、凭据、域或跳板路径时，在授权范围内重新启动相关 playbook。
- 在规划下一步行动前，用每次迭代的新发现更新
/tmp/kali-pentest-state/<target>/ 中的状态文件。
- 关闭服务前自检： 在将某个服务标记为完成之前，验证执行规范中逐服务系统化测试要求的每一项均已完成，或已明确记录为"不适用"。某服务"看起来安全"并不等于已经完成测试——那只是完成了识别。
第五步：报告
逐步执行 references/playbooks/reporting-workflow.md——这是一个 8 步工作流，不是单一的"写报告"动作。使用 references/reporting/tools/report-template.md 作为文档结构——不要自行设计结构。
开始报告前，执行当前 playbook 的“停止条件”检查清单。未满足的条目需返回相关阶段——不得在已知覆盖缺口未记录的情况下进入报告阶段。
包括：
- 范围、授权说明、日期、环境和限制。
- 执行过的命令和主要工具版本。
- 已确认发现：严重等级、证据、影响、复现步骤和修复建议。每个发现必须包含完整的验证/重现过程——执行的确切命令及其实际输出——使读者可以独立重现结果。
- 重要的阴性结果，例如不可达主机或已测试但无发现的服务。
- 生成的产物及保存位置。
报告工具选择见 references/reporting/README.md。
报告文件生成
报告可能超过 20KB。不要尝试用单次工具调用写入完整报告——拆分为多段（每段 ≤8KB），第一段用 cat >，后续用 cat >>。报告写入 /tmp/kali-pentest-state/<target>/。报告是宿主机侧的产物，不要在远程 Kali 环境内生成。
参考布局
references/environment/ 定义服务器和 Docker 执行环境就绪要求。references/playbooks/ 定义场景流程和决策点。references/<category>/README.md 用于选择某一分类下适合的工具。references/<category>/tools/<name>.md 提供具体命令参数和示例。
