The dump is a claim, not a receipt

I'm Johannes. I have spent eighteen years on the response side of security, and I now build the machinery that turns raw evidence into answers. This post is about the rawest evidence there is.

In June 2024, LockBit announced it had breached the United States Federal Reserve and would publish 33 terabytes of banking data. The security press held its breath. The data went up, people started reading it, and it belonged to a mid-sized bank in Arkansas.

Nobody outside the gang knows whether the misdirection was strategy or sloppiness. What matters is where the truth finally lived: not in the announcement, not in the ransom note, not in the headlines written between the two, but in the bytes, which said Evolve Bank & Trust to anyone who actually looked.

In a prior post I argued that in a breach, the attacker can prove what they took and you can only prove what you logged, and that the dump they publish is the fastest evidence available to you. Several people made the same objection: the dump lies too. Attackers inflate, recycle and fabricate.

They are right, and it changes nothing about the conclusion, because the lie is in the claim and the truth is in the data. The dump is a claim, not a receipt. The number on the leak site is a press release from someone whose business is leverage. The gigabytes underneath it are a dataset, and a dataset can be interrogated, which is exactly why the attacker would prefer you never get past the headline.

The catch is that interrogating it is a data engineering problem of real size, it lands during the worst week of your year, and almost nobody staffs for it.

Three ways the claim lies

The claim and the data are different documents, and they diverge in three reliable ways.

Misattribution. The Federal Reserve case is the loud one, but the pattern is a decade old. When Troy Hunt wrote up how he verifies breaches for Have I Been Pwned, his worked example was a list sold as a dating site's user database that, on inspection, was nothing of the kind: wrong structure, accounts that did not exist on the service, most likely credentials aggregated from elsewhere and relabelled to sell. The name on the listing is chosen for its price, not its accuracy.

Recycling. In June 2025 the press reported sixteen billion leaked credentials as though a breach of unprecedented size had just happened. It was roughly thirty separate compilations stitched together from years of infostealer logs and previously circulated data: an inventory of history, not an event. A victim who takes the claimed count at face value notifies the world about a breach that mostly happened to other people, years ago.

Fabrication. In January 2024 someone offered 48.6 million Europcar customer records for sale. Europcar looked at the sample and found customers living in towns that do not exist. The records were synthetic, generated to look like a breach, because a fake breach of a real brand still sells and still forces a denial. Europcar could make that denial airtight specifically because someone read the sample against ground truth and pointed at the impossible addresses.

Notice the shape of all three. The lie was never exposed by a statement. It was exposed by reading the data. Verification is not a press function. It is a query.

Why you read it, in the order that actually matters

The compliance answer, that reading the dump scopes your notification duty, is true and it is the least of it. Here is the real order.

The story. About one breach in five is disclosed by the attacker, which means the first public account of what happened to your customers is frequently written by the person who took it, with a number chosen for effect. That number sets in days, and once set, you inherit it. The only thing that displaces a circulating claim is a specific, evidenced counter-claim, and the raw material for that counter-claim is sitting in the dump. Reputation is decided at the speed you can read.

What they now know. A dump is not only your customers' data; it is a map of you. Credentials, API keys, VPN configurations, network diagrams, the security assessment somebody attached to an email in 2022, the incident response plan itself. Every one of those in the dump is a live operational exposure, because the dump is public and the next attacker reads it too. You cannot rotate every secret and re-architect everything as a precaution; the estate is too big. Reading the dump tells you which keys are actually burned, which paths are actually mapped, what the follow-on attack already knows. Scoping that is not a compliance exercise. It is the difference between targeted hardening this week and discovering in six months that the second intrusion walked in on credentials from the first.

The crown jewels. Whether your source code, your formulations, your deal pipeline or your litigation strategy is in the dump changes the nature of the event entirely: it moves the damage from "regrettable disclosure" to competitive and legal exposure with a decades-long tail, and it decides urgent questions, injunctions, counterparty notifications, deal timelines, that no regulator will ever ask you about. The IP question has a property the personal-data question does not: only you can answer it, because only you know what your crown jewels look like. No outside forensics firm can tell you whether the file matters. Which means the dump has to be read by, or against, your own ground truth.

The people. Which real, current individuals are actually in there, which is where notification duty finally enters, fourth on the list, and where the counting is hardest. The same person appears as a row in a CRM export, a signature block in a mailbox, and a mangled string in a log. Your affected-individuals number is wrong until those collapse into one.

What reading it actually takes

So you read the dump. Here is what that sentence hides.

It arrives as hundreds of gigabytes, sometimes terabytes, of whatever the attacker's tooling happened to produce: database exports in three dialects, mailbox files, CSVs with broken encodings, directory trees ripped mid-copy, archives inside archives, some corrupt. Before a single question can be answered, all of it has to be parsed into something queryable, and every claimed record then has to survive four tests: is it real, is it yours, is it current, and who is actually in it.

I can put numbers on what the last step costs, because I do this for a living. On a public research corpus of 49,547 emails, clean, well-formed, adversary-free, my system extracts roughly 249,000 raw entity mentions that resolve to 710 actual people. A 350-to-1 reduction, on cooperative data. A hostile dump is larger, dirtier, and salted by someone who profits from your overcount.

