Siete pasos hacia el ransomware: CitrixBleed 2 utilizado como arma por brokers de acceso inicial

Un agradecimiento especial al personal del Centro de Operaciones de Seguridad de Huntress (SOC), porque sin ellos estaríamos describiendo los incidentes a continuación con detalles mucho más dolorosos, y a Lindsey Welch, quien revisa incansablemente nuestro contenido en cuestión de minutos. Además, este blog se escribió con ayuda de IA.

Introducción

A lo largo de la primera mitad de 2026, la unidad de Respuesta Táctica de Huntress trabajó en una serie de intrusiones que seguían el mismo patrón: un gateway Citrix NetScaler expuesto, un acceso anómalo repentino al entorno, una escalada de privilegios prolija, una cuenta de administrador falsa de "Citrix", software de acceso remoto genérico y, cuando el operador conseguía lo que buscaba, ransomware Dragonforce.

Huntress evalúa con alta confianza que un agente de acceso inicial (IAB) está utilizando como arma CVE-2025-5777 (CitrixBleed 2) para obtener acceso a entornos Citrix, con el objetivo final de implementar ransomware. En nuestras observaciones, el ransomware implementado fue Dragonforce, pero informes públicos y privados encuentran indicadores de que otros grupos de ransomware también usan este clúster, lo cual forma la base de nuestra evaluación como agente de acceso inicial.

Contexto

Si has investigado incidentes de ciberseguridad durante suficiente tiempo, sabes que la mayoría de las intrusiones se ven un poco diferentes entre sí. Aprendes a convivir con la ambigüedad: un RMM aquí, un señuelo de phishing allá, un webshell en un servidor IIS olvidado. Pero de vez en cuando trabajas dos casos seguidos y sientes un cosquilleo de reconocimiento: la misma línea de comandos extraña, el mismo nombre de cuenta desechable, la misma mala configuración que el atacante aprovechó. Luego trabajas un tercero. Y un cuarto.

Eso es lo que pasó con el clúster que llamamos, internamente y sin mucha imaginación, el clúster de Citrix NetScaler.  

En la primera mitad de 2026 (entre enero y junio) respondimos a media docena de incidentes en organizaciones sin relación entre sí (distintas industrias, distintos proveedores de servicios administrados, distintas partes del país) que eran tan mecánicamente similares que, para el último caso, ya podíamos predecir el próximo artefacto antes de extraer el registro que lo contenía. Sabíamos el nombre de cuenta que el operador iba a crear. Sabíamos el servicio que iba a explotar. Incluso sabíamos el nombre de la estación de trabajo que encontraríamos filtrado a través de un mapeo de impresora, porque era el mismo nombre de estación de trabajo cada vez.

Figura 1: La previsibilidad y el comportamiento agrupado suelen ser la pista definitiva para el acceso inicial.

La empresa de ciberseguridad Sophos también ha identificado el clúster que hemos observado como STAC3725, lo cual coincide con varios de los análisis que presentamos en este artículo, y sirve como un excelente punto de referencia para respaldar nuestro análisis. En nuestros casos, no observamos el uso de herramientas QEMU para la explotación; atribuimos esto a la detección y disolución rápidas de las actividades adversarias, o al plan acelerado del adversario tras disrupciones repetidas por parte de proveedores de seguridad. 

Este blog consolida lo que observamos: el vector de acceso inicial y el análisis forense que lo comprobó, el mecanismo de escalada de privilegios que conecta los casos, y las tácticas de persistencia y movimiento lateral.

Vamos a profundizar.

Dentro del manual de juego

Antes de profundizar en cualquier técnica específica, ayuda ver toda la máquina en movimiento, porque la característica definitoria del clúster es su repetición. Quita el ruido específico de cada organización y verás que todos los casos siguieron los mismos siete pasos:

Figura 2: Cadena de ataque de Citrix NetScaler al ransomware Dragonforce.

