The Mask That Convicts: The Automated Unmasking Loop

TI-2026-086K · Series: The Wardrobe · Case 11 · Classification: HIGH · Confidence: HIGH

Ten cases described an attack. This one describes the answer. Back in The Impostor Economy (085B) the series coined a phrase for what a forged identity does to the forger — it is "the mask that convicts the wearer." That was a sentence. This case is the cron job it became. The pipeline now detects a spoofed fleet, keys a ban to the fleet's own costume name, escalates proven impostors past every volume threshold, and drops them at both the host firewall and the router — automatically, hourly, seven days at a stretch. The costume that bought passage is now the handle that condemns the whole fleet at once.

Executive Summary

The unmasking loop has five stages, and every one of them is live:

Detect. The web-threats pipeline runs two identity detectors — spoofed_impostor_cluster (≥5 IPs impersonating one crawler whose provenance failed) and identity_rotation (a /24 cycling ≥2 stolen names) — turning masked traffic into named campaign objects.
Collect. An hourly Kubernetes CronJob, web-threats-autoban, calls fetch_spoofed_fleets(), which pulls those campaigns from the web-threats API and gathers their member IPs.
Escalate. For a proven impostor, the SPOOFED_ESCALATE rule bans on any malicious intent — threshold one — because the provenance failure has already done the convicting.
Key by name. The CrowdSec decision's scenario string is the fleet's costume: web-threats/autoban (spoofed fleet): Fake-Googlebot Fleet AS396982 (77 IPs).
Enforce. The firewall-bouncer applies the decision at host nftables and mirrors it to the MikroTik router's crowdsec-blacklist — a 168-hour (7-day) block at both host and edge.

One manual batch run banned 171 proven fleet members (skipping 6). The live decision log right now shows web-threats/autoban bans sitting at ~167 hours to expiry, beside the honeypot's cowrie-ssh-bruteforce (24h) entries. And the loop carries designed-in brakes — a verified-crawler guard, a 2,219-entry allowlist, an already-banned skip — plus one collateral tradeoff the operator flagged and accepted on purpose. This is the series' thesis turned into infrastructure.

The Loop, End to End

Trace a single fake Googlebot through the machine.

It arrives at the edge presenting Mozilla/5.0 (compatible; Googlebot/2.1), egressing a Google Cloud tenant address on AS396982. The classifier runs the provenance check from 086E — is this IP inside Google's published Googlebot range? — and it fails: AS396982 is not the real crawler's home. The verdict is SPOOFED. Because four or more of its siblings did the same, the spoofed_impostor_cluster detector fires and mints a campaign: Fake-Googlebot Fleet AS396982 (77 IPs), with an identity profile that reads spoofed:77 (google/search/indexing).

An hour later — at most — the web-threats-autoban CronJob wakes. It looks back 48 hours, calls fetch_spoofed_fleets(), and pulls that campaign with its member IP list. Each member is checked against the guards (below). Those that survive are handed to CrowdSec as a ban, and here is the detail that makes the whole series' title literal: the ban's reason string is the fleet's own name. The decision does not say "scanner" or "bad IP." It says Fake-Googlebot Fleet AS396982 (77 IPs). The costume is filed as the crime.

CrowdSec holds the decision for 168 hours. The firewall-bouncer enforces it immediately at the host's nftables, and the decision is mirrored to the MikroTik router's crowdsec-blacklist, where it becomes an inbound src-drop at layer 3. From that moment the fleet member is dropped twice over — once at the host firewall, once at the network edge — for a week.

That week matters. The GCP fleets are disposable instances, spun up and torn down; a 24-hour ban would often outlive the instance by little. Seven days holds the address long past the instance that used it, so recycled tenant IPs stay cold. Detection, judgment, and enforcement have closed into one automated circuit, and the unit that travels through it is never the IP — it is the fleet.

Threshold One: Why the Impostor Has No Slow Lane

The sharpest piece of the loop is the escalation rule, because it removes the mask economy's favourite escape.

Normally the autoban is patient. It is rule-driven: each probe intent carries a ban threshold — critical and high intents ban at 1 hit, medium at 5, low at 20 — so ordinary suspicious traffic has to accumulate before it is blocked. That patience is deliberate; it keeps the false-positive rate down on genuinely ambiguous behaviour.

