Kawabunga, amigo, ¡te han hecho víctima de ransomware!

Los analistas de Huntress observaron recientemente un incidente en el que se implementó una variante más reciente de ransomware, KawaLocker (también conocida como ransomware KAWA4096).

No es raro que nuevas variantes de ransomware aparezcan en el radar del Huntress SOC. Hace aproximadamente un año, Huntress observó un incidente en el que se implementó el ransomware ReadText34 en el entorno de un cliente, y apenas el mes pasado, encontramos una variante de ransomware nunca antes divulgada llamada “Crux.”

En un incidente reciente a principios de este mes, vimos un ataque de ransomware KawaLocker que involucró varias otras herramientas, incluida una usada para deshabilitar herramientas de seguridad.

¿Qué es el ransomware KawaLocker?

KawaLocker debutó por primera vez en junio de 2025, según un análisis de julio del equipo SpiderLabs de TrustWave, que descubrió inicialmente la amenaza. Algunos aspectos de KawaLocker guardan similitudes con otras variantes, como Qilin y Akira; por ejemplo, su sitio de filtración de datos tiene un diseño similar al sitio de filtración de Akira, mientras que su nota de rescate es casi idéntica a la de Qilin. Sin embargo, los analistas de SpiderLabs consideraron que esto se debía a un esfuerzo por aumentar su visibilidad y no a una colaboración directa.

Acceso inicial y HRSword

El 8 de agosto, vimos a un actor de amenazas acceder al endpoint de la víctima mediante el protocolo de escritorio remoto (RDP), usando una cuenta comprometida.

El actor de amenazas empleó varios medios para identificar y “remediar” las herramientas de seguridad en el endpoint. El actor de amenazas implementó kill.exe y HRSword, diseñado para monitorear varios componentes del sistema y que puede darles visibilidad en todo el sistema. El lanzamiento de HRSword se inició con el siguiente comando:

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

Luego se observó al actor de amenazas ejecutar tasklist.exe canalizado a través de un comando find para ubicar herramientas específicas de interés, y luego implementar herramientas para deshabilitar esas herramientas de seguridad. Poco después, se observó que los servicios de Windows asociados con esas herramientas de seguridad instaladas se bloqueaban.

Los controladores de kernel instalados como parte de las herramientas del actor de amenazas, sysdiag.sys y hrwfpdr.sys, se instalaron y luego se eliminaron usando un archivo por lotes que empleaba el Service Control Manager, sc.exe. Se observaron comandos del Service Control Manager como sc start <driver>, sc stop <driver> y sc delete <driver> en la telemetría de EDR.

Tanto sysdiag.sys como hrwfpdr.sys parecen estar asociados con la empresa china Huorong Network Technology, ya que ambos tienen certificados emitidos por Beijing Huorong Network Technology Co., Ltd., y ambos controladores contienen información de versión de archivo similar a la que se muestra en la Figura 1. Cabe destacar que esta es la misma entidad que desarrolla HRSword, según una publicación en LinkedIn sobre la herramienta de la analista de intrusiones cibernéticas Mikelle Bandin.

Figura 1: información de versión del archivo de controlador sysdiag.sys

Al inicio de su sesión, el actor de amenazas había ejecutado advanced_port_scanner.exe, probablemente como medio de enumeración de dispositivos y servicios dentro de la infraestructura. A partir de esto, parece que se guardó una lista de nombres de equipos en un archivo llamado 1.txt. Después de deshabilitar lo que consideraron herramientas de seguridad que representaban un obstáculo para sus esfuerzos, el actor de amenazas ejecutó el siguiente comando:

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

El archivo por lotes contenía únicamente el siguiente comando:

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

En resumen, esto fue parte del esfuerzo del actor de amenazas por extender su alcance habilitando RDP en endpoints adicionales dentro de la infraestructura, probablemente para poder iniciar sesión en cada uno y repetir sus intentos de implementar ransomware manualmente, o al menos, poder acceder mediante RDP a los endpoints listados en el archivo 1.txt si lo necesitaran en el futuro.

Implementación del ransomware KawaLocker

Cuando el actor de amenazas implementó el ransomware KawaLocker, lo hizo contra el volumen E:\ en el endpoint, mediante el siguiente comando:

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

Como el comando se ejecutó contra el volumen E:\, los archivos canario de rescate de Huntress en el volumen C:\ no se vieron afectados. Sin embargo, el endpoint tenía una configuración de auditoría que provocó que se escribieran eventos Microsoft-Windows-Security-Auditing/4663 en el registro de eventos de seguridad, lo que indica que se intentó acceder a un objeto. A partir de estos mensajes, Huntress pudo obtener una lista de archivos cifrados, así como una copia de la nota de rescate, cuyo extracto se ilustra en la Figura 2.

Figura 2: extracto de la nota de rescate

La dirección de correo electrónico que aparece al final de la nota de rescate es kawa4096@onionmail[.]org, de donde probablemente proviene la referencia a KAWA4096.

Después de que el actor de amenazas implementó el ransomware, se eliminaron las copias de seguridad de volumen (Volume Shadow Copies), se borraron los registros de eventos de seguridad, sistema y aplicación de Windows, y el ransomware se autoeliminó, mediante los siguientes comandos:

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" 

Según el análisis de Trustwave, estos comandos están incorporados como parte del ejecutable del ransomware.

Indicios de detección para KawaLocker

Afortunadamente, gracias a las detecciones, la investigación y la respuesta aplicadas a este endpoint, los analistas de Huntress pudieron evitar que el actor de amenazas accediera a otros endpoints, incluidos aquellos en los que se había intentado habilitar RDP. Esta respuesta evitó un mayor impacto en la infraestructura de la víctima.

Cuando los analistas de Huntress observan familias de ransomware como estas, ya sean completamente nuevas, emergentes o de apenas unos meses de antigüedad, trabajamos para determinar qué ocurrió en el incidente relacionado y en qué orden, de modo que ataques similares puedan detectarse y remediarse más fácilmente en el futuro. En este incidente, ciertas pistas, como el uso de HRSword o la eliminación de Shadow Copies mediante WMI, pueden aportar rastros valiosos para detectar el uso de KawaLocker en futuros ataques.

Indicadores de compromiso