No todas las víctimas experimentaron los siete pasos. Algunas intrusiones se detectaron y aislaron en el paso cuatro o cinco; una llegó hasta el ransomware antes de que el socio detuviera el ataque. Pero la secuencia nunca cambió, y tampoco la mayoría de los ingredientes. Cuando ves una cadena de ataque reproducida con tanta fidelidad en entornos no relacionados, no estás viendo una coincidencia. Estás viendo a un operador que sigue un manual de procedimientos. Casi con certeza se trata de un agente de acceso inicial (IAB) o un afiliado de ransomware que ha convertido en producto esta ruta exacta, desde "equipo Citrix expuesto a internet" hasta "cifrado a nivel de dominio".

Una nota sobre la atribución: en general, es difícil atribuir el comportamiento de un actor de amenazas como un IAB o un afiliado de ransomware debido a las tácticas superpuestas y la visibilidad limitada. Como vimos cifrado activo de DragonForce en un caso de este clúster, confiamos en su relación con DragonForce, pero no podemos afirmar con certeza que el patrón que capturamos sea claramente un IAB o un afiliado de DragonForce en sí. Además, la coordinación con Sophos, así como los boletines de amenazas publicados por proveedores de seguridad, ha generado ambigüedad sobre la asociación de este clúster con un actor de ransomware específico. Consideramos probable que la actividad que capturamos corresponda a un IAB común y muy exitoso.

Acceso inicial: desangrando un NetScaler

La parte más importante, y más incomprendida, de este clúster es cómo entró el operador. A primera vista en los registros del gateway, parece un ataque de fuerza bruta: miles y miles de inicios de sesión fallidos, un torrente de nombres de usuario sin sentido, una campaña evidente de rociado de contraseñas. Esa lectura es incorrecta, y la diferencia importa muchísimo para la respuesta. 

La verdad en los registros

En uno de los dispositivos que examinamos, el conjunto de archivos de registro del sistema principal de NetScaler (ns.log) contenía 5937 eventos AAA LOGIN_FAILED originados desde las direcciones IP del operador durante una sola ventana de ~5 horas. Cada uno de ellos tenía un valor de User extraño e imprimible. No era un nombre de usuario plausible, sino ruido binario que llenaba la terminal de caracteres no imprimibles, secuencias de escape, etc.

Figura 3: entradas del ns.log del dispositivo Citrix que muestran caracteres no imprimibles: esto es memoria heap filtrada.

Solo tras un examen más detenido pudimos discernir qué era realmente este ruido. Juntamos los valores del nombre de usuario y comenzamos a analizar los datos en su conjunto, y lo que encontramos no era un sinsentido, sino memoria heap filtrada del dispositivo Citrix. Un alud de datos sin sentido subrayaba información como un encabezado HTTP filtrado, direcciones IP internas, indicadores de inicio de sesión, etc. 

CitrixBleed2 (CVE-2025-5777)

CVE-2025-5777, apodada "CitrixBleed 2" en honor al CitrixBleed original de 2023 (CVE-2023-4966), es una sobrelectura de memoria en NetScaler ADC y Gateway cuando se configura como un servidor virtual Gateway o AAA. La falla es alcanzable en pre-autenticación. Cuando el dispositivo recibe una solicitud POST al endpoint de inicio de sesión (/p/u/doAuthentication.do y equivalentes) en la que la variable del formulario de inicio de sesión está presente pero vacía, analiza más allá de los datos proporcionados y serializa un fragmento de memoria de proceso adyacente en la respuesta, aproximadamente 127 bytes por solicitud. Al enviar suficientes de estas solicitudes, un adversario puede luego examinar los fragmentos del heap en busca de tokens de sesión válidos de alguien que haya iniciado sesión en ese momento. 

Las dos mitades de la firma estuvieron presentes en nuestro último análisis: 

• El lado de la solicitud: una ráfaga de alta frecuencia de POSTs de inicio de sesión malformados desde una sola IP de origen, con el parámetro de inicio de sesión vacío. En los dispositivos que lo capturaron, esto se manifestó como una inundación de inicios de sesión fallidos.

• El lado de la respuesta: la memoria filtrada apareciendo en el campo User de los eventos AAA LOGIN_FAILED resultantes, frecuentemente precedidos por las propias migas de pan de diagnóstico del dispositivo: "Login request is not expected to be encrypted" y "X509 cert not found".

