critica alerta global

CISA confirma explotación activa de falla crítica en BeyondTrust

El fabricante liberó el parche BT26-05-RS para un bypass de autenticación en Remote Support (ex Bomgar). The Hacker News atribuye la explotación previa al parche a un actor vinculado a China; CSA Labs sigue la campaña bajo el nombre interno 'Armory Castle'.

·10 min de lectura ·Equipo Vantis
En 30 segundos
  • CISA agregó CVE-2026-102764, un bypass de autenticación en BeyondTrust Remote Support (ex Bomgar) versiones autoalojadas ≤26.2.3, a su catálogo KEV el 16 de octubre de 2026 por explotación activa confirmada.
  • El fabricante publicó el parche BT26-05-RS para versiones 24.3.1 y posteriores; quienes operan versiones más antiguas deben actualizar primero y luego aplicar el parche.
  • CISA describe una cadena completa post-explotación: acceso inicial, persistencia, escalamiento de privilegios y movimiento lateral. Dos fuentes primarias (CISA y CSA Labs) confirman el patrón de explotación de forma independiente; la atribución a un actor vinculado a China proviene de una sola fuente derivada (The Hacker News) y se trata como evaluación de confianza media, no como hecho.

Qué pasó

CISA emitió una alerta urgiendo el parcheo de CVE-2026-102764, una vulnerabilidad crítica de bypass de autenticación en BeyondTrust Remote Support (producto conocido anteriormente como Bomgar), que afecta a instalaciones autoalojadas en versión 26.2.3 y anteriores. El fabricante liberó la Security Advisory BT26-05 con el parche BT26-05-RS; las organizaciones que corren versiones anteriores a 24.3.1 deben primero actualizar a una versión soportada antes de poder aplicar el parche.

Según CISA, actores de amenaza ya están explotando la falla activamente para obtener acceso inicial al appliance y, desde ahí, establecer persistencia, escalar privilegios y moverse lateralmente hacia la red del cliente. El CVE fue incorporado al catálogo KEV el 16 de octubre de 2026, lo que en Estados Unidos activa plazo de remediación obligatorio para agencias federales (BOD 22-01) — esa obligación no aplica en Chile, pero la inclusión en KEV es la señal más confiable de que la explotación es real y no teórica.

The Hacker News reporta que la explotación habría comenzado como día cero, antes de la publicación del parche, y la atribuye a un actor vinculado a China especializado en tomar control de appliances de soporte remoto. CSA Labs publicó una nota de investigación paralela que rastrea la misma campaña bajo el nombre interno 'Armory Castle', centrada en la toma de control del appliance. Ninguna de las dos fuentes primarias (CISA, CSA Labs) confirma públicamente la atribución geopolítica; esa pieza específica depende de una sola fuente derivada, por lo que la tratamos como indicio, no como hecho confirmado.

Por qué importa acá

No tenemos evidencia de una organización chilena específicamente afectada por esta campaña, y no la inventamos. Lo que sí es relevante para un lector en Chile:

Anatomía del ataque

Mapeo a marcos públicos, para que puedas cruzarlo con tu propia matriz de cobertura.

Qué hacer, fase por fase

Estructurado sobre las seis funciones del NIST CSF 2.0, según el ciclo de respuesta a incidentes de NIST SP 800-61r3 (abril 2025, reemplaza al r2). Proteger y Detectar vienen abiertas.

GV GobernarQuien decide, que se reporta y a quien

Si el appliance BeyondTrust Remote Support autoalojado es operado por una entidad bajo la Ley 21.663 (OIV) o maneja acceso a sistemas críticos de terceros (MSP), la decisión de parchear deja de ser técnica y pasa a ser de gobierno de riesgo de proveedores. Un incidente confirmado de explotación activa en este producto configura deber de reporte a ANCI; no citamos plazo porque no lo verificamos para este caso.

  • Identificar al dueño de negocio del appliance (TI interna vs. MSP contratado) y exigir evidencia de parcheo dentro de 48 horas.
  • Si la entidad es OIV bajo Ley 21.663, activar el procedimiento interno de evaluación de incidente para decidir si corresponde reporte a ANCI.
ID IdentificarSi esto me toca, por donde me toca

El primer paso no es leer la alerta, es saber si el producto existe en el inventario. BeyondTrust Remote Support históricamente se vendía como Bomgar; en CMDBs antiguas puede aparecer con ese nombre.

  • Buscar en el inventario de activos appliances 'BeyondTrust Remote Support' o 'Bomgar', autoalojados, y registrar la versión exacta.
  • Verificar si la consola administrativa del appliance es alcanzable desde internet (escaneo externo propio o con Shodan/Censys contra el rango IP de la organización).
  • Si la gestión está tercerizada con un MSP, solicitar formalmente confirmación de versión y estado de parcheo.
PR ProtegerComo evito que ocurra

La prioridad inmediata es el parche; mientras no esté aplicado, reducir la superficie de exposición es el control compensatorio real.

Controles priorizados

P1: esta semana · P2: este mes · P3: este trimestre

PrioControlEsfuerzoMapeo
P1 Aplicar el parche BT26-05-RS; en versiones autoalojadas anteriores a 24.3.1, actualizar primero a una versión soportada y luego parchar. bajo MITRE ATT&CK M1051 CIS Controls v8 7.1 ISO 27001 A.8.8
P1 Eliminar la exposición directa a internet de la consola administrativa de Remote Support; restringir acceso a VPN corporativa o lista de IPs permitidas. medio MITRE ATT&CK M1030 CIS Controls v8 4.4 ISO 27001 A.8.20
P1 Forzar MFA en todas las cuentas administrativas del appliance y rotar credenciales inmediatamente después de aplicar el parche. bajo MITRE ATT&CK M1032 CIS Controls v8 6.5 ISO 27001 A.8.5
P2 Revisar logs de sesiones administrativas de los últimos 30-60 días buscando orígenes IP anómalos o cuentas creadas sin autorización documentada. medio MITRE ATT&CK M1047 CIS Controls v8 8.5 ISO 27001 A.8.15
P2 Si el appliance es administrado por un MSP, exigir contractualmente evidencia de parcheo y de revisión de exposición como parte de la gestión de riesgo de proveedores. medio MITRE ATT&CK M1016 CIS Controls v8 15.1 ISO 27001 A.5.19
P3 Evaluar si la exposición residual justifica migrar a un modelo gestionado por el fabricante o incorporar una capa WAF frente al appliance. alto MITRE ATT&CK M1030 CIS Controls v8 13.1 ISO 27001 A.8.20

El orden importa: parchar sin restringir exposición deja la ventana abierta a la siguiente falla del mismo producto; restringir exposición sin parchar no cierra el bypass ya conocido. Los dos primeros controles deben ejecutarse en paralelo, no en secuencia.

DE DetectarComo me doy cuenta de que ya ocurrio

No hay IOCs públicos (IPs, hashes o dominios) asociados a esta campaña al momento de publicación; CISA, CSA Labs y el reporte de The Hacker News describen comportamiento, no artefactos. La detección disponible es conductual, sobre los logs del propio appliance y del perímetro que lo protege.

  • Confirmar que los logs de auditoría del appliance BeyondTrust se están enviando a un SIEM central; si no se está haciendo, es la primera brecha a cerrar.
  • Revisar sesiones administrativas de los últimos 30-60 días buscando orígenes IP fuera de los rangos de administración conocidos.

Qué necesitas tener logueado

  • Logs de auditoría del appliance BeyondTrust Remote Support (inicio de sesión administrativa, cambios de configuración, creación de cuentas)
  • Logs de firewall/proxy perimetral que exponen o protegen la consola del appliance
  • EDR/XDR en los endpoints que reciben sesiones de soporte remoto desde el appliance
  • Logs del proveedor de identidad (IdP) si la autenticación al appliance está federada vía SSO

Reglas y consultas de detección

sigmaSesión administrativa en BeyondTrust Remote Support sin desafío MFA previo
title: Sesion administrativa BeyondTrust sin MFA previo
id: 3b9f2a1d-6c4e-4f82-9a71-8e2d5b6c9f04
status: experimental
description: Detecta la creacion de una sesion con privilegios administrativos en la consola de BeyondTrust Remote Support que no esta precedida por un evento de desafio MFA en la ventana esperada, patron conductual consistente con un posible bypass de autenticacion relacionado a CVE-2026-102764. Requiere que el appliance envie su log de auditoria al SIEM con eventos de sesion y de MFA diferenciados.
references:
  - https://www.cisa.gov/news-events/alerts/2026/10/16/cisa-urges-patching-critical-vulnerability-beyondtrust-remote-support
  - https://www.beyondtrust.com/trust-center/security-advisories/bt26-05
author: Vantis
date: 2026-10-20
logsource:
  product: beyondtrust
  service: remote-support-audit
detection:
  admin_session:
    EventType: 'AdminSessionStart'
  mfa_challenge:
    EventType: 'MFAChallengeIssued'
  condition: admin_session and not mfa_challenge
fields:
  - SourceIP
  - AccountName
  - SessionId
falsepositives:
  - Integraciones SSO legitimas que delegan el desafio MFA a un IdP externo y no generan el evento MFAChallengeIssued localmente en el appliance
  - Cuentas de servicio con excepcion de MFA aprobada formalmente
level: high
Requiere: Logs de auditoría del appliance BeyondTrust Remote Support reenviados al SIEM, con eventos de inicio de sesión y de desafío MFA diferenciados por tipo de evento.
splunkSesiones administrativas BeyondTrust sin MFA correlacionado
index=beyondtrust sourcetype=bt_remote_support_audit EventType="AdminSessionStart"
| join type=left SessionId
    [ search index=beyondtrust sourcetype=bt_remote_support_audit EventType="MFAChallengeIssued"
      | rename SessionId as mfa_SessionId ]
| where isnull(mfa_SessionId)
| table _time, SourceIP, AccountName, SessionId
Requiere: Índice `beyondtrust` con sourcetype `bt_remote_support_audit` poblado desde el forwarder de logs del appliance.
sentinel-kqlSesiones administrativas anómalas en appliance de soporte remoto (CommonSecurityLog)
CommonSecurityLog
| where DeviceVendor == "BeyondTrust" and Activity == "AdminSessionStart"
| join kind=leftouter (
    CommonSecurityLog
    | where DeviceVendor == "BeyondTrust" and Activity == "MFAChallengeIssued"
    | project SessionId_mfa = DeviceCustomString1
) on $left.DeviceCustomString1 == $right.SessionId_mfa
| where isempty(SessionId_mfa)
| project TimeGenerated, SourceIP, DestinationUserName, DeviceCustomString1
Requiere: Logs del appliance BeyondTrust reenviados vía CEF/syslog hacia la tabla CommonSecurityLog, con DeviceVendor=BeyondTrust configurado en el conector.
Falsos positivos esperables

No existen IOCs públicos (IPs, hashes, dominios) asociados a esta campaña al momento de publicar; cualquier regla basada en indicadores sería ficticia. Las reglas aquí son conductuales y experimentales: dependen de que el appliance distinga eventos de sesión administrativa y de desafío MFA en su log de auditoría. Entornos con SSO federado que delega el MFA a un IdP externo (Okta, Azure AD) pueden no generar el evento de MFA localmente, generando falsos positivos sistemáticos — hay que validar contra el modelo de autenticación real antes de poner la regla en modo de alerta activa.

RS ResponderContencion y erradicacion

Si se detecta indicio de explotación (sesión administrativa anómala, cuenta nueva no reconocida, cambios de configuración no autorizados), tratar el appliance como comprometido, no solo vulnerable.

  • Aislar el appliance de la red mientras se investiga (desconectarlo no basta si ya existió movimiento lateral; revisar también los endpoints que recibieron sesiones de soporte remoto recientes).
  • Rotar todas las credenciales administrativas del appliance y de las cuentas de servicio asociadas.
  • Revisar y revocar sesiones activas y tokens de API del appliance.
  • Preservar logs de auditoría antes de aplicar el parche o reconstruir, para análisis forense posterior.
RC RecuperarVolver a operar y no repetirlo

La recuperación no termina con el parche aplicado; incluye confirmar que no quedó persistencia en los sistemas que el appliance administraba.

  • Aplicar BT26-05-RS (o la ruta de actualización correspondiente desde versiones pre-24.3.1) y validar la versión final.
  • Auditar cuentas administrativas creadas o modificadas en el appliance durante la ventana de exposición estimada.
  • Reforzar el control de exposición (restricción por IP/VPN) como condición permanente, no solo como medida temporal post-incidente.
  • Documentar el caso para la revisión de gestión de proveedores si el appliance es operado por un tercero.

Llévatelo

Lo de arriba explica. Esto se ejecuta. Son archivos, no capturas de pantalla: se abren, se pegan y funcionan.

La regla Sigma es la canónica: es el formato neutral del que se derivan las demás. Si tu SIEM no aparece en la lista, esa se convierte con pySigma. Las traducciones a motores concretos van sin validar contra tu modelo de datos — revisa los nombres de tabla y campo antes de subirlas a producción.

Fuentes

¿Esto te aplica y no sabes por dónde partir?

Revisamos tu exposición real frente a lo que describe este análisis: superficie expuesta, cobertura de detección y brechas frente a la Ley 21.663. Diagnóstico de 15 minutos, sin costo.

Agendar diagnóstico

Relacionado