dnr-respond

# dnr-respond Lead-in-hand incident response: take one concrete starting point and answer the four questions an incident commander needs, in order — **what happened, did it succeed, how far did it go, and what do we do about it.** The output is a verdict, a quantified blast radius, a root cause proven in source, and a response plan that is *proposed, never executed*. Invoke with `/dnr-respond <lead> [--logs dir] [--repo path] [--fresh]`. **The lead (`$1`) can be:** - an incident id from the hunt's `INCIDENTS.json` (e.g. `INC-2`) — the `/dnr-hunt` handoff - an alert pasted from an alert queue (JSON line or prose) - an IOC: an IP, an account name, a route, a session identifier - free text ("a customer says their address was quoted in a phishing email") **Other arguments:** - `--logs` = logs directory or dnr target directory (same resolution as `/dnr-hunt`; defaults to `targets/dnrcanary` if it exists, else cwd). - `--repo` = application source (defaults to the target's `app/`). - `--fresh` = ignore any checkpoint in the run dir's `.dnr-respond-state/` and mint a new run dir. ## Hard rules (shared with /dnr-hunt — the track's contract) 1. **Log evidence alone never confirms a vulnerability.** `confirmed_exploited` requires log evidence + the flaw in source + a PoC fired locally this session. Otherwise the ceiling is `suspected`. 2. **Query, don't read.** Never `Read` or `cat` a log file; `wc`/`head`/ `tail` to profile, `grep`/`awk`/`sort`/`uniq`/`python3` to interrogate. Small files (alert queues, error logs under ~200 lines) may be read whole. 3. **Propose, never execute.** No blocking, disabling, rotating, or config changes — in any environment, including the demo app. The plan names actions; humans execute them. 4. **Local only.** PoCs fire at `127.0.0.1` against an instance you started. Never touch a remote host. 5. **Every number is a query result.** "How many records" and "how many customers" get answered by pipelines run this session, never estimated. ## Run directory and checkpointing **First action — establish the run directory**, the same way `/dnr-hunt` does, but as a *consumer*. Let `TARGET` be the basename of the resolved `--logs`/target path (default `targets/dnrcanary`) and `SCOPE` that path. - **Lead is `INC-n`** (the `/dnr-hunt` handoff, or a second lead from a hunt you already started responding to): work the response into the investigation that incident lives in. `{RUN}` is the newest `results/TARGET/<timestamp>/` directory that contains an `INCIDENTS.json` — find it with Bash, e.g. `ls -1d results/TARGET/*/ | sort -r | while read d; do [ -f "$d/INCIDENTS.json" ] && echo "$d" && break; done`. Do **not** call `rundir` for an `INC-n` lead — `rundir` mints a fresh empty dir once a prior `/dnr-respond` in that dir has completed, which would strand the incident's `INCIDENTS.json` in the old dir. Only if no run dir holds an `INCIDENTS.json` (you were handed `INC-n` but never ran the hunt) fall through to the `rundir` line below. - **Any other lead** (alert, IOC, free text): Bash `python3 .claude/skills/_lib/checkpoint.py rundir results/TARGET --state .dnr-respond-state --scope "SCOPE"` (append `--fresh` if it's in `$ARGUMENTS`). This adopts the newest run dir for the target if one exists, else mints a fresh `results/TARGET/<timestamp>/`. That path is `{RUN}`; substitute the literal path everywhere below, and double-quote it (and `SCOPE`) in Bash. Checkpoint mechanics are identical to `/dnr-hunt`, state dir `{RUN}/.dnr-respond-state/`, phases 0–4. When `{RUN}` already holds a **completed** `.dnr-respond-state` from an earlier lead, `load` reports `complete` and the rules below reset it cleanly — a second lead enriches the same `INCIDENTS.json` and writes its own `RESPONSE-<lead>.md`. On start: `python3 .claude/skills/_lib/checkpoint.py load {RUN}/.dnr-respond-state` — absent/complete/`--fresh` → `reset` and start at Phase 0; running with `phase_done == N` → read `phase0.json`…`phaseN.json`, resume at N+1. After each phase: Write payload to `{RUN}/.dnr-respond-state/_chunk.tmp`, then `checkpoint.py save {RUN}/.dnr-respond-state <N> <name> --from {RUN}/.dnr-respond-state/_chunk.tmp`. Never write `progress.json` directly; never pass payload via heredoc/stdin. After outputs: `checkpoint.py done {RUN}/.dnr-respond-state 4`. ## Phase 0 — Parse the lead, locate inputs 1. Resolve `--logs` (dnr target config or bare directory) and inventory log files (`du`, `wc -l`, `head -2` each — identify formats and field positions). The corpus is expected to exist already — the target README covers generating it. 2. Parse the lead into starting entities: - `INC-n` → read that entry from `{RUN}/INCIDENTS.json` (the run dir adopted above); its IPs, accounts, routes, and timeline rows are the seed set. - alert line → source IP, rule, path, timestamp. - IOC → the entity itself. - free text → extract the observables (who reported, what data, when); the seed set may start as just a route or a table name. 3. State the working question in one sentence (e.g. "did 203.0.113.66's activity against /login succeed, and if not, what did?"). Everything in Phase 1 serves that question. Checkpoint `phase0.json`: `{"lead": ..., "lead_type": ..., "entities": {"ips": [], "accounts": [], "routes": [], "windows": []}, "question": ..., "logs_dir": ..., "repo": ..., "files": [...]}` ## Phase 1 — Scope: pull everything the entities touched For each seed entity, extract its complete activity, then expand one ring: - **Per IP:** every request — time-ordered, with route, status, size, UA, and authenticated user. Summarize phases of behavior, don't paste hundreds of lines. - **Per account:** every login (from which IPs), every authenticated request. Compare against that account's historical pattern in the same corpus — new IP, new UA, new volume, new hours are all signal. (A new IP *alone* is baseline noise — users roam; combine it with volume, cadence, or what the session did next before treating it as a lead.) - **Per route:** who else hit it the same way in the window? One attacker found via an alert may not be the only one. - **Ring expansion (once):** entities discovered above join the set — the account an IP logged into, the second IP that touched the same account, the route a session pivoted to. Expand once, deliberately; /dnr-hunt's open-ended loop is the tool when scope keeps growing. - **Correlate the error log and alert queue** rows for all entities into one timeline. Checkpoint `phase1.json`: `{"activity": [{"entity", "summary", "first_seen", "last_seen", "requests", "key_lines": [...]}], "expanded_entities": [...], "timeline": [...]}` ## Phase 2 — Verdict and blast radius Answer the working question with evidence on both sides: - **Did it succeed?** Status codes alone don't answer this — a 401 wall says no; 200s with anomalous sizes, error-then-success progressions, and data-shaped responses say yes. State the verdict and the discriminating evidence. - **Blast radius, quantified.** What data was reached: which routes/tables, how many records, over what time span, belonging to how many distinct users/customers. Each figure comes from a pipeline (count the exfil-page sizes, count the distinct ids walked, join walked ids to owners via the app's own data if available locally — running the target's deterministic `seed_command` early, before Phase 3, is fine). - **Containment status check (read-only).** Is the activity ongoing at the end of the corpus window, or did it stop? When was the last attacker action? - If the verdict is "did not succeed", the workup doesn't end — say what the attacker was *trying* and why it failed; that feeds the plan's hardening section and the `ruled_out` record. Checkpoint `phase2.json`: `{"verdict": ..., "succeeded": bool, "discriminators": [...], "blast_radius": {"data": ..., "records": N, "distinct_victims": N, "window": ...}, "ongoing": bool, "last_activity": ...}` ## Phase 3 — Root cause and PoC Same bar as `/dnr-hunt` Phase 3–4: 1. Read the implicated handler(s) in `--repo`; name the flaw (or the defense) at file/function precision; check sibling routes for the same flaw class. 2. Seed and start the app locally per target config: `seed_command` / `app_command` are target-relative — run them with the target directory as cwd; launch in the background via a single command that prints the PID (the same `python3 -c "...subprocess.Popen..."` pattern /dnr-hunt Phase 4 shows, with the port override env var if the default port is busy). Fire the **minimal** PoC, record command + response excerpt, fire the negative PoC against defended routes, then `kill <pid>` (never by port or pattern). 3. No runnable app → verdict ceiling is `suspected`, stated explicitly. Checkpoint `phase3.json`: `{"root_cause": {"file", "function", "mechanism"}, "poc": {"command", "status", "response_excerpt"}, "negative_poc": {...}, "siblings_checked": [...]}` ## Phase 4 — The response plan (PROPOSED, NEVER EXECUTED) and outputs Write the plan to `{RUN}/RESPONSE.md` — or `{RUN}/RESPONSE-<lead>.md` (e.g. `RESPONSE-INC-2.md`) if a `RESPONSE.md` from a different lead already exists in the run dir; never silently overwrite another incident's plan. Sections, every action carrying **what / why / risk-if-wrong**: 1. **Verdict & summary** — three sentences: what happened, did it succeed, how far it went. 2. **Timeline** — the merged entity timeline from Phase 1. 3. **Containment (proposed)** — block/deny candidates (IPs, sessions, tokens), accounts to suspend, routes to rate-limit or disable. For each: the evidence line that justifies it and what breaks if the call is wrong (e.g. blocking a NAT IP locks out legitimate users behind it). 4. **Eradication & remediation (proposed)** — the code fix, described at file/function level, handed off as a `/triage`-compatible vuln entry; interim mitigations if the fix will take time. 5. **Recovery (proposed)** — exactly which credentials rotate (the queried list, not "all users"), which customers get notified (the distinct-victim list from Phase 2), what monitoring confirms the attacker is out. 6. **Detection engineering (proposed)** — the rules that would have caught this earlier, derived from what you actually used to find it: the discriminating queries from Phase 2 turned into alert logic (e.g. error-rate per source on a route; sequential-id access cadence; account-from-new-IP at volume). Note which existing alerts fired, which were noise, and what that says about the queue. 7. **Open questions** — what this corpus cannot answer (earlier history, other log sources, whether stolen data was used elsewhere). Then update `{RUN}/INCIDENTS.json` (same schema as `/dnr-hunt`; create it if absent): add or enrich this incident — verdict, quantified impact, root cause, PoC, timeline. Extra keys are fine — graders match on content, not structure. Negative outcomes go to `ruled_out`. Mark complete (`checkpoint.py done {RUN}/.dnr-respond-state 4`) and point the user onward (substitute the literal `{RUN}` path): - for the fix, from inside `{RUN}`: `/triage INCIDENTS.json --repo <repo>` then `/patch TRIAGE.json --repo <repo>` — both write to the directory they're invoked from, so running them there lands the verdicts and patches beside the incidents - on a dnr target: `python <target>/grade.py {RUN}/INCIDENTS.json` to self-score (the user runs this) - a human reviews and executes (or rejects) each proposed action; nothing in RESPONSE.md has been done ## Customizing beyond the demo - Feed it your real alert queue one alert at a time — the lead parser takes any JSON or prose alert; the method doesn't change. - Auth logs, CDN/WAF exports, and EDR threat events slot into Phase 1 as additional per-entity activity sources; keep the single merged timeline. - The Phase 4 plan template is the part most worth adapting to your org: map containment to your actual controls (WAF rules, IdP session revocation, feature flags) — still as proposals routed to the owning team, never as actions the agent takes.