Kali Pentest Skill

安全约束（首先阅读）

1. 授权是强制性前提：未经用户确认的书面授权，不得扫描或探测任何目标。
2. 范围具有约束力：仅测试用户已授权的主机、域名、端口、账号和技术手段。
3. 风险确认：High/Critical 级别操作需用户明确批准后方可执行。
4. 禁止操作：攻击未授权目标、对生产系统执行破坏性操作、未经明确要求修改/删除/加密目标文件、攻击关键基础设施。

高风险操作包括漏洞利用、凭据喷洒、暴力破解、NTLM 中继、钓鱼、无线攻击、持久化、数据外传、近似 DoS 的扫描和侵入式漏洞检查。

第一步：确定执行环境

检查用户消息中的连接信息。若未提供，向用户询问。

环境初始化：

• 全新任务：在 Agent 本地主机上执行 mkdir -p /tmp/kali-pentest-state/<target>/。命名规则和文件格式见 references/environment/state-files.md。
• 继续任务：重新读取已有状态文件以恢复进度。
• 开始测试前，更新 Kali 工具：apt-get update && apt-get upgrade -y。

能力检查

根据任务选择匹配的环境：

如果选定任务需要当前环境不支持的能力，停止并说明限制，不要强行运行工具。

执行重型任务前，按所选环境运行就绪检查：

• 本地模式：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 范围确认

1. 明确目标：IP、域名、CIDR 范围、应用 URL、无线 SSID、镜像文件或账号集合。
2. 确认授权：与用户明确确认。这是强制要求。
3. 测试类型：黑盒、白盒、灰盒、认证、未认证、内网、外网、无线或取证。
4. 了解约束条件：时间限制、排除的主机/端口、速率限制、锁定策略、维护窗口、合规要求。
5. 设置风险门槛：约定哪些 High/Critical 操作在执行中需要二次确认。

2.2 选择深度

仅在用户明确要求时才直接运行 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 层读取顺序：

1. references/playbooks/README.md — 新任务开始或中途切换 playbook 时，从决策树中选择正确的 playbook。
2. references/playbooks/<playbook>.md — 按当前阶段执行场景工作流。
3. references/<category>/README.md — 利用 Golden Path 和决策树为当前阶段选择合适的工具。
4. references/<category>/tools/<toolname>.md — 仅在即将运行某个工具时读取。

当 playbook 切换到另一个 playbook 时，从第 2 层重新启动此序列。不要预先阅读未到达阶段的材料。

工具分类

关键检查项使用多个互补工具。单个工具结果为空不能证明目标安全。

跨服务交互测试： 当同一主机上运行多个服务时，测试共享资源——共享文件系统（在一个服务上传的文件可通过另一个服务访问）、共享数据库（一个应用的凭据可访问另一个应用的数据）、反向代理关系（通过直接访问后端绕过 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/<na