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

Quadrant: Reference (lookup tables). Audience: Red-team developers needing the authoritative catalog map and the profile contract.

This page is the authoritative map of the Red catalog: the profile contract every .mjs file honours, the label rule that decides whether a sample counts as automated or as human baseline, the verdict-classification table the e2e runner applies, the 47-profile catalog (45 must-block bots + 1 detection-ceiling + 1 baseline), and the seven raw-protocol attacks the Go cmd/redteam client constructs. It is a lookup reference, not a build guide — to author a new profile, see Write a Red profile; for how these 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: T4-class adversaries (anti-detect plus real-human click-farms) remain a design boundary mitigated by rate and reputation, and the heuristic rules HR-11 / HR-12 / HR-17 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 hard-rule id 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 one of TP / FN / FP / TN, plus the two detection-ceiling classes CEILING / CEIL-CAUGHT. This mirrors the source exactly:

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 a must-block bot. The single T4 native_coherent_ceiling profile is the documented detection ceiling: ALLOW is the honest expected result, priced via the attested / ceiling-guard mechanism (rate limiting plus cross-session reputation), not a bypass. A CHALLENGE or DENY on it is a bonus, not the pass condition.

Note: A human CHALLENGE is scored TN, not FP. So humanFPR is a DENY-only metric — it under-reports human friction, because a human sent to a proof-of-work interstitial does not count against it. Inspect the challenge-rate on the baseline separately; do not read a clean humanFPR as “zero human friction”.

The 47-profile catalog

The catalog is 47 profiles = 45 must-block bots + 1 detection-ceiling + 1 baseline. Rows are in runner.mjs PROFILES order. Expected HR is the hard rule the profile is designed to trip; where the ground-truth mapping does not pin a specific rule, the profile is still expected to score TP (CHALLENGE or DENY) but the exact rule is marked score-driven / for verification.

The catalog is organised as the T0–T4 attacker cost-escalation ladder defined in test/e2e/tiers.mjs — from the cheapest trivial script (T0) up to a funded real-engine adversary (T3) and the honest detection ceiling (T4). assertCoverage() in runner.mjs fails loudly if this catalog and the tier ladder drift. The raw-protocol attacks are a parallel axis that eighteen .mjs catalog profiles shell into via _bin.mjs.

flowchart TD
  CAT["47-profile catalog (test/redteam/*.mjs) · 45 must-block bots + 1 detection-ceiling + 1 baseline"]
  CAT --> BASE["Baseline · 1"]
  CAT --> T0["T0 trivial · 13"]
  CAT --> T1["T1 low · 12"]
  CAT --> T2["T2 moderate · 12"]
  CAT --> T3["T3 high · 8"]
  CAT --> T4["T4 ceiling · 1 (ALLOW by design)"]
  RAW["Raw-protocol attacks · 18 -attack values (cmd/redteam)"]
  T0 -. "e.g. tls-static" .-> RAW
  T1 -. "e.g. flood" .-> RAW
  T3 -. "e.g. distributed" .-> RAW

Node counts sum to the catalog total: 1 + 13 + 12 + 12 + 8 + 1 = 47.

Baseline

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

T0 · trivial ($0, a script, no browser)

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

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

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

T2 · moderate ($$, stealth / rotation / fingerprint-spoof / humanizers)

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

T3 · 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.

T4 · very high — the detection ceiling

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 hard 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. A hard rule fires on a specific tell (for example HR-7 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 hard 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 RIT tokens precisely, and it spoofs the client-hint / sec-fetch headers a real Chrome sends so the L6 header cross-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-layer 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-layer cap, and the ordered hard-rule evaluation. See Run the Detection Observatory.

Related pages

• Hard rules, verdicts and signal-ID reference — the HR-1..HR-21 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.