Red Team: Four Adversaries, Kill-Chain or It's Locked

Red Team — four adversaries: kill-chain or it's locked

When to use it: hardening a feature or service you own before ship, doing a security
review that goes past a linter/checklist, threat-modeling a change, or running a sanctioned
pentest. Four adversaries each attack a different surface with a "break it or prove it's
locked" mandate, and every claimed exploit is reproduced or refuted before it's reported.
Authorized / own-system / staging / CTF / sanctioned-engagement only. Keyword bait: "red
team", "adversarial review", "find exploits", "kill chain", "pentest", "attack surface",
"threat model", "break it", "harden".

Not a review that says "consider adding validation." Each adversary has one job: produce a
working exploit chain, or prove the surface is defended. Findings are verified before they're
reported, so you get real kill-chains and a defensible "locked" certificate — not a pile of maybes.

Rules of engagement — read first, non-negotiable

Authorization is a precondition. Only run against code/systems you own, a disposable
staging/sandbox copy, a CTF target, or an engagement with written scope. No authorization →
stop.
No live damage. Reproduce against local/staging/throwaway. No real DoS or load attacks, no
deleting/exfiltrating real user data, no touching third-party or shared infra, no pivoting
outside scope.
Findings are for fixing. Weaponized payloads stay in the report, scoped to the target; the
deliverable is a fix.
Time-box and log what you tried, so "locked" is evidence, not silence.

Refuse to point this at a system the user doesn't own, or to weaponize output against third
parties — it hardens what you control.

The mandate

Every adversary ends with exactly one verdict per attack, no hedging:

EXPLOITED — a working kill-chain: entry → technique → escalation → impact, with
reproducible steps and the vulnerable file:line.
LOCKED — the attack is stopped, citing the specific control that stops it
(file:line / config / framework behavior), not "looks fine."
PLAUSIBLE — a lead only, allowed solely as input to the verification gate; never a final
reported claim.

The four adversaries

Each gets the target (diff / spec / running instance), its checklist, and the order: "break it or
certify it locked — quote file:line for every claim, chain findings into impact." Surfaces
map to the OWASP Top 10 + API/abuse categories.¹

1 · Identity & Access — authN bypass; session forgery/fixation; JWT alg=none/kid/
key-confusion; password-reset & OTP flaws; IDOR / BOLA (swap an id → read another tenant's
data); privilege/scope escalation; multi-tenant isolation breaks; CSRF on state changes;
OAuth redirect_uri/state abuse; auth applied to some routes but not a sibling.

2 · Injection & Untrusted Input — SQL/NoSQL injection; XSS (stored/reflected/DOM); SSTI;
command / path-traversal / LDAP / header / log injection; SSRF (esp. cloud metadata
169.254.169.254); XXE; insecure deserialization; mass-assignment; file-upload → RCE /
content-type confusion; open redirect. Trace every attacker-controlled value from entry to sink.

3 · Business Logic & Abuse — race conditions / TOCTOU (double-spend, coupon/limit applied
twice, check-then-act gaps); replay / missing idempotency; workflow & state-machine bypass
(reach "shipped" without "paid", skip verification); price / quantity / negative-value
tampering; credit/refund/coupon abuse; enumeration & scraping; rate-limit / quota bypass. These
pass every input validator — the bug is in the rules, not the parsing.

4 · Secrets, Supply Chain & Infra — hardcoded/committed secrets and secrets in logs;
vulnerable/abandoned/typosquatted deps and transitive CVEs; dependency confusion; CI/CD &
container/deploy misconfig (privileged container, exposed registry, over-broad IAM); exposed
admin/debug/metrics/actuator endpoints; missing or loose security headers & CORS; verbose
errors leaking internals; missing TLS / cookie Secure/HttpOnly/SameSite; SSRF-reachable
internal services.

Kill-chain format (one per confirmed finding)

[SURFACE] Title                                   Severity: Critical|High|Med|Low
Chain:    entry point → technique → escalation → impact
Repro:    exact request/steps against the sanctioned target
Evidence: path/to/file.ext:line — the vulnerable code
Fix:      the specific control that closes it (and a regression test)

Severity = impact × exploitability. Pre-auth RCE or cross-tenant read = Critical; a self-only info
leak behind auth = Low.

The verification gate — kill false positives

A hallucinated exploit is worse than none — it burns trust and time. Never report an unverified
chain. For each EXPLOITED/PLAUSIBLE claim, spawn an independent skeptic prompted to refute
it: reproduce end-to-end, or find why it can't fire (an upstream guard, framework auto-escaping,
an unreachable branch).²

CONFIRMED (reproduced) → report as an exploit.
REFUTED → drop it; record why so it isn't re-raised.
NEEDS-MANUAL → hand to a human with the exact one-line check.

Use ≥2 independent verifiers for Critical/High. This is Trust but Verify
pointed at the attacker's own claims.

How to run

Fan out four Opus adversaries in parallel (finding real exploits needs strong reasoning), each
on one surface with its checklist; then a verify pass per claimed exploit; then synthesize a
ranked report. Best as a multi-agent workflow (attack → verify → synthesize). Route mechanical
enumeration (dependency list, secret grep, route inventory) to Haiku/Sonnet; adversaries and
verifiers stay on Opus. See Subagents and Context Injection
for handing each adversary pre-fetched context so it attacks instead of re-reading the codebase.

Output & compounding

A ranked red-team report: confirmed kill-chains (severity-ordered, repro + fix), a
locked-surface certificate (the control that defended each surface, with file:line), and
NEEDS-MANUAL leads. Feed every Critical/High back as a constitution rule + regression test so
the class can't reappear — see The Compounding Layer.