Corpus Audit: 251 of 587 Files Record No Established Entry Route

The question was a fair one, and it was put more or less like this: any list of attack types has malware, session hijacking and SQL injection near the top of it, so why does this corpus hardly mention them?

We measured rather than answered. Every file carries a `vector` field in its record. Counting it across all 587 files: 251 of them — 42.8% — record no established entry route, sitting instead on "Various", "Not established" or "Under review".

That is the finding. Not that this desk under-covers a technique, but that in two files out of every five, nobody ever published how the intrusion started.

The reason those numbers are low is that a technique taxonomy is written from the defender’s side — it enumerates what can be done to you. This database is written from the disclosure side, and it can only record what somebody was willing or obliged to say.

A Form 8-K says an unauthorised third party gained access to certain systems. A breach notification letter says the same in longer words. Neither is required to say how, and the corpus filed at 24-0821 that a company is not even obliged to explain the reasoning behind its own disclosure, let alone the mechanism.

SQL injection is the sharpest case. The MOVEit Transfer campaign — CVE-2023-34362, exploited by Cl0p from late May 2023 — was a SQL injection flaw in a managed file transfer product, and by the tracking most widely cited it reached over 2,700 organisations and tens of millions of people. It is very probably the largest SQL-injection-driven data theft in history.

Almost none of the downstream notifications say "SQL injection". They say a third-party file transfer tool was compromised, because from the notifying organisation’s point of view that is the true and complete description of what happened to them. They did not run the vulnerable software. Their supplier did.

So the technique disappears at exactly the point where the harm becomes countable. It is present once, at the top of the chain, and absent from every one of the thousands of disclosures underneath — which is also why this corpus files that campaign under concentration rather than under injection.

Filing the cases where the technique is on the record, and only those. Four went up alongside this one: a password spray Microsoft described in an SEC exhibit at 24-0112, a vulnerability chain CISA set out in an emergency directive at 24-0110, an infostealer platform whose seizure is documented at 24-1028, and a volumetric attack at 24-1029 where the only source is the vendor that absorbed it and the file says so.

What we are not doing is filling the gap by inference. This desk could write a plausible-sounding file asserting that some 2024 breach "likely began with credential stuffing", and it would be indistinguishable from the ones where somebody actually said so. That trade — coverage for reliability — is the one thing the database cannot afford.

The corpus already refuses attacker-supplied volumes, unconfirmed ransom payers and researcher dossiers naming people who have not been convicted. An unsourced vector is the same category of claim.

The reader was right that the coverage looks thin, and wrong about what it means. It does not mean SQL injection is rare. It means the disclosure regime records who was affected and not how, and that a database built from disclosures inherits that shape whether or not it wants to.

We would rather the 42.8% were visible than smoothed over. A corpus that reported a vector for every file would be more useful and less true, and any reader could tell the difference eventually — usually at the worst moment, when they went to cite it.