Estas dos líneas de registro de diagnóstico no son, por sí solas, una detección confiable. El par de marcadores es necesario pero está lejos de ser suficiente como evidencia forense. El factor que realmente separa un ataque del ruido de fondo son los datos binarios que se filtran a través del parámetro user, o, de forma aún más simple, una sesión que existe sin un inicio de sesión correspondiente.

Demostrando el secuestro de sesión

Es poco común que el análisis forense demuestre satisfactoriamente una hipótesis. En un incidente, pudimos reconstruir a partir de los registros toda la cadena del ataque: 

• Un empleado legítimo se autenticó en el gateway normalmente, LDAP con MFA/OTP, desde la dirección IP conocida y confiable del usuario a las 13:07 UTC.

• Veintiún minutos después, a las 13:28 UTC, la sesión del mismo usuario estaba siendo controlada activamente desde la dirección IP del adversario.

• No hubo ninguna autenticación exitosa desde la IP del atacante en ninguna parte de los registros.

Una sesión válida y completamente autenticada que opera desde la IP de un atacante con cero autenticaciones exitosas solo se explica de una manera: el token de sesión fue robado y reproducido. La fuga de memoria estaba demostrablemente activa durante la sesión en vivo de la víctima, el atacante montó esa sesión minutos después, y la MFA simplemente fue irrelevante. Ya estaba satisfecha. 

Vale la pena señalar que también se investigó una hipótesis alternativa. Actualmente, existe una vulnerabilidad en la gestión de sesiones de NetScaler mediante la cual una confusión de sesión de tipo time-of-check/time-of-use (CVE-2026-4368) también puede hacer que un usuario acceda a las sesiones de otro usuario. Es una coincidencia tentadora, pero no se sostuvo para estos casos por dos razones independientes. La versión del dispositivo afectado estaba fuera del rango vulnerable de ese CVE, y la condición de carrera requiere que el atacante tenga una sesión autenticada contra la cual competir, lo cual nunca existió en nuestros registros. La evidencia apuntaba claramente a la divulgación de memoria.

Analizando la fuga

Debido a que los bytes filtrados están presentes en los registros, contamos con una buena parte de qué datos fueron enumerados. Extrajimos todos los valores del campo User de los registros (alrededor de 382 KB de heap en bruto) y los analizamos en busca de estructura coherente. 

Reconstruimos los fragmentos de heap filtrados (que no son contiguos entre sí, pero pueden revelar patrones) y descubrimos los siguientes datos: 

• Plantilla de reflexión: una respuesta HTTP diminuta con Content-Length: 5 (los cinco caracteres de la variable de inicio de sesión vacía) y Content-Type: text/plain; charset=utf-8, seguida inmediatamente del fragmento de heap. 

• Datos de certificado X.509 / ASN.1: encabezados de secuencia, identificadores de objeto como basicConstraints, keyUsage, subjectKeyIdentifier, etc., consistentes con el certificado de servidor de Let's Encrypt.

• Metadatos de tráfico en vivo: encabezados del proxy de Netscaler como Citrix-ns-orig-srcip, Citrix-ns-orig-destip, etc., que expusieron las IP de clientes internos detrás de los datos, junto con encabezados Host y otros metadatos HTTP. 

Y, en honor a la honestidad, no logramos recuperar una cookie de sesión. Es la desafortunada naturaleza de esta vulnerabilidad: la visibilidad está muy oculta y es difícil de capturar de forma confiable con la frecuencia con la que rota ns.log. Sin embargo, sostenemos que el patrón de ataque y los informes públicos correspondientes de otras organizaciones demuestran con solidez que CitrixBleed 2 representa el vector de ataque más probable. 

Las impresoras ganan

Nuestro detalle favorito del acceso inicial, sin embargo, es cómo recolectamos los nombres de equipo del adversario en el entorno. Cuando un usuario se conecta a través de Citrix, el entorno de escritorio publicado crea automáticamente asignaciones de impresoras de cliente, que incluyen el nombre de la estación de trabajo del cliente. 

Debido a que el operador rara vez cambiaba el nombre de su equipo, pudimos triangular la actividad del adversario en el registro de eventos de aplicación de Windows de los servidores víctimas, caso tras caso, a través del evento de creación automática "Print to PDF" de Citrix: 

