Un dispositivo de acceso remoto expuesto a Internet no necesita una contraseña robada para convertirse en la puerta de entrada de un ransomware.
Durante 2026, Arctic Wolf ha investigado varias intrusiones relacionadas con afiliados de Anubis en las que el acceso inicial se produjo mediante credenciales VPN válidas o mediante la explotación de Citrix Bleed 2, nombre con el que se conoce a CVE-2025-5777, una vulnerabilidad crítica en NetScaler ADC y NetScaler Gateway.
El fallo permite extraer de la memoria del appliance información sensible que puede incluir cookies y tokens de sesión. Si el atacante consigue material válido, puede reutilizar una sesión ya autenticada sin conocer la contraseña y sin completar de nuevo el segundo factor.
A partir de ahí, los afiliados de Anubis combinan herramientas legítimas de administración remota, utilidades nativas de Windows y túneles salientes para avanzar por la red sin desplegar inmediatamente un malware fácilmente reconocible.
La principal conclusión para los defensores es incómoda: la mejor oportunidad de detener el ataque aparece antes del cifrado, cuando comienzan a coincidir anomalías de sesión, accesos desde infraestructuras de hosting, despliegue de herramientas RMM y movimiento hacia controladores de dominio, hipervisores, sistemas de backup o dispositivos NAS.
Resumen ejecutivo
- CVE-2025-5777 es una vulnerabilidad crítica de lectura de memoria en NetScaler ADC y NetScaler Gateway.
- Puede explotarse sin autenticación cuando el dispositivo funciona como Gateway o servidor virtual AAA.
- La información filtrada puede permitir el secuestro de sesiones y la elusión práctica del MFA.
- Arctic Wolf ha observado su explotación en intrusiones asociadas a afiliados de Anubis.
- Los atacantes utilizan herramientas legítimas como ScreenConnect, Zoho Assist, MeshAgent, Remotely o UltraVNC para confundirse con la actividad normal de TI.
- Parchear el dispositivo no invalida necesariamente el material de sesión obtenido antes de la actualización.
- Tras actualizar, deben cerrarse las sesiones activas e investigarse posibles accesos durante la ventana de exposición.
Qué es Citrix Bleed 2
CVE-2025-5777 es una vulnerabilidad de validación insuficiente de entradas que provoca una lectura de memoria fuera de límites en determinados dispositivos NetScaler.
Según el boletín de seguridad CTX693420 de Citrix, el fallo afecta a equipos NetScaler ADC y NetScaler Gateway configurados como:
- servidor virtual VPN;
- ICA Proxy;
- CVPN;
- RDP Proxy;
- servidor virtual AAA.
Citrix le asignó una puntuación CVSS 4.0 de 9,3, con explotación remota, sin privilegios previos y sin interacción del usuario.
El fallo se activa mediante una petición HTTP especialmente manipulada contra el endpoint:
/p/u/doAuthentication.do
Cuando el manejador de autenticación procesa determinados parámetros incompletos o malformados, el appliance puede devolver fragmentos de memoria que no habían sido inicializados correctamente.
El análisis técnico publicado por el Splunk Threat Research Team explica que la respuesta puede contener información como:
- cookies de sesión;
- tokens de autenticación;
- contexto SAML;
- nombres de usuario;
- información procedente de solicitudes legítimas;
- material asociado a sesiones administrativas.
No significa que cada petición devuelva automáticamente una sesión aprovechable. El atacante puede tener que repetir el proceso y analizar el contenido filtrado hasta encontrar material válido. Sin embargo, el ataque no requiere conocer previamente ninguna cuenta y puede ejecutarse contra un dispositivo accesible desde Internet.
Por qué puede eludir el MFA
El MFA protege principalmente el proceso de autenticación. Solicita una prueba adicional cuando un usuario inicia sesión, pero no vuelve a ejecutar necesariamente todo el proceso en cada petición realizada dentro de una sesión ya establecida.
Si un atacante roba y reutiliza un token de sesión válido, no está superando el MFA mediante fuerza bruta ni aprobando fraudulentamente una notificación. Está presentando al sistema una sesión que ya fue autenticada.
Por eso, desde el punto de vista del servicio, la actividad puede parecer inicialmente legítima.
Es el mismo principio que aparece en los ataques de adversario en el medio contra Microsoft 365: el objetivo deja de ser la contraseña y pasa a ser el artefacto que demuestra que la autenticación ya se completó.
Este riesgo se explica con mayor detalle en nuestro análisis sobre el secuestro de cuentas de Microsoft 365 mediante robo de tokens.
La conclusión no es que el MFA haya dejado de ser útil. Sigue siendo uno de los controles más eficaces contra el robo y la reutilización de contraseñas. La conclusión correcta es que el MFA debe complementarse con una gestión segura de sesiones, detección de cambios de contexto y capacidad para revocar rápidamente tokens y conexiones activas.
Cómo está utilizando Anubis Citrix Bleed 2
En una investigación publicada el 30 de junio de 2026, Arctic Wolf documentó varias intrusiones de afiliados de Anubis.
El acceso inicial observado se agrupaba principalmente en dos categorías:
- Uso de credenciales VPN válidas.
- Explotación de vulnerabilidades en servicios remotos, entre ellas CVE-2025-5777.
No todas las intrusiones siguieron exactamente la misma cadena. Anubis opera como ransomware como servicio, por lo que cada afiliado puede emplear herramientas y procedimientos diferentes.
Aun así, Arctic Wolf identificó varios patrones comunes:
- conexiones procedentes de proveedores VPS o redes de hosting;
- acceso posterior mediante RDP y SMB;
- búsqueda y extracción de credenciales;
- creación de servicios con PsExec;
- instalación de herramientas RMM;
- movimiento hacia infraestructura crítica;
- uso de servicios cloud para exfiltrar información;
- creación de canales alternativos mediante cloudflared, proxies autenticados o túneles SOCKS sobre SSH.
Los atacantes prestaron especial atención a servidores de Remote Desktop Services, controladores de dominio, hipervisores, sistemas próximos a las copias de seguridad y dispositivos NAS.
El objetivo es claro: obtener suficiente control para maximizar el impacto, dificultar la recuperación y aumentar la presión sobre la víctima antes de iniciar el cifrado.
Herramientas legítimas para ocultar una intrusión
Una de las características más relevantes de estas operaciones es el uso de software que también puede estar presente en una empresa por motivos legítimos.
Entre las herramientas observadas por Arctic Wolf aparecen:
- ScreenConnect;
- Zoho Assist;
- MeshAgent;
- Remotely;
- UltraVNC;
- Total Software Deployment.
Ninguna de ellas es malware por definición. Son soluciones comerciales o de código abierto utilizadas para soporte, administración remota y distribución de software.
El problema aparece cuando una organización permite varias herramientas equivalentes sin inventario, sin propietario y sin una política clara de autorización.
Vista de forma aislada, la instalación de un agente RMM puede parecer una intervención del equipo de soporte. Vista junto a una sesión VPN anómala, conexiones desde un VPS, ejecución de PsExec y acceso a un hipervisor, la misma instalación adquiere un significado completamente distinto.
Esta correlación entre identidad, endpoint y red es una de las funciones esenciales de un SOC gestionado con monitorización y respuesta 24/7.
La cifra de víctimas debe interpretarse con cautela
Las cifras publicadas por los grupos de ransomware proceden habitualmente de sus propios sitios de filtraciones. Son útiles para analizar tendencias, pero no equivalen a un registro independiente de incidentes confirmados.
Además, no debe asumirse que todas las organizaciones reclamadas por Anubis fueron comprometidas mediante Citrix Bleed 2.
La investigación de Arctic Wolf acredita la presencia de CVE-2025-5777 como vía de acceso en determinadas intrusiones y documenta el comportamiento posterior de varios afiliados. No atribuye todos los ataques conocidos de Anubis a esta única vulnerabilidad.
La información técnicamente relevante no es una cifra concreta de víctimas, sino la confirmación de que los operadores de ransomware están integrando el robo de sesiones de NetScaler en cadenas de ataque reales.
Cómo detectar intentos de explotación de CVE-2025-5777
La detección debe cubrir cuatro planos: el propio NetScaler, las sesiones, los endpoints y el tráfico de salida.
1. Indicadores en NetScaler
Conviene revisar las solicitudes POST dirigidas a:
/p/u/doAuthentication.do
Entre las señales que pueden justificar una investigación se encuentran:
- parámetros
loginincompletos o malformados; - respuestas con caracteres no imprimibles o contenido inesperado;
- bloques de datos de alta entropía dentro de campos que deberían estar vacíos;
- múltiples solicitudes desde una misma dirección IP;
- actividad procedente de proveedores VPS o redes de hosting;
- intentos repetidos sin un inicio de sesión convencional asociado.
Cisco publicó la regla Snort SID 65120 para detectar patrones compatibles con intentos de explotación de CVE-2025-5777.
Estas señales no deben interpretarse de manera aislada. Un intento contra el endpoint demuestra exploración o explotación potencial, pero no confirma por sí solo que el atacante haya obtenido una sesión válida.
2. Anomalías de sesión
Las sesiones AAA y SSL VPN deben analizarse para localizar:
- una misma cuenta utilizada desde varias direcciones IP;
- diferencias anómalas entre la IP original del cliente y el origen posterior;
- accesos desde un proveedor de hosting después de una conexión residencial;
- cambios incompatibles de país o región;
- agentes de usuario distintos dentro de una misma sesión;
- actividad fuera del horario normal del usuario;
- acceso a recursos que ese usuario no utiliza habitualmente.
Un cambio de IP no prueba automáticamente un secuestro. Los usuarios cambian entre Wi-Fi, redes móviles y proveedores diferentes. La señal gana valor cuando coincide con un ASN de hosting, actividad lateral o herramientas RMM no autorizadas.
3. Varias herramientas RMM en un mismo equipo
Una de las detecciones más rentables consiste en agrupar la aparición de varias herramientas de administración remota sobre el mismo endpoint dentro de una ventana corta.
En Microsoft Defender XDR o Microsoft Sentinel puede utilizarse una consulta KQL como punto de partida:
let RMMTools = dynamic([
"ScreenConnect.ClientService.exe",
"ZohoMeeting.exe",
"MeshAgent.exe",
"Remotely_Agent.exe",
"winvnc.exe"
]);
DeviceProcessEvents
| where FileName in~ (RMMTools)
| summarize
FirstSeen=min(Timestamp),
LastSeen=max(Timestamp),
Tools=make_set(FileName),
ToolCount=dcount(FileName),
Accounts=make_set(AccountName)
by DeviceName, bin(Timestamp, 6h)
| where ToolCount >= 2
| order by ToolCount desc
La consulta debe adaptarse a las herramientas aprobadas por cada organización y al esquema de telemetría disponible.
La presencia de dos agentes puede ser legítima durante una migración o una intervención técnica. Por eso, el resultado debe correlacionarse con:
- quién realizó la instalación;
- proceso padre;
- línea de comandos;
- firma digital;
- origen del instalador;
- ticket de cambio;
- sesión VPN relacionada;
- conexiones posteriores.
4. Túneles y canales de salida
La aparición de cloudflared no es necesariamente maliciosa. Cloudflare Tunnel es una herramienta legítima que muchas empresas utilizan para publicar servicios sin abrir puertos entrantes.
Debe investigarse cuando:
- no forma parte del inventario autorizado;
- aparece por primera vez tras una sesión VPN anómala;
- se ejecuta desde directorios temporales;
- utiliza tokens o argumentos desconocidos;
- crea persistencia como servicio;
- conecta con infraestructura no asociada a la organización;
- coincide con actividad de RDP, SMB, PsExec o exfiltración.
También deben revisarse túneles SSH, proxies SOCKS, utilidades de transferencia cloud y conexiones salientes persistentes desde servidores que normalmente no las necesitan.
Parchear Citrix Bleed 2 es necesario, pero no suficiente
Citrix publicó las siguientes versiones corregidas:
Las versiones generales 12.1 y 13.0 están fuera de soporte y deben migrarse a una rama compatible.
La actualización corrige la vulnerabilidad, pero no demuestra que el dispositivo no fuera explotado antes. Tampoco debe asumirse que invalida automáticamente todos los artefactos de sesión que un atacante pudiera haber obtenido.
Después de actualizar todos los nodos del par HA o del clúster, Citrix recomienda finalizar las conexiones ICA y PCoIP activas:
kill icaconnection -all
kill pcoipConnection -all
Además, la organización debería:
- Revisar el periodo comprendido entre la primera posible exposición y la remediación.
- Analizar los registros AAA, VPN, NetScaler, firewall, EDR y Active Directory.
- Identificar sesiones utilizadas desde direcciones IP o ASN inesperados.
- Buscar cuentas, servicios o configuraciones creados durante ese periodo.
- Revisar instalaciones de herramientas RMM y utilidades de túnel.
- Comprobar accesos a controladores de dominio, hipervisores, NAS y sistemas de backup.
- Rotar las credenciales o secretos afectados cuando existan indicios de exposición.
- Activar un proceso formal de respuesta a incidentes y análisis forense si no puede descartarse el compromiso.
No debe realizarse una rotación indiscriminada sin coordinación. Cambiar credenciales de cuentas de servicio, integraciones o infraestructura crítica sin conocer sus dependencias puede provocar una interrupción adicional. La rotación debe priorizarse según las evidencias y ejecutarse mediante un plan controlado.
Qué hacer si todavía no puedes actualizar
La recomendación principal es instalar una versión corregida cuanto antes.
Cuando no sea posible hacerlo inmediatamente, la reducción de exposición debe ser temporal y documentada. Dependiendo de la arquitectura, puede incluir:
- retirar el servicio de Internet;
- deshabilitar los servidores virtuales Gateway o AAA afectados;
- restringir el acceso mediante controles de red;
- reforzar la monitorización del endpoint vulnerable;
- conservar registros suficientes para la investigación;
- establecer una ventana urgente de actualización.
Estas medidas compensatorias no convierten una versión vulnerable en segura. Solo reducen temporalmente la superficie mientras se completa la remediación.
Hardening para reducir el impacto
La respuesta no debe limitarse al appliance. Citrix Bleed 2 demuestra que una sesión comprometida en el perímetro puede convertirse rápidamente en movimiento lateral si la red interna ofrece pocas barreras.
Controlar las herramientas de administración remota
La organización debería mantener:
- una relación de herramientas RMM autorizadas;
- un propietario técnico para cada herramienta;
- versiones y servidores de gestión permitidos;
- reglas EDR para detectar alternativas no aprobadas;
- controles de aplicación cuando sean viables;
- revisión periódica de agentes abandonados.
Lo anómalo no es necesariamente utilizar una herramienta remota. Lo anómalo es no poder explicar por qué hay tres distintas en el mismo servidor.
Segmentar la infraestructura crítica
Una sesión VPN no debería proporcionar acceso directo y generalizado a:
- controladores de dominio;
- consolas de virtualización;
- infraestructura de backup;
- dispositivos NAS;
- plataformas de gestión;
- redes administrativas.
Estos activos necesitan segmentación, cuentas administrativas separadas y controles adicionales de acceso.
Controlar el tráfico saliente
La seguridad perimetral no consiste únicamente en bloquear conexiones entrantes. También debe existir visibilidad sobre qué servidores pueden abrir túneles, utilizar proxies o transferir grandes volúmenes de información a servicios cloud.
Una política de salida bien diseñada permite detectar canales alternativos antes de que se utilicen para persistencia o exfiltración.
Gestionar continuamente la exposición
Un Gateway vulnerable y publicado en Internet debe tener prioridad sobre vulnerabilidades internas de bajo impacto, aunque todas aparezcan juntas en el mismo escáner.
La priorización debe considerar:
- exposición externa;
- explotación conocida;
- criticidad del activo;
- privilegios alcanzables;
- controles compensatorios;
- impacto sobre la recuperación.
Este enfoque forma parte de un programa de gestión continua de la exposición o CTEM y de una gestión de vulnerabilidades basada en riesgo real.
También resulta útil combinar CVSS con fuentes como KEV, EPSS y SSVC. Explicamos cómo utilizarlas en nuestra guía sobre priorización de vulnerabilidades explotables con KEV, EPSS y SSVC.
Qué implica para NIS2 y DORA
Para una organización sujeta a NIS2 o DORA, un NetScaler vulnerable expuesto a Internet no es únicamente un problema técnico.
Puede revelar deficiencias en:
- inventario de activos;
- gestión de vulnerabilidades;
- monitorización;
- control de accesos remotos;
- respuesta a incidentes;
- continuidad de negocio;
- gestión del riesgo de terceros;
- conservación de evidencias.
NIS2 exige medidas técnicas, operativas y organizativas proporcionadas para gestionar los riesgos de seguridad y responder a incidentes significativos.
DORA exige a las entidades financieras gestionar el riesgo tecnológico, registrar y clasificar incidentes, probar la resiliencia operativa y controlar las dependencias de proveedores tecnológicos.
En ambos casos, la organización debe poder acreditar:
- cuándo identificó que estaba afectada;
- cómo priorizó la vulnerabilidad;
- cuándo aplicó la corrección;
- qué sesiones invalidó;
- qué registros revisó;
- cómo descartó o confirmó una intrusión;
- qué medidas implantó para evitar una repetición.
No basta con presentar una captura que demuestre que el appliance ejecuta una versión corregida. Debe existir una trazabilidad completa entre detección, decisión, remediación, validación e investigación.
El verdadero perímetro es la sesión
Los dispositivos VPN y de acceso remoto concentran identidad, conectividad y confianza en un único punto expuesto a Internet. Por eso resultan tan valiosos para los atacantes.
Anubis no ha inventado una técnica completamente nueva. Ha combinado piezas conocidas de una forma eficaz:
- Obtener acceso mediante una sesión o credencial válida.
- Confundirse con la actividad normal utilizando herramientas legítimas.
- Crear canales alternativos de control.
- Alcanzar los sistemas que determinan la capacidad de recuperación.
- Exfiltrar información.
- Cifrar o destruir cuando la organización dispone de menos opciones.
La defensa útil no consiste en asumir que el borde nunca será vulnerado. Consiste en poder detectar rápidamente que una sesión legítima está siendo utilizada de manera ilegítima, invalidarla y contener el acceso antes de que llegue a los sistemas críticos.
La sesión se ha convertido en parte del perímetro y debe protegerse como tal.
¿Tu NetScaler estuvo expuesto durante la ventana vulnerable?
Actualizar CVE-2025-5777 es solo el primer paso. Si el dispositivo permaneció accesible desde Internet, también hay que determinar si se filtraron sesiones, si alguna fue reutilizada y qué actividad se produjo después.
Hard2bit puede ayudarte a:
- revisar la exposición y la versión de los appliances;
- analizar registros de NetScaler, VPN, firewall, EDR y Active Directory;
- localizar sesiones potencialmente secuestradas;
- identificar herramientas RMM o túneles no autorizados;
- contener una intrusión activa;
- documentar las evidencias necesarias para NIS2, DORA, ENS o ISO 27001.
Solicita una revisión técnica de la exposición o activa nuestro equipo de respuesta a incidentes.
Fuentes técnicas
- Boletín CTX693420 de Citrix
- Investigación de Arctic Wolf sobre Anubis, Citrix Bleed 2 y cloudflared
- Análisis y detecciones de Citrix Bleed 2 de Splunk
- Aviso de INCIBE-CERT sobre las vulnerabilidades de NetScaler
- Registro de CVE-2025-5777 en NVD
Aviso
Este artículo se publica únicamente con fines informativos y formativos. Los indicadores técnicos, consultas de detección, comandos, versiones afectadas y medidas de remediación descritos pueden variar en función de la versión de NetScaler, la arquitectura, la configuración y las herramientas de seguridad utilizadas por cada organización.
Antes de ejecutar cualquier comando o aplicar cambios en un entorno de producción, debe comprobarse la información vigente publicada por Citrix y por los proveedores de seguridad correspondientes, probar el procedimiento en un entorno controlado cuando sea posible y seguir los procesos internos de gestión de cambios y respuesta a incidentes.
La presencia de un indicador, herramienta o conexión de red mencionados en este artículo no confirma por sí sola una actividad maliciosa ni que se haya producido un compromiso. Del mismo modo, la ausencia de estos indicadores no permite descartar una intrusión. Cuando existan sospechas de explotación o acceso no autorizado, deben preservarse las evidencias disponibles y recurrirse a profesionales cualificados de respuesta a incidentes o análisis forense digital.