Qilin e Inc encadenan un bypass de PAN-OS durante meses

<p>El perímetro es ahora el vector de ataque. Unit 42 confirmó el lunes que los operadores de ransomware Spikey Scorpius (Qilin) y Tarnished Scorpius (Inc) siguen explotando activamente CVE-2026-0257, un bypass de autenticación en los portales y gateways de GlobalProtect de PAN-OS, para saltarse el MFA y establecer sesiones VPN dentro de redes corporativas. Informes públicos también vinculan la vulnerabilidad con grupos que despliegan el ransomware Settra. Las víctimas abarcan educación, finanzas, sanidad, administración pública, energía, manufactura y más, y la fase posterior a la explotación termina en tus hipervisores.</p>

<p>Lo que hace este caso especialmente doloroso es la cronología. El fallo se parcheó y se incluyó en KEV en mayo, la explotación empezó en cuestión de días y, cinco meses después, varios grupos de ransomware siguen aprovechando gateways sin parchear. Si tu entorno de PAN-OS o Prisma Access no se ha actualizado, no estás ante un riesgo teórico, sino ante una carrera en la que quizá ya vas perdiendo.</p>

La cronología: parcheada en mayo, comprometida a mediados de mayo

<p>Reconstruyamos esto en orden, porque la secuencia es la historia.</p>

<p>13 de mayo. Palo Alto Networks divulgó y parcheó CVE-2026-0257 (CVSS 7.8), inicialmente con gravedad media, y afirmó que conocía intentos de explotación pero que no había observado explotación maliciosa, según The Register. CISA la añadió ese mismo día al catálogo de Vulnerabilidades Explotadas Conocidas. El fallo en sí: un bypass de autenticación en los componentes del portal y gateway de GlobalProtect que permite a un atacante no autenticado eludir los controles de seguridad e iniciar conexiones VPN.</p>

<p>Desde el 17 de mayo. Esa valoración inicial envejeció rápido. A finales de mayo, investigadores de Rapid7 informaron de explotación exitosa en varios entornos de clientes desde al menos el 17 de mayo, cuatro días después del parche. El 29 de mayo es la línea que Unit 42 traza entre la actividad previa a la prueba de concepto y la posterior, lo que importa para cómo buscar indicios (más abajo).</p>

<p>Principios de junio. El informe de amenazas de Unit 42 indica que sus investigaciones sobre intrusiones que abusan del fallo llevan activas desde principios de junio, en once sectores identificados. En julio, Arctic Wolf detectó a Qilin explotando el mismo CVE en operaciones que iban desde ataques rápidos de solo cifrado hasta doble extorsión completa, según The Hacker News. Después, ReliaQuest detectó a operadores de Qilin y Settra usándolo, y el 19 de octubre Unit 42 actualizó su informe para confirmar que Qilin e Inc siguen haciéndolo: casi cinco meses de encadenamiento sostenido de ransomware contra una sola CVE perimetral.</p>

<p>Es el modo de fallo clásico de KEV: existe una solución, se publica el aviso y una buena parte de Internet simplemente nunca parchea. Los atacantes no necesitan un zero-day cuando una CVE de 158 días sigue funcionando perfectamente.</p>

El primitivo: saltar el portal, heredar la confianza

<p>Este es el mecanismo, con el nivel de detalle que respaldan los informes. GlobalProtect gestiona la autenticación y la entrega de configuración en el portal; el gateway termina las sesiones VPN. CVE-2026-0257 permite a un atacante eludir los controles de autenticación del portal e iniciar una conexión VPN, que además evita el MFA, porque la sesión nunca se autenticó correctamente. No puedes salir con MFA de un fallo que omite directamente el paso de autenticación. Es la diferencia entre una ganzúa y la fuerza bruta: no hay intentos fallidos que limitar ni inicios de sesión fallidos que alertar, porque no hay ningún inicio de sesión fallido.</p>

<p>Unit 42 es cuidadosa al distinguir lo confirmado de lo supuesto: solo una pequeña parte de los dispositivos sondeados llegó a establecer sesiones VPN, generando eventos de gateway conectado, y en sus primeras observaciones no se identificó comportamiento posterior al acceso ni movimiento lateral. Los casos de ransomware documentados desde junio son una fase distinta y posterior, cuando la operación se vuelve ruidosa. Por tanto, un evento de gateway conectado que coincida con estos indicadores no es prueba de ransomware, pero la recomendación de Unit 42 no admite dudas: trátalo como un incidente, no como una curiosidad.</p>

<p>La cadena posterior a la explotación que describe Unit 42 es tradecraft de ransomware de manual con un giro desagradable:</p>

1. Obtener el punto de apoyo mediante CVE-2026-0257 y establecer una sesión VPN, eludiendo el MFA.
2. Reconocer la red interna con herramientas RMM de doble uso: software legítimo haciendo trabajo ilegítimo, para que pase desapercibido.
3. Moverse lateralmente por RDP y SMB.
4. Preparar herramientas de robo de credenciales y exfiltración, y luego desplegar el ransomware.

El jefe final: volcado de credenciales offline desde un VMDK

<p>Ahora el giro, y hay que reconocer el mérito: es un trabajo ofensivo realmente ingenioso, por mucho que nos disguste quién lo hace. Andy Piazza, de Unit 42, describe un caso en el que los atacantes pivotaron desde el gateway VPN comprometido hasta el dispositivo de gestión vCenter. Desde allí desactivaron el control de seguridad execInstalledOnly en los hipervisores ESXi y ejecutaron una herramienta personalizada que volcó credenciales offline, directamente desde el disco virtual (VMDK) de un controlador de dominio.</p>

<p>Piensa en por qué es brutal. Tu EDR vive en el sistema operativo invitado. Si el atacante opera en la capa del hipervisor y lee el disco del controlador de dominio sin ejecutar nada dentro del invitado, la telemetría interna por la que pagaste no ve nada. Es el equivalente de seguridad a robar un archivo de guardado del disco en lugar de enfrentarte al jefe dentro del juego. Unit 42 lo califica como un método muy sofisticado para obtener credenciales de todo el dominio, y por una vez el adjetivo está justificado: los hechos demuestran por qué.</p>

<p>Y como un solo punto de apoyo nunca basta, Unit 42 observó a actores encadenando el acceso a PAN-OS con la explotación de CVE-2023-27532 contra la infraestructura de backup de Veeam: ataca las copias de seguridad antes que la producción, para que la víctima no tenga nada limpio desde lo que restaurar. Si tu plan de respuesta a ransomware asume que tus backups sobrevivirán, esta combinación debería quitarte el sueño. Ya hemos cubierto encadenamientos igual de metódicos en nuestro análisis de un exploit de root construido a partir de un fallo de 37 años: atacantes pacientes que ensamblan cadenas fiables con piezas que los defensores olvidaron.</p>

El multiplicador de errores de configuración en tu interfaz de gestión

<p>Oculto en la actualización del 20 de octubre hay un hallazgo que merece su propia cola de tickets. Durante las intervenciones de respuesta a incidentes asociadas a la campaña Lunar Peak, Unit 42 encontró una y otra vez el mismo error: las organizaciones habían asignado perfiles de GlobalProtect a servicios HTTP/HTTPS en sus interfaces de gestión, exponiendo sin querer el plano de gestión a Internet en los puertos 4443 y 3879, a menudo sin que nadie lo supiera. Una CVE en GlobalProtect más una interfaz de gestión expuesta a Internet es un error que se agrava solo, y los atacantes solo necesitan que lo cometas una vez.</p>

<p>El paso de verificación es refrescantemente sencillo y puedes hacerlo desde una cafetería: desde una red externa, intenta una conexión HTTPS fuera de banda a tu IP de gestión en los puertos 4443 y 3879. Si responde, tienes un problema. La solución es configurar correctamente los perfiles Interface Management según la documentación de Palo Alto Networks: restringe el acceso de gestión, aplica el mínimo privilegio y no permitas que los perfiles GP toquen el plano de gestión.</p>

Cómo buscar esto hoy

<p>Unit 42 separó sus indicadores por fase, y esa división es útil operativamente. Para la actividad previa a la PoC (antes del 29 de mayo), busca en los logs de GlobalProtect inicios de sesión exitosos desde nueve IP, entre ellas 23.128.228[.]6, 104.207.144[.]154, 146.19.216[.]119, 146.19.216[.]120, 146.19.216[.]125, 179.43.172[.]213, 185.195.232[.]139, 198.12.106[.]60 y 202.144.192[.]47. Después, busca eventos de gateway conectado con identificadores de host obviamente sintéticos: la PoC y las herramientas dejan huellas como aa:bb:cc:dd:ee:ff, 00:11:22:33:44:55 y nombres de dispositivo como WINDOWS-LAPTOP-001, DESKTOP-GP01 y GP-CLIENT. Las flotas reales tienen nombres de host desordenados y variados; los valores de marcador uniformes son la pista.</p>

<p>Para la actividad posterior a la PoC, el exploit público tiene codificada su configuración de cliente, así que busca eventos de gateway conectado exitosos que coincidan con:</p>

endpoint_os_version : "Microsoft Windows 10 Pro 64-bit"
source_user_info.domain : (empty)

<p>La lógica de detección es lo bastante simple como para esbozarla como una consulta: cualquier evento de gateway conectado cuya cadena de sistema operativo del endpoint coincida exactamente con el valor codificado en la PoC y cuyo campo de dominio esté vacío merece la atención de un analista. Un campo de dominio vacío en una conexión exitosa es, en la mayoría de los entornos, una anomalía que merece alerta por sí sola.</p>

<p>Si encuentras un acierto, el orden de respuesta importa. Asume que la sesión VPN fue un punto de apoyo, no todo el ataque. Busca herramientas RMM que no hayas desplegado tú, movimiento lateral por RDP/SMB desde el segmento del gateway y, dado el pivote hacia vCenter, audita la capa de hipervisor: quién tocó execInstalledOnly, si se montaron o copiaron VMDK y si se sondeó la infraestructura de Veeam en busca de CVE-2023-27532. Después, rota las credenciales de dominio asumiendo que se volcaron offline, porque el EDR interno no lo habría detectado. Cortex Xpanse de Palo Alto puede enumerar gateways y portales PAN-OS expuestos si lo tienes; si no, un escaneo externo de tus rangos te dará casi la misma respuesta.</p>

Las cuentas de coste que nadie quiere hacer

<p>La pregunta del editor —¿es tu dispositivo perimetral el punto de entrada de ransomware de mayor riesgo?— se responde sola con estos datos. Una CVE que inicialmente se valoró como media ha alimentado al menos a tres operaciones de ransomware durante cinco meses, porque el parche requiere una ventana de mantenimiento y el exploit solo necesita una petición GET. El coste de contención y parcheo es una parada planificada, una auditoría de configuración, una búsqueda en logs y quizá una rotación de credenciales. El coste de la exposición es lo que documentó Unit 42: robo de credenciales de todo el dominio, compromiso a nivel de hipervisor, backups destruidos y cifrado en toda la infraestructura. Ni The Register ni Unit 42 cuantifican económicamente los incidentes, y Palo Alto Networks no respondió a las preguntas de The Register, incluida la de cuántas organizaciones han sido afectadas, así que el número real se desconoce. Pero la asimetría, sí.</p>

<p>Parchea a una versión de PAN-OS corregida o aplica las soluciones alternativas documentadas por el fabricante, ejecuta las búsquedas anteriores, prueba tus interfaces de gestión desde el exterior y revisa tu postura en ESXi y Veeam mientras estás en ello. El conjunto completo de indicadores y los enlaces a los avisos están en el informe de amenazas de Unit 42, con análisis técnico complementario de Rapid7 y Arctic Wolf citado en él. El puente levadizo lleva cinco meses bajado. Ve a levantarlo.</p>