Hacking Cat despliega Gorilla RAT y Monkey Ransomware contra objetivos rusos

Las operaciones proucranianas evolucionan hacia la destrucción de datos

Los investigadores de Kaspersky han vinculado dos familias de malware documentadas recientemente con Hacking Cat, un grupo hacktivista prorruso que ataca organizaciones rusas desde aproximadamente febrero de 2024.

En un principio, el grupo se centró en alterar sitios web y robar datos. Sin embargo, según los resultados de la investigación, para el verano de 2025 sus operaciones empezaron a implicar cada vez más el cifrado de archivos de las víctimas o la destrucción directa de datos.

Entre los malware identificados se encuentran Gorilla RAT, una herramienta de acceso remoto con capacidades de tunelización de red, y Monkey Ransomware, un cifrador de archivos que añade la extensión .monkey a los datos afectados. En sistemas comprometidos durante operaciones atribuidas a Hacking Cat han aparecido varias variantes de Monkey.

Los investigadores también observaron el wiper Nemo durante un ataque conjunto en el que participaron Hacking Cat y Ukrainian Cyber Alliance. Su objetivo aparente era interrumpir las operaciones y provocar la pérdida permanente de datos, no obtener pagos de rescate.

Las organizaciones afectadas son principalmente entidades rusas u organizaciones que operan en territorios ocupados por Rusia. No se han divulgado la lista completa de víctimas, el número de sistemas comprometidos ni la magnitud de la pérdida de datos resultante.

Gorilla RAT abre vías hacia las redes internas

Gorilla RAT es una herramienta de acceso remoto no documentada anteriormente que puede tunelizar el tráfico de red a través de un sistema infectado. Esto ofrece al operador una posible ruta desde el host inicialmente comprometido hasta otros servicios o equipos que no están directamente expuestos a internet.

Esta tunelización cambia la función del primer dispositivo infectado. En lugar de servir únicamente como punto de vigilancia, puede convertirse en un intermediario para explorar segmentos de la red interna y acceder a sistemas adicionales.

En algunos incidentes atribuidos al grupo, los atacantes comprometieron primero servidores de Microsoft Exchange y después instalaron Gorilla RAT. No se conocen las vulnerabilidades concretas de Exchange utilizadas para obtener el acceso inicial. Tampoco se han divulgado identificadores CVE, ediciones de Exchange afectadas ni versiones vulnerables exactas.

Esta ausencia de información limita la detección y la corrección específicas de vulnerabilidades. Por sí solos, estos hallazgos no permiten a los administradores determinar si los atacantes aprovecharon una vulnerabilidad recién descubierta, una vulnerabilidad antigua sin parchear o una debilidad de configuración.

La exposición general, sin embargo, está clara. Un servidor de Exchange accesible desde internet puede proporcionar tanto un punto de entrada como una posición persistente dentro de una organización si es vulnerable o no está adecuadamente protegido.

Kaspersky no ha divulgado hashes, nombres de archivo, infraestructura de comando y control ni detalles del protocolo de Gorilla RAT. Por ello, los equipos de defensa deben buscar comportamientos sospechosos en lugar de depender exclusivamente de indicadores fijos. Entre las señales relevantes se encuentran las conexiones salientes no justificadas desde sistemas de Exchange, tráfico inusual similar al de un proxy y accesos desde un servidor de correo a recursos internos con los que normalmente no se comunica.

Monkey Ransomware evolucionó mediante varias implementaciones

Monkey Ransomware apareció por primera vez a finales del verano o principios del otoño de 2025. Durante los meses siguientes, sus operadores lo modificaron repetidamente y produjeron versiones escritas en distintos lenguajes de programación.

El malware cifra los datos de los usuarios y marca los archivos afectados con la extensión .monkey. Se recuperaron varias variantes de entornos comprometidos, lo que apunta a un desarrollo continuo y no al uso de una única compilación estática.

Kaspersky evaluó que la velocidad y el alcance de estos cambios podrían reflejar el uso de inteligencia artificial generativa. Un modelo podría ayudar a reescribir funciones, traducir código entre lenguajes o generar implementaciones alternativas con mayor rapidez que un equipo pequeño trabajando de forma manual.

Se trata de una evaluación, no de una prueba. La rápida iteración también podría deberse a la experimentación convencional, la reutilización de código existente o el trabajo de varios desarrolladores. No se ha divulgado ninguna prueba directa de que Hacking Cat introdujera instrucciones en un servicio de IA o incorporara código generado por un modelo.

La distinción es importante para comprender la capacidad de desarrollo, pero no cambia la respuesta ante incidentes. Con independencia de cómo se crearan las variantes, las reescrituras frecuentes pueden reducir la eficacia de la detección basada en firmas y complicar la comparación entre muestras.

La información disponible no especifica el algoritmo de cifrado de Monkey, la gestión de claves, el formato de la nota de rescate ni si la recuperación de los archivos es técnicamente posible. Tampoco está claro si sus operadores mantienen un proceso de descifrado fiable para las víctimas que pagan.

Nemo Wiper apunta a objetivos que van más allá de la extorsión

