BeyondTrust Remote Support: zero-day explotado por espías chinos

¿Cuánto tiempo necesita un grupo de intrusión respaldado por un Estado dentro de tu appliance de soporte remoto antes de que «lo parcheamos» deje de ser una respuesta suficiente? Según lo publicado esta semana por Mandiant y Google Threat Intelligence Group, la respuesta honesta es unos once minutos: el tiempo que transcurre entre la primera solicitud maliciosa y una web shell instalada en el directorio raíz web del appliance.

La vulnerabilidad es CVE-2026-102764, una omisión de autenticación crítica en BeyondTrust Remote Support (antes Bomgar) en las versiones 26.2.3 y anteriores, con puntuación 9,3 en CVSS 4.0. Según The Record, la explotación se remonta al 29 de agosto, semanas antes de que alguien la detectara, y se atribuye a ARMORY CASTLE, también conocido como UNC5221, un grupo que Mandiant y BeyondTrust describen como una operación de espionaje patrocinada por el Estado chino. CISA añadió la falla a su catálogo de Vulnerabilidades Explotadas Conocidas el 16 de octubre y dio a las agencias federales hasta el 19 de octubre, mañana, para remediarla. Si tienes un appliance autoalojado, este fin de semana no es de descanso.

El fallo: suplantar identidad para entrar y, después, operar sobre archivos

La entrada de CISA en KEV describe CVE-2026-102764 como una omisión de autenticación mediante suplantación que permite a un atacante remoto realizar operaciones sobre archivos en el appliance. El informe de Mandiant, citado por CSO Online, precisa el alcance: un atacante no autenticado puede encadenar esas operaciones sobre archivos hasta obtener control a nivel de host y llegar a todas las credenciales que el appliance almacena o gestiona. Para un equipo cuya función es precisamente gestionar sesiones remotas privilegiadas, es la peor primitiva posible que ponerle en las manos a alguien.

BeyondTrust divulgó la falla en el aviso BT26-05 y afirma que publicó la corrección, BT26-05-RS, el 8 de octubre, antes de la divulgación pública. Hay una letra pequeña en la alerta de CISA: los parches solo existen para las versiones compatibles (24.3.1 y posteriores). Si tu appliance ejecuta una versión anterior, no recibes un hotfix; recibes un proyecto de actualización. Las instancias SaaS alojadas por BeyondTrust de Remote Support y Privileged Remote Access se parchearon automáticamente, y la empresa indica que esos clientes no necesitan ninguna acción adicional. La compañía está reteniendo detalles técnicos de la vulnerabilidad mientras los clientes autoalojados aplican el parche, así que nadie fuera de las partes involucradas ha publicado una prueba de concepto. Todo lo que se sabe sobre la explotación proviene de respuesta a incidentes, no de teoría.

Once minutos desde la primera solicitud hasta la web shell

La cadena de post-explotación que documentó Mandiant merece un repaso, porque es una lección magistral en cómo exprimir al máximo la persistencia a partir de un único fallo en un appliance. La cronología de BeyondTrust sitúa la primera explotación el 29 de agosto, contra una instancia alojada por BeyondTrust y un appliance autoalojado. Unos 11 minutos después de la primera solicitud maliciosa, según el análisis de Google, apareció en el directorio raíz web del appliance una web shell en PHP que Mandiant denomina SAWFLY.

SAWFLY se ejecutó con una cuenta de servicio sin privilegios: un obstáculo menor, no un muro. Para escalar privilegios, el actor usó un truco clásico de los CTF: copiar el binario de la shell a una ruta aparentemente inofensiva, asignarle root y activar el bit SUID. Mandiant describió los pasos, que en esencia tienen este aspecto:

# copy the shell to a path that blends in with system daemons
cp /bin/sh /usr/bin/dbus-authd
# make root the owner and set the SUID bit
chown root /usr/bin/dbus-authd
chmod u+s /usr/bin/dbus-authd
# any user executing it now gets an euid-0 shell
/usr/bin/dbus-authd -p

Es el tipo de truco que esperarías en una máquina de Hack The Box, y precisamente por eso funciona en appliances que nadie audita: un binario SUID llamado dbus-authd no activa ninguna alarma si nadie lo busca. Después, el actor plantó un script de inicio que escribe una entrada de sudo sin contraseña en la plantilla de sudoers de BeyondTrust, de modo que root sobrevive a reinicios y a restablecimientos de configuración, no solo a la sesión actual. Es persistencia diseñada contra las dos cosas que un administrador intentaría primero.

Después llegó el premio. El actor ejecutó varias variantes de bt-secrets, la utilidad de línea de comandos propietaria de BeyondTrust, para volcar la bóveda de credenciales del appliance: todas las credenciales que almacenaba el equipo. Luego, la herramienta de mesa de ayuda se volvió contra su propio dueño. Usando una cuenta de administrador comprometida, el atacante elevó los permisos de Jump Item y Team de la cuenta de No Access a Administrator.

Mandiant describió la consecuencia sin rodeos: ese único cambio de configuración dio al actor autorización permanente para lanzar sesiones remotas contra cualquier sistema incluido en la lista de Jump Items del appliance, sin necesidad de más explotación, porque el propio appliance ahora trataba ese acceso como legítimo.

Léelo otra vez si gestionas una mesa de ayuda: la lista de Jump Items es el mapa de tus endpoints que tiene el appliance. Tener derechos de administrador sobre ella equivale a un acceso remoto con apariencia legítima a todo lo que hay detrás, montado sobre la herramienta en la que confía tu propio equipo de TI. Para la exfiltración y el C2, el actor desplegó BARECLAW, un tunelizador SOCKS5 a medida, y editó la configuración de HAProxy del appliance para enrutar el tráfico hacia él mediante un listener local oculto: un proxy de entrada que parece tráfico normal del appliance. Para cubrir sus huellas, se borraron más de una docena de registros del sistema, del servidor web y de aplicaciones. La conclusión de Mandiant, según The Record: cualquier appliance vulnerable accesible desde internet debe considerarse potencialmente comprometido hasta que sea revisado.

Quién está detrás y por qué el precedente de Ivanti debería preocuparte

Mandiant sigue al actor como ARMORY CASTLE (antes UNC5221) y, junto con GTIG, lo atribuye a una presunta operación de espionaje vinculada a China (PRC); BeyondTrust respaldó esa evaluación y la describió como una «operación de espionaje patrocinada por el Estado centrada en la recopilación de inteligencia a largo plazo». El grupo está activo desde octubre de 2023, con objetivos documentados que incluyen servicios legales, proveedores SaaS, empresas de externalización de procesos de negocio, empresas tecnológicas y gobiernos. Mandiant señaló que los atacantes «aprovecharon un conocimiento profundo de los componentes internos de los appliances de BeyondTrust»; el abuso de bt-secrets por sí solo demuestra que estudiaron el producto, no solo el fallo.

El patrón es más revelador que la atribución. ARMORY CASTLE ya estuvo implicado en zero-days contra Citrix y varias fallas de Ivanti: CVE-2023-46805, CVE-2024-21887 y CVE-2025-0282. Su modus operandi, según lo describió BeyondTrust: usar un zero-day de forma selectiva contra objetivos escogidos y, una vez que la vulnerabilidad es pública, pasar a la explotación masiva de cada instancia sin parchear. En un caso de 2025, Mandiant informó de que el actor tomó un parche de Ivanti para una falla de bajo riesgo, lo estudió y aplicó ingeniería inversa para lograr ejecución remota de código funcional contra appliances sin parchear. La advertencia de GTIG y Mandiant esta semana fue explícita:

«Las organizaciones deben prepararse para una posible explotación generalizada tras esta divulgación», afirmaron Google Threat Intelligence Group y Mandiant en su entrada de blog.

Así que el reloj no solo corre para el parcheo: corre para el margen entre la divulgación y la fase de explotación masiva, que con esta banda históricamente arranca rápido.

Un mes sin detección y una lección incómoda sobre la clasificación de alertas

La cronología de la detección merece su propio escrutinio, porque es la parte de esta historia que se aplica a tu entorno. La explotación comenzó el 29 de agosto. BeyondTrust detectó la intrusión el 28 de septiembre, alertada solo después de que se informara públicamente el compromiso de los appliances perimetrales de otro proveedor y de que Mandiant enviara un aviso breve e inespecífico que puso a los ingenieros a buscar. «Nuestros sensores se dispararon en tiempo real cuando el actor escaló privilegios», escribió BeyondTrust, pero la herramienta de triaje integrada en su plataforma de detección de terceros cerró esas alertas como falsos positivos. La compañía no ha nombrado al proveedor y afirma que está trabajando con él para que la clasificación automatizada no pueda cerrar por sí sola señales de alta severidad.

Hay que reconocer a BeyondTrust que, cuando las personas miraron, la respuesta fue rápida: la instancia alojada se contuvo 27 minutos después de la identificación. Pero un mes de permanencia en un appliance perimetral, terminada por un aviso externo y agravada por un bot de triaje que cierra alertas automáticamente, es un escenario que cada SOC debería simular con sus propias herramientas esta semana. Ni BeyondTrust ni Mandiant han dicho si otros clientes fueron comprometidos: es una incógnita confirmada y, dado el historial del actor, la ausencia de víctimas nombradas no garantiza que no las haya.

La matemática entre actualizar y sufrir una brecha

Aquí está el compromiso en términos concretos. Opción A: aplicar BT26-05-RS, una actualización del appliance, algo de negociación de ventanas de cambio y quizá una conversación incómoda sobre por qué Remote Support quedó una o dos versiones atrás. Si estás en una versión anterior a la 24.3.1, la opción A incluye primero una actualización completa de versión, que es trabajo real pero trabajo programable.

La opción B es el camino que CISA describe para una posible compromisión, y parece una factura de respuesta a incidentes: aislar el appliance; tomar una instantánea de los appliances virtuales o crear una imagen forense de los físicos; reenviar los eventos de syslog y de sesión al SIEM antes de tocar nada; extraer los registros de WAF, proxy inverso y cortafuegos perimetral de toda la ventana de exposición; reconstruir desde un estado conocido como bueno; y luego rotar todas las credenciales que el appliance almacenó o inyectó, revocar todas las sesiones de soporte activas y revisar los nuevos registros de MFA en cuentas privilegiadas. Ese último punto es el más traicionero: rotar credenciales de todo lo que un appliance de soporte ha tocado se mide en semanas, no en horas. La opción A es más barata en un orden de magnitud y, para las agencias federales, su plazo vence mañana según el calendario de KEV.

Qué hacer este fin de semana

Primero detección, luego remediación: con una ventana de exposición de un mes y un actor que borra registros, parchear un equipo comprometido solo le da al atacante un equipo recién parcheado. Pasos concretos, extraídos de la alerta de CISA y de los hallazgos de Mandiant:

• Envía los eventos de syslog y de sesión del appliance a tu SIEM antes de reconstruir, y conserva una imagen o instantánea para análisis forense.
• Busca los artefactos de persistencia que nombró Mandiant: un /usr/bin/dbus-authd con SUID, entradas de sudo sin contraseña en la plantilla de sudoers, scripts de inicio inesperados y configuraciones de HAProxy que enrutan a listeners locales ocultos.
• Busca el comportamiento, no solo los archivos: sesiones privilegiadas no reconocidas, cambios de permisos de Jump Item o Team a Administrator, archivos de script desconocidos y huecos en los registros o en su reenvío; el actor borró más de una docena de archivos de registro.
• Reconstruye desde un estado conocido como bueno, aplica BT26-05-RS, rota todas las credenciales que el appliance almacenó o inyectó, revoca las sesiones de soporte activas y revisa los registros de MFA en cuentas privilegiadas.
• Reduce la superficie de ataque de forma permanente: limita el acceso externo solo a los servicios necesarios para dar soporte a los usuarios y restringe las interfaces de administración a redes de confianza.
• Revisa tu automatización de triaje: si tu herramienta puede cerrar automáticamente alertas de alta severidad, el mes de permanencia de BeyondTrust es tu advertencia.

Los appliances perimetrales siguen siendo la puerta de entrada elegida porque concentran confianza: credenciales, brokering de sesiones y un mapa de endpoints. ARMORY CASTLE ya ha ejecutado este manual contra Ivanti, Citrix y BeyondTrust. Parchea, crea imágenes, busca y rota: en ese orden, y empieza ahora.