In recent weeks, a new and rapidly expanding ransomware-as-a-service (RaaS) program called **VanHelsingRaaS** has been making waves in the cybercrime world. Launched on March 7, 2025, this service has already demonstrated its rapid growth and deadly potential, having infected three victims within just two weeks of its introduction. Reputable affiliates can join for free, while new affiliates must pay a $5,000 deposit to gain access to the program. After two blockchain confirmations of the victim’s ransom payment, the affiliates receive 80% of the revenue, while the remaining 20% is paid to the RaaS operators. Affiliates are provided with an easy-to-use control panel to manage attacks and a cross-platform locker, VanHelsing, which targets a wide variety of systems, including “Windows, Linux, BSD, ARM, and ESXi systems”.
This multi-platform support significantly broadens the reach of the ransomware, enabling it to target a wide variety of systems. In addition to the locker, affiliates are provided with a dedicated control panel that facilitates the management and execution of ransomware campaigns. However, there is one crucial rule: encryption of systems in CIS (Commonwealth of Independent States) countries is strictly prohibited in typical behavior observed in Russian cybercrime.
In less than two weeks since its introduction to the cybercrime community, this RaaS has already infected three victims, demanding large ransom payments for decryption and the deletion of stolen data. During negotiations, they demanded **$500,000** to be paid to a specified Bitcoin wallet.
The ransomware associated with the VanHelsing RaaS was first discovered on March 16, 2025. It is written in C++, and based on the compilation timestamp, the sample appears to have been deployed on the same day against the first victim targeted by this affiliate group. The ransomware accepts multiple command-line arguments that control the encryption process, such as whether to encrypt network and local drives or specific directories and files. It seems that the ransomware is still in its early stages of development, as some functionality appears to be incomplete. While log messages for these features are present, the actual actions associated with them do not seem to be implemented at this stage.
The ransom note dropped as `README.txt` on each enumerated folder, informs the victim that their network has been breached, and their personal data, financial reports, and important documents have been encrypted. The attacker demands Bitcoin for file restoration, warning that the use of third-party decryptors will result in permanent data loss. They warn that their encryption is unbreakable and that paying the ransom is the only way to recover the files. The note ends with an invitation to contact the attacker.
The ransomware contains two embedded images, which are dropped into the `C:\Windows\Web` folder. The `vhlocker.png` file is used to replace the victim’s desktop background with the RaaS logo, while `vhlocker.ico` is intended to associate the encrypted files, which have the `.vanlocker` extension, with the `.ico` file type. However, this is a flaw in the ransomware. The encrypted files are actually given the `.vanhelsing` extension, not `.vanlocker`, meaning the `.ico` file is not properly associated with the encrypted files.
The ransomware executable still contains the **PDB file path**, which provides some information about its development environment. This **PDB file** **path** includes the development path and project name associated with the malicious program, revealing details that could potentially help trace other projects developed by the same author.
In this particular case, the **PDB file** is located at the following path:
“`
C:UsersADMINI~1AppDataLocalTemp2cd9563b4cbc415b3920633b93c0d351b1-lockerRelease1-locker.pdb
“`
Based on this search, Check Point Research discovered two additional files: a second variant of the VanHelsing ransomware, compiled on **March 11, 2025**, which contains differences compared to the updated version from **March 16**. The second file, identified based on its PDB path, is an executable that loads an embedded binary into memory. However, the buffer associated with this executable contains no valid data, rendering the loader ineffective.
The **VanHelsing Ransomware** supports multiple **command-line arguments**, enabling attackers to fine-tune the encryption process based on their objectives. These arguments dictate various aspects of the ransomware’s behavior, including target selection, execution parameters, and stealth features. Below are the supported arguments:
`-h, Displays the list of supported command-line arguments and usage instructions for` `-v, Prints all logs during execution, providing detailed output for debugging or monitoring the ransomware’s actions.` `–no-logs, Suppresses the printing of logs during ransomware execution.` `–Driver $DRIVER, Specifies a target drive for encryption, allowing the ransomware to encrypt all files and folders on the selected drive.` `–Directory $DIRECTORY, Specifies a target folder for encryption, allowing the ransomware to encrypt all files and subfolders within the selected folder.` `–File $FILE, Specifies the single file to be encrypted.` `–Force, Allows multiple instances of the ransomware to run simultaneously. If the flag is not present, the ransomware attempts to create a mutex` `–no-priority, If the flag is not set, the malware increases the priority of its process, causing the system to prioritize the ransomware’s execution over other processes.` `–no-wallpaper, If this flag is set, the malware will not change the desktop background image.` `–no-local, If this flag is set, the ransomware will not encrypt any local files present on the machine, potentially limiting its attack to network drives, remote systems, or specific directories.` `–no-mounted, This flag ensures that the ransomware only encrypts` `DRIVE_FIXED) and excludes any remote or mounted drives, such as network shares or external storage devices.` `–no-network, When this flag is set, the ransomware will avoid encrypting network drives, focusing only on local drives or other specified targets.` `–no-admin, Allows the ransomware to execute even if the process is not running with administrative privileges.` `–Silent, Silent ransomware process mode; later we elaborate on this feature in more detail. For instance, files on network shares encrypted in this mode won’t have their extension changed.` `–skipshadow, When this command is specified, the ransomware skips the deletion of shadow copies, potentially leaving system backups intact.` `–spread-smb, Enables the ransomware to spread to SMB servers by copying and executing the ransomware from the network shares.` `–spread-vcenter, Not implemented yet, likely indicates that the malware would support a feature for spreading or propagating through a` `–no-autostart, Not implemented yet, possibly if this argument is not set, the ransomware would not configure itself to launch automatically when the system boots.` `–system, which has not been implemented yet. Currently, it simply prints “` `-v`
We have analyzed two samples of VanHelsing Ransomware, compiled five days apart based on their timestamps. The latest version introduces new command-line arguments and features. This suggests that the malware is actively being updated, and new arguments are likely to be introduced in future versions of the ransomware.
Shadow copies are backup copies of files or volumes created by Windows’ Volume Shadow Copy Service (VSS), often used for restoring files or recovering from system failures. Ransomware deletes shadow copies to prevent victims from restoring their encrypted files using Windows’ built-in backup mechanisms. By removing these backups, the attackers increase the likelihood that victims will have no choice but to pay the ransom for file recovery.
In the malicious binary, the function responsible for deleting shadow copies begins by initializing the **Component Object Model (COM)** through `CoInitializeEx` and `CoInitializeSecurity`, enabling interaction with system management services. It then determines the system architecture using `GetNativeSystemInfo` before creating an instance of the appropriate COM object via `CoCreateInstance`, ensuring compatibility with the target environment.
The malware connects to the `ROOT\CIMV2` namespace and executes a WMI query to retrieve all shadow copies stored on the local system using the `Win32_ShadowCopy` class. It allows the malware to access and manage the shadow copies. Then, enumerates through the retrieved shadow copies and creates child processes which delete them by shadow ID.
“`
“cmd.exe /c C:\Windows\System32\wbem\WMIC.exe shadowcopy where “ID=’%s'” delete”
“`
The ransomware’s local encryption routine requires obtaining the existing drives. Initially, it calls `GetLogicalDriveStringsW(0, 0)`, which returns the buffer size for the logical drive strings. Then, it calls the function again with the correct buffer size, obtaining a buffer with strings that specify valid drives in the system.
Once all drives on the machine are identified, the ransomware enumerates them, selecting only fixed local drives and mounted drives unless executed with the `–no-mounted` argument, in which case mounted drives are excluded from encryption.
The ransomware would later recursively enumerate and encrypt all files and folders on the selected drives, ensuring comprehensive data encryption across the targeted storage locations.
The ransomware begins the encryption process by enumerating folders and files using the Windows API functions `FindFirstFileW`, `FindNextFileW`, and `FindClose`. To prevent rendering the system completely unusable, it selectively excludes certain folders, files, and file extensions from encryption, ensuring that critical system components remain intact.
The files contained in the below folders are excluded from encryption:
“`
“tmp”, “winnt”, “temp”, “thumb”, “$Recycle.Bin”, “$RECYCLE.BIN”, “System Volume Information”, “Boot”, “Windows”, “Trend Micro”, “program files”, “program files(x86)”, “tor browser”, “windows”, “intel”, “all users”, “msocache”, “perflogs”, “default”, “microsoft”
“`
While the below file extensions and files are excluded from being encrypted for various reasons, mostly due to being critical for Windows functionality:
“`
“.vanlocker”, “.exe”, “.dll”, “.lnk”, “.sys”, “.msi”, “boot.ini”, “autorun.inf”, “bootfont.bin”, “bootsect.bak”, “desktop.ini”, “iconcache.db”, “ntldr”, “ntuser.dat”, “ntuser.dat.log”, “ntuser.ini”, “thumbs.db”, “GDIPFONTCACHEV1.DAT”, “d3d9caps.dat”, “LOGS.txt”, “README.txt”, “.bat”, “.bin”, “.com”, “.cmd”, “.386”, “.adv”, “.ani”, “.cab”, “.ico”, “.mod”, “.msstyles”, “.msu”, “.nomedia”, “.ps1”, “.rtp”, “.syss”, “.prf”, “.deskthemepack”, “.cur”, “.cpl”, “.diagcab”, “.diagcfg”, “.diagpkg”, “.dll”, “.drv”, “.hlp”, “.pdb”, “.hta”, “.key”, “.lock”, “.ldf”, “.ocx”, “.icl”, “.icns”, “.ics”, “.idx”, “.mod”, “.mpa”, “.msc”, “.msp”, “.nls”, “.rom”, “.scr”, “.shs”, “.spl”, “.theme”, “.themepack”, “.wpx”
“`
A similar mistake to the one previously mentioned regarding the `.ico` file association occurs in the blacklist of excluded file extensions. The ransomware mistakenly excludes `.vanlocker` files from encryption, even though the actual encrypted files use the `.vanhelsing` extension. This oversight means that if a second instance of the ransomware runs, it could encrypt already encrypted files again, leading to double encryption.
By default, the ransomware will attempt to encrypt any connected network drives, unless the `–no-network` command-line argument is specified. The function responsible for encrypting the network drives runs as a separate thread.
Initially, retrieves the local hostname and its corresponding IP address, then proceeds to scan a range of IP addresses [1-255). For each IP address in the local network, the thread will attempt to connect to port 445, identifying which machines on the local network are running SMB.
For each running SMB server, the ransomware will call `NetShareEnum` and proceed to construct a network path to access a shared resource on the remote machine. Then, the ransomware continues with folder and file enumeration, followed by encryption. It is worth mentioning that in “Silent” mode, network shares will have their files encrypted without the extension being changed to `.vanhelsing`.
If the ransomware is executed with the `–spread-smb` command-line argument, it still encrypts network shares, but the approach differs from the one mentioned above. The ransomware contains an embedded `psexec.exe` binary, which is dropped into the Temp folder. Similar to network encryption, the malware will scan for SMB shares and try to determine if the share has write permissions. Network shares containing `NETLOGON` or `sysvol` are excluded from encryption, as encrypting them could potentially interrupt user authentication.
VanHelsing locker will copy itself to the network share as `$SHARE\\vanlocker.exe`. Executing `psexec.exe` will trigger the ransomware process on the network share, which will then proceed to encrypt the files. The ransomware on the share will execute without encrypting mounted or other network shares. Below are the execution arguments:
“`
cmd.exe /c $TEMP/psexec.exe -accepteula \\$SHARE -c -f $SHARE\vanlocker.exe -d –no-mounted –no-network