Nuestra industria tiene un problema de categorización de actores de ransomware.
Los artículos de noticias suelen destacar titulares llamativos como “El grupo de ransomware Akira ataca infraestructura crítica”. Sin embargo, la realidad es que Akira, y muchas otras variantes de ransomware, se distribuyen mediante un modelo de afiliados. Esto se conoce comúnmente como un modelo “Ransomware-as-a-Service”, o RaaS. Esto significa que un grupo central de desarrolladores crea y mantiene el encriptador de archivos y la infraestructura, y puede ofrecer otros servicios (por ejemplo, gestionar negociaciones y cobros de rescate, revisar y categorizar datos robados, etc.), pero vende el encriptador de archivos a terceros, o afiliados, que luego ejecutan los ataques reales donde se despliega el ransomware. En algunos casos, los afiliados no se han limitado a una sola variante de ransomware, sino que se mueven entre varios proveedores de ransomware distintos.
Entonces, ¿qué importancia tiene esto? ¿Qué significa para las investigaciones, las detecciones y las organizaciones afectadas?
Quizás lo más importante es que, muy a menudo, los indicadores y las tácticas, técnicas y procedimientos (TTPs) varían de un ataque a otro, incluso cuando los archivos son encriptados por el mismo ransomware. En particular para los MSSP y MDR, aunque puede haber un grupo de ataques en toda su base de clientes que incluyan los mismos indicadores y TTPs, o muy similares, con el tiempo probablemente surgirán varios grupos distintos que muestran con claridad diferentes afiliados o grupos en acción. Como resultado, los ataques atribuidos a “el grupo de ransomware” a menudo serán notablemente distintos según cuándo, y quién, esté haciendo el reporte. Un ataque de ransomware exitoso reportado hace seis meses, en un sector o región geográfica completamente diferente, puede seguir un manual de operaciones totalmente distinto al de un ataque más reciente, desde el acceso inicial, pasando por la evasión de defensas, la preparación y exfiltración de datos, hasta el despliegue del ransomware.
Además, se ha observado que varias muestras de RaaS contienen comandos integrados para terminar procesos y/o inhibir la recuperación, lo que reduce la barrera para un ataque y pago de rescate exitosos, de modo que un afiliado no tenga que recordar realizar estas acciones por su cuenta. Por ejemplo, se sabe ampliamente que el encriptador de archivos de Akira lanza un comando de PowerShell, como proceso hijo, para eliminar las copias de instantáneas de volumen (VSC) disponibles. En 2020, se descubrió que las muestras de Sodinokibi incluían 156 comandos integrados únicos para terminar procesos y servicios asociados con productos antivirus. Esta es una observación, no una afirmación de que esto sea exclusivo de las variantes y muestras de RaaS.
¿Es NightSpire RaaS?
Según se informa, el ransomware NightSpire se descubrió por primera vez en febrero de 2025, y estuvo activo durante todo el año. Parece haber cierta confusión sobre si NightSpire sigue o no un modelo de ransomware-as-a-service (RaaS). Investigadores de Halcyon han argumentado que los actores mantienen sus operaciones internamente, al afirmar en una publicación de julio de 2025: “No están operando un programa público de RaaS, y no hay programa de afiliados; es un negocio cerrado”. Sin embargo, dos meses después, otro reporte de HivePro indica que los atacantes están “operando bajo un modelo de Ransomware-as-a-Service (RaaS)”.
Es posible que esto no se trate tanto de confusión, sino de una evolución en la estructura y el modelo del propio grupo. Pero, ¿por qué esto termina marcando una diferencia desde la perspectiva de los defensores?
Incidente de NightSpire
A fines de marzo de 2026, se instaló el agente de Huntress en varios endpoints para un cliente recién incorporado. Poco después de instalar el agente en los primeros endpoints, se detectaron puntos de apoyo maliciosos, o mecanismos de persistencia, lo que indica que probablemente el agente se instaló después de que el incidente ya había comenzado. A medida que continuaba el monitoreo, se generaron señales adicionales, incluida la ejecución del ransomware NightSpire en un endpoint. A partir de ahí, se inició una investigación más profunda.
Esta investigación reveló que el actor de amenazas había accedido a un endpoint mediante RDP varios días antes de que se instalara el agente de Huntress, y había instalado Chrome Remoting Desktop, seguido de Everything, una herramienta de búsqueda de archivos disponible gratis en voidtools. Dos días después, se pudo ver al actor de amenazas ejecutando MEGASync, probablemente para la exfiltración de datos, y luego instalando VMWare Workstation en el endpoint, para después ejecutar Everything, desde donde, según el linaje de procesos, se pudo ver al actor de amenazas accediendo a archivos mediante la interfaz de Everything. Luego se pudo ver al actor de amenazas ejecutando 7Zip para archivar archivos de una carpeta específica. Al día siguiente, se observó al actor de amenazas instalando WPS Office, una suite de oficina multiplataforma disponible gratis de la empresa china Kindsoft Office Software. La figura 1 muestra un fragmento del sitio web de WPS.
Figura 1: Fragmento del sitio web de WPS
En un segundo endpoint dentro de la infraestructura, como se muestra en la figura 2, se generaron señales de puntos de apoyo para Chrome Remoting Desktop y AnyDesk poco después de instalarse el agente de Huntress.
Figura 2: Señales de puntos de apoyo
Estas señales de puntos de apoyo o persistencia reflejaban las del primer endpoint.
La figura 3 muestra un fragmento de la nota de rescate recuperada del endpoint infectado.
Figura 3: Fragmento de la nota de rescate, marzo de 2026
La nota de rescate es sumamente específica y, sin otro incidente más reciente con el cual compararla, su precisión es pura especulación. Sabemos que el actor de amenazas ejecutó Everything, 7Zip y MEGASync, y sabemos que el actor de amenazas vio algunos archivos mediante Everything, pero no contamos con evidencia para validar la afirmación de que se tomaron “2.5TB” de datos, ni el contenido real de los archivos tomados.
Incidente anterior de NightSpire
Resulta que esta no fue la primera vez que Huntress había visto un entorno de cliente donde se había implementado el ransomware NightSpire. Durante este incidente, no se capturaron muchos datos relacionados con las TTPs del actor de amenazas, pero se observó que los archivos cifrados tenían agregada la extensión .nspire, y se recuperó una copia de la nota de rescate _nightspire_readme.txt de uno de los endpoints.
La Figura 4 muestra el contenido completo de la nota de rescate recuperada del incidente del 2 de diciembre de 2025.
Figura 4: Nota de rescate, diciembre de 2025
Observaciones
Los informes disponibles públicamente sobre el ransomware NightSpire indican que los ataques han incluido el uso de utilidades nativas, o "LOLBins", como WMI o PsExec. Sin embargo, en el incidente más reciente investigado por Huntress, este no parece ser el caso. De hecho, el actor de amenazas, ya sea "el grupo de ransomware NightSpire" o un afiliado, parece haber tenido que "traer de afuera" todas sus herramientas, incluyendo Chrome Remoting Desktop y AnyDesk para persistencia, 7Zip y Everything para la preparación y recolección de datos, MEGASync para la exfiltración de datos, y VMWare Workstation y WPS Office para otros fines. Ninguna de estas aplicaciones es nativa del entorno comprometido, y tuvieron que descargarse en los endpoints.
Esto muestra una diferenciación respecto a incidentes reportados públicamente con anterioridad y vinculados a NightSpire. Al observar el incidente anterior que Huntress identificó en diciembre de 2025, hay otras diferencias en las TTPs. Si bien ya no se dispone de mucha información sobre este incidente, una cosa está clara: el propio cifrador de archivos del ransomware parece haber sido modificado en algún momento durante los casi cuatro meses previos a finales de marzo de 2026. Por ejemplo, se modificaron los nombres y el contenido de los archivos de la nota de rescate.
Estas diferencias podrían indicar una evolución del propio ransomware, o podrían representar variaciones debidas a afiliados que distribuyen NightSpire. Aunque todavía está por verse si NightSpire sigue un modelo RaaS, las TTPs variables en estos incidentes muestran que los indicadores de compromiso (IoCs) vinculados a "grupos" de ransomware no siempre son fijos, en particular si potencialmente hay afiliados involucrados. Los analistas de Huntress han visto esto con otras variantes de RaaS, donde los grupos de IoC y TTP difieren notablemente entre ataques, empezando por los nombres de las estaciones de trabajo, y continuando con el resto de su estrategia, pasando por la preparación y exfiltración de datos hasta la implementación del ransomware. Si bien algunos aspectos pueden parecer consistentes entre ataques, como el acceso inicial y el hecho de que se usan varias herramientas, otros aspectos de los ataques tienden a variar de forma significativa, lo que respalda la idea de que distintos grupos o afiliados son responsables de los ataques.
Indicadores de compromiso
|
Indicador |
Descripción |
|
bde50a42efc079edde1a314243ad339db2d42e343fbbcd39117803b0f5960355 |
Hash SHA256 del cifrador de archivos, enc.exe, del 2 de diciembre de 2025 |
|
ad67031e2ca68764fe1a7d6632c02b02a299d59efb920710011a9a2ccf4399b7 |
Hash SHA256 del cifrador de archivos, enc.exe, del 25 de marzo de 2026 |
|
.nspire |
Extensión de archivo cifrado |
|
_nightspire_readme.txt, [nspire_msg].txt |
Nombres de archivo de la nota de rescate, 2 de diciembre de 2025 y 25 de marzo de 2026, respectivamente |
|
prince1990905@gmail[.]com |
Dirección de correo electrónico asociada con Chrome Remoting Desktop, 24 y 25 de marzo de 2026 |
|
C:\Users\[REDACTED]\Downloads\ |
Carpeta de operaciones del actor de amenazas, 25 de marzo de 2026 |