用途
dnr-hunt 是一个主动威胁狩猎技能，面向 Web 与应用日志。它的起点不是告警，而是一个问题：“这里面有没有不该存在的东西？”它把日志与源码作为输入，输出事件（incidents）。其核心主张是：方法本身与发现同等重要——先建立基线，再按“假设 → 查询 → 转向”推进，每一步都书面记录，任何可疑点都必须经源码确认并在本地实例上引爆 PoC 后才能被认定为真实。
主要能力
- 基线画像：在提出假设之前，先用约十几个低成本管道对访问日志建立基线，包括时间窗口、状态码直方图、来源 IP 排行、路由排行、User-Agent 清单、认证情况、各路由响应大小分布、错误日志与告警队列。
- 假设驱动的狩猎循环：强制维护书面台账，每行包含假设、查询、结果、判定与下一步转向。判定分为 supported / refuted / needs-pivot，被否定的假设同样保留在台账中。
- 种子扫描：第一轮运行服务器错误、逐条告警判定、高频 IP 异常、查询字符串中的注入语法、枚举模式、认证异常、大小异常、低流量时段活动等扫描，命中后沿实体双向追踪。
- 源码确认：对每个涉及路由的嫌疑点，在源码树中定位处理函数，追踪可疑输入从请求到汇聚点（查询、文件系统、认证决策），精确指出漏洞或防御机制。
- PoC 引爆：对源码确认的漏洞，在本地启动应用实例，用 curl 发送最小 PoC 请求，并记录命令与响应片段；同时可对判定为不可利用的路由发送反向 PoC 以证明其被拦截。
- 输出与路由：生成 INCIDENTS.json 与 INCIDENT_REPORT.md，区分已确认事件与已排除项，并给出后续可执行的下一步命令。
使用方式
调用命令：/dnr-hunt [target-or-logs-dir] [--repo path] [--fresh]
$1：dnr 目标目录（含 config.yaml 且 kind: dnr，例如 targets/dnrcanary），或纯日志文件目录。默认 targets/dnrcanary（若存在），否则为当前工作目录。--repo：产生日志的应用源码树。对 dnr 目标默认使用其 app/ 目录。没有源码时，任何发现都不能超过 suspected。--fresh：忽略运行目录下 .dnr-hunt-state/ 中的检查点，新建运行目录。
运行目录与检查点：每次运行的第一步是建立运行目录，命令为：
python3 .claude/skills/_lib/checkpoint.py rundir results/TARGET --state .dnr-hunt-state --scope "SCOPE"
若参数含 --fresh 则追加 --fresh。该命令打印一个路径，即本次狩猎可用的最新运行目录（{RUN}）。所有输出与状态都位于 {RUN} 下。阶段状态持久化到 {RUN}/.dnr-hunt-state/，中断后可恢复。检查点 I/O 一律通过 checkpoint.py 完成，不得直接用 Write 工具写 progress.json，也不得通过 heredoc 或 stdin 传递载荷。
阶段流程：
- Phase 0 — 定位并验证输入：解析 $1，读取 config 中的 logs_dir、app_command、seed_command、port；清点日志文件与告警队列（du -h、wc -l、head -2、tail -2），识别格式与 awk 字段位置；解析 --repo 并列出文件，但暂不读源码。
- Phase 1 — 语料画像（先于假设建立基线）：运行约十几个单行管道，记录时间窗口、状态码直方图、Top talkers、Top routes、User-Agent 清单、认证情况、各路由大小分布、错误日志与告警队列摘要，并记录每个观察所用的确切管道。
- Phase 2 — 狩猎循环（强制台账）：无假设不查询，无台账行不假设。第一轮运行全部种子扫描，命中后沿实体转向。停止条件为连续两轮未出现新实体。每轮后检查点 phase2.json。
- Phase 3 — 源码确认：对每个涉及路由的嫌疑点，在 --repo 中读取处理函数，追踪可疑输入到汇聚点，精确命名漏洞或防御机制，并检查同类缺陷的兄弟路由。
- Phase 4 — PoC 引爆（confirmed_exploited 的门槛）：按目标配置在本地启动应用（先 seed 再后台启动并打印 PID），轮询 /healthz 直到响应，用 curl 发送最小 PoC，记录命令与响应片段，必要时发送反向 PoC，最后用捕获的 PID 停止应用（kill <pid>，不得按端口或模式杀进程）。若应用无法在本环境运行，需明确说明，相关判定保持 suspected。
- Phase 5 — 输出：写入 {RUN}/INCIDENTS.json 与 {RUN}/INCIDENT_REPORT.md，然后标记完成并告知用户下一步命令。
硬性规则
- 仅凭日志证据永远不能确认漏洞。判定阶梯：confirmed_exploited 需要日志证据、源码中定位的缺陷（文件 + 函数）、以及本次会话中对本地实例引爆的 PoC 三者齐备；suspected 为有日志证据但无引爆的 PoC；attempted_not_vulnerable 为观察到攻击流量但源码显示防御且 PoC（若引爆）被弹回。
- 查询而非阅读。日志文件故意大于任何上下文窗口，绝不用 Read 或 cat 读取日志文件；用 wc/du/head/tail 画像，用 grep/rg/awk/sort/uniq 管道或 python3 查询。告警队列与错误日志通常较小，先查大小，约 200 行以下可整读。
- 只提出，不执行。不阻断、不禁用账户、不轮换凭据、不改配置，即使在演示应用上也不做。响应动作属于 /dnr-respond 的计划，以提案形式存在。
- 仅限本地。PoC 只对 127.0.0.1 上由你启动的应用实例发送，绝不向远程主机发送流量。
- 每个数字都是查询结果。行数、请求数、时间跨度、受影响客户数等均来自本次会话运行的管道，并在台账中引用，绝不凭记忆估计。
适用场景
- 自有日志：将 $1 指向任意访问/应用/认证日志目录。方法（基线 → 台账 → 源码 → 引爆）与格式无关，Nginx/Apache combined 日志、JSON-lines 应用日志、CDN/WAF 导出、认证日志均可，只需在 Phase 0 识别字段位置并调整 awk 管道。
- EDR / 端点遥测：将威胁事件导出为 CSV/JSON 后以同样方式狩猎，实体变为进程/主机/用户，源码确认变为配置或二进制审查，判定阶梯保持不变。
- 规模：当 grep 遍历过慢时，可加载到 DuckDB 并以 SQL 运行相同扫描。
- 检测工程后续：每个已确认事件都应在 /dnr-respond 的计划中形成检测规则提案。
限制
- 没有源码时，任何发现都不能超过 suspected。
- 若应用无法在当前环境运行，相关判定保持 suspected，报告需说明应在何处运行什么。
- 本技能不执行任何响应动作，仅提出提案。
- 关于收费、价格、平台支持范围等具体信息，资料中暂未提供。