WIN-4EOAP4JTJR9 (y un equivalente, WIN-VI960VQI4I6) aparecieron en incidente tras incidente. También puedes correlacionar al cliente malicioso con una sesión específica alternando entre el canal Microsoft-Windows-TerminalServices-LocalSessionManager/Operational (que registra la IP de origen y el ID de sesión) y el proveedor MetaFrameEvents en el registro de aplicación (que vincula ese ID de sesión con el nombre de impresora/cliente filtrado). Es un regalo que sigue dando frutos: un comportamiento predeterminado de Citrix que, en silencio, deja la huella digital del propio equipo del operador. 

Escalada de privilegios fácil

Si CitrixBleed 2 es cómo el operador logra entrar, el mecanismo de escalada de privilegios es lo que hace que este clúster sea inconfundible. Es el mismo truco, ejecutado de la misma manera, en todos los casos de endpoint, y es lo suficientemente ingenioso como para merecer un repaso detallado. 

Por qué escalar

El punto sutil pero interesante que da origen a la actividad de escalada de privilegios: la sesión que el operador secuestra suele pertenecer a un usuario normal, un empleado que inicia sesión en un escritorio Citrix publicado para hacer su trabajo habitual. Estas cuentas suelen ser no privilegiadas. El adversario entra al entorno con el acceso de un usuario normal y debe elevarse a SYSTEM para instalar los servicios, crear las cuentas, etc., que detallaremos más adelante en este blog. En lugar de buscar una mala configuración específica del entorno cada vez, el adversario trae una herramienta de escalada de privilegios local (LPE) portátil y confiable, y la usa en todas partes. El uso de esta herramienta nos permite agrupar este comportamiento de manera confiable.

Figura 4: Usuario controlado por el adversario ejecutando la aplicación LPE, que vuelve a lanzar AppMgmt.

Figura 5: Mecanismo LPE, ahora ejecutándose como NT AUTHORITY\SYSTEM, creando el usuario de puerta trasera.

El dropper

La herramienta en sí es un pequeño ejecutable sin firmar, que se deja en un directorio de trabajo como C:\temp, C:\logs, descargas del usuario, etc., y se renombra con frecuencia según la víctima: eng.exe, legal.exe, as.exe, etc. Se entrega con frecuencia dentro de un archivo protegido con contraseña descargado del servicio de intercambio de archivos temp[.]sh. El archivo zip en sí suele llevar un nombre similar al del ejecutable. Pudimos descifrar con éxito la contraseña de este archivo zip, loko123, para acceder a la herramienta de escalada de privilegios que estaba usando el adversario. 

Cómo funciona el LPE

El mecanismo real es un hermoso ejemplo de abuso de los componentes internos de Windows.

El registro de Windows admite un valor especial llamado SymbolicLinkValue de tipo REG_LINK. Cuando está presente bajo una clave, convierte esa clave en un enlace simbólico: todo lo que se lee o escribe a través de la clave se redirige de forma transparente al destino del enlace, de manera similar a un symlink del sistema de archivos. El exploit: 

1. Planta el symlink. Crea un REG_LINK SymbolicLinkValue bajo una clave de clase de dispositivo– específicamente el GUID de la clase de dispositivo RdpBus {28d78fad-5a12-11d1-ae5b-0000f803a8c2} y apunta el destino del enlace hacia la jerarquía de estado de Group Policy: …\Group Policy State\Machine\GPO-List\test

2. Dispara la redirección como SYSTEM. Al ejecutar gpupdate, el adversario fuerza una actualización de políticas que hace que el motor de GP reprocese la política de la máquina. Ese motor se ejecuta como SYSTEM. Cuando lee y escribe a través del REG_LINK plantado, sigue el symlink hacia donde el atacante lo apuntó, lo que permite que una escritura en contexto de SYSTEM llegue a una clave protegida que el usuario sin privilegios nunca podría tocar directamente.