And we have run the pipeline against the real thing. Several breach corpora that circulate on the dark net have been through it, as test loads, without an incident clock, and they were an education that no clean corpus could have provided. One of them held the classic: a zip inside a zip inside a rar, and at the bottom of that, a PST mailbox carrying 3,297 attachments, any of which could be another container. Nothing about that is technically hard. It is just endless, and endless is the attack: an analyst under deadline opens two layers by hand, meets the third, and moves on to a file that looks easier, which means the bottom of the archive is exactly where nobody looks. Depth does not defeat tooling; it defeats attention. Whatever reads a dump has to unpack recursively until it hits bytes, every time, with no human deciding whether each level is worth it. The broader lesson transfers: the messiness is not noise around the data, it largely is the data, and a pipeline that assumes well-formed input does not degrade gracefully on a dump, it stops.

The cost problem nobody prices in

There is a newer reason victims stall on the dump, and it is money.

The 2026 instinct, handed a mountain of unstructured text, is to point a large language model at it. Do the arithmetic first. LLM processing is priced by the token, and a dump's tokens are overwhelmingly junk: recycled filler, corrupt fragments, machine-generated padding, the same record duplicated across nine exports. Run a frontier model naively across terabytes and you have built the most expensive possible way to read garbage. The junk does not just waste the spend; the junk is the majority of the spend.

The fix is the same one incident response already knows: triage before you commit your expensive resource. In my pipeline, the model is the last layer, not the first. Cheap layers run over everything: parsing, hashing and dedup, pattern extraction, keyword scoring, embeddings, classification. The expensive reasoning runs only over what earned it. On that same public corpus, classification marked 63 files of 49,547 as story-bearing before deep analysis ran across the result: a needle-to-haystack ratio of nearly 800 to 1, decided by layers that cost a rounding error of what a full-corpus model pass would. On a hostile dump the ratio is harsher, because a bigger share is junk by construction.

The stealable principle: spend model tokens the way you spend senior incident hours. Nobody puts their lead responder on reading every log line; do not put your frontier model there either. Classification is not a preprocessing detail. It is the cost model, and on dump-scale data it is the difference between an answer this week and an invoice you cannot defend.

What this argument conveniently skips

The honesty section, as always.

The dumps we processed were test loads, chosen by us, on our schedule. I have not run this end to end inside a live incident, with counsel arguing about whether we may even load the data while the clock runs. That difference is not cosmetic: the legal handling question is real. The dump is stolen property containing other people's personal data, and some jurisdictions make possessing it, even defensively, genuinely uncomfortable. The teams best placed to read it fast are often the least free to touch it, and I do not have a clean answer for that tension, only the observation that the attacker is not similarly constrained, and that the analysis I have described was done with exactly that constraint in mind.

And the counting is only as good as your ground truth. Deciding a record is recycled, stale or fabricated means testing it against what you actually hold: real customer sets, real schemas, real towns. An organisation whose own data map is two years stale cannot fully use even a perfectly processed dump, because the reference it must be compared against is itself wrong. The dump work inherits every dull evidence decision from that prior post; it does not replace them.

What is still unsolved

The deepest problem is proving absence. Reading the dump can show a record is fake, recycled or stale. It cannot show the attacker holds nothing more. "The published data is not ours" is a sentence you can defend; "that is all they took" never is. The dump bounds the floor of the breach, not the ceiling, and I have not seen anyone, vendor, victim or regulator, articulate that boundary well.

What to take from this

The dump is a claim, not a receipt. The number is marketing; the bytes are evidence.
The lie is never exposed by a statement. It is exposed by reading the data.
Read it for the story, the burned secrets and the crown jewels first. Notification is the fourth reason, not the first.
The dump is a map of you. Rotate what it proves is burned, not everything you fear might be.
Only you can answer the IP question. Ground truth does not outsource.
Depth does not defeat tooling; it defeats attention. Unpack to the bytes, every time.
Spend model tokens like senior incident hours: triage with cheap layers, reason over what earned it.
Entity resolution is where the count comes from: 350 to 1 on clean data, worse on hostile.
The dump bounds the floor of the breach, never the ceiling.

If you have processed a hostile dump under a real incident clock, I want to hear what broke, because everyone I ask describes the same improvised week of grep and regret. Turning that week into hours, at a cost you can defend, with every finding traced to the exact source bytes, is the problem I work on during the day: that work is here.

Sources

LockBit's Federal Reserve claim and the Evolve Bank & Trust data: Malwarebytes, BleepingComputer and SecurityWeek coverage, June 2024, plus Evolve's own confirmation. https://www.malwarebytes.com/blog/news/2024/06/federal-reserve-breached-data-may-actually-belong-to-evolve-bank
Europcar's fabricated 48.6M-record "breach": BleepingComputer, January 2024. https://www.bleepingcomputer.com/news/security/europcar-denies-data-breach-of-50-million-users-says-data-is-fake/
The "16 billion credentials" compilation, June 2025: Cybernews (original report); InfoStealers.com analysis of its composition. https://cybernews.com/security/billions-credentials-exposed-infostealers-data-leak/
Troy Hunt, "Here's how I verify data breaches," 2016. https://www.troyhunt.com/heres-how-i-verify-data-breaches/
Attacker-disclosed breach share (19%): IBM, Cost of a Data Breach Report 2025. https://www.ibm.com/reports/data-breach