BreachSense Still Lists Capgemini As A February 9 0APT Victim. KryBit Leaked The Access Logs Proving It Fake On April 14. The Real 2024 Breach Goes Uncatalogued. Assume Breach Cuts Both Ways.

# BreachSense Is Still Listing Capgemini As A February 9, 2026 Victim. The Access Logs Proving It Fake Have Been Public Since April 14. The Real Capgemini Breach Capgemini Never Acknowledged Is The Bigger Bug. Assume Breach Cuts Both Ways.

Someone using BreachSense's free breach-monitoring service today sees Capgemini listed as a February 9, 2026 victim of the 0APT ransomware crew. The page is live as of this hour. There is no retraction, no footnote, no editor's note. The claim was proven fabricated thirty days ago by KryBit's leak of 0APT's own infrastructure — including the access logs that documented every victim claim 0APT had ever posted.

The aggregator has not updated. That is the surface bug. There is a worse one behind it.

This post walks both. We will name the structural problem at the end.

What the access logs actually proved

On April 14, 2026, the rival ransomware crew KryBit breached 0APT's panel infrastructure, exfiltrated the full operational data set — PHP source code, system files, full access logs — and posted it on KryBit's own leak site as a defacement. The leak settled a turf war. It also handed defenders a forensic gift.

Halcyon, GuidePoint Security, Kela, BankInfoSecurity, CyberScoop, and Infosecurity Magazine all published analysis on the leak between April 15 and late April. The findings converged:

• All 190+ victims 0APT claimed between January 28 and February 4, 2026 — Capgemini included — were fabricated. No data was ever exfiltrated from any of the listed targets.

• The "file trees" 0APT posted to make victim entries look credible were 20+ GB text documents containing random bytes piped from /dev/random. Not encrypted data. Not real exfiltrated files. Random noise reformatted to fill a browser.

• "Payment Verified" badges remained displayed on still-published victims, contradicting standard ransomware-crew behavior (paid victims get removed). The badges were brand decoration, not extortion mechanics.

• Some victim names were AI-generated and pasted alongside real businesses to inflate the perceived target list.

• In at least two cases that researchers verified directly with the alleged victims, the victims confirmed zero intrusion after their own DFIR analysis.

0APT had a functioning ransomware (Windows and Linux variants, RSA-4096 full-file encryption, RaaS panel). It did not have the victims. The whole January batch was a brand-building stunt aimed at affiliate recruitment.

That batch included Capgemini.

Why BreachSense is still carrying the entry

The aggregator's business model runs on raw claim volume. The freemium-to-paid conversion pitch is "comprehensive coverage" — every breach claim catalogued and searchable. Auditing the data after the fact to remove debunked entries shrinks the offer and exposes that "monitoring" was always cataloguing-without-verifying.

We are not picking on BreachSense specifically. We checked seven breach-tracking pages this evening. BreachSense is the only one we confirmed currently carrying the February 9 0APT/Capgemini entry as a live claim. Other pages that surface in the same search results — CyberInsider, Hedgehog Security, Technijian, CapacityGlobal, CertPro — are covering the older September 2024 "grep" event, not the Feb 9 0APT claim. The aggregator-persistence problem is real but narrower than the rant about it suggests; the structural critique still applies to the category.

The structural critique is this: breach aggregators treat actor-claim plus victim-silence as confirmation. They do not apply assume-breach symmetrically. They produce a one-way ratchet from claim to catalogue, with no verification gate in front and no audit gate behind. Whether the claim is real or fake, once it lands in the corpus it stays.

The bigger bug — September 2024 grep, which is real and never acknowledged

The September 2024 leak by the threat actor "grep" is a different shape entirely. That one happened. Twenty gigabytes of Capgemini data hit BreachForums — source code, private keys, API keys, employee data, client cloud configurations, and log files from virtual machines belonging to T-Mobile Europe (later clarified: not T-Mobile US). The data was real. Multiple researchers downloaded and analyzed samples. Capgemini was given the opportunity to deny it. The company has not — eight months later, no public statement confirming or denying the compromise.

Under GDPR's seventy-two-hour notification requirement to CNIL, a confirmed breach affecting EU subjects would trigger a public regulatory notice. We have not found such a notice. Either Capgemini concluded the breach was not material enough to trigger notification (which is a defensible reading depending on the data classification), or they concluded notification was required but chose a path that does not produce a public artifact (which would be a worse story), or the breach happened in a way that legally falls outside the notification trigger (also possible). We do not know which. Capgemini's silence is the catalog entry that should exist.

This is the version of "assume breach cuts both ways" that matters. When an actor with a real intrusion publishes evidence, the burden of denial sits on the named target. Silence is information. The breach-aggregator industry catalogs the easy half — claim plus silence equals listed — but it does not catalog the harder half: confirmed exfiltration plus continued silence equals unanswered. The second pattern is worse than the first because the data is real and the obligation to disclose is real.

How we got here in ninety minutes

Tonight's chain started with a single zero-result query on our own search endpoint. A practitioner searched our blog for capgemini and got nothing. We checked. We did not have a Capgemini post. We drafted one and published it. Forty minutes later we double-checked the February 2026 event against the KryBit access-log leak and discovered we had treated a fabricated claim as a real event. We walked the chain backward, named our own overclaim in this follow-up, and surfaced the deeper finding about the September 2024 silence.

The methodology is replicable. Anyone can do it. The five-minute MSP confirmation pass we added to our own playbook tonight produces the right answer if it includes a bluff-claim-actor flag and an access-log corroboration check. The reason aggregators do not produce the right answer is not that the methodology is hard. It is that the methodology shrinks their corpus and exposes their pitch.

What we are doing about it

We are not yet shipping a breach-tracking service. When we do, it will carry verification depth that the category currently lacks. The 5-minute confirmation pass, the bluff-claim-actor flag, the access-log corroboration check, the regulator-filing cross-reference, and the silence-as-information audit are the methodology layers. Each is a small lift; together they are the discriminator.

Until then, the receipts tonight are this: Capgemini was not breached on February 9, 2026 by 0APT. Capgemini was breached in September 2024 by "grep" and has never publicly acknowledged the event. BreachSense has one of these stories wrong by inclusion and is missing the other by omission. The category as a whole is doing the same thing.

Assume breach cuts both ways. Our publishing posture is going to apply it symmetrically. The aggregator category should too. Until they do, we will keep walking the chain.

— Patrick Duggan, May 12, 2026

---

Her name was Renee Nicole Good.

His name was Alex Jeffery Pretti.