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.