Agradecimientos: Un agradecimiento especial a Adam Mooney y Jamie Dumas por sus contribuciones a esta investigación.

Antecedentes

Los analistas de Huntress observaron recientemente dos incidentes en los que se desplegó una variante de ransomware más nueva, Settra. Un incidente ocurrió en julio en una organización del sector de servicios al consumidor y retail, mientras que el otro ocurrió en septiembre en una empresa del sector manufacturero.

Settra se vio por primera vez en junio y ha habido algunos reportes públicos sobre la variante desde entonces, incluidos reportes que han descrito los vectores de acceso inicial que han usado los atacantes detrás de este ransomware. Los analistas de Huntress no confirmaron los vectores de acceso inicial para los dos incidentes que investigamos; sin embargo, encontramos varios otros rastros valiosos de actividad posterior al compromiso, incluido el uso de RMM, varios intentos de los actores de amenazas de ocultar sus huellas, y evidencia de BYOVD.

Si bien hay cierta información pública disponible sobre esta variante de ransomware, estamos publicando nuestro propio análisis para que los defensores puedan comprender mejor las TTP relacionadas con los ataques de ransomware Settra.

Lo que sabemos según los reportes públicos

¿Qué es el ransomware Settra? Según la información disponible públicamente, el ransomware Settra se observó por primera vez en junio, lo que lo convierte en una nueva variante en la escena. La Figura 1 ilustra una descripción general de IA de Google sobre el ransomware Settra. 

Figura 1: Descripción general de IA de una búsqueda en Google sobre el ransomware Settra que muestra información disponible públicamente

El 22 de julio, MoxFive compartió hallazgos a partir de actividad observada hasta mediados de julio, exponiendo su perspectiva sobre el grupo. El acceso inicial a las infraestructuras afectadas incluyó el compromiso de VPN y el uso de credenciales ya obtenidas. Una vez que obtienen acceso a la infraestructura, se ha visto al grupo instalar BYOVD en los sistemas afectados e instalar el RMM MeshAgent para mantener acceso persistente.

La Figura 2 ilustra información sobre el grupo compartida por SOCRadar, que lo define como "un grupo de ransomware y extorsión de datos" con un enfoque principal en la extorsión global.

Figura 2: Información de SOCRadar sobre el ransomware Settra

Hasta el momento, no se ha publicado públicamente nada que indique que el ransomware Settra siga un modelo de ransomware como servicio (RaaS). Para entender un poco más sobre cómo funciona RaaS, consulta nuestra cobertura anterior sobre este tema (incluido Inside the RaaS Headlines y How The RaaS Business Model Actually Works).

Observaciones de TTP de Huntress 

Huntress ha observado dos incidentes de ransomware Settra en los entornos de nuestros clientes, incluido un ataque en julio y uno en septiembre en el que el agente de Huntress se instaló a mitad del incidente. Eso significa que el endpoint ya estaba comprometido cuando se desplegó el agente de Huntress, y es posible que el atacante siguiera activo después. Los analistas de Huntress no determinaron de manera definitiva el método de acceso inicial a la infraestructura en estos dos incidentes; sin embargo, los investigadores descubrieron varias tácticas y similitudes notables posteriores al compromiso. 

Una de esas similitudes fue que, en ambos incidentes, el ejecutable de ransomware se nombró según el nombre de dominio de la organización afectada, con el sufijo _win64.exe.

El incidente de julio 

Una de las primeras detecciones de EDR para el incidente de julio fue para el RMM MeshAgent, renombrado como mvtcs.exe, que apuntaba a la dirección IP de comando y control (C2) 45.13.122[.]7. Esto fue seguido al día siguiente por el lanzamiento del ejecutable de ransomware desde la carpeta C:\Perflogs. Luego, los archivos se cifraron y se renombraron con la extensión .locked, y se creó la nota de rescate RESTORE_FILES.txt (Figura 3). 

Una vez lanzado el ejecutable de ransomware, la telemetría de EDR mostró varias otras medidas que ocurrieron inmediatamente después. El actor de amenazas borró varios registros de eventos de Windows, usó reagentc /disable para deshabilitar el entorno de recuperación de Windows, usó ipconfig /flushdns para vaciar la caché de DNS, y ejecutó la utilidad nativa de Windows diskpart mediante un script para eliminar una partición de recuperación (el script no se pudo recuperar en ninguno de los dos incidentes). Finalmente, la telemetría de EDR mostró a los actores de amenazas usando el siguiente comando:

cmd.exe /c cipher /w:D:\ >nul 2>&1

Este comando lanzó la utilidad nativa de Windows cipher para sobrescribir el espacio libre (previamente eliminado) en varios volúmenes (en este comando específico, el volumen D:), lo que hace que los datos eliminados sean mucho más difíciles de recuperar. 

Figura 3: Un extracto de la RESTORE_FILES.txt nota de rescate de Settra

El incidente de septiembre

La segunda ocurrencia fue aproximadamente dos meses después, y fue el resultado de que el agente de Huntress se instaló a mitad del incidente. Aun así, hubo bastante información disponible para que los analistas de Huntress armaran el rompecabezas y desarrollaran una imagen de las actividades del actor de amenazas. 

