Here is a ransomware trend that is becoming more frequent in 2026: The same victim organizations are posted twice, under two different flags. This is occurring frequently enough that we stopped treating it as a curiosity and went looking for the why behind this trend. We expected one answer, but we found at least five.Our team discussed this increasing trend during our Ctrl-Alt-DECODE ep. 10 livestream and in our monthly Threat Debrief, which ranks the most active ransomware groups and recent ransomware news. Now, let's take an in-depth look.
Two ransomware groups can claim the same victim for numerous reasons.
It can be a cartel crediting one break-in to two brands, an unpaid affiliate recycling old data for a second shakedown, or a newcomer inventing victims to look dangerous. But the most common explanation is also the least glamorous: an organization got breached, never fixed what let the attackers in, and got breached again.
These are different stories that demand different responses, and telling them apart is a significant challenge.
Before we share figures, here is a constraint worth stating plainly. The dataset examined here is a deliberately curated collection of confirmed duplicate claims, assembled specifically to study the phenomenon, not a random sample of all ransomware victims. Nothing in it supports a claim about how often these mechanisms occur in the broader population.
The attribution is each group's own self-labeling on their leak sites, which is the very thing this piece argues is unreliable. And the dates are posting dates, not breach dates: the gaps we measure between first and second claim are publication intervals, not confirmed re-compromise intervals. Despite the limitations, this data tells us something about mechanisms, timing patterns, and group relationships.
Across five months of tracking, we documented 98 individual leak-site claims covering 49 distinct victim organizations. Every victim was claimed by exactly two different group names; none showed up under three or more.
We did victim matching on both organization name and root domain, to catch the same organization listed under slightly different domain variants (for example, .com vs .de) or posted by its two groups under different domains entirely.
The median gap between first and second claim was 12 days, mean time was around 23, with a tail reaching 96. Five cases landed on the same day; 16 within the first week; 12 in the 8-to-30-day band; 16 cases fell at 31 days or beyond.
The non-simultaneous profile is the first structural observation: whatever generates these duplicates, it is mostly not two groups posting simultaneously from the same access. And the directional handoffs are not random. A group we track as Beast appeared before Qilin three times. A group we track as The Gentlemen did the same. Devman appeared before DragonForce three times. These are patterns where there should be noise.
Graph: Days between a victim’s first and second leak-site appearance. Median gap is 12 days. Source: Bitdefender leak-site tracking, Jan-June 2026.
Sometimes the two group names are not two groups at all. They belong to a single operation, and the victim shows up twice because two brands inside the same criminal network each posted the same break-in. It is one attack, counted twice.
The DragonForce cartel model is a current example. When RansomHub went offline, and its affiliates needed a place to land, many migrated to the DragonForce infrastructure. Qilin, which accounts for 20 of the 98 claims in our set, exhibits a gravitational pull consistent with the absorption of displaced affiliates from other programs.
Its April 2025 spike to 71 victims in a single month was closely correlated with a new partnership announcement. The directional Devman to DragonForce handoff, which appears three times in our data, reads less like two independent operators targeting the same victim and more like affiliate movement through a shared network, with each posting generating a separate leak-site entry (Bitdefender Threat Debrief, May 2025).
The clearest confirmed rebrand in recent memory is Hunters International becoming World Leaks. Technical infrastructure, code, extortion playbook: all carried over (Group-IB, “Hunters International”, 2025). A victim appearing under both names is not two separate extortion events. It is one organization cycling through a naming change, and the public statistics that count them as distinct groups inflate accordingly.
The victim’s practical problem with this explanation: There is one underlying incident, one set of stolen data, and one negotiation decision to make. Treating it as two separate attacks and responding twice is not just inefficient. It is analytically wrong.
Sometimes there is only one break-in, but the stolen data gets listed a second time by someone chasing another payday. The affiliate model that makes ransomware scalable is what produces this example. Affiliates handle the access work. The core program provides the locker, the negotiation infrastructure, and the leak site. In exchange, affiliates receive a cut of ransom payments. When that payment does not arrive, some affiliates move the data elsewhere.
The Change Healthcare case is a reported version of this scenario. An affiliate who worked the breach through ALPHV/BlackCat allegedly did not receive their share after the victim paid. The same data reportedly then reappeared via RansomHub (The Register, April 2024). Whether the specific causal chain is confirmed matters less than what the scenario implies structurally: a single stolen dataset can generate two distinct extortion attempts, under two distinct group names, separated by weeks.
The timing signal in our data is consistent with this mechanism. The 1-to-30-day time band accounts for 28 cases combined, and sequential re-listing fits that profile better than a simultaneous broker sale to two independent buyers. Parallel operations from independently purchased access would more likely produce near-simultaneous postings. Staggered postings point toward a handoff.
The victim’s practical problem in this case: Paying the first group does not bind the second. The data is already in a different threat actor’s hands. A second payment buys compliance from the second group, not closure on the underlying exposure.
Sometimes, both claims are real: two genuinely separate break-ins of the same organization. The version we see most often in the field is also the most uncomfortable. A company is breached, treats it as a one-off to clean up, and never absorbs the broader lesson about why it was exposed.
Months later, a second, unrelated group finds the organization's environment just as open as the first group did. Sometimes threat actors enter through the same door, sometimes through a different door, but one that was always just as unlocked as the first.
We cannot read root cause directly from posting dates, but we can observe that 16 of the 49 cross-group cases show a gap of 31 days or more between first and second claim.
What we often discover during the incident response work is that it’s rarely a single missed patch that caused a security breach. It is an organization that fixed the one thing that was exploited and changed nothing else: the breached credentials rotated but not the hundreds beside them, multi-factor authentication promised but never deployed, monitoring that still cannot see the part of the network both groups walked through. Sometimes the lesson learned is the wrong one entirely, a new tool bought to stop last quarter’s exact technique while the conditions that made the company easy (weak identity controls, flat networks, no detection) remain untouched.
Access brokers add another mechanism within this bucket. A single set of valid credentials, purchased from a broker who acquired them during the first breach, can be resold to multiple buyers (Bitdefender IAB role study, 2024). Each buyer runs an independent operation. The victim then appears under two flags because two separate groups purchased what amounts to the same key.
The practical problem for victims in this case: If the organization is no harder to breach than it was the first time, then paying the second ransom, making the same disclosures, and moving on is like planning for a third incident.
What distinguishes buckets one through three is that each involves real access at some point in the causal chain. The timing patterns differ. The group relationships differ. But somewhere, an attacker touched systems. The next category removes even that assumption.
Sometimes there is no break-in behind the claim at all. The group either invented the victim or copied it from someone else’s leak site.
Take 0APT. It surfaced in early 2026 with a burst of claims no real operation produces: 91 victims in 48 hours in late January, then 458 the following month (Bitdefender Threat Debrief, March 2026). In April, a rival group called KryBit breached 0APT’s own infrastructure and leaked the logs, settling the question of whether the group could legitimately claim these victims. It could not.
0APT’s leak site was being run from a mobile phone. Its download links were fakes that piped random data to anyone who clicked. The group did not have the infrastructure to support a single real attack, let alone hundreds (Ctrl-Alt-DECODE ep. 8).
Another example is LockBit’s behavior after Operation Cronos. This is a clear external illustration of deliberate fabrication for reputational purposes.
After law enforcement disrupted the group, LockBit posted purported Federal Reserve victim data. The data was actually from Evolve Bank. The false attribution is difficult to explain as a mistake (Unit 42, “Ransomware Leak Site Data Analysis”, 2025).
Dispossessor, another group, took a simpler approach: reposting existing Cl0p, LockBit, and Hunters International victim lists wholesale, with no original access required (
BleepingComputer, August 2024).The victim’s practical problem in this category: This inverts the repeat-victimization problem because, in this case, there may be no breach to remediate. The correct response is verification, not negotiation. Paying a group that fabricated a claim buys nothing, and treating a fabricated claim as a confirmed breach generates disclosures and crisis responses that produce their own damage.
When fabrication is common enough to appear in a carefully curated set, the statistics built on raw leak-site scraping absorb the noise without knowing they are doing it.
Here is what that looks like in numbers.
Scrape the leak sites for the first quarter of 2026 and you count 3,014 claimed ransomware victims, up about 15% from the 2,616 a year earlier. A clean, alarming headline: ransomware surged. Then remove a single group. 0APT, now confirmed fake, and its 549 claims. Strip that out, and the same quarter reads 2,465 victims, down roughly 6%. One fabricated brand is the entire distance between “ransomware surged” and “ransomware fell.” The noise did not just blur a number; it reversed a trend.
So, how does Bitdefender typically triage a situation when a second ransomware claim names your organization? Here's a decision chart that can help:
Chart: Disclosure is a legal judgment for counsel, not a conclusion this flow should reach. Its job is to get you to counsel, knowing which problem you actually have, and recommending the next thing to verify.
Here are some details to consider at each step of your evaluation.
Step 1: Is there actual proof attached, or are you just a name on a list? A group that posts a victim name without a data sample has demonstrated the ability to type, nothing more. And having no sample often points to fabrication or plagiarism. Verify before responding, and do not brief stakeholders as though a breach occurred until you have confirmed one actually has.
Step 2: If there is a sample, does it contain new data, or the same files from a previous leak? If it's the same data, this typically indicates re-extortion on new letterhead. This is the same breach. A second payment does not buy silence from an actor holding a distinct copy of the data, because there is no distinct copy.
Step 3: Is the second group connected to the first? Shared infrastructure, cartel relationships, quick succession measured in days rather than months? If yes, treat it potentially as one underlying incident and one negotiation. Two group names does not mean two decision-makers.
Step 4: This is where you have new data, shared by an unconnected group at a later timeframe. The question that matters is not whether you closed the door from last time, but whether anything about your security has actually changed since then. If the honest answer is no, this is repeat victimization, not primarily a data-handling problem, and the fix is the security program, not the single patch. If the organization did materially harden and was breached anyway through a different route, the most likely explanation is brokered access sold to an independent second buyer.
The timing offers a heuristic, not a rule. Same-day postings lean toward cartel structure or shared access. A days-to-weeks timeline leans toward affiliate churn and re-extortion. If claims are months apart, then you can lean toward repeat victimization. Use these heuristics to direct an investigation, not to close it.
Here are key takeaways from this blog:
First, whether this is a new breach or an echo of the old one changes everything about the technical response.
A security posture that has not actually improved is an open invitation for another incident.Second, paying one group does not bind another, since distinct actors holding distinct copies operate without a shared agreement.
Third, disclosure is a legal decision that requires counsel, not a conclusion a victim triage flow should reach. What the flow can do is help a victim arrive at counsel with a clearer picture of which problem category they are actually dealing with.
The rise of duplicate victim claims reveals a ransomware ecosystem that can be difficult to interpret. Understanding whether a second claim represents a new intrusion, recycled access, or outright fabrication is now a critical part of incident response. For defenders, context matters as much as the claim itself.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。