But a proven impostor gets no patience. The SPOOFED_ESCALATE rule bans a confirmed spoofed-fleet member on any malicious intent, threshold one. The logic is exact: the provenance check has already convicted this IP — it claimed to be Googlebot and demonstrably is not — so its very next hostile request needs no corroborating volume. This was validated the day it shipped, when it banned 35.247.135.112, a fake Googlebot on GCP running a single vhost_enum probe (vhost_enum:1) — below the normal threshold of five, banned anyway because it was a proven impostor.

Follow what that does to the attacker's economics. The whole point of a 77-IP fleet, and of the rotation subnets in 086G, is to stay under thresholds — spread the volume so no single identity accumulates enough to trip a rule. Threshold-one escalation deletes that strategy for anyone wearing a convicted costume. The 78th Fake-Googlebot IP does not get to make five quiet requests; it is classified into the already-named fleet on its first bad move and banned. The mask that let the fleet scale is exactly what makes each new member instantly catchable — the fleet name is a standing conviction that new members inherit on arrival. Attrition, the attacker's usual friend when facing per-IP bans, becomes the attacker's enemy: every fresh IP is not a fresh start but another entry under a name already on the blocklist.

The Brakes: Aggression With Designed-In Restraint

A loop this aggressive would be dangerous without guards, and the series' own warnings (085C, 086E) are precisely about the false positives an over-eager unmasker could cause. So the autoban carries three explicit brakes, and they are worth naming because they are what make it shippable.

The verified-crawler guard. fetch_spoofed_fleets() skips fleets on a VERIFIED_CRAWLER_ASN. This is the stale-range hedge from 086E made operational: if the classifier's published-range list for a real operator ever lags — the operator adds an ASN and curation hasn't caught up — the autoban will not ban traffic from a verified-crawler ASN even if a transient check looked wrong. The verified-crawler exemption is preserved by design, so the cost of curation staleness is a missed ban, never a banned Googlebot.

The allowlist. The autoban skips ALLOWLIST_NAMES. When nordvpn-allow was added, the allowlist grew from 40 entries to about 2,219, and a SKIP on an allowlisted IP was validated end-to-end. Legitimate egress the operator relies on is protected from the loop.

The already-banned skip. The loop skips IPs already under an active CrowdSec decision — and it skips all active decisions, not just the ~495 mirrored to MikroTik, because the host firewall-bouncer already enforces every decision at nftables. Skipping only the MikroTik subset would re-ban ~52,000 already-enforced IPs every hour: pure churn, no security gain. The guard is a performance and correctness decision.

Together these say something about the posture: the system is maximally aggressive on proven impostors and carefully conservative everywhere else. The conviction that unlocks threshold-one banning is not "looks suspicious" — it is the provenance failure, the one verdict the series has insisted all along is categorically different from mere suspicion.

The One Tradeoff It Makes on Purpose

Forensic honesty requires surfacing the loop's most debatable decision, because the operator made it deliberately and wrote it down rather than letting it hide in the code.

On 2026-07-13 the spoofed-fleet batch-ban was set to ban impostors on shared-CDN and proxy ASNs too — Cloudflare (AS13335), Fastly, Akamai — not only dedicated-cloud VMs. The risk is real and was named explicitly: a shared CDN edge IP can carry many tenants' traffic, so banning it to stop a fake ChatGPT-User transiting Cloudflare Workers could, in principle, drop legitimate traffic that happens to egress the same edge. A guidance note in the roadmap explicitly says not to add a shared-CDN skip.

Why accept that? Because for this infrastructure the operator is confident no legitimate inbound transits Cloudflare, Fastly, or Akamai to his estate — the homelab is not CDN-fronted (a fact established in the 066 series), so a Cloudflare-egress request reaching it is, by construction, not a legitimate CDN customer's traffic but a WARP/Worker tunnel. Given that, banning the shared edge IP has no legitimate victim here, and refusing to ban it would leave the egress-laundering landlord of 086H a free pass.

The point for a reader is not that the decision is universally right — it is emphatically not right for a CDN-fronted estate, where it would drop real users. The point is that it is a values call specific to one infrastructure, made consciously and documented, not an accident buried in a config. That is the honest way to ship an aggressive control: state the tradeoff, name who accepted it, and record the assumption it rests on so the next operator can check whether it still holds.

Steelmanning: "An auto-banner that trusts its own classifier is one bug from disaster"

