kage

Kage — 渗透测试沙箱

何时使用此技能

• kage <target> — 黑盒测试
• pentest <target> / security audit on <target> — 同上
• kage audit <local path> — 仅白盒源码审计
• kage greybox <target> <source-path> — 黑盒测试 + 源码上下文

<target> 可以是域名、URL、通配符（*.example.com）或本地源码 路径。在 greybox 模式下，第 0 轮会先对源码运行捆绑的 audit-context-building 方法，然后在第 2–3 轮中提供信任边界和认证流程 上下文。

容器模型

每个工具都通过 $K 垫片在独立的 Kali 容器中运行。每个工作目录都有 自己的容器（名称根据 $PWD 生成），因此可以同时运行两个测试任务， 互不干扰。

SKILL_DIR="$HOME/.claude/skills/kage"
K="$SKILL_DIR/scripts/k"
"$K" <cmd>            # runs <cmd> inside this engagement's container
"$K" ls | reset | prune | nuke   # management subcommands

探测脚本位于容器内的 /skill/scripts/*.py（只读绑定挂载）。 结果写入 /workspace/results/<target>/（从当前工作目录绑定挂载）。

切勿直接在主机上运行渗透测试工具。

---

第 0 轮 — 设置

SKILL_DIR="$HOME/.claude/skills/kage"
K="$SKILL_DIR/scripts/k"
"$K" whoami            # warms the sandbox; surfaces docker errors

TARGET="example.com"   # derive from user prompt; slugify for paths

# Host-side mkdir so dirs are owned by your UID (host Write tool needs this).
mkdir -p "results/$TARGET"/{recon,vulns,testing,exploits,chains,verification,judging,reports}

如果用户当前工作目录中存在 ./creds.md，请读取。如果不存在：询问 是否继续进行黑盒测试，或指向模板 assets/creds.sample.md。

灰盒预检（仅当模式为 greybox 时）

将 audit-context-building 方法应用于 <source-path>。对于复杂模块，分派 function-analyzer 子 Agent；如有必要，可并行分派多个。

输出 results/$TARGET/context.md，内容涵盖：信任边界、认证 流程、数据流、高价值入口点、已知敏感参数。所有第 2 轮测试人员和第 3a 轮利用者都要将 context.md 与 常规输入一并读取。

写入 results/$TARGET/engagement.json，内容为 {target, scope_type, started_at, rules_of_engagement}。

---

第 1 轮 — 侦察（两个阶段）

发现阶段以流式管道快速运行（1–3 分钟）。漏洞扫描耗时较长（5–15 分钟）， 并在子 Agent 中独立运行，以免 nuclei 的冗长输出 污染主上下文。

阶段 1 — 发现

R="results/$TARGET"
"$K" bash -c '
  set -e
  cd /workspace
  R="results/'"$TARGET"'"
  (subfinder -d "'"$TARGET"'" -silent \
     | tee "$R/recon/subs.txt" \
     | httpx -silent -title -tech-detect -status-code \
     | tee "$R/recon/live.txt") &
  (gau --subs "'"$TARGET"'" > "$R/recon/wayback.txt") &
  (until [ -s "$R/recon/live.txt" ]; do sleep 1; done
   katana -u "$R/recon/live.txt" -d 3 -jc -silent -o "$R/recon/crawl.txt") &
  (python3 /skill/scripts/dorks.py -d "'"$TARGET"'" --output "$R/recon/dorks.json") &
  wait'

同时分派 port-scanner： HOSTS_FILE=$R/recon/live.txt，OUTDIR=$R/recon/ports/。

如果已设置 GITHUB_TOKEN，也运行 scripts/gitmail.py：

"$K" bash -c "GITHUB_TOKEN=\"$GH_TOKEN\" python3 /skill/scripts/gitmail.py \
   -O <guessed-org> -r -s --verified-only \
   -o /workspace/$R/recon/github.json"

等待管道、port-scanner（以及运行时的 gitmail）完成后再进入阶段 2。

阶段 2 — 漏洞扫描

分派 vuln-scanner，并设置 LIVE_HOSTS_FILE=$R/recon/live.txt、OUTPUT=$R/vulns/nuclei.txt。

等待 vuln-scanner 完成后再进入第 2 轮。

摘要

写入 recon/summary.md：子域名数量、存活主机数量、高价值 端口、nuclei 严重性计数 + 重点结果、认证端点、包含 ID 的 API 路径、接受 URL 的参数。

如果用户说了 recon-only，则到此为止。

---

第 2 轮 — 深入测试（并行扇出）

读取 recon/summary.md。对于每个触发条件，同时启动相应的测试子 Agent——在一条消息中发出所有调度指令。每个测试器都会向共享容器发起自己的 $K 调用（docker exec 可并发执行），并写入自己的 testing/<class>/ 路径。

recon 中的触发条件	调度
login / SSO / OAuth / JWT 端点	auth-tester
带对象 ID 的 API 端点 + 2 个账户	idor-tester
403、管理面板、受角色限制的路由 + ≥2 种角色	access-control-tester
url= / redirect= / proxy= / fetch= / webhook= 参数	ssrf-tester
参数化 URL、搜索字段、表单、GraphQL 变量	injection-tester
面向用户的 HTML（评论、个人资料、搜索）	client-side-tester
OpenAPI/Swagger URL、/graphql、REST 路由	api-tester
支付 / 优惠券 / 兑换 / 邀请 / 注册端点	logic-tester
爬虫探测范围较小；可能存在隐藏路径	content-discovery
第 1 轮发现的 JS 包	js-secret-scanner
任何可访问的 Web 主机	headers-tester
需要 2 个或更多已创建账户（自助注册）	使用 agentmail 创建临时邮箱（需要 AGENTMAIL_API_KEY）

在 greybox 模式下，每个测试器还会读取 results/$TARGET/context.md，针对源码已知的薄弱点进行测试，而不是泛化扫描。

等待所有测试器返回。 将它们的 JSON 汇总为候选发现清单。每个探测都会生成统一的 findings[] / summary{} 结构；所有 HTTP 请求都通过 scripts/tls.py（Cloudflare 目标则使用 scripts/browser.py）。

5 分钟规则。 如果某个线索在 5 分钟内无法证实，就继续处理下一个。不要提交理论上的漏洞。

---

第 3 轮 — 利用、验证、串联、判定

按顺序执行。每一步的结果都会作为下一步的输入。

3a. 利用 — 编写 PoC 前先筛选

阅读 references/judging.md。对每个候选发现：

• 直接剔除符合自动剔除模式的项目（缺少响应头且没有 PoC、版本横幅、自我型 XSS、注销 CSRF、TRACE/TRACK、TLS 密码套件问题、SPF/DKIM/DMARC、信息泄露型 500 错误、缺少速率限制但没有滥用场景）。不要为这些项目编写 PoC。
• 如果影响描述中包含“可能会”或需要黑盒测试无法验证的条件，则剔除。在 greybox 模式下，先检查 context.md——源码可能会证实或否定这一点。
• 只有在攻击者操作能够产生可观察、可复现且具有实际影响的服务器端结果时，才编写 PoC（数据访问、代码执行、绕过身份验证、成本放大、状态变更、财务影响）。

对于每个保留项，在 results/$TARGET/exploits/<slug>.py 编写一个 curl_cffi PoC。无法在首次运行时复现的项目一律剔除。

3b. 验证 — 并行执行

针对每个 PoC，调度 verifier——在一条消息中发出所有 verifier 任务。每个验证器都有自己的 OUTDIR=results/$TARGET/verification/F<NNN>/、全新的身份验证信息、干净的会话，并进行 3 次可复现性测试。

将结果汇总到 verification/verified_findings.json。

3c. 串联

针对已验证的发现调度 chain-builder。它会映射 references/chains.md 中的 7 种规范模式，并寻找有创意的组合。

3d. 判定

调度 judge。它会应用 references/judging.md 中的 4 道关卡筛选，评定置信度和 CVSS，去重，并执行排除清单。

输出：judging/approved_findings.json（唯一会纳入报告的发现）、judgment.md（审计记录）、dropped_findings.md。

---

第 4 轮——审计报告

调度 report-writer，并提供： TARGET、ENGAGEMENT_JSON、APPROVED_FINDINGS_JSON、 TEMPLATE=$SKILL_DIR/references/audit-report-template.md、 OUTPUT=results/$TARGET/audit-report.md。

该 Agent 根据 engagement 和已批准的发现填写 {{placeholders}}。 它不会重新筛选——评审者已完成筛选。完成后，向用户打印汇总 表。

---

需要明确呈现的故障模式（不要忽略）

• 未安装 Docker / Docker 未运行 → 打印 shim 的错误，然后停止。
• 目标无法访问 / DNS 解析失败。
• 被限流或被 WAF 拦截 → 放慢速度、轮换指纹 （tls.py --impersonate <name>），或改用 scripts/browser.py。
• 用户要求进行身份验证测试，但缺少 creds.md。

参考文档（按需加载）

• references/methodology.md — 各攻击类别的触发条件 + 调用详情
• references/judging.md — 四道筛选关卡 + 严重性分级标准 + 排除列表
• references/chains.md — 7 种命名的升级模式
• references/report-formatting.md — 平台规范（HackerOne、Bugcrowd、Intigriti）
• references/audit-report-template.md — 第 4 轮模板
• references/tools.md — 沙盒中安装的工具完整清单
• references/audit-context-building/SKILL.md — 灰盒方法论
• references/agentmail/SKILL.md — 一次性收件箱配置
• assets/creds.sample.md — 范围 + 凭据模板
• assets/wordlist-strategy.md — 针对目标的子域名单词列表