Dire Wolf Ransomware: Threat Combining Data Encryption and Leak Extortion
DireWolf Ransomware Group
The DireWolf ransomware group made their first appearance in May 2025. On May 26 of the same month, they disclosed their first 6 victims on a darknet leak site, marking the beginning of their full-fledged activities. The group stated that their only goal is money and contacts their victims through the Tox messenger. Their targets come from a variety of industries, including manufacturing, IT, construction, and finance in Asia, Australia, Italy, and others. They use a double extortion technique that involves both encrypting data and threatening to leak it. So far, 16 organizations in 16 regions have fallen victim to their attacks, including the United States, Thailand, and Taiwan.
Figure 1. DireWolf victim board
Analysis Details
Figure 2. DireWolf execution flow
DireWolf controls its operations based on command-line arguments without a configuration file. The -d argument can be used to specify a specific directory as a target, and the -h argument prints the execution help. After processing the arguments, an initial protection check is immediately performed. This check uses the system-wide mutex Global\direwolfAppMutex to determine whether the program is already running, and it also checks for the presence of the encrypted completion marker, C:\runfinish.exe, to identify whether the system has already been processed. If either of these conditions are met, the program immediately halts further execution, logs the event, and then calls its self-deletion routine to remove the executable and terminate.
Conversely, if the condition is met, the pre-processing routine is launched and then a worker pool is configured after a 2-second delay. The size of the worker pool is managed as a global variable, and a number of goroutines equivalent to 8 times the number of logical CPUs are concurrently injected to process the target path in parallel. This design maximizes throughput by filling the I/O wait time with other tasks, but depending on the system, it can significantly increase CPU usage and the disk queue, leading to performance degradation and service delays.
Ransomware applies various anti-recovery techniques to maximize the success rate of file encryption. First, it reduces analysis traces through self-deletion and deletes event logs and backup-related data, making incident analysis and system recovery difficult. The running Windows event log service (eventlog) identifies the process ID through a WMI query (Get-WmiObject -Class win32_service -Filter “name = ‘eventlog'”) and then forcibly terminates it with the taskkill command.
This process is not a one-time event but is performed in the form of ① checking the event log process ID → ② force closing it → ③ waiting for a certain amount of time and repeating the same procedure. This means that even if the eventlog service is restarted, it is periodically explored and terminated, so log collection remains blocked.
Figure 3. Part of the infinite loop function that deletes event logs
They also used the command prompt to completely delete system restore points (shadow copies) and delete scheduled backup tasks and metadata. For example, the vssadmin delete shadows /all /quiet command can be used to delete all volume shadow copies, and the wbadmin command can be used to stop running backup tasks (wbadmin stop job -quiet), perform system status backups, and delete all backup versions (wbadmin delete backup -keepVersions:0 -quiet). They used the bcdedit /set {default} recoveryenabled No command to disable the Windows Recovery Environment (WinRE) and the bcdedit /set {default} bootstatuspolicy ignoreallfailures command to prevent recovery mode from being entered when booting fails. Afterward, they used the wevtutil cl command to delete the major event logs, including the Application, System, Security, and Setup logs.
Figure 4. List of recovery commands
Furthermore, the ransomware terminates specific processes in advance to disrupt the normal recovery procedures before encrypting files. The targets include databases (MSSQL, Oracle), mail servers (Exchange), virtualization platforms (VMware), backup software (Veeam, Veritas BackupExec), and security solutions (Symantec, Sophos). Major examples include sqlservr.exe, vss.exe, memtas.exe, tomcat6.exe, onenote.exe, and outlook.exe. This aims to disable processes related to data storage, management, collaboration, and security, thus preventing recovery and normal operation.
Additionally, various services are targeted for termination to render recovery and security features powerless. Identified services include BackupExecJobEngine, SQLSERVERAGENT, wuauserv, VeeamTransportSvc, and MSExchangeIS, which play a crucial role in backup management, database operation, Windows update, virtualization resource management, and mail server operation. The termination of these services not only involves the deletion of recovery points and disabling of backups, but also simultaneously renders monitoring and security features powerless, maximizing the effects of detection evasion and analysis disruption.
In the pre-encryption phase, the malware forcibly terminates processes and services related to backup, security, database, and email servers to prevent recovery. It then executes the actual encryption routine. The encryption process differs based on the arguments provided when the ransomware is executed. If the -d argument is provided, the malware only traverses the specified directory and its subdirectories. If no argument is provided, it targets all connected local and network drives except for CD/ROM drives. During the target directory exploration process, encryption exception conditions are applied. This includes essential folders for the operating system and recovery such as AppData, Windows, Program Files, $Recycle.Bin, and system volume information. It also includes system paths such as bootmgr, ntldr, and NTUSER.DAT, and file names such as HowToRecoveryFiles.txt. Additionally, certain file extensions are excluded from being encrypted, such as executable files (.exe), libraries (.dll), drivers (.sys, .drv), and images (.iso, .img). These exceptions are in place to ensure that the system remains operable after encryption. This allows the ransom note to be displayed and enables the victim to proceed with the payment process.
First, a random-based private key is created to generate an independent encryption key for each file. This key is then used to perform the Curve25519 key exchange operation with the DireWolf public key that is hard-coded in the malware. The shared secret generated through this process is put through the SHA-256 algorithm to be used as the encryption key, and the same encryption value result is processed again to derive the nonce value. This key-nonce pair is used as the input for the ChaCha20 stream cipher algorithm during the encryption process. ChaCha20 is known for its high speeds and suitability for processing large amounts of data. DireWolf also applies encryption strategies based on the file size. Small files under 1 MB are fully encrypted, while large files over 1 MB have only the first 1 MB segment encrypted. This method provides a similar level of protection to full encryption while significantly increasing the processing speed. This approach is designed to allow the threat actor to damage as many files as possible within a short time frame, reducing the possibility of recovery and strengthening their negotiation position.
Figure 5. Encryption structure
After all encryption processes are completed, the ransomware performs post-processing. First, the malware creates an empty marker file in the C:\runfinish.exe path to record the completion status of the encryption process. This marker is used as a checkpoint to prevent the duplication of encryption in the same system and to prevent unnecessary re-encryption from occurring. Then, the cmd /c start shutdown -r -f -t 10 command is called to schedule a forced reboot 10 seconds later. The -r flag is used to reboot the system, the -f flag is used to forcibly terminate all running user processes, and the -t 10 option is used to add a 10-second delay, minimizing the time available for users to respond. When executed, the start command separates the process into a separate process context, allowing the reboot command to be executed independently even if the main process is terminated.
Regardless of whether the reboot is successful or not, the self-deletion routine is always executed. Specifically, it involves using the timeout /T 3 command to wait for 3 seconds before executing the del command. This also involves invoking cmd.exe as a separate process and executing it asynchronously. As a result, even if the system is actually rebooted, the process continues to run and triggers self-deletion, removing the malicious executable from the disk. This makes it difficult for security personnel or analysts to collect samples from the site after a reboot, and it also becomes challenging to obtain the original malware file during the forensic analysis process.
The ransom note is created under the name “HowToRecoveryFiles.txt”. As the ransom note is created in the path after the encryption process of a specific folder is completed, a ransom note is created in all folders on the system.
Figure 6. Ransom note
The ransom note includes a hard-coded roomID and username, which are the names of the affected company, showing that a breach had already occurred against the company before the ransomware was executed. The threat actor also uploaded some of the leaked files to a free file-sharing site, allowing them to be accessed and using this as a means of proving that the data had actually been stolen and threatening the victim.
Conclusion
Despite being a newly emerged group in May 2025, DireWolf has been actively launching attacks against companies worldwide. They pose a high threat to any organization with vulnerable systems, regardless of the industry, including manufacturing, IT, construction, and finance. Technically, DireWolf performs file encryption by combining Curve25519-based key exchange with ChaCha20 stream encryption. In this process, a random session key is generated for each file, and the threat actor’s hard-coded public key and shared secret are used to derive the encryption key. The key is then passed through SHA-256 and used as the encryption key and nonce, ultimately giving the affected file the .direwolf extension. This design effectively blocks all known decryption methods, leaving victims with no means of recovery other than negotiating with the threat actor. DireWolf also goes beyond file encryption by actively employing anti-recovery and anti-analysis techniques. It proactively terminates backup and restoration processes and services (such as Veeam, Veritas, MSSQL, Exchange, and security solutions) and deletes event logs and disables recovery environments using the wevtutil, wbadmin, and bcdedit commands. After encryption is complete, it attempts to force a reboot using the shutdown -r -f -t 10 command and removes the malicious executable file using a self-deletion routine, significantly reducing the likelihood of forensic analysis and malware recovery.
AhnLab’s Response
Detection names and engine dates of AhnLab products are as follows.
V3
Malware/Win.Generic.C5380825
Ransom/MDP.Delete.M2117(2021.10.13.01)
Ransom/MDP.Command.M1751(2021.10.08.00)
Ransom/MDP.Behavior.M2813 (2020.03.24.03)
Ransom/MDP.Decoy.M1171 (2016.07.15.02)
Ransom/MDP.Event.M1946 (2018.06.06.00)
EDR
SystemManipulation/EDR.Event.M2486 (2022.07.09.00)
SystemManipulation/EDR.Event.M1751(2018.09.08.00)
Ransom/MDP.Event.M1946 (2018.09.07.03)
Ransom/EDR.Decoy.M2470 (2022.09.30.00)