The strongest objection is not that the loop is too weak but that it is too trusting: it bans automatically, at threshold one, on the classifier's SPOOFED verdict — so a single classifier bug, or a stale range, or a mis-curated ASN could auto-ban a real crawler at scale, silently, for a week at a time. Isn't automated enforcement on a fallible verdict reckless?

It would be, without the structure that is actually there, and the structure is the answer:

The convicting signal is the strongest one available. Threshold-one escalation fires only on SPOOFED — checked-and-contradicted provenance — not on "claimed" or "unverifiable." That is the one verdict backed by the operator's own published ASN (086E), the least bug-prone input in the system.
The verified-crawler guard is the explicit failsafe for exactly the feared failure mode: it refuses to ban verified-crawler ASNs, so a stale range degrades to a missed ban, not a false one. The asymmetry is chosen deliberately — the loop is built to fail open for legitimate crawlers.
Every ban is legible and reversible. The decision is keyed to a human-readable fleet name and expires in 168 hours; a mistaken ban is visible in the decision log and self-heals in a week, and can be lifted instantly (as the roadmap shows was done when testing individual IPs).

The objection correctly identifies the risk of automated enforcement on a fallible verdict — and the design's response is not to deny the fallibility but to (a) gate automation behind the least fallible verdict, (b) fail open for the protected class, and (c) keep every action legible and short-lived. That is a defensible engineering answer to a legitimate fear, and it is why the aggression is shippable rather than reckless.

What Holds, and What Is Bounded

Documented, HIGH confidence: the five-stage loop (detect → collect → escalate → key-by-name → enforce); the hourly CronJob with 48h lookback and 168h ban; SPOOFED_ESCALATE threshold-1 validated on 35.247.135.112; the fleet-name-keyed CrowdSec scenarios and banned_fleet=171 batch; two-layer nftables + MikroTik enforcement; the three guards; the accepted shared-CDN tradeoff and its stated assumption. All from the enforcement logs, the autoban source, and the operator's own decision record.

Bounded: the loop's precision in the wild — its false-positive and false-negative rates over time. The guards are documented and the escalation is gated on the strongest verdict, but a measured error rate (how often a verified-crawler skip prevents a bad ban, how often a stale range causes a missed one) is not quantified here. Held as: the design is failure-open for legitimate crawlers by construction; the empirical rates are a monitoring follow-up.

Why It Matters

The Mask That Convicts is the case where the series stops analysing the attacker and starts showing the defender's completed answer. Every prior case ended by pointing at behaviour or provenance as the thing to judge; this one shows the judgment wired to a trigger. The forged Googlebot's costume is no longer a cost the defender pays to see through — it is the label the ban is filed under, the standing conviction the next fleet member inherits, the exact string that turns 77 disposable instances into one week-long block at host and edge.

And it closes the loop 086A opened with a specific, hard-won inversion. There, the mask made the fleet efficient: one costume, seventy-seven bodies, cheap passage. Here, the same fact runs backward: one costume, seventy-seven bodies, one name — and the name is on the blocklist. The economics that made the wardrobe worth building are the economics that make it catchable, once the defender agrees to treat the fleet, not the IP, as the thing it bans. The mask was always going to convict the wearer. This case is the machine that reads the verdict, files it under the costume, and enforces it at the door — every hour, for a week, automatically.

Cross-references

TI-2026-085B — The Impostor Economy — the "mask that convicts the wearer" aphorism this case operationalises.
TI-2026-086A — The Wardrobe Rack — the fleet-as-unit detection that this case enforces as fleet-as-unit banning.
TI-2026-086E — The Newest Trust — the SPOOFED provenance verdict that gates threshold-one escalation, and the curation-staleness risk the verified-crawler guard hedges.
TI-2026-086H — The Landlords — the shared-CDN (Cloudflare) egress-laundering that the accepted collateral tradeoff deliberately bans through.

Next in the series — TI-2026-086L, The Verifier's Dilemma: the shared-hyperscaler false-verify and false-spoof hazards, curation staleness, and why the strongest verdict is also the most fragile to maintain.

TLP:WHITE. Defensive infrastructure and attacker fleet names only. No internal addresses or secrets disclosed. One infrastructure-specific policy tradeoff surfaced and attributed; empirical error rates explicitly left as a monitoring follow-up.