La Figura 4 ilustra las señales asociadas con la detección de BYOVD (gdrv.sys), que normalmente los actores de amenazas instalan como una forma de afectar las herramientas de seguridad integradas, provocar fallas en servicios relacionados con aplicaciones antivirus, y más. Cabe destacar que el otro incidente de Settra que Huntress observó en julio no mostró signos de BYOVD. 

Figura 4: Señales que indican el uso de BYOVD y del RMM MeshAgent por parte del atacante

En este incidente, la telemetría de EDR también detectó que el actor de amenazas instaló el RMM MeshAgent. Esta instancia de RMM no fue renombrada, y apuntaba a la dirección IP 193.5.65[.]114, que no solo apareció en la información del certificado del ejecutable de MeshAgent, sino que también estaba en las conexiones de red activas obtenidas del endpoint en el momento del incidente. 

El ejecutable de ransomware se lanzó desde la carpeta Documents del usuario comprometido, y dio como resultado una secuencia similar de acciones destinadas a impedir la recuperación. En este incidente, no se observó el uso de la utilidad cipher. Los archivos cifrados tenían el sufijo con la extensión .locked_wip, y la nota de rescate RESTORE_FILES.txt apareció en varias carpetas.

Al igual que en el primer incidente, según la telemetría de EDR, el ejecutable de ransomware incluye comandos integrados para deshabilitar las opciones de recuperación, además de borrar varios, aunque no todos, los registros de eventos de Windows. La lista de registros de eventos de Windows borrados aparece de la siguiente manera:

Application

Security

System

Setup

ForwardedEvents

Microsoft-Windows-TerminalServices-LocalSessionManager/Operational

Microsoft-Windows-TerminalServices-RDPClient/Operational

Microsoft-Windows-Sysmon/Operational

Microsoft-Windows-PowerShell/Operational

Microsoft-Windows-WinRM/Operational

Microsoft-Windows-TaskScheduler/Operational

Microsoft-Windows-Defender/Operational

Al observar la lista de registros de eventos de Windows borrados, es fácil ver por qué se incluyen algunos, ya que borrarlos dificulta (pero no elimina) las actividades de análisis forense digital y respuesta a incidentes. Sin embargo, nota que el último registro de eventos de Windows está mal escrito; la ortografía correcta es Microsoft-Windows-Windows-Defender/Operational. Como resultado, el registro no se borró.

Al igual que en el primer incidente, en este incidente el ejecutable de ransomware también ejecutó reagentc.exe /disable para deshabilitar la imagen de arranque del entorno de recuperación de Windows, si estaba disponible, y ejecutó diskpart.exe contra un archivo de script. No se pudo recuperar el texto del script, pero evaluamos que el uso de la utilidad fue para eliminar una partición de recuperación, si existe. En ambos incidentes, no había información disponible que sugiriera que alguna de las dos opciones (el uso de un entorno de recuperación de Windows, o el uso de una partición de recuperación) estuviera en uso activo antes del compromiso. Tampoco hubo un intento aparente de determinar si este era, de hecho, el caso. Estos comandos estaban integrados en el ejecutable de ransomware, y se lanzaron como un proceso secundario de esa imagen ejecutable.

Información adicional de este incidente de septiembre indica que el nombre de estación de trabajo WIN-LIVFRVQFMKO estuvo asociado con la actividad maliciosa. Este es un nombre de estación de trabajo que los analistas de Huntress han observado asociado con otros incidentes que se remontan al 24 de diciembre de 2024. De hecho, los analistas de Huntress han observado este nombre de estación de trabajo asociado con la dirección IP 193.5.65[.]114 durante incidentes anteriores, que se remontan a noviembre de 2025, así como recientemente en febrero de 2026.

Dos incidentes de Settra: varias tácticas similares 

Si bien hubo ligeras diferencias entre los dos incidentes, como el nombre y la dirección IP de C2 del RMM MeshAgent, así como las carpetas desde las que operaron los actores de amenazas, el comportamiento general de los ataques fue notablemente similar. Gran parte de las similitudes posteriores se debieron a los comandos integrados dentro del ejecutable de ransomware, que, nuevamente, se nombró según el nombre de dominio de la organización afectada, con el sufijo _win64.exe.

Defendiéndose contra el ransomware Settra 

No es inusual que el Huntress Security Operations Center (SOC) se encuentre con variantes de ransomware más nuevas como Settra (anteriormente, observamos variantes emergentes como Crux, KawaLocker, y Cephalus). Si bien seguirán surgiendo nuevas variantes de ransomware, muchas de las TTP siguen siendo las mismas, ya sea el mal uso de RMM, el uso de BYOVD, o los intentos de los actores de amenazas de borrar los registros de eventos de Windows.

Los defensores deben seguir centrándose en los "fundamentos" que pueden ayudar a prevenir este tipo de técnicas desde el principio. Además, deben tener un buen entendimiento de las acciones que ocurren después del compromiso, para desarrollar una capacidad de detección y respuesta ante estos ataques antes de que escalen. 

Indicadores de compromiso (IOC)