CVE-2026-102764 en BeyondTrust: qué hacer hoy mismo

El 16 de octubre de 2026 me llegó una alerta de CISA que me hizo dejar la taza de café a un lado: un APT con sello chino, conocido por la industria como Armory Castle (anteriormente UNC5221, también reportado como Warp Panda), llevaba un mes y medio operando dentro de instancias de BeyondTrust Remote Support (antes Bomgar) gracias a un zero-day que nadie en el mundo conocía. La ventana de exposición fue del 29 de agosto al 8 de octubre, y el parche estuvo disponible cinco días antes de la divulgación pública. Si tú administras uno de esos appliances on-prem — ya sea un help desk interno o una consola que expone a Internet para técnicos externos — este CVE te toca de cerca, y la respuesta no es solo “actualizar cuando pueda”.

El incidente loBeyondTrust documentó en su advisory BT26-05: detectaron actividad sospechosa en una instancia SaaS durante un barrido proactivo el 28 de septiembre, reprodujeron el vector ese mismo día, y notificaron a clientes con appliances auto-hospedados siete días después del fix. CISA, por su parte, agregó CVE-2026-102764 a su catálogo KEV el mismo día de divulgación, y la NHS del Reino Unido publicó una alerta equivalente (CC-4870). El contexto importa: esto no es un RCE apocalíptico de un firewall de borde, es un fallo de validación de origen en un componente interno del appliance de Remote Support que permite a un atacante remoto hacer operaciones de archivo sin autenticación. El CVSS es 9.3 (Critical), CWE-290. Las versiones afectadas son todas las de Remote Support iguales o anteriores a 26.2.3, y el código afectado también está en Privileged Remote Access — aunque ahí BeyondTrust dice que no encontró un camino de explotación. Para cualquier sysadmin que opera infraestructura de soporte remoto, esto es la versión adulta de “actualiza Windows”. Y este artículo es la guía operativa para hacerlo bien.

TL;DR — Lo que vas a tener al final

Qué es CVE-2026-102764 y por qué CWE-290 importa

El identificador CWE-290 corresponde a “Authentication Bypass by Spoofing” — una categoría que agrupa fallos en los que un componente acepta mensajes o credenciales que parecen venir de una fuente legítima sin validar de verdad el origen. En el caso de BeyondTrust Remote Support, el fallo está en un componente interno de mensajería: el sistema que coordina las sesiones entre el técnico, el cliente que solicita soporte y el appliance que media entre ambos. Ese componente recibe mensajes de varios procesos internos y, aparentemente, no validaba suficientemente el origen real del mensaje antes de ejecutar la operación solicitada.

Lo que hace este CVE técnicamente es permitir a un atacante remoto disparar operaciones de archivo sobre el appliance sin autenticarse. Sin usuario, sin credencial, sin token de sesión, sin necesidad de que alguien en la mesa de soporte esté haciendo algo. Lo único que necesita el atacante es alcanzar la interfaz del appliance desde la red. A partir de ahí, la operación de archivo no tiene un payload útil por sí sola (no es un RCE directo), pero es una primitiva muy flexible: el atacante puede escribir archivos al disco, moverlos, copiar, y dependiendo de cómo está montado el sistema de archivos del appliance, abusar del SUID binario, escribir en ubicaciones comprometidas, o manipular archivos que otros procesos consumen como configuración.

Aquí viene el matiz que la prensa especializada cubrió bien y que conviene tener claro. La primitiva de CVE-2026-102764 es “operación de archivo sin autenticación”. Lo que Armory Castle hizo con esa primitiva fue una cadena de explotación en varias etapas que empieza con la escritura de un webshell PHP, pasa por escalada a root, persiste vía configuración de arranque, roba credenciales, y termina modificando los permisos de Jump Items para pivotar a la red interna. La vulnerabilidad sola no es RCE; la cadena completa sí es RCE con persistencia y movimiento lateral. Cuando CISA puntúa el CVE en 9.3, lo que está evaluando es la combinación primitiva + exploit chain observado en producción.

Versiones afectadas y cómo verificar si tu appliance está en riesgo

La matriz de versiones según BeyondTrust y el análisis de Censys de la divulgación del 16 de octubre es esta:

Producto	Versión	Estado
BeyondTrust Remote Support	todas las versiones ≤ 26.2.3	Vulnerable — aplicar BT26-05-RS
BeyondTrust Remote Support	24.3.1 a 26.2.3	Aplicar parche directamente
BeyondTrust Remote Support	anteriores a 24.3.1	Upgrade primero a una versión soportada, luego aplicar el parche
BeyondTrust Remote Support SaaS	n/a	Ya parchado por BeyondTrust (auto-remediado el 9 de octubre)
BeyondTrust Privileged Remote Access	comparten código afectado	Aplicar parche preventivo (sin camino de explotación confirmado en PRA)

Verificar la versión del appliance es trivial por la interfaz web de administración. La ruta que BeyondTrust documenta para self-hosted es entrar a la consola /appliance con un usuario admin y revisar el panel “Appliance Information” o “Software Version” donde aparece la versión exacta. Si vas a administrarlo por SSH, el appliance tiene un shell restringido que expone el dato. En mi experiencia como sysadmin, lo más rápido para tener esto en un script es capturar la versión desde la API interna del appliance:

# Si tu appliance expone la API interna en HTTPS local
curl -sk https://<bt-appliance>/api/appliance-info 
  -H "Authorization: Bearer $BT_API_TOKEN" | jq '.version'
# Versiones afectadas: cualquier string <= "26.2.3"
# Versiones parchadas: "26.2.4" o superior
# Si la respuesta no incluye '.version' o devuelve 403, el appliance
# usa autenticación por cookies y debes entrar por la UI

Para flotas medianas y grandes el chequeo manual no escala. La mejor forma es conectar tu CMDB al appliance usando el módulo de Ansible que BeyondTrust publicó, o un simple cron que recorra la lista de appliances y vuelque la versión a un log central. En mi setup habitual esto lo hago con un script en Python que tira de la API /api/appliance-info cada 6 horas y me manda un Slack si detecta una versión vieja:

# Inventario automatizado via cron + Slack (ejemplo)
cat > /usr/local/bin/bt-version-check.sh << 'EOF'
#!/bin/bash
for host in $(cat /etc/bt-appliances.list); do
  ver=$(curl -sk -H "Authorization: Bearer $BT_API_TOKEN" 
    "https://${host}/api/appliance-info" 2>/dev/null | 
    python3 -c 'import json,sys; print(json.load(sys.stdin).get("version",""))')
  if [ -z "$ver" ]; then
    echo "$host: API no responde o sin token" | 
      curl -X POST -H 'Content-type: application/json' 
      --data "{"text":"$(cat)"}" "$SLACK_WEBHOOK"
  elif python3 -c "import sys; sys.exit(0 if '$ver' <= '26.2.3' else 1)"; then
    echo "$host @ $ver : VULNERABLE a CVE-2026-102764" | 
      curl -X POST -H 'Content-type: application/json' 
      --data "{"text":"$(cat)"}" "$SLACK_WEBHOOK"
  fi
done
EOF
chmod +x /usr/local/bin/bt-version-check.sh
# Cron cada 6 horas
echo "0 */6 * * * root /usr/local/bin/bt-version-check.sh" >> /etc/crontab

Si después de correr este chequeo descubres que tuviste el appliance expuesto a Internet entre el 29 de agosto y el 8 de octubre (o en cualquier momento posterior), trátalo como comprometido hasta demostrar lo contrario. El consejo oficial de CISA es exactamente ese: cualquier appliance self-hosted que haya estado accesible remotamente durante la ventana de explotación se considera “potentially compromised until reviewed”. La sección de respuesta a incidentes de este artículo describe el playbook concreto.

Aplicar el parche BT26-05-RS sin romper producción

BeyondTrust ofrece el patch de tres formas distintas según el tipo de appliance y el modelo de despliegue. El método más limpio para self-hosted es el panel web /appliance, donde vas a “Software Updates” y te aparece la actualización BT26-05-RS lista para instalar. El proceso tarda entre 5 y 15 minutos dependiendo del modelo del appliance (los appliance físicos tardan más por la verificación de integridad del firmware). Durante el upgrade el servicio de soporte sigue funcionando pero no acepta nuevas sesiones; las sesiones activas se mantienen, pero ningún técnico nuevo puede iniciar sesión hasta que termine.

