An extortion crew that appears to have breached nobody still named 61 organizations on its leak site, and every one of those victims had to work out whether the claim was real. Researchers at Recorded Future's Insikt Group found that the blog run by a group calling itself 0APT was advertising stolen data that had been fabricated with generative AI, which leaves defenders with an awkward new task: proving a negative.
Insikt Group reported the launch of the 0APT blog in late January 2026. The site claimed to run an affiliate program on a ransomware-as-a-service model and, as of 5 February 2026, listed 61 breached victims while stating that a further 115 across multiple countries and industries were still to be leaked. Insikt assessed that the ransomware was fake and the victim list was AI-generated.
The tells
- Several of the files uploaded as proof of theft were simply empty.
- The site showed low-quality development throughout, a mix of AI-generated scripts and unprofessional web work.
- Source code comments appeared in Hindi and Urdu, which points to operators in South Asia rather than the Russia and Commonwealth of Independent States base that most top-tier ransomware groups work from.
- The claimed pace, dozens of victims inside a few weeks, is what an established organized group produces, yet 0APT was simultaneously recruiting penetration testers with existing network access to join its affiliate program.
0APT is not alone. ReliaQuest flagged a second group, ALP-001, which surfaced in March with leak data that also looked machine-generated. Ransomware brands are quick to copy each other, and fabricated leaks are cheap, so the tactic is likely to keep spreading. It sits alongside the broader move of generative AI into criminal operations, from the large share of business email compromise now written by language models to AI-assisted tooling.
Why a fake leak still costs you
The point is not that 0APT or ALP-001 are formidable adversaries. It is that a low-credibility leak site generates real pressure anyway. When an organization is named, the first question is not attribution but classification: is this a genuine intrusion, a recycled dataset from an old breach, or an invention? Answering it burns analyst hours, legal review and executive attention inside an already compressed disclosure window. New leak sites arrive with large victim dumps often enough that the question comes up regularly, as with the crew that debuted with 28 claims at once.
Recorded Future's argument, set out in its analysis, is that answering the question quickly is a data governance problem as much as a security one. Extortion has already shifted from encryption, to encryption plus theft, to theft alone, because holding data hostage is easier than managing decryption keys. Verifying a claimed leak means knowing not just where your data lives but what format it is stored in and how it is protected, so an analyst can compare a sample against what a real export from your systems would look like. That extends to suppliers and partners, since a leak attributed to your name may have come from theirs.
What you should do
Decide now who classifies a leak claim and how, before your name appears on a blog. Keep an inventory that records data formats and storage locations, not just systems, and retain enough knowledge of legitimate export structures to spot a synthetic file. Where a claim touches a vendor, ask them the same questions. And resist the urge to confirm or deny publicly until the sample has been checked, because acknowledging a fabricated breach is its own incident.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.