La actividad de Hacking Cat no puede considerarse exclusivamente ransomware con motivación económica. Los investigadores observaron Nemo Wiper en una operación conjunta con Ukrainian Cyber Alliance y evaluaron que el malware tenía como objetivo destruir información e interrumpir infraestructuras.

En junio, sin que se haya divulgado el año, los dos grupos llevaron a cabo un ataque destructivo contra Donbassteploenergo. Esta empresa estatal de calefacción opera en zonas ocupadas por Rusia de la región ucraniana de Donetsk.

Un wiper plantea un riesgo distinto al del ransomware convencional. El cifrado utilizado para extorsionar deja abierta, en teoría, la posibilidad de descifrar los datos, aunque el pago nunca garantiza su recuperación. En cambio, el malware destructivo puede sobrescribir o corromper la información sin conservar ningún mecanismo práctico de restauración.

Hacking Cat también colaboró con el grupo prorruso Cyber Anarchy Squad. En marzo, nuevamente sin que se haya divulgado el año, ambos grupos se atribuyeron la responsabilidad de comprometer a un contratista que prestaba apoyo a Rosatom, la corporación estatal rusa de energía nuclear. No se conocen los detalles del método de acceso inicial, los sistemas comprometidos ni los efectos operativos.

Estas colaboraciones indican que las campañas pueden combinar el acceso, las herramientas y las reivindicaciones públicas de varios actores. Por tanto, una misma intrusión puede involucrar a más de un grupo y perseguir más de un objetivo.

El malware compartido dificulta la atribución

La atribución de Kaspersky no es unánime. Hacking Cat reconoció la propiedad de algunas herramientas en un comunicado publicado en Telegram, pero negó que los lockers de ransomware pertenecieran al grupo. Acusó a los investigadores de combinar de forma incorrecta malware de actores no relacionados y cuestionó algunos aspectos de su trabajo de ingeniería inversa.

Los investigadores también encontraron el mismo malware en operaciones asociadas con grupos diferentes. En algunos casos, al parecer distintos actores utilizaron cadenas de infección idénticas y de varias etapas.

Una posible explicación es la existencia de un desarrollo centralizado o parcialmente centralizado. Un único programador o un pequeño equipo de desarrollo podría crear y mantener herramientas que posteriormente se distribuyen entre varios grupos hacktivistas prorrusos.

Este modelo difuminaría la frontera entre desarrolladores y operadores. Encontrar una determinada familia de malware en el sistema de una víctima no identificaría necesariamente al grupo que seleccionó el objetivo, llevó a cabo la intrusión o controló la infraestructura.

El uso compartido de herramientas también aumenta el riesgo de atribuciones circulares. Los investigadores pueden asociar un malware con un grupo basándose en un incidente anterior y utilizar después esa asociación para atribuir ataques posteriores, incluso después de que la herramienta se haya extendido a otros operadores.

Por tanto, los hallazgos respaldan una relación entre Hacking Cat, las campañas observadas y parte de las herramientas personalizadas, pero no demuestran que el grupo sea el propietario exclusivo de todas las variantes de Monkey Ransomware.

Los operadores de Exchange deben buscar actividad posterior al compromiso

No se han publicado instrucciones formales de mitigación ni indicadores específicos de proveedor para estas campañas. Las organizaciones que ejecutan Microsoft Exchange deben comenzar por instalar las actualizaciones de seguridad compatibles y confirmar que los servidores accesibles desde el exterior no carecen de parches relevantes del proveedor.

Dado que se desconocen las vulnerabilidades explotadas y las versiones afectadas, la aplicación de parches por sí sola no debe considerarse una prueba de que un sistema nunca fue comprometido. Los administradores deben revisar la actividad histórica de Exchange, los registros de autenticación, las cuentas creadas recientemente y los procesos iniciados por componentes del servidor de correo.

El acceso a las interfaces de administración debe restringirse siempre que sea posible desde el punto de vista operativo. Las conexiones inesperadas desde hosts de Exchange hacia sistemas internos requieren investigación, especialmente cuando se asemejan a tunelización, uso de proxies o movimiento lateral.

Los equipos de defensa también deben buscar en endpoints y servidores de archivos archivos terminados en .monkey, modificaciones masivas de archivos sin explicación y actividad de cifrado simultánea en varios directorios. Los sistemas de copia de seguridad deben comprobarse por separado para garantizar que los atacantes no hayan borrado ni corrompido las copias de recuperación.

El posible comportamiento de un wiper exige un aislamiento rápido. Entre los indicadores se encuentran las escrituras destructivas a gran escala, la corrupción repentina de archivos, la eliminación de material de recuperación y la interrupción coordinada de varios equipos.

El enfoque defensivo más sólido consiste en relacionar estas señales en lugar de analizarlas de forma aislada. Una actividad sospechosa en Exchange seguida de tunelización interna, el despliegue de software de acceso remoto desconocido y cambios generalizados en los archivos pueden revelar toda la cadena de intrusión antes de que el cifrado o la destrucción alcancen el resto de la red.