Si prefieres línea de comandos o quieres automatizarlo en una flota, el appliance expone un endpoint de upgrade autenticado por API. Ten en cuenta que el upgrade requiere reinicio del servicio de soporte (no del appliance entero en la mayoría de los casos), así que conviene hacerlo en una ventana de mantenimiento:

# Confirmar la versión actual antes de tocar nada
BEFORE=$(curl -sk -H "Authorization: Bearer $BT_API_TOKEN" 
  "https://${BT_APPLIANCE}/api/appliance-info" | 
  python3 -c 'import json,sys; print(json.load(sys.stdin)["version"])')
echo "Versión actual: $BEFORE"
# Disparar el upgrade vía API (requiere token con permisos de admin)
curl -sk -X POST 
  -H "Authorization: Bearer $BT_API_TOKEN" 
  -H "Content-Type: application/json" 
  -d '{"patch_id": "BT26-05-RS", "maintenance_window": true}' 
  "https://${BT_APPLIANCE}/api/upgrade"
# Esperar a que termine (~10 min en appliance físico)
for i in $(seq 1 20); do
  sleep 30
  CUR=$(curl -sk -H "Authorization: Bearer $BT_API_TOKEN" 
    "https://${BT_APPLIANCE}/api/appliance-info" | 
    python3 -c 'import json,sys; print(json.load(sys.stdin)["version"])')
  echo "Iteración $i: versión actual $CUR"
  if python3 -c "import sys; sys.exit(0 if '$CUR' > '26.2.3' else 1)"; then
    echo "Parche aplicado correctamente"
    break
  fi
done
# Verificar que el header de respuesta del appliance menciona el parche
curl -skI "https://${BT_APPLIANCE}/login" | grep -i 'x-appliance-patch'

Hay tres trampas que ya he visto cometer en la primera ronda de upgrades. La primera es no leer la nota de release completa: si tu versión es anterior a 24.3.1, el parche no se aplica encima, tienes que upgrade primero a una versión soportada (24.3.1 mínimo) y después instalar el BT26-05-RS. Forzar la actualización sobre una versión vieja deja el appliance en estado inconsistente. La segunda trampa es olvidar que el upgrade requiere espacio en disco: BeyondTrust recomienda al menos 5 GB libres en la partición donde vive el appliance, y las máquinas virtuales con discos dinámicos a veces no los tienen si provisionaron 20 GB originalmente. La tercera trampa es no coordinar con el equipo de soporte: durante el upgrade las sesiones activas siguen pero las nuevas sesiones fallan con un error genérico que confunde al técnico que reporta el problema.

Si tienes appliances antiguos por debajo de 24.3.1, conviene aplicar primero el upgrade a 24.3.x o superior, esperar 48 horas de operación estable, y después aplicar el BT26-05-RS. BeyondTrust documenta el procedimiento exacto en su guía de upgrade para appliances antiguos. No hay atajos, y tratar de aplicar el parche directo sobre una versión sin soporte generalmente termina en ticket de soporte con su equipo.

El playbook de Armory Castle: lo que hicieron en producción

El análisis forense de Mandiant y GTIG (Google Threat Intelligence Group) es lo que hace este caso particularmente importante. No es una cadena teórica de exploit; es una cadena observada en producción con timestamps y artefactos. Lo que documentaron ilustra exactamente por qué un fallo de validación de origen se vuelve crítico cuando se combina con un appliance Linux mal configurado.

La fase uno: aprovechando CVE-2026-102764, el atacante disparó una operación de archivo que depositó un archivo PHP en el web root del appliance. Once minutos después del exploit inicial, el appliance registró la creación de mangoapi.php, un webshell PHP ligero al que Mandiant bautizó SAWFLY. El identificador único del archivo es estable entre incidentes — el SHA-256 publicado es dc14e215269a93fdbc4c1a80b984c23faf7af0911c6dbb85309796a6f2ae95fb, y conviene tenerlo en una regla YARA o en el SIEM como IoC si haces análisis de endpoints del appliance.

La fase dos: escalada a root. SAWFLY corría inicialmente bajo la cuenta de servicio del web server (sin privilegios altos). El atacante abusó de binarios con bit SUID que el appliance mantiene en su imagen base — un patrón clásico en appliances Linux donde el fabricante asume un entorno cerrado y olvida que un webshell ya es condición suficiente para SUID abuse. Con root, el atacante modificó la configuración de arranque del appliance para que la cuenta de servicio retuviera privilegios administrativos passwordless después de reinicios y resets de configuración: persistencia garantizada incluso si descubrían y borraban el webshell.

La fase tres: robo de credenciales. Con root activo, el atacante intentó usar la utilidad nativa bt-secrets del appliance, que extrae contraseñas, API keys y credenciales de integraciones del almacén local. Aquí Mandiant confirma que el atacante borró los logs relacionados con esas operaciones, reforzando la recomendación oficial de BeyondTrust de mantener telemetría off-appliance. La frase textual del advisory es que confiar solo en los logs locales deja al defensor sin evidencia suficiente para reconstruir la intrusión.

La fase cuatro: movimiento lateral. Con credenciales de administrador comprometidas, el atacante entró al portal de Remote Support y cambió permisos de Jump Items y Team permissions de “No Access” a “Administrator” en cuentas que no usaba el equipo legítimo. Esos Jump Items son los atajos del appliance para alcanzar endpoints internos (RDP, SSH, VNC, PowerShell) sin instalar agentes. Con permisos de Admin, el atacante podía iniciar sesiones de soporte hacia sistemas internos y usar el transfer file nativo de Remote Support para moverse documentos relevantes al reconocimiento interno.

La fase cinco: tunelización persistente con BARECLAW. El atacante desplegó un binario ELF llamado ingredi_ws (Mandiant lo bautizó BARECLAW), un tunneler SOCKS5-over-WebSocket custom. SHA-256: 1f19b9a27d79c11bda00a1e8faf74a7fdd683d38ccef1b60df2fd0307e3aa462. Después modificó la configuración de HAProxy del appliance para rutear un path web específico al túnel local, dándose un canal extra hacia sistemas internos que era difícil de detectar con escaneo externo. La regla de YARA que Mandiant publicó busca los strings característicos de BARECLAW como “--ws-path must start with '/'” o “mux: %s“.

El detalle importante: aunque BeyondTrust confirmó actividad en al menos un appliance SaaS y uno self-hosted, Mandiant aclara que no se confirmó explotación amplia al cierre del análisis del 15 de octubre. Eso significa que, al día de hoy, podemos protegernos antes de que se vuelva masivo — pero la ventana es corta porque GTIG ya observó que Armory Castle tiende a moverse desde zero-days selectivos hacia explotación oportunista más amplia una vez que el CVE se hace público.

Cómo investigar si tu appliance fue víctima

El primer paso es triage de exposición: ¿el appliance estuvo accesible remotamente entre el 29 de agosto y el 8 de octubre, o sigue estándolo? Si la respuesta es sí, las siguientes son las búsquedas específicas que Mandiant recomienda correr en tu telemetría. Lo más accionable es buscar los IoCs de archivo en el propio appliance y en los backups perimetrales:

# Buscar artefactos de SAWFLY en el filesystem del appliance
# (vía SSH al appliance con cuenta admin de soporte)
find / -type f ( -name "mangoapi.php" -o -name "app_84304470*.php" ) 
  2>/dev/null
# Cualquier resultado positivo es confirmación de compromiso.
# app_84304470*.php es el staging webshell que SAWFLY usó
# antes del deploy principal.
# Buscar BARECLAW en rutas habituales
find / -type f -name "ingredi_ws" 2>/dev/null
find /etc/haproxy -newer /var/log/dpkg.log 2>/dev/null | 
  xargs grep -l "ingredi_ws|ws-socks" 2>/dev/null
# Cualquier cambio en haproxy.cfg posterior al 29-ago debe revisarse manual
# Buscar el binario bt-secrets ejecutado fuera de horario
grep -E "bt-secrets" /var/log/auth.log /var/log/audit/audit.log 
  2>/dev/null | grep -v "cron|system"
# Actividad de bt-secrets en horario noño es sospechosa

El segundo eje de búsqueda es el lateral movement vía Jump Items y Team permissions. Esos eventos quedan registrados en el log del appliance, pero si el atacante fue root, pudo haber borrado evidencia local. Por eso CISA insiste en enviar el log del appliance a un SIEM externo en tiempo real. La regla general que Mandiant propone es buscar cualquier evento user_changed que promueva permisos de Jump Item a Administrator para usuarios que el equipo no reconoce:

# En el SIEM, regla equivalente a esta pseudoconsulta:
# Buscar eventos "user.permission.changed" con dest=Administrator
# y source.user IN (lista de cuentas que el equipo reconoce)
# Cualquier user fuera de esa lista con dest=Administrator es IoC
grep -E "permission_changed|user_changed" /var/log/beyondtrust/audit.log 2>/dev/null 
  | awk -F',' '$4 == "Administrator" && $5 != "known_admin"'
# Listar todos los Jump Items activos para revisión manual
curl -sk -H "Authorization: Bearer $BT_API_TOKEN" 
  "https://${BT_APPLIANCE}/api/jump-items" | 
  python3 -c "
import json,sys
items = json.load(sys.stdin).get('items', [])
for it in items:
  if it.get('permissions') == 'Administrator':
    print(f"ALERTA: {it.get('name')} @ {it.get('host')} tiene Admin")"

El tercer eje es la telemetría perimetral. Si tienes WAF, reverse-proxy, o firewall frente al appliance, los logs de esa ventana son oro forense. Busca POSTs al appliance con strings tipo application/x-www-form-urlencoded o cuerpos pequeños que dispararon respuestas 200 del appliance en momentos sin que ningún técnico legítimo estuviera activo. Para flotas con la API expuesta, los logs del reverse-proxy suelen tener la huella completa del atacante porque el reverse-proxy no es parte del appliance y el atacante no lo tocó:

# En el WAF o reverse-proxy, buscar requests al appliance fuera de horario
zcat /var/log/nginx/beyondtrust.*.log.gz 2>/dev/null 
  | awk -F'"' '$7 ~ /^/api/[a-z]+$/ {print $1,$7,$9}' 
  | grep -v "$BT_NORMAL_HOURS" 
  | head -50
# Cualquier POST al appliance fuera del horario de soporte legítimo
# en la ventana del 29-ago al 8-oct es un candidato para revisión

Respuesta a incidente si confirmas compromiso

Si después de los pasos anteriores confirmaste artefactos de SAWFLY o BARECLAW en el appliance, o si encontraste eventos user_changed sospechosamente elevando permisos de Jump Item, el playbook de CISA es estricto y conviene seguirlo en orden. Empieza por aislar, no por limpiar: borrar el webshell antes de aislar deja al atacante aún con acceso root por otros vectores y elimina la única evidencia que te dice qué tocó.

El primer paso es aislar el appliance de la red interna sin apagarlo (un shutdown limpio puede perder artefactos en memoria y va contra la guía forense). Una VLAN de cuarentena, reglas de firewall que bloqueen todo excepto SSH desde una IP de administración, o el equivalente en HAProxy frente al appliance son los caminos válidos. Mantén el appliance accesible solo para ti o el incident commander en lo que dura la respuesta. El segundo paso es tomar evidencia antes de cualquier acción:

# Snapshot del appliance virtual (si es VM)
virsh snapshot-create-as bt-appliance-01 pre-incident-2026-10-19 
  --description "Snapshot pre-respuesta CVE-2026-102764"
# Imagen forense si es appliance físico
dd if=/dev/sda of=/mnt/evidence/bt-appliance-01.img bs=4M status=progress
sha256sum /mnt/evidence/bt-appliance-01.img > 
  /mnt/evidence/bt-appliance-01.img.sha256
# Capturar memoria volátil si tienes herramientas (AVML, LiME)
./avml > /mnt/evidence/bt-appliance-01.mem
sha256sum /mnt/evidence/bt-appliance-01.mem > 
  /mnt/evidence/bt-appliance-01.mem.sha256
# Exportar logs del appliance a SIEM externo ANTES de tocar nada
curl -sk -H "Authorization: Bearer $BT_API_TOKEN" 
  "https://${BT_APPLIANCE}/api/audit-log?start=2026-08-29T00:00:00Z" 
  > /mnt/evidence/bt-appliance-01-audit.json
sha256sum /mnt/evidence/bt-appliance-01-audit.json

El tercer paso es rebuild. CISA recomienda explícitamente reconstruir el appliance desde una imagen limpia parchada, no limpiar el comprometido. La razón práctica es que no puedes saber a ciencia cierta si el atacante modificó binarios del sistema, así que un cleanup deja un appliance en estado “parece limpio pero no sabes qué más tiene”. El rebuild estándar es desplegar un appliance nuevo desde la imagen oficial actual (que ya incluye el BT26-05-RS), migrar la configuración desde el backup pre-incidente, y verificar que las cuentas de servicio y las contraseñas de integración se rotaron.

El cuarto paso es rotación total de credenciales. Esto es más amplio de lo que parece: cualquier secreto que el appliance haya almacenado o inyectado es candidato a rotación. BeyondTrust enumera específicamente las contraseñas de administradores del appliance, las API secrets usadas por integraciones, el material SAML si usas SSO, las credenciales en el vault del appliance, y cualquier credencial que se haya usado en sesiones de soporte durante la ventana de compromiso. CISA recomienda también revisar nuevos registros de MFA en cuentas privilegiadas, porque un atacante con root pudo haber añadido métodos de autenticación para mantener acceso persistente.

El quinto y último paso es revocar todas las sesiones activas del appliance. Una vez rebuild y parchado, sesiones vivas del atacante (que pueden seguir autenticadas si tenías tokens de larga duración) siguen siendo válidas hasta que el appliance las expire o las revoques. El endpoint de la API que revoca sesiones del portal de soporte se llama POST /api/sessions/revoke-all y requiere el token de admin:

# Revocar todas las sesiones activas (después de rebuild)
curl -sk -X POST 
  -H "Authorization: Bearer $BT_API_TOKEN" 
  "https://${BT_APPLIANCE}/api/sessions/revoke-all"
# Esto invalida tokens persistentes del atacante aunque conservara
# credenciales capturadas. Combinado con la rotación de secretos,
# cierra las dos vías de re-entrada.

Resumen

CVE-2026-102764 es de los avisos que un sysadmin no quiere ver en una mañana de lunes, pero la respuesta es manejable si te mueves con orden. Primero confirma si tu appliance aplica — todas las versiones 26.2.3 y anteriores, sin excepciones. Segundo, aplica el parche BT26-05-RS a través de /appliance o la API, con la ventana de mantenimiento coordinada con tu equipo de soporte. Tercero, si tu appliance estuvo expuesto remotamente durante la ventana de explotación, trátalo como potencialmente comprometido y corre las búsquedas de artefactos SAWFLY, BARECLAW y eventos user_changed sospechosos en Jump Items. Cuarto, si confirmas compromiso, sigue el playbook CISA: aislar, preservar evidencia, rebuild desde imagen limpia, rotar todo secreto que el appliance tocó, y revocar sesiones activas. Quinto, deja un log forwarder permanente hacia tu SIEM porque los atacantes borran evidencia local, y sin telemetría off-appliance no reconstruyes nada.

Lo que no debes hacer es quedarte en “ya actualicé, problema resuelto”. El atacante tuvo root, posiblemente modificó binarios del sistema, y pudo plantar persistencia que el upgrade de BeyondTrust no toca. Si tu organización es chica y no tienes un IR retainer, el advisory de CISA del 16 de octubre es un playbook suficiente para responder sin apoyo externo. Si manejas una flota mediana o grande, conviene alinear el playbook con el incident commander antes de empezar la ventana de actualización — la diferencia entre una respuesta de 2 horas limpia y una respuesta de 3 días caótica está en haber escrito el runbook antes de la crisis.

Preguntas frecuentes

Lee también

• CRA Cyber Resilience Act: lo que cambia para sysadmins de redes Linux en 2026
• Protege SSH con Fail2ban: guía definitiva para sysadmins Linux
• AppArmor: cómo confinar aplicaciones Linux y reducir superficie de ataque
• Arch Linux post-instalación: hardening, AUR y snapper para sysadmins