3. Detona al iniciar un servicio. Con una configuración secuestrada ya plantada en una clave de servicio/GPO protegida, el operador inicia el servicio afectado mediante cmd.exe /c sc start AppMgmt >nul 2>nul, lo que inicia el servicio Application Management (AppMgmt). Este servicio hace que el Service Control Manager (SCM) lance la configuración secuestrada en un contexto privilegiado– relanzando el dropper como SYSTEM. Esto finalmente sirve para crear la cuenta de puerta trasera con privilegios elevados.

4. Se limpia a sí mismo. Antes de detonar, el exploit toma una instantánea del árbol de claves de destino original– recorriendo cada subclave y guardando los valores y rutas originales. Después de ejecutarse, restaura el registro, dejándolo en su estado original. Esta limpieza sirve para evadir la detección: al dejar el registro indistinguible de su estado previo al exploit, la herramienta elimina los artefactos en los que un respondedor normalmente se basaría.

Figura 6: main mostrando el ciclo de sincronización, el desmontaje mediante NtDeleteKey de las claves GPO-List\test\test plantadas, un disparo final de RdpBus, y la limpieza "Restoring registry…" que devuelve el registro a su estado original

¿Por qué AppMgmt?

La elección de AppMgmt como vehículo de detonación es deliberada desde la perspectiva del atacante. AppMgmt es un servicio integrado de Windows que se ejecuta en segundo plano mediante el DLL de servicio appmgmts.dll . Su función legítima es la implementación de software mediante Group Policy y Windows Installer (MSI). Eso significa: 

• Siempre está presente 

• Es plausiblemente relacionado con lo que está sucediendo 

• Normalmente está inactivo 

La prueba de que la escalada funcionó es bastante concisa. Primero se ejecuta en el contexto del usuario sin privilegios, y luego, inmediatamente después de ejecutarse sc start AppMgmt, los siguientes comandos se ejecutan desde el mismo binario como NT AUTHORITY\SYSTEM, porque el SCM lo relanzó. Los siguientes comandos son siempre los mismos: 

• net user <ctx-account> <hardcoded-password> /add /y

• net localgroup Administrators <ctx-account> /add

Una nota sobre la falibilidad del atacante

Vale una pequeña sonrisa: en un caso, nuestros analistas notaron los errores de tipeo del operador en la automatización, un gpupdate /force perdido disparado a través del dropper en un momento extraño (un comando malformado), y en otra parte del clúster, un encantador useeeer donde se quería decir user. 

Figura 7: "net useeer" no es un comando válido, lo cual resulta curioso, pero el adversario parece entusiasmado.

Incluso el tradecraft productivizado lo ejecuta un humano que a veces se equivoca al teclear. Esto no cambia el resultado, pero es un recordatorio útil de que el operador automatiza el ataque, no lo ejecuta de forma auto-mágica. 

Instalándose

Con una cuenta de administrador de puerta trasera en mano, el operador establece persistencia manual (hands-on-keyboard) usando herramientas de gestión remota legítimas, el ya estándar enfoque de "vivir de la tierra con software confiable" que frustra las listas de permitidos ingenuas. 

¿Qué encontramos? Bueno… 

ScreenConnect, mayormente

La opción más común fue un cliente de ScreenConnect no autorizado, instalado mediante un pequeño MSI (us.msi, SC.msi, 1111.msi) y configurado para comunicarse con infraestructura de retransmisión controlada por el atacante. Recuperamos directamente las configuraciones a partir de los parámetros de lanzamiento del cliente. El servidor y el puerto de retransmisión, junto con el ID de instancia, están incorporados en la línea de comandos y en la ruta de instalación del cliente. En varios casos, encontramos los siguientes servidores de retransmisión e ID de instancia: 

• Retransmisión relay.dltsolutions[.]top, ID de instancia 9963f404a99f0fc4

• Retransmisión relay.eurofin[.]digital:8041, ID de instancia aee74a66ea5bb239

Respaldo con Zoho Assist

En varios casos, el operador también (o en su lugar) instaló Zoho Assist mediante za.msi, presente en varios casos del clúster. Hemos decidido no revelar los indicadores recopilados de Zoho Assist, ya que se recuperaron varias credenciales probablemente robadas que exponen a usuarios comprometidos de Outlook en entornos no relacionados. 

Netbird/Atera

Y en un caso singular, cerca del inicio de la evolución del tradecraft del adversario, notamos que se implementó una combinación de Netbird/Atera, lo cual coincide con las observaciones de Sophos sobre Netbird. En este entorno, Netbird estaba configurado para comunicarse con hxxps{://]opa[.]tlsd[.]shop, y una vez establecida esa conexión, se descargó Atera a través del enlace de soporte estándar de Atera.

Acciones sobre los objetivos

Lo que ocurrió después de establecer los puntos de apoyo varió según cuánto tiempo se le permitió al operador permanecer en el entorno, lo cual a su vez dependió en gran medida de qué tanto se siguieron las indicaciones de remediación de Huntress. En algunos casos, las remediaciones no se completaron con éxito y el dispositivo Citrix no fue parchado, lo que permitió el reingreso posterior del adversario. 

Control manual del teclado

En los casos que avanzaron, el operador usó la cuenta de administrador de puerta trasera para: 

• Vuelve a iniciar sesión de forma interactiva mediante RDP usando las cuentas de administrador recién creadas.

• Ejecuta PsExec contra endpoints locales con la bandera -s para obtener una shell de SYSTEM. 

• Realiza reconocimiento de endpoints y sesiones: qwinsta, whoami, wmic, etc. 

• Despliega herramientas de Impacket contra controladores de dominio, soltando binarios basados en RemCom. En un caso, Microsoft Defender puso en cuarentena con éxito el payload de ejecución remota de Impacket y la actividad de volcado del registro, lo que les dio a los defensores un tiempo valioso.

• Extraen credenciales con Mimikatz, ejecutado desde directorios anómalos (por ejemplo, C:\Binaries)

El objetivo: ransomware Dragonforce

En el caso más avanzado que trabajamos, el operador llegó a la meta. Después de establecer una cuenta de administrador de puerta trasera en el servidor de la víctima, extrajeron y ejecutaron un binario de ransomware DragonForce (1.exe), lo que resultó en el cifrado del entorno. La rápida intervención de los analistas de Huntress logró contener el cifrado a un solo endpoint, pero la intención del clúster nunca fue ambigua tras el cifrado.

La asociación con DragonForce, las tácticas consistentes y la reutilización de infraestructura y nombres de cuenta en víctimas no relacionadas son las razones por las que evaluamos este clúster como una sola operación de IAB/afiliado, y no como un patrón disperso de intrusiones oportunistas e independientes. 

Tomando acción

Esto debería servir como un llamado a la acción para los usuarios de los dispositivos Citrix NetScaler. Es hora de aplicar los parches, ahora mismo. En un entorno, observamos a un adversario obtener acceso y completar su explotación en menos de una hora, además de desplegar ransomware, algo que solo se detuvo gracias a las medidas de aislamiento masivo de Huntress, lo que impidió un acceso mayor. Estos son algunos pasos inmediatos que las empresas pueden tomar:

• Aplica parches a los dispositivos Citrix NetScaler con la versión de software más reciente, y revisa el dispositivo regularmente en busca de actualizaciones. 

• Envía los registros de NetScaler a soluciones SIEM o de retención de registros. Los registros de NetScaler rotan rápidamente y los registros del dispositivo pueden contener evidencia de un compromiso solo de forma efímera. Es fundamental conservar estos datos para su revisión. 

  • Si te interesa revisar los registros tú mismo, NetScaler publicó un artículo excelente sobre cómo buscar señales de un compromiso de CitrixBleed2. 

• Termina las sesiones activas de los dispositivos vulnerables a CVE-2025-5777. Los tokens de sesión obtenidos pueden ser duraderos y permitir el acceso del adversario incluso después de aplicar los parches. 

• Audita los entornos Citrix vulnerables en busca de usuarios CtxAppVCOMService, ctxsvc y test que no deberían estar ahí. (Ten en cuenta que "test" puede ser un usuario legítimo o ambiguo en algunos entornos.)

• Audita los entornos Citrix vulnerables en busca de instancias inesperadas de ScreenConnect y/o Zoho Assist. 

Indicadores de compromiso (IoC)