The 648 sessions their detection had already cleared
A market research platform is attacked by people who coordinate in public. Reading those channels was never the hard part. Turning what they say into something a platform team can deploy on Monday was the hard part, and it was a person's job every week.
What was actually broken
The translation tax. Every handoff between two vocabularies loses signal, and this one has two: fraud-operator slang on one side, the platform's real telemetry column names on the other.
There is a measured version of that failure in the codebase, and it is the most useful thing we found. The detection rules had been matching against 17 hand-typed field names that did not exist in the client's data. The rules read correctly. They referenced columns nobody had ever created. They could never fire.
A rule that cannot fire looks exactly like a rule that found nothing.
What we built
A weekly pipeline that ingests the channels, drops the noise on a keyword gate, clusters what survives by tactic, and sends each batch for analysis. It runs itself on a schedule and posts the result. Nobody starts it.
The gate that matters sits at the end: any signal that cannot be matched against a real telemetry field in the client's own schema gets demoted. That allowlist is the single source of truth for their column names, and it is enforced in code rather than described in a document. It exists because of the 17 invented fields.
The output is a set of deployable sweep rules. The human-readable digest is the side effect, not the product.
Five consecutive weeks, from the run log
| Week | Messages ingested | Signals | Sweep rules |
|---|---|---|---|
| 1 | 1,163 | 8 | 4, all new |
| 2 | 1,347 | 8 | 2, one new |
| 3 | 1,351 | 0 | none |
| 4 | 98,972 | 9 | 2, both new |
| 5 | 687 | 2 | none |
103,520 messages, 27 signals, 8 sweep rules of which 7 were new. Every run ended by posting to their channel on its own.
Week 3 is in the table on purpose. It read 1,351 messages and produced nothing. A pipeline that finds something every single week is a pipeline that is grading itself.
The number to sit with
Alongside the pipeline we ran a one-off fingerprint analysis on a device-data export: 2,000 sessions, 1,769 of them carrying a usable fingerprint, 664 distinct ones.
| Cut | Result |
|---|---|
| Sessions in the two densest anti-detect clusters | 776 |
| Of those, scored LOW RISK by their own detection | 648 |
| Users running two or more evasion tools across sessions | 109 |
| Worst single user | 7 stacks, one address, 7 sessions, every one cleared |
Those were not sessions nobody looked at. A working detection stack had already looked at them and cleared them.
The fingerprint signals went into their production device risk model. Four other rules we proposed were killed by our own measurement: the traffic they keyed on turned out to be 99.45% concentrated in a single domain, so the rules would have flagged that domain and nothing else. We dropped them rather than tune them into looking useful.
What this case study does not claim
- No total run count. Five weeks are logged. That is the number we have.
- No fraud dollars caught or prevented. That figure was never measured, so it does not exist and we will not produce one.
- No hours-saved figure for the analyst work this replaces.
- Not portable by config. The collection, the schedule and the reporting move as they are. The signal-to-schema mapping is a rebuild for every client, because it is the part that has to be true about your data.
If this is your problem
You have intel and you cannot ship it. Most teams in this position do. The gap is not an intel gap. It is the distance between what an attacker calls a thing and what your schema calls it.
Three decisions carry this system, and they transfer:
- The output is a rule you can deploy, not a briefing somebody reads.
- A signal that cannot be matched to a real column in your data gets demoted before it reaches anyone.
- A quiet week reports a quiet week.
Anonymized at the founder's direction. Every number here comes from the engagement record: message counts read out of the corpus database, weekly figures read out of the run log, analysis cuts read out of the tool's own output.
If something in your business runs on a person reading things every week and translating them by hand, the same kind of system can be running in a week. Start with one thing: $1,000 fixed, one week, running by Friday.
Start with one thing: $1,000, one weekMore work: the review work that checks itself first · the pipeline that failed 95 times silently · the investigations OS · the research desk that runs itself