Kawabunga, Dude, You’ve Been Ransomed!

Huntress analysts recently observed an incident where a newer ransomware variant, KawaLocker (also known as KAWA4096) ransomware, was deployed. 

It’s not unusual for new ransomware variants to pop up on the Huntress SOC radar. About a year ago, Huntress observed an incident where the ReadText34 ransomware was deployed in a customer’s environment, and just last month, we found a never-before-publicized ransomware variant called “Crux.” 

In a recent incident earlier this month, we saw a KawaLocker ransomware attack that involved various other tools, including one used to disable security tools.

What is KawaLocker ransomware? 

KawaLocker first made its debut in June 2025, according to an analysis in July from TrustWave’s SpiderLabs team, which initially uncovered the threat. Some aspects of KawaLocker bear similarities to other variants, such as Qilin and Akira—for example, its data leak site has a similar design to the leak site of Akira, while its ransom note is nearly identical to that of Qilin. However, SpiderLabs analysts felt that this was in an effort to increase their visibility and not due to any direct collaboration. 

Initial access and HRSword

On August 8, we saw a threat actor accessing the victim’s endpoint via Remote Desktop Protocol (RDP), using a compromised account. 

Several means were employed by the threat actor to identify and “remediate” security tooling on the endpoint. The threat actor deployed kill.exe and HRSword, which is designed to monitor various system components and can give them visibility across the system. The HRSword launch was initiated with the following command:

C:\Windows\System32\cmd.exe /c @pushd C:\Users\[User]\AppData\Local\Temp\7ZipSfx.000 >nul 2>&1 & CALL C:\Users\[User]\AppData\Local\Temp\7ZipSfx.000\HRSword.bat

The threat actor was then observed running tasklist.exe piped through a find command to locate specific tooling of interest, and then deploying tools to disable those security tools. Shortly after, the Windows services associated with those installed security tools were observed crashing.

The kernel drivers installed as part of the threat actor’s tooling, sysdiag.sys and hrwfpdr.sys, were installed and later removed using a batch file that employed the Service Control Manager, sc.exe. Service Control Manager commands such as sc start <driver>, sc stop <driver>, and sc delete <driver> were observed in EDR telemetry.

Both sysdiag.sys and hrwfpdr.sys appear to be associated with China-based Huorong Network Technology, as both have certificates issued by Beijing Huorong Network Technology Co., Ltd., and both drivers contain file version information similar to what is illustrated in Figure 1. Notably, this is the same entity that develops HRSword, per a LinkedIn post on the tool by cyber intrusion analyst Mikelle Bandin.

Figure 1: sysdiag.sys driver file version information

Early in their logon session, the threat actor had run advanced_port_scanner.exe, likely as a means of enumeration of devices and services within the infrastructure. From this, it appeared that a list of host names was saved to a file named 1.txt. After disabling what they saw as security tools that would pose an obstacle to their efforts, the threat actor ran the following command:

PsExec.exe  -h @1.txt -d -c "\\[REDACTED]\1.bat"

The batch file contained only the following command: 

REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server /v fDenyTSConnections /t REG_DWORD /d 0 /f && netsh firewall set opmode disable

In short, this was the threat actor’s efforts to extend their reach by enabling RDP on additional endpoints within the infrastructure, likely so that they could log in to each one, and repeat their efforts to manually deploy ransomware, or at the very least, be able to access the endpoints listed in the file 1.txt via RDP should they need to in the future.

KawaLocker ransomware deployment

When the threat actor deployed the KawaLocker ransomware, they did so against the E:\ volume on the endpoint, via the following command:

e.exe  -d="E:\\"

As the command was run against the E:\ volume, Huntress ransom canary files on the C:\ volume were not impacted. However, the endpoint had an audit configuration that resulted in Microsoft-Windows-Security-Auditing/4663 events being written to the Security Event Log, indicating that an attempt was made to access an object. From these messages, Huntress was able to obtain a list of encrypted files, as well as obtain a copy of the ransom note, an excerpt of which is illustrated in Figure 2. 

Figure 2: Excerpt of ransom note

The email address listed at the end of the ransom note is kawa4096@onionmail[.]org, which is likely from where the reference to KAWA4096 originated.

After the threat actor deployed the ransomware, Volume Shadow Copies were deleted, the Security, System, and Application Windows Event Logs were cleared, and the ransomware self-deleted, via the following commands:

vssadmin.exe delete shadows /all /quiet

cmd.exe /c wevtutil cl security | wevtutil cl system |  wevtutil cl application

cmd.exe /C ping 127.0.0.1 -n 2 > nul && del /F "C:\Users\[User]\Desktop\e.exe" 

Per the Trustwave analysis, these commands are embedded as part of the ransomware executable.

Detection breadcrumbs for KawaLocker

Fortunately, based on the detections, investigation, and response to this endpoint, Huntress analysts were able to prevent the threat actor from accessing other endpoints, including those for which enabling RDP had been attempted. This response obviated further impact to the victim’s infrastructure.

When Huntress analysts observe ransomware families like these—whether they’re brand new, emerging, or only a few months old—we work to determine what happened in the related incident, and in what order, so that similar attacks can be more easily detected and remediated in the future. In this incident, certain clues—such as the use of HRSword or deletion of Shadow Copies via WMI—can add valuable breadcrumbs to detecting the use of KawaLocker in future attacks. 

Indicators of Compromise