What if you paid the ransom and your data was still destroyed?
For many organizations, this is the nightmare scenario: you think you’ve negotiated your way out of a ransomware attack, you’ve paid the ransom demanded, and you’ve waited for the promised decryption tool. But when you think your data is safe and the ordeal is finished, you discover your data is still lost.
This isn’t always because of bad faith or deliberate betrayal. When ransomware developers engage in internal conflicts, they often steal or leak each other’s tools. As a consequence, these compromised tools often reach inexperienced criminal affiliates who lack the technical expertise to properly implement them. This creates an environment where these operators can successfully deploy ransomware attacks and encrypt victims’ data, but cannot reliably decrypt it afterward, even if they intend to honor ransom payments. The result is a breakdown: the technical skills needed to launch attacks have become separated from those required to reverse them, leaving both criminals and victims unable to recover encrypted data despite successful extortion attempts.
The VanHelsing ransomware leak is an exemplary study of this problem. It shows why simply planning to ‘pay and recover’ isn’t a real or reliable strategy, and why true data resilience depends on secure, reliable backups and incident preparedness, not the promises of criminals. It also highlights the need for companies to engage incident response firms that have the in-house capability via tools and personnel to spot these issues before a decision path is made to acquire a decryption tool from a cyber criminal. Paying a ransom is a decision of great consequence, and if the end result is unfavorable, yet forecastable, an unnecessary ransom payment can be avoided.
Who is VanHelsing?
VanHelsing is a relatively new but telling example of how Ransomware-as-a-Service (RaaS) evolves.
Launched in March 2025, VanHelsing quickly established itself as another plug-and-play option for threat actors who lack the skill or patience to develop their own malware. Like other RaaS operations, VanHelsing provides a turnkey model. Core developers build and maintain the ransomware infrastructure, then recruit affiliates to carry out attacks in exchange for a cut of the ransom. Affiliates don’t need coding skills, encryption knowledge, or any significant resources; all they need is access to the service and a willingness to extort.
Key characteristics of the VanHelsing operation
- Broad platform support, including Windows, Linux, BSD, ARM architectures, and ESXi systems. This cross-platform capability expands the attack surface and gives affiliates flexibility to choose high-value targets.
- Known Activity. At least eight confirmed victims so far, spanning multiple industries. (This is likely an undercount, given that many incidents go unreported or are negotiated quietly.)
- High-Value Focus. VMware ESXi servers are a prime target. ESXi hosts are central to many enterprise environments, running numerous virtual machines on a single server. An ESXi attack can cripple entire lines of business at once, making organizations more likely to pay ransom demands.
VanHelsing’s approach reflects a broader, troubling trend in ransomware: commoditization. Instead of requiring the expertise of sophisticated planning or social engineering, these services enable low-skill affiliates to deploy highly destructive attacks with minimal effort.
For defenders, this changes the risk calculation. Ransomware no longer comes only from well-funded, highly technical groups. Even if it is loosely organized, amateurish crews can inflict catastrophic damage. The barrier to entry has fallen dramatically, meaning more attackers, more attacks, and greater unpredictability for security teams to manage.
The Leak That Exposed VanHelsing
Rather than gaining notoriety solely for its attacks, VanHelsing has become a cautionary example of the disfunction and immaturity common within many ransomware operations.
The incident began when one of VanHelsing’s own developers attempted to sell the group’s source code on the underground RAMP cybercrime forum. This sale was advertised as a package that included the affiliate panel, data leak Tor site components, and builders for both Windows and Linux encryptors, with a price tag of $10,000 USD.
While there is opacity in the details, it is evident in their response that core VanHelsing operators were blindsided and infuriated. Through a scorched-earth response, these operators publicly leaked the source code themselves on the same forum to sabotage the rogue dev’s sale. Their announcement made clear this was retaliation, and they accused the seller of attempting to scam buyers with stolen code.
Critically, the leak did not include the Linux encryptor builder or complete backend databases. This omission limited its immediate value for would-be attackers, though it did create significant security exposure.
When Coveware by Veeam’s technical experts analyzed VanHelsing’s leaked code, a few details emerged:
- Visual Studio project files were carelessly stored in the “Release” folder, typically used for compiled binaries, suggesting sloppy development practices.
- The codebase was incomplete and disorganized, requiring modification to function properly.
- The builder does not require connectivity to a live affiliate panel to complete the build process — it can function entirely offline. However, the panel’s source code was also included in the leak.
In effect, the leak exposed VanHelsing’s entire RaaS model, demonstrating how affiliates built payloads, managed victims, and executed extortion campaigns. In doing so, it laid bare the group’s technical limitations and internal dysfunction.
Leaked Builders are a Broader Problem
This episode highlights a key truth about many ransomware groups: they are not highly disciplined criminal enterprises with robust software engineering practices. They’re often loose networks of individuals whose internal disputes can spill into public view, leaving behind flawed and dangerous code for anyone with the means to repurpose.
To punctuate this phenomenon, let’s note that VanHelsing’s leak isn’t an isolated incident. Ransomware source code leaks have repeatedly transformed how the game is played by putting powerful tools into more hands.
Briefly, some notable examples include:
- Babuk (2021), where a leaked builder fueled widespread ESXi attacks.
- Conti (2022), where an internal breach led to public leaks used by other gangs.
- LockBit (2022), where a builder leak enabled rapid imitation and evolution.
Historical leaks have enabled less-skilled criminals to build and distribute ransomware quickly. But this proliferation comes at a cost to code quality, which degrades as affiliates tweak it for new variants, introduce mistakes, or cut corners to deploy attacks faster.
For defenders, understanding this dynamic is crucial. These are not professional software companies, but instead are volatile, opportunistic crews whose tools may be effective enough to cause massive damage, but so poorly built that recovery, even with a paid ransom, is far from guaranteed.
Broken Encryption Destroys Data
This brings us to perhaps the most important lesson from the VanHelsing case: the risk of irreversible data destruction, even in scenarios where a victim pays the ransom to acquire a presumable effective decryption tool.
VanHelsing’s encryptor code is notably flawed. Reverse engineering of samples showed that its encryption routines are riddled with bugs, particularly in how they handle large-scale server environments like VMware ESXi. These flaws mean that, during an attack, the ransomware may write encrypted data to the wrong locations, overwriting data that hasn’t yet been encrypted. The result is irreparable damage to the file, that even an accurate decryption tool cannot fix.
Image: Screenshot of a text file that has been corrupted by VanHelsing after being encrypted, then decrypted using VanHelsing’s decryptor.
Reverse-engineering insights:
- Critical flaws in encryption logic. The ransomware writes to incorrect file offsets, destroying unencrypted data in the process.
- No transaction-safe design. There’s no mechanism to verify that the encrypted output can be cleanly reversed. Once corruption happens, it is permanent.
Further, Coveware by Veeam analysis confirmed that in the Windows version of VanHelsing, some of these problems appeared partially fixed. But on ESXi — again, one of the most lucrative targets — the encryptor remained catastrophically broken, meaning there will almost certainly be significant data loss to virtual machines and environments.
Even sophisticated groups rarely achieve 100% decryption. If the 1% they can’t decrypt is your critical data, you’re out of luck. Organizations can’t rely on threat actors’ professionalism or honesty, and they certainly can’t count on their technical competence. When data is encrypted by a threat actor, there is an overwhelming incentive to expect at least a portion of that data will be forever lost.
What This Means for Defenders
For CISOs and security leaders, the VanHelsing case is a direct warning about the current threat landscape and what defenses must adapt to address. More than ever, the game is dictated by ease of access to powerful attack tools. Leaked source code for builders, affiliate panels, and encryption routines are all widely available on underground forums. These tools are marketed as ready-to-use packages for buyers with little to no technical background.
The democratization of ransomware development means attackers are often unskilled, unpredictable, and careless. Their aim is not to carefully negotiate with their victims nor maintain a reputation of reliability; many simply want fast, one-time payouts, regardless of whether the victim’s data was ever able to be recovered.
More than malware, encryption itself has become a destructive weapon. When code is buggy, as with VanHelsing’s ESXi-targeting routines, encryption can permanently corrupt data beyond recovery even for the attacker.
This shifts the mindset from focusing solely on prevention to building true operational resilience that anticipates and can absorb these worst-case outcomes.
Key defensive priorities for security leaders:
- Don’t count on threat actors for recovery. Paying the ransom isn’t a dependable strategy. Even with the best intentions, criminals may not be able to restore what they encrypted.
- Recognize the limits of incident response and insurance. Incident response firms and insurance coverage are critical components of a security program. However, they can’t restore data that’s been irreversibly corrupted. Insurance can help with costs, but not with lost business operations or reputational damage. Competent IR firms, such as Coveware by Veeam can detect corruption before ransom payment decisions are made.
- Invest in secure, tested, and resilient backups. This is the foundation of ransomware defense. Backups must be frequent, immutable, offsite or air-gapped, and regularly tested to ensure full, reliable restoration when needed.
- Harden critical systems like ESXi. ESXi servers remain a prime target. Organizations must apply best-practice hardening, including strong authentication, network segmentation, restricted management access, timely patching, and continuous monitoring for signs of compromise.
Ultimately, real resilience is proactive, not reactive. Organizations will only be ready for compromise when their environment assumes that compromise is possible — and ensures that business operations can continue and recover even when attackers use dangerous, flawed, or destructive tools.
For analysis on the most prolific ransomware threat trends in Q2 2025, read more here.
The post Dangerous Tools in Clumsy Hands: Lessons from the VanHelsing Ransomware Leak appeared first on Veeam Software Official Blog.
from Veeam Software Official Blog https://ift.tt/ZdiJgTu
Share this content: