Un zero-day de BeyondTrust Remote Support se explota desde agosto

BeyondTrust publicó el 15 de octubre de 2026 el aviso BT26-05 para CVE-2026-102764, un fallo de Remote Support con CVSS 9,3 que deja a un atacante sin credenciales manipular ficheros del appliance, y Mandiant confirma que el grupo de espionaje ARMORY CASTLE lo explotaba como zero-day desde finales de agosto. Las instancias SaaS quedaron parcheadas el 9 de octubre y las autoalojadas hasta la versión 26.2.3 dependen de que el administrador instale el parche BT26-05-RS.

Qué ha pasado

El fabricante divulgó el fallo el 15 de octubre de 2026 en su aviso BT26-05, que lo califica de crítico con una puntuación de 9,3. El registro CVE, publicado ese mismo día, describe el problema como una validación insuficiente del origen de los mensajes que intercambian componentes internos de Remote Support, lo que permite a un atacante hacer operaciones sobre ficheros del appliance. El producto se llamaba Bomgar hasta su compra por BeyondTrust y lo usan los equipos de soporte TI para conectarse a equipos de usuarios y a servidores.

Ese mismo día, Google Threat Intelligence Group (GTIG) y Mandiant publicaron su informe sobre ARMORY CASTLE, el grupo al que atribuyen la explotación. Mandiant halló las pruebas durante una respuesta a incidentes en un cliente y sitúa la primera explotación a finales de agosto de 2026, siete semanas antes del aviso. El informe define al grupo como «a suspected PRC-nexus espionage threat actor» (un actor de espionaje presuntamente vinculado a la República Popular China) y recuerda que antes lo seguía como UNC5221. Según BleepingComputer, CrowdStrike llama Warp Panda a la misma actividad.

La ventana de exposición es lo que más preocupa. Según el informe de Mandiant, BeyondTrust aplicó el parche a todos los inquilinos SaaS el 9 de octubre de 2026, seis días antes de hacer público el fallo, mientras que los clientes con appliance propio solo lo reciben de forma automática si tienen activadas las actualizaciones críticas. BleepingComputer fecha ese despliegue SaaS el 8 de octubre, un día antes que Mandiant, y nos quedamos con la fecha del laboratorio porque encaja con la del aviso del fabricante. En el momento de escribir esta noticia, la mañana del 16 de octubre, el CVE no figura en el catálogo KEV de CISA, cuyo feed se actualizó por última vez el 15 de octubre a las 17:00 UTC.

Detalles técnicos

El dato de CVSS procede de la ficha de NVD, que a 16 de octubre solo recoge la puntuación enviada por BeyondTrust como CNA en formato 4.0, con estado Received. No hay vector 3.1 publicado, así que no podemos comparar ambas escalas. El vector no exige privilegios ni interacción del usuario y el impacto es alto en confidencialidad, integridad y disponibilidad del propio appliance.

Mandiant resume la intrusión en un diagrama de ocho pasos. Los cinco primeros ocurren dentro del appliance y los tres últimos saltan a la red interna con credenciales de administrador. El informe subraya que el grupo demostró «a deep understanding of BeyondTrust appliance internals» (un conocimiento profundo de las interioridades del appliance de BeyondTrust) al abusar de utilidades propias, plantillas de arranque y el enrutado del proxy inverso.

El diagrama oficial recoge el efecto de cada fase, no el detalle del exploit, que BeyondTrust no ha publicado. Tras explotar el fallo, el grupo subió una webshell que Mandiant llama SAWFLY y que apareció en la raíz web unos once minutos después de las primeras peticiones. Es un implante PHP ligero y ofuscado que responde con un 404 cuando falta su parámetro, para pasar desapercibido ante escáneres automáticos. Con la webshell en marcha, el atacante escaló a root, volcó el almacén de contraseñas del appliance con la utilidad interna bt-secrets y plantó un script de arranque para mantener privilegios de root tras un reinicio o un reseteo de configuración.

Nuestro gráfico resume esa cadena de post-explotación con los nombres de ficheros y rutas que publica Mandiant.

Para el salto a la red interna, ARMORY CASTLE desplegó un túnel propio escrito en C que Mandiant llama BARECLAW. Monta un proxy SOCKS5 sobre WebSocket y, en el caso observado, escuchaba en el puerto 19800 con un token de autenticación y la salida de registro desactivada. El grupo también modificó la configuración de HAProxy del appliance para que el proxy enrutara una ruta concreta hacia ese listener local, de modo que el backdoor solo fuera accesible a través del propio proxy inverso y quedara invisible a un escaneo externo. Con credenciales de administrador robadas entró en la consola de soporte y elevó un rol de Jump Item de No Access a Administrator, lo que le dio sesiones remotas hacia los equipos dados de alta en el appliance.

Mandiant publica tres indicadores de fichero. Conviene cargarlos en el EDR y el antivirus del perímetro.

GTIG acompaña el informe con reglas YARA de caza para las dos piezas de malware. Esta es la que detecta la webshell SAWFLY por sus constantes de transporte Base32 y el patrón de ejecución:

rule G_Hunting_Webshell_SAWFLY_1 {
  meta:
    author = "Google Threat Intelligence Group"
  strings:
    $b32 = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567" ascii wide
    $rc4 = "range(0,255)" ascii wide
    $pack = "pack('H*'," ascii wide
    $eval = "@eval(" ascii wide
    $code404 = "http_response_code(404)" ascii wide
  condition:
    filesize < 20KB and
    all of them
}

La segunda regla cubre el túnel BARECLAW y está en el mismo informe de GTIG. Sobre un proxy inverso o un WAF situado delante del appliance, Mandiant recomienda vigilar las rutas que quedan fuera del conjunto conocido de Remote Support, en especial rutas .php desconocidas y peticiones de upgrade a WebSocket desde fuera del rango de los técnicos de soporte y los endpoints gestionados.

A quién afecta

A cualquier organización con un appliance Remote Support en una versión hasta la 26.2.3 que haya estado accesible desde Internet entre finales de agosto y la aplicación del parche. Mandiant es tajante: todo appliance alcanzable desde Internet en una versión vulnerable durante la ventana de explotación «should be treated as potentially compromised until it has been reviewed» (debe tratarse como potencialmente comprometido hasta que se revise). El SaaS quedó cubierto el 9 de octubre, pero los pasos de rotación de credenciales y revisión de configuración siguen aplicando también ahí.

No hay un recuento de exposición específico de este CVE a 16 de octubre de 2026. La cifra más cercana la da BleepingComputer, que cita a Shadowserver y más de 1.400 instancias de Remote Support expuestas en Internet, sin desglose por países ni distinción entre equipos parcheados y vulnerables. En las fuentes consultadas no aparece una cifra de exposición en España ni un aviso de INCIBE-CERT o del CCN-CERT sobre este CVE a esa fecha. BeyondTrust es un proveedor habitual de acceso privilegiado en banca, sector público y grandes empresas, también en España, así que la ausencia de aviso nacional no equivale a ausencia de riesgo.

Esta es la cuarta vez en 2026 que un fallo de BeyondTrust Remote Support acaba en explotación o en el catálogo KEV, después de la cadena de inyección de comandos de febrero (CVE-2026-1731, con uso confirmado en ransomware) y los fallos de autenticación de julio. El producto se ha convertido en un objetivo recurrente, en la misma semana que los avisos de root en Cisco Secure Email Gateway y en los firewalls de Palo Alto.

Qué hacer

1. Aplica el parche BT26-05-RS. En self-hosted 24.3.1 o posterior, instálalo desde la interfaz /appliance o confirma que la actualización automática ya lo aplicó. En versiones anteriores, actualiza primero a una rama soportada. Si el parche no aparece en /appliance, abre un caso con soporte de BeyondTrust citando BT26-05.
2. Trata como comprometido cualquier appliance que estuviera expuesto en una versión vulnerable. Preserva antes de tocar: haz una instantánea de la máquina virtual con memoria y exporta el disco, y recoge los logs del syslog, del proxy inverso o WAF y del firewall perimetral de toda la ventana, porque el atacante con acceso root borra los registros locales.
3. Aísla al perímetro en lugar de hacerlo desde /appliance: bloquea el tráfico entrante hacia la dirección pública del equipo en el firewall para no alterar la configuración que luego vas a revisar, y deniega la salida salvo a los puntos de actualización y licencia de BeyondTrust.
4. Reconstruye en vez de limpiar. Mandiant recomienda redesplegar desde una imagen limpia y parcheada los equipos con compromiso confirmado o desconocido, porque el cliente no puede auditar el sistema de ficheros del host y la persistencia a nivel de host sobrevive al reinicio y al reseteo de configuración. Restaura solo una copia de configuración anterior a la ventana de exposición.
5. Rota las credenciales, pero solo después de parchear o reconstruir, en orden de dependencia: administración de /appliance, administradores y usuarios locales de /login, secretos de clientes de la API, cuentas de enlace de los proveedores de seguridad y claves de firma SAML, y el Vault de Remote Support o el Password Safe integrado. Rotarlas antes las expone a un atacante que aún controle el equipo.
6. Revisa la configuración de /login contra una línea base anterior a la ventana: cambios de usuarios y roles, sobre todo roles de Jump Item elevados a Administrator, cuentas de API, proveedores de seguridad y destinos de eventos salientes o de syslog. Elimina lo que no tenga registro de cambio o dueño conocido.
7. Busca en el appliance y en la red los indicadores publicados: ficheros inesperados en la raíz web, binarios SUID nuevos, cambios en scripts de arranque o en la plantilla de sudoers, configuración de HAProxy alterada, actividad de la utilidad bt-secrets, cambios de permisos de administrador y tráfico WebSocket saliente. Los indicadores de detección por comportamiento ayudan a priorizar esta caza.
8. Exige SAML con MFA resistente al phishing para todos los usuarios de /login, deja el rol de Jump Item por defecto en No Access y reenvía el syslog del appliance a un SIEM sobre TLS con retención de varios meses. Si confirmas un compromiso, notifícalo a INCIBE-CERT (empresas y ciudadanos) o al CCN-CERT (sector público).

Análisis

La lectura para quien gestiona uno de estos equipos es incómoda. Entre finales de agosto y el 15 de octubre hubo semanas de explotación silenciosa sin parche público, y el cliente no tiene forma de auditar el sistema de ficheros del host para saber si entró alguien. Eso convierte el estado del parche en una condición necesaria pero no suficiente: un appliance al día puede llevar dentro un backdoor que sobrevive al reinicio. La recomendación de Mandiant de reconstruir en vez de limpiar no es exagerada, es la consecuencia lógica de un dispositivo cerrado en el que la persistencia vive por debajo de lo que el administrador puede ver.

Lo que el aviso del fabricante no cuenta también importa. BeyondTrust describe el fallo como una operación sobre ficheros, sin entrar en qué permite encadenar, y es el informe de Mandiant el que muestra el salto de esa subida de fichero a control total del host y de las credenciales que el appliance custodia o intermedia. Para un producto cuya razón de ser es guardar accesos privilegiados, que un fallo de validación de origen termine en un volcado del almacén de secretos es el peor escenario posible.

GTIG avisa de lo que suele venir después. En campañas anteriores, ARMORY CASTLE pasó de la explotación selectiva como zero-day a la explotación oportunista y a gran escala en cuanto el fallo se hizo público, como ocurrió en 2024 con los fallos de Ivanti CVE-2023-46805 y CVE-2024-21887. El laboratorio valora «with high confidence» (con alta confianza) que el grupo seguirá usando zero-days en dispositivos de borde. La prudencia, por tanto, es asumir que en los próximos días intentarán explotar este CVE otros actores, y que los indicadores que hoy son de un incidente concreto pronto describirán una campaña más amplia.

Preguntas frecuentes

¿Estoy a salvo si mi instancia es SaaS?

El appliance en sí quedó parcheado el 9 de octubre de 2026 sin que tuvieras que hacer nada. Pero si tu instancia estuvo expuesta durante la ventana de explotación, Mandiant pide aplicar igualmente la revisión de configuración y la rotación de credenciales, porque el parche cierra la puerta pero no deshace un acceso previo. Revisa los informes de sesiones de soporte de ese periodo.

¿Basta con instalar el parche para quedar limpio?

No si el equipo estuvo expuesto. La intrusión implicó acceso root, volcado del almacén de credenciales, borrado de logs y cambios de persistencia, así que parchear no resuelve por sí solo un compromiso anterior. Mandiant recomienda reconstruir desde una imagen limpia los appliances con compromiso confirmado o desconocido y rotar después las credenciales.

¿Cómo sé si me han atacado?

Busca ficheros inesperados en la raíz web, binarios SUID nuevos como una copia de /bin/sh, cambios en la plantilla de sudoers o en los scripts de arranque, configuración de HAProxy modificada, actividad de la utilidad bt-secrets y tráfico WebSocket saliente del appliance. Como el atacante borra los logs locales, el syslog remoto y los registros del proxy inverso son la fuente fiable. Cualquier revisión seria arranca de una buena respuesta a incidentes.

¿Qué relación tiene este caso con los fallos anteriores de BeyondTrust?

Es un CVE distinto e independiente, pero el cuarto de 2026 en Remote Support. Los de febrero (CVE-2026-1731) y julio eran inyecciones de comandos y omisiones de autenticación, y este es una suplantación del origen de los mensajes internos. El patrón, repetido en Ivanti y en Fortinet, es que los dispositivos de acceso remoto se han vuelto la vía de entrada preferida de los grupos de espionaje. Por qué el perímetro ya no basta y hay que verificar cada acceso lo repasamos en nuestro texto sobre la era post-perímetro.