Back to Details

kage

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Kage — pentest sandbox

Kage — 渗透测试沙箱

When to use this skill

何时使用该技能

  • kage <target>
    — black-box engagement
  • pentest <target>
    / 
    security audit on <target>
    — same as above
  • kage audit <local path>
    — white-box source audit only
  • kage greybox <target> <source-path>
    — black-box + source context
<target>
can be a domain, URL, wildcard (
*.example.com
), or a local source path. In 
greybox
mode, Turn 0 runs the bundled 
audit-context-building
 methodology on the source first, then feeds trust-boundary and auth-flow context into Turns 2–3.
  • 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阶段。

Container model

容器模型

Every tool runs inside a per-engagement Kali container via the 
$K
shim. Each working directory gets its own container (name derived from 
$PWD
), so two engagements run simultaneously without cross-contamination.
bash
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
Probes live at 
/skill/scripts/*.py
inside the container (read-only bind mount). Results go to 
/workspace/results/<target>/
(bind-mounted from your CWD).
Never run pentest tools directly on the host.
所有工具都通过
$K
垫片在每个测试任务专属的Kali容器内运行。每个工作目录对应一个独立容器（名称由
$PWD
生成），因此两个测试任务可以同时运行而不会互相干扰。
bash
SKILL_DIR="$HOME/.claude/skills/kage"
K="$SKILL_DIR/scripts/k"
"$K" <cmd>            # 在当前测试任务的容器内运行<cmd>
"$K" ls | reset | prune | nuke   # 管理子命令
探针位于容器内的
/skill/scripts/*.py
（只读绑定挂载）。结果会输出到
/workspace/results/<target>/
（从当前工作目录绑定挂载）。
切勿直接在主机上运行渗透测试工具。

Turn 0 — Setup

第0阶段 — 初始化

bash
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
bash
SKILL_DIR="$HOME/.claude/skills/kage"
K="$SKILL_DIR/scripts/k"
"$K" whoami            # 预热沙箱；显示Docker错误信息

TARGET="example.com"   # 从用户指令中获取；转换为路径友好格式

Host-side mkdir so dirs are owned by your UID (host Write tool needs this).

在主机端创建目录，确保目录归当前UID所有（主机写入工具需要此设置）。

mkdir -p "results/$TARGET"/{recon,vulns,testing,exploits,chains,verification,judging,reports}

Read `./creds.md` from the user's CWD if present. If absent: ask whether
to proceed black-box, or point at the template in
[`assets/creds.sample.md`](assets/creds.sample.md).
mkdir -p "results/$TARGET"/{recon,vulns,testing,exploits,chains,verification,judging,reports}

如果用户当前工作目录存在`./creds.md`则读取该文件。如果不存在：询问用户是否继续进行黑盒测试，或指向[`assets/creds.sample.md`](assets/creds.sample.md)中的模板。

Greybox pre-flight (only if mode is 
greybox
)

灰盒预检查（仅在
greybox
模式下执行）

Apply the 
audit-context-building
 methodology to 
<source-path>
. For dense modules, dispatch the 
function-analyzer
 sub-agent — multiple in parallel if warranted.
Output 
results/$TARGET/context.md
covering: trust boundaries, auth flow, data flow, high-value entry points, known-sensitive parameters. All Turn-2 testers and Turn-3a exploiter read 
context.md
alongside their usual inputs.
Write 
results/$TARGET/engagement.json
with 
{target, scope_type, started_at, rules_of_engagement}
.
对
<source-path>
应用
audit-context-building
方法论。对于复杂模块，调度
function-analyzer
子代理——如有必要可并行调度多个。
输出
results/$TARGET/context.md
，内容包括：信任边界、认证流、数据流、高价值入口点、已知敏感参数。所有第2阶段的测试器和第3a阶段的漏洞利用工具都会在常规输入之外读取
context.md
。
写入
results/$TARGET/engagement.json
，包含
{target, scope_type, started_at, rules_of_engagement}
信息。

Turn 1 — Recon (two phases)

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

Discovery runs fast (1–3 min) as a streaming pipe. Vuln scanning is long (5–15 min) and isolated in a sub-agent so nuclei's verbose output doesn't pollute the main context.
发现阶段运行速度快（1-3分钟），采用流式管道。漏洞扫描耗时较长（5-15分钟），并在子代理中独立执行，避免nuclei的冗长输出污染主上下文。

Phase 1 — Discovery

阶段1 — 发现

bash
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'
In parallel, dispatch 
port-scanner
: 
HOSTS_FILE=$R/recon/live.txt
, 
OUTDIR=$R/recon/ports/
.
If 
GITHUB_TOKEN
is set, also run 
scripts/gitmail.py
:
bash
"$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"
Wait for pipe + port-scanner (+ gitmail if run) before Phase 2.
bash
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
：
bash
"$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"
等待管道任务+端口扫描器（若运行则包括gitmail）完成后进入阶段2。

Phase 2 — Vuln scan

阶段2 — 漏洞扫描

Dispatch 
vuln-scanner
 with 
LIVE_HOSTS_FILE=$R/recon/live.txt
, 
OUTPUT=$R/vulns/nuclei.txt
.
Wait for vuln-scanner before Turn 2.
调度
vuln-scanner
，参数为
LIVE_HOSTS_FILE=$R/recon/live.txt
，
OUTPUT=$R/vulns/nuclei.txt
。
等待漏洞扫描完成后进入第2阶段。

Summary

总结

Write 
recon/summary.md
: subdomain count, live-host count, high-value ports, nuclei severity counts + top hits, auth endpoints, ID-bearing API paths, URL-accepting parameters.
Stop here if the user said 
recon-only
.
写入
recon/summary.md
：子域名数量、存活主机数量、高价值端口、nuclei漏洞严重程度统计+顶级发现、认证端点、带ID的API路径、接受URL的参数。
如果用户要求
recon-only
则在此处停止。

Turn 2 — Deep testing (parallel fan-out)

第2阶段 — 深度测试（并行分发）

Read 
recon/summary.md
. For every trigger that fires, spawn the matching tester sub-agents simultaneously — emit all dispatches in one message. Each tester issues its own 
$K
calls into the shared container (docker exec is concurrent) and writes to its own 
testing/<class>/
path.
Trigger in reconDispatch
login / SSO / OAuth / JWT endpoints
auth-tester
API endpoints with object IDs + 2 accounts
idor-tester
403s, admin panels, role-gated routes + ≥2 roles
access-control-tester
url=
/ 
redirect=
/ 
proxy=
/ 
fetch=
/ 
webhook=
params
ssrf-tester
parameterised URLs, search fields, forms, GraphQL vars
injection-tester
user-facing HTML (comments, profile, search)
client-side-tester
OpenAPI/Swagger URL, 
/graphql
, REST routes
api-tester
payment / coupon / redeem / invite / signup endpoints
logic-tester
crawler surface thin; hidden paths likely
content-discovery
JS bundles discovered in Turn 1
js-secret-scanner
any live web host
headers-tester
needs 2+ provisioned accounts (self-service signup)use 
agentmail
 to spin up disposable inboxes (requires 
AGENTMAIL_API_KEY
)
In 
greybox
mode, every tester also reads 
results/$TARGET/context.md
and targets source-known weak points over generic scans.
Wait for all testers to return. Aggregate their JSON into a candidate-finding inventory. Every probe emits a shared 
findings[]
/ 
summary{}
shape; all HTTP goes through 
scripts/tls.py
(or 
scripts/browser.py
for Cloudflare targets).
5-minute rule. If a lead doesn't prove itself within 5 minutes, move on. No theoretical bugs.
读取
recon/summary.md
。对于每个触发项，同时生成对应的测试子代理——在一条消息中发送所有调度指令。每个测试器会在共享容器中发起自己的
$K
调用（docker exec支持并发），并将结果写入各自的
testing/<class>/
路径。
侦察中的触发项调度的代理
登录/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分钟内无法验证，则放弃。不保留理论性漏洞。

Turn 3 — Exploit, verify, chain, judge

第3阶段 — 漏洞利用、验证、链化、评估

Sequential. Each step feeds the next.
按顺序执行。每个步骤的结果作为下一个步骤的输入。

3a. Exploit — filter BEFORE writing a PoC

3a. 漏洞利用 — 编写PoC前先过滤

Read 
references/judging.md
. For each candidate finding:
  • Drop outright if it matches an auto-drop pattern (missing headers without PoC, version banners, self-XSS, logout CSRF, TRACE/TRACK, TLS cipher issues, SPF/DKIM/DMARC, info-leak 500s, rate-limit absent without an abuse scenario). Do NOT build a PoC for these.
  • Drop if the impact statement contains "could potentially" or requires a condition unverifiable black-box. In 
    greybox
    mode, check 
    context.md
    first — source may confirm/refute.
  • Build a PoC only when attacker action produces an observable, reproducible server-side outcome with real impact (data access, code execution, auth bypass, cost amplification, state change, financial).
For each survivor, write a 
curl_cffi
PoC at 
results/$TARGET/exploits/<slug>.py
. Drop anything that doesn't reproduce first run.
阅读
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. Verify — parallel

3b. 验证 — 并行执行

For each PoC, dispatch 
verifier
 — emit all verifier Tasks in one message. Each gets its own 
OUTDIR=results/$TARGET/verification/F<NNN>/
, fresh auth, clean session, 3× reproducibility.
Aggregate into 
verification/verified_findings.json
.
对于每个PoC，调度
verifier
——在一条消息中发送所有验证任务。每个任务对应独立的
OUTDIR=results/$TARGET/verification/F<NNN>/
，使用全新的认证信息、干净的会话，进行3次可复现性验证。
将结果聚合到
verification/verified_findings.json
。

3c. Chain

3c. 链化

Dispatch 
chain-builder
 on verified findings. It maps the 7 canonical patterns in 
references/chains.md
 and looks for creative combinations.
针对已验证的发现调度
chain-builder
。它会映射
references/chains.md
中的7种典型升级模式，并寻找创造性的组合方式。

3d. Judge

3d. 评估

Dispatch 
judge
. It applies the 4-gate filter from 
references/judging.md
, scores confidence + CVSS, deduplicates, enforces the exclusion list.
Outputs: 
judging/approved_findings.json
(the only findings that reach the report), 
judgment.md
(audit trail), 
dropped_findings.md
.
调度
judge
。它会应用
references/judging.md
中的4门过滤机制，对置信度和CVSS评分，去重，执行排除列表。
输出：
judging/approved_findings.json
（唯一会进入报告的发现）、
judgment.md
（审计追踪）、
dropped_findings.md
。

Turn 4 — Audit report

第4阶段 — 审计报告

Dispatch 
report-writer
 with: 
TARGET
, 
ENGAGEMENT_JSON
, 
APPROVED_FINDINGS_JSON
, 
TEMPLATE=$SKILL_DIR/references/audit-report-template.md
, 
OUTPUT=results/$TARGET/audit-report.md
.
The agent fills 
{{placeholders}}
from engagement + approved findings. It does NOT re-filter — the judge already did that. Print a summary table to the user when done.
调度
report-writer
，参数为：
TARGET
、
ENGAGEMENT_JSON
、
APPROVED_FINDINGS_JSON
、
TEMPLATE=$SKILL_DIR/references/audit-report-template.md
、
OUTPUT=results/$TARGET/audit-report.md
。
该代理会根据测试任务信息和已批准的发现填充
{{placeholders}}
。它不会重新过滤——评估环节已完成此工作。完成后向用户打印汇总表格。

Failure modes to surface (don't swallow)

需要暴露的失败模式（请勿隐藏）

  • Docker not installed / not running → print the shim's error, stop.
  • Target unreachable / DNS fails.
  • Rate-limited or WAF-blocked → slow down, rotate fingerprint (
    tls.py --impersonate <name>
    ), or swap to 
    scripts/browser.py
    .
  • creds.md
    missing when the user asked for authenticated testing.
  • Docker未安装/未运行 → 打印垫片的错误信息，停止执行。
  • 目标无法访问/DNS解析失败。
  • 被速率限制或WAF拦截 → 降低速度，轮换指纹（
    tls.py --impersonate <name>
    ），或切换到
    scripts/browser.py
    。
  • 用户要求进行认证测试但缺少
    creds.md
    。

Reference docs (load on demand)

参考文档（按需加载）

  • references/methodology.md
     — per-attack-class triggers + invocation details
  • references/judging.md
     — 4-gate filter + severity rubric + exclusion list
  • references/chains.md
     — 7 named escalation patterns
  • references/report-formatting.md
     — platform conventions (HackerOne, Bugcrowd, Intigriti)
  • references/audit-report-template.md
     — Turn 4 template
  • references/tools.md
     — full inventory of tools installed in the sandbox
  • references/audit-context-building/SKILL.md
     — greybox methodology
  • references/agentmail/SKILL.md
     — disposable-inbox provisioning
  • assets/creds.sample.md
     — scope + credentials template
  • assets/wordlist-strategy.md
     — target-specific subdomain wordlists
  • references/methodology.md
     — 各攻击类别的触发条件 + 调用细节
  • references/judging.md
     — 4门过滤机制 + 严重程度标准 + 排除列表
  • 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
     — 针对目标的子域名字典策略