A new and rapidly expanding ransomware operation, dubbed VanHelsing, has emerged on the cybercrime scene. First observed on 7 March 2025, VanHelsing operates as a "Ransomware-as-a-Service" (RaaS) program, effectively licensing its malicious tools to other cybercriminals, known as affiliates.
This model, which requires new affiliates to pay a $5,000 deposit, allows for a rapid scaling of attacks. The operators offer a sophisticated, multi-platform locker that targets not only Windows but also Linux, BSD, ARM, and ESXi virtualization systems, significantly broadening its potential victim pool. Affiliates are provided with an easy-to-use control panel to manage their campaigns and keep 80% of any ransom payments. The service's only stated rule is a prohibition on targeting nations within the Commonwealth of Independent States (CIS) [1].
The operation has already proven effective. In less than two weeks since its launch, the group has successfully breached at least three known victims, issuing hefty ransom demands, with one negotiation reportedly involving a $500,000 demand.
Analysis of the ransomware itself, which is written in C++, reveals a tool under active and rapid development; two variants compiled just five days apart show significant updates. The ransomware is highly configurable, featuring extensive command-line arguments that allow attackers to fine-tune their assault. These controls allow for targeting specific drives, running in a "silent" mode, and systematically deleting shadow copies to prevent victims from easily restoring their data [1].
This blog post offers a comprehensive analysis of the VanHelsing ransomware, detailing its Ransomware-as-a-Service (RaaS) model and how attackers fine-tune operations using command-line parameters. We conclude with essential mitigation strategies and how Picus Platform helps defend against the VanHelsing ransomware campaign.
The VanHelsing locker is a C++ binary engineered for stability and efficiency during its destructive mission. Upon execution, the ransomware first attempts to create a named mutex, "Global\VanHelsing", to ensure that only a single instance of the ransomware is running on the victim's system at any given time. This is a standard practice to prevent multiple encryption processes from interfering with each other, which could lead to file corruption or incomplete encryption. If the mutex already exists, the new process will terminate. However, this check can be deliberately bypassed by the attacker using the --Force command-line argument, allowing for multiple simultaneous instances if desired.
To maximize its access to system resources and speed the encryption process, the ransomware is also designed to increase its own process priority. This instructs the operating system's scheduler to give the ransomware preferential treatment over other running applications, ensuring that the encryption task is completed as quickly as possible. This behavior can be suppressed with the --no-priority flag, likely for scenarios where an attacker wishes to remain more stealthy.
A debug artifact left within the binary provides a small but revealing glimpse into the developer's environment. A Program Database (PDB) file path was discovered, pointing to the location of the debug symbols on the build machine [1]:
|
C:\Users\ADMINI~1\AppData\Local\Temp\2\cd9563b4cbc415b3920633b93c0d351b\1-locker\Release\1-locker.pdb |
VanHelsing is not a monolithic, "fire-and-forget" ransomware. Instead, it is a highly flexible tool designed for hands-on keyboard attacks, where its behavior is precisely controlled through an extensive set of command-line arguments. This design empowers affiliates to tailor their attack methodology to the specific environment they have compromised, making the ransomware exceptionally versatile. An operator can choose to encrypt an entire local system, target only specific network shares, encrypt a single high-value directory, or disable features that might trigger security alerts.
Below are the most remarkable supported arguments of the ransomware and their functions [1]:
--Force: Allows multiple instances of the ransomware to run simultaneously (skips mutex creation).
--no-priority: If set, the ransomware does not increase the priority of its process.
--no-admin: Allows the ransomware to execute even if not running with administrative privileges.
--Silent: Silent ransomware process mode, implementing a two-stage encryption/renaming process.
--spread-smb: Enables spreading to SMB servers by copying and executing the ransomware from network shares.
--spread-vcenter: Likely intended to support spreading through a vCenter server. (Not implemented yet.)
The VanHelsing locker employs a modern and secure hybrid encryption scheme designed for both speed and irreversibility. The core of this scheme is an embedded Curve25519 public key hardcoded within the ransomware binary.
The file encryption process is executed as follows:
For each file targeted for encryption, the ransomware generates two random, ephemeral values: a 32-byte key and a 12-byte nonce.
The content of the file is then encrypted using the ChaCha20 stream cipher, a fast and secure algorithm, with the newly generated key and nonce.
To ensure the file can only be decrypted by the operators, the ephemeral key and nonce are themselves encrypted using the embedded Curve25519 public key. Only the holder of the corresponding private key can reverse this process. Below is the code part that generates random keys and encrypts them [1]:
|
ccRtlGenRandom_32_40EE80((int)rnd_buffer_32); |
4. The encrypted key and nonce are converted to hexadecimal strings and stored in the file, along with the encrypted file content. The final structure follows a specific format:
|
---key---$KEY_HEX---endkey------nonce---$NONCE_HEX---endnonce--$ENCRYPTED_CHUNKS |
To maximize the speed of the attack, especially on servers with large files such as databases, the ransomware incorporates a performance optimization. If a file is approximately 1 GB (0x3E800000 bytes) or larger, the locker does not encrypt the entire file. Instead, it encrypts only the first 30% of the file's content. For smaller files, the entire content is encrypted. The encryption itself is performed in chunks of approximately 1 MB (0x100000 bytes). Below is the code part that checks the file size and encrypts it accordingly [1]:
|
if ( file_size > 0x3E800000 ) 0, |
Beyond encryption, VanHelsing employs several techniques to sabotage recovery efforts and evade detection by security software. A primary anti-recovery measure is the systematic deletion of Volume Shadow Copies. These copies are Windows' built-in mechanism for creating point-in-time backups of files, and their removal is a critical step for ransomware to prevent easy restoration.
The ransomware accomplishes this by leveraging the Windows Management Instrumentation (WMI) service. It first initializes the Component Object Model (COM) and connects to the ROOT\\CIMV2 namespace. It then executes a WMI query to retrieve all instances of the Win32_ShadowCopy class. For each shadow copy found, it spawns a child process to execute a command that deletes the copy by its unique ID. The specific command used is [1]:
|
cmd.exe /c C:\\Windows\\System32\\wbem\\WMIC.exe shadowcopy where \"ID='%s'\" delete |
Perhaps the most remarkable feature is the --Silent mode, which is a deliberate tactical countermeasure against modern endpoint detection and response (EDR) and other behavioral analysis tools. Security products often use a scoring system to identify malicious activity; a process that performs heavy file I/O (encryption) and immediately renames those files is a major red flag that would trigger a high-score alert. The --Silent mode is designed to circumvent this by splitting the attack into two distinct stages [1]:
Encryption Stage: The ransomware first runs an encryption pass on the target files. In this stage, it reads the original content, encrypts it, and writes it back to the file, but crucially, it skips the file renaming step.
Renaming Stage: After the encryption is complete, a second function is called. This function's sole purpose is to iterate through the now-encrypted files and rename them by appending the .vanhelsing extension.
By separating these actions, the ransomware attempts to make each stage appear less suspicious in isolation. The first stage is I/O-intensive but lacks the highly suspicious renaming behavior. The second stage is a mass-renaming event, which might still be flagged, but by the time it occurs, the critical data encryption is already complete. This two-stage process demonstrates that the threat actors have studied how modern endpoint protection works and have engineered a specific bypass, indicating a higher level of sophistication and a commitment to evading defenses.
By default, the ransomware is designed to encrypt any connected network drives, a behavior that can be suppressed with the --no-network argument. The ransomware begins by getting the local hostname and IP address, then scans the local network for other machines running SMB by attempting to connect to port 445 on a range of IP addresses (1-255). For each active SMB server it discovers, the ransomware uses the NetShareEnum function to list available shared resources. It then proceeds to enumerate and encrypt the files and folders within those shares. Notably, when operating in "Silent" mode, files on network shares are encrypted, but their extensions are not changed to .vanhelsing, making the attack stealthier on network storage. Below is the code part that scans IPs for open SMB ports [1]:
|
ioctlsocket(socket, 0x8004667E, &v15); // non blocking socket |
When executed with the --spread-smb command-line argument, VanHelsing activates a more aggressive lateral movement capability. The ransomware contains an embedded psexec.exe binary, which it drops into the system's Temp folder. It scans for SMB shares on the network and checks for write permissions. To avoid disrupting critical domain services, the ransomware specifically excludes shares containing NETLOGON or sysvol from its encryption routine. Below is the code part that excludes NETLOGON and sysvol shares [1]:
|
while ( 1 ) |
Once a writable share is identified, the ransomware copies itself to the network share as $SHARE\\\\vanlocker.exe. It then uses the dropped psexec.exe to remotely execute the copy on the target server. The command used for remote execution is specifically crafted to control the behavior of the newly launched instance [1]:
|
cmd.exe /c $TEMP/psexec.exe -accepteula \\\\$SHARE -c -f $SHARE\\vanlocker.exe -d --no-mounted --no-network < NUL |
Based on the detailed analysis of VanHelsing, the following recommendations are provided for detection engineering and strategic mitigation.
Command-Line and Process Monitoring: Create high-fidelity detection rules for the specific parent-child process relationship and command-line arguments used for shadow copy deletion. Specifically, monitor for cmd.exe spawning wmic.exe with a command line containing shadowcopy and delete.
Indicator-Based Detection: Deploy endpoint detection rules to monitor for the creation of the specific mutex "Global\VanHelsing".
Network Traffic Analysis: To detect the --spread-smb activity, monitor for anomalous SMB traffic patterns, particularly from workstations to other workstations or servers over port 445. Look for attempts to write an executable file to shares, followed by remote service creation or execution attempts.
Backup and Recovery: The single most critical defense against ransomware is a robust and resilient backup strategy. Given that VanHelsing actively targets and deletes local Volume Shadow Copies, backups must be stored offline, on immutable storage, or in a logically and physically segmented network location. Regularly test data restoration procedures to ensure their viability in an emergency.
Network Segmentation: Implement a strong network segmentation policy to contain the blast radius of a potential infection. This is crucial for mitigating the threat of the --spread-smb lateral movement capability.
WMI Monitoring: Enhance monitoring of WMI activity. While WMI is a legitimate administrative tool, queries to the Win32_ShadowCopy class from non-standard administrative tools, user-context processes, or unsigned executables should be treated as highly suspicious and investigated.
We also strongly suggest simulating VanHelsing Ransomware Campaign Attacks to test the effectiveness of your security controls against real-life cyber attacks using the Picus Security Validation Platform. You can also test your defenses against hundreds of other ransomware variants, such as HybridPetya, Yurei, BlackNevas, and CyberVolk, within minutes with a 14-day free trial of the Picus Platform.
Picus Threat Library includes the following threats for the VanHelsing Ransomware Campaign:
|
Threat ID |
Threat Name |
Attack Module |
|
53854 |
VanHelsing Ransomware Campaign |
Windows Endpoint |
|
55633 |
VanHelsing Ransomware Email Threat |
Network Infiltration |
|
78861 |
VanHelsing Ransomware Download Threat |
Network Infiltration |
Start simulating emerging threats today and get actionable mitigation insights with a 14-day free trial of the Picus Security Validation Platform.
References
[1] “VanHelsing, new RaaS in Town,” Check Point Research. Accessed: Oct. 28, 2025. [Online]. Available: https://research.checkpoint.com/2025/vanhelsing-new-raas-in-town/