Red-team catalog reference: profiles, raw-protocol attacks and verdict classification

Diátaxis quadrant: Reference. Audience: defensive-test developers who need the authoritative catalog map and profile contract.

This page is the authoritative human-readable map of the Red catalog: the profile contract every .mjs file honours, the labels used for evaluation, the verdict classification applied by the end-to-end runner, the 65 catalog entries, and the Go raw-protocol client. It is a lookup reference, not a build guide. To author a profile, see Write a Red profile; for how the pieces fit together, see Red catalog architecture.

Important: This catalog is purely defensive, local-only and self-target-only. Everything here exercises your own detector’s test catalog against your own loopback server; it teaches understanding and extending that catalog, never third-party evasion. Read the Red-team rules of engagement before running anything — that page carries the guardrail these profiles operate under (loopback target hard-coded, no external hosts). Blocked traffic here is “automated” / “not verified as human”. Every verdict named below is reference-measured on your machine, not a guarantee: coherent browser or human-assisted automation-class adversaries (anti-detect plus real-human click-farms) remain a design boundary mitigated by rate and reputation, and the heuristic rules datacenter-network browser rule / no interaction observed rule / missing or replayed request-integrity token rule can challenge some real humans.

The profile contract

Every profile is an ES module under test/redteam/ that exports three things. The shape is fixed because test/e2e/runner.mjs imports the module and reads exactly these fields.

The returned object is the /api/collect response verbatim: verdict is one of ALLOW | CHALLENGE | DENY, riskScore is 0–100, hardRuleFired is the winning enforcement-rule identifier or empty, and topContributors is the ranked {id, score} list. The runner records topContributors.map(c => c.id) into results.json.

Helper modules _bin.mjs (wraps the Go cmd/redteam binary) and _driver.mjs (launches the browser) export no run() and are not profiles.

The bot: label rule

classify() decides whether a sample is automated or human baseline solely from the label prefix:

• A label starting with bot: is scored as automation.
• The only non-bot label is human (in human.mjs), the human baseline.

Warning: Getting the label wrong silently flips a profile into the human baseline. A profile that forgets the bot: prefix is treated as a human sample: its DENY becomes a false positive and its ALLOW becomes a true negative, quietly corrupting the reported rates. There is no error — the mislabel just changes which column the sample lands in.

Verdict classification

classify(label, verdict) in runner.mjs maps each result to a true positive, false negative, false positive, true negative, expected boundary result, or additional boundary catch. The exact machine strings remain in the source and result files:

const denied = verdict === 'DENY' || verdict === 'CHALLENGE';
if (label.startsWith('ceiling:')) return denied ? 'CEIL-CAUGHT' : 'CEILING';
if (label.startsWith('bot:')) return denied ? 'TP' : 'FN';
return verdict === 'DENY' ? 'FP' : 'TN';

Note: A ceiling: label is not an expected automated denial. The single native_coherent_ceiling profile represents the coherent-automation detection boundary: ALLOW is the honest expected result under the current reference policy. A CHALLENGE or DENY is an additional catch, not the pass condition.

Note: A human CHALLENGE is scored as a true negative, not a false positive. The humanFPR field is therefore a denial-only metric. It under-reports human friction because a challenged human does not count against it. Inspect the baseline challenge rate separately; do not read a clean field as “zero human friction”.

The 65-entry catalog

The catalog is 65 entries = 63 automated behavior profiles + 1 coherent boundary case + 1 synthetic human baseline. Rows are grouped by increasing attacker cost. “Expected enforcement rule” names the predicate the profile is designed to exercise; where no single predicate is pinned, the expected result is score-driven and must be verified from the run.

The catalog is organised as a five-band automation cost ladder defined in test/e2e/tiers.mjs — from direct Hypertext Transfer Protocol automation through real-browser automation and the coherent browser or human-assisted automation boundary. assertCoverage() in runner.mjs fails if this catalog and the machine-readable ladder drift. The raw-protocol checks are a parallel axis that eighteen .mjs catalog profiles invoke through _bin.mjs.

flowchart TD
  CAT["65-entry catalog · 63 automated + 1 boundary + 1 human baseline"]
  CAT --> BASE["Baseline · 1"]
  CAT --> Direct["Direct HTTP automation · 15"]
  CAT --> Default["Off-the-shelf browser automation · 12"]
  CAT --> Stealth["Stealth-patched browser automation · 17"]
  CAT --> Real["Real-browser automation · 19"]
  CAT --> Boundary["Coherent boundary case · 1 (ALLOW by design)"]
  RAW["Raw-protocol attacks · 18 -attack values (cmd/redteam)"]
  Direct -. "for example tls-static" .-> RAW
  Default -. "for example flood" .-> RAW
  Real -. "for example distributed" .-> RAW

Node counts sum to the catalog total: 1 + 15 + 12 + 17 + 19 + 1 = 65.

Baseline

The single must-not-block sample. A DENY here is a false positive.

direct HTTP automation · trivial ($0, a script, no browser)

Non-browser HTTP/uTLS clients, header/token tricks, and the cheapest behaviour tells. Blue’s expectation: reliable.

off-the-shelf browser automation · low ($, off-the-shelf tools on defaults)

Naive automation frameworks, single-axis TLS/engine churn, and cheap resource/DoS abuse. Blue’s expectation: reliable.

stealth-patched browser automation · moderate ($$, stealth / rotation / fingerprint-spoof / humanizers)

Stealth-patched automation, multi-axis rotation, fingerprint-spoof contradictions, and mouse/keystroke humanizers. Blue’s expectation: reliable.

real-browser automation · high ($$$, real engine + AI + proxy infrastructure)

Real-engine anti-detect (nodriver / camoufox / xvfb / anti-detect), full AI-agent cadence, and residential-proxy-rotation correlation. Blue’s expectation: degrades gracefully — scores and challenges or denies at lower confidence.

Coherent browser or human-assisted automation · very high — documented boundary

A fully coherent BotBrowser-class engine spoof (or genuine human behaviour on a real engine): not separable by detection alone. Blue’s honest expectation: NOT solved. The coherent case scores ALLOW; it is priced only by rate limiting and cross-session reputation (the attested / ceiling-guard mechanism), not caught by a signal. This single profile carries the ceiling: label, so its ALLOW is the expected honest result, not a false negative.

Note: The expected verdict and enforcement rule in these tables are reference-measured from the bundled catalog run against the local engine; run self-validation to reproduce them for your build. An enforcement rule fires on a specific tell (for example headless browser plus another automation indicator rule on a headless browser that also exposes webdriver), so it is stable across environments; the exact risk score is not, and a profile whose tell is score-driven rather than rule-driven can land on a different enforcement rule if signal availability changes.

Raw-protocol attacks (cmd/redteam)

The Go cmd/redteam client drives evasions a browser cannot: it controls the TLS ClientHello (via uTLS) and request-integrity tokens precisely, and it spoofs the client-hint / sec-fetch headers a real Chrome sends so the header consistency checks stay quiet — isolating the one bypass under test. It exposes eighteen real -attack values.

Note: These are eighteen values the -attack switch in cmd/redteam/main.go implements; the table below documents a representative seven. The full set also includes privacy-evasion, signal-forgery, nonbrowser-ua, sec-chua-absent, sec-fetch-absent, rit-absent, ja4-churn, multi-axis-rotate, grease-absent-js, coherent-ceiling, and xff-spoof. (HTTP/2 Rapid Reset is exercised by the rapid_reset node profile, not this binary.)

The -host flag defaults to 127.0.0.1:8443. That default is advisory, not enforced — the CLI connects to whatever host:port is passed, so keeping it loopback is the operator’s responsibility. (Contrast the Detection Observatory launcher, which is structurally locked to loopback.)

Two entry points for the same attack

Every raw-protocol -attack value also exists as a .mjs profile that shells to the Go binary via _bin.mjs — eighteen profiles in all (for example flood, distributed, tls-static). Running the profile and running the raw -attack exercise the same underlying attack; the profile wrapper is what lets the e2e runner and the Observatory catalog reach it.

Where verdict detail comes from

The full per-stage trace is not in every output. Sources, from least to most detail:

• node test/redteam/run-one.mjs <profile> https://127.0.0.1:8443 stdout — intentionally minimal: {label, verdict, riskScore, hardRuleFired}. It drops topContributors.
• POST /api/collect JSON — the full {verdict, riskScore, hardRuleFired, topContributors} returned to every profile’s run().
• test/e2e/results.json — the runner’s record per run, including the top contributor id list.
• GET /playground/explain/{id} (Detection Observatory) — the complete ScoreTrace for a stored session: per-signal contributions, dedup keep/drop, per-stage cap, and the ordered enforcement-rule evaluation. See Run the Detection Observatory.

Related pages

• enforcement rules, verdicts and signal reference — the Core rules table and verdict bands.
• Red catalog architecture — how profiles, helpers, the runner and the Go client fit together.
• Write a Red profile — authoring guide, including the three registration points.
• Self-validation Red-team run — running the suite and reading the rates.
• Run the Detection Observatory — the live feed and the score trace.
• Red-team rules of engagement — the guardrail these attacks operate under.