Cuando los permisos de soporte remoto se convierten en una vía de ataque

Ilustración de TechiesJournal de la secuencia que describe el artículo. La mayoría de las computadoras aparecen atenuadas porque la evidencia no establece que se accediera a todos los endpoints, y la imagen no muestra a cuántos se accedió.

El incidente de BeyondTrust de agosto de 2026 demostró cómo los atacantes podían usar una plataforma de soporte remoto comprometida para llegar a sistemas internos mediante funciones administrativas legítimas. Ilustra por qué proteger una plataforma de gestión remota es distinto de proteger cada una de las computadoras que gestiona.

El atacante no necesitaba explotar cada endpoint

Las plataformas de soporte remoto permiten a los equipos de TI administrar computadoras, resolver problemas y acceder a sistemas en toda la organización. Un ingeniero de soporte puede conectarse a la computadora portátil de un empleado, investigar el fallo de una aplicación o transferir un archivo de diagnóstico. Un administrador de infraestructura puede usar la misma plataforma para gestionar servidores.

Estas funciones son útiles porque las organizaciones pueden gestionar el acceso remoto desde un sistema central. Ese sistema pasa a ser también el responsable de decidir quién puede conectarse a qué máquinas y qué acciones se permiten durante una sesión.

En agosto de 2026, unos atacantes explotaron una vulnerabilidad en BeyondTrust Remote Support, una plataforma empresarial de administración remota. La vulnerabilidad, CVE-2026-102764, consistía en una validación insuficiente del origen de los mensajes dentro de un componente interno, lo que permitía operaciones con archivos no autorizadas en determinadas condiciones. Fuente: BeyondTrust Security Advisory BT26-05.

La vulnerabilidad ofrecía una vía de entrada inicial a los appliances afectados (los servidores o máquinas virtuales que ejecutan la plataforma). Pero la investigación de Mandiant documentó algo que iba más allá de la explotación inicial.

Tras comprometer la plataforma, los atacantes cambiaron los permisos administrativos del soporte remoto, establecieron sesiones con endpoints internos y usaron la función de transferencia de archivos integrada en el producto para obtener documentos, entre ellos inventarios de software.

El acceso a los endpoints investigados se logró a través de la plataforma de soporte remoto. Mandiant no informó de que se explotara una vulnerabilidad distinta en cada computadora de destino para establecer esas sesiones.

Este es el problema técnico central: una vez que los atacantes controlaron una plataforma autorizada a acceder a sistemas internos, pudieron hacer un uso indebido de sus funciones de gestión remota ya existentes. Fuente: Google Threat Intelligence Group y Mandiant, ARMORY CASTLE Exploits BeyondTrust, 15 de octubre de 2026.

Por qué las plataformas de soporte remoto tienen una responsabilidad de seguridad distinta

Las plataformas de soporte remoto operan entre los administradores de TI y los sistemas que gestionan. La plataforma autentica al personal de soporte, mantiene las conexiones de acceso remoto configuradas y aplica los permisos que determinan a qué sistemas puede llegar ese personal.

En BeyondTrust Remote Support, un Jump Item representa una conexión de acceso remoto configurada hacia un sistema. Un Jump Item contiene o referencia la información necesaria para iniciar esa conexión. Según su tipo, esto puede implicar un Jump Client, un Jumpoint u otros datos de conexión.

Los Jump Items pueden organizarse en Jump Groups, lo que permite a las organizaciones separar las conexiones por equipo, ubicación o responsabilidad operativa.

Piensa en una organización hipotética con dos grupos: las estaciones de trabajo de los empleados y los servidores de producción. Su equipo de mesa de ayuda puede estar autorizado a conectarse a las estaciones de trabajo, mientras que el acceso a los servidores de producción se reserva a los administradores de infraestructura. Ambos equipos pueden autenticarse correctamente en la misma plataforma Remote Support. Aun así, su autorización para llegar a los sistemas gestionados puede ser distinta.

Cómo funcionan los permisos de los Jump Items

BeyondTrust usa los Jump Item Roles (roles de Jump Item) para definir las acciones que los usuarios pueden realizar con los Jump Items. Estos permisos pueden incluir iniciar sesiones, crear o eliminar Jump Items y editar la configuración de conexión o las políticas asociadas.

El acceso efectivo no depende necesariamente de un solo ajuste. La documentación versionada de BeyondTrust describe asignaciones de roles a través de usuarios individuales, políticas de grupo y relaciones entre usuarios y Jump Groups. Cuando se aplican varios Jump Item Roles, prevalece la asignación más específica.

Por ejemplo, un rol general de usuario puede permitir operaciones de soporte remoto, mientras que una asignación más específica para un Jump Group concreto restringe el acceso a las conexiones de ese grupo. Para establecer el acceso efectivo de un usuario, un administrador debe examinar las asignaciones aplicables en lugar de basarse solo en el rol general del usuario.

El artículo usa Jump Item Roles, la terminología que aparece en la investigación de Mandiant y en la documentación correspondiente de BeyondTrust Remote Support. Las organizaciones deben interpretar los detalles de configuración según la versión y la edición del producto que tengan instaladas. Fuente: BeyondTrust Remote Support v24.3, Jump Item Roles.

Iniciar una sesión no equivale a controlar el endpoint

El permiso para lanzar una sesión de soporte remoto es solo una parte de la autorización. Un usuario puede ser capaz de iniciar una conexión y seguir limitado por la política de sesión configurada. La computadora de destino también tiene sus propios privilegios del sistema operativo y sus propios controles de seguridad.

Por tanto, hay que distinguir tres permisos:

• Permiso para iniciar sesión en la plataforma Remote Support.
• Autorización para iniciar una sesión a través de un Jump Item concreto.
• Privilegios para realizar operaciones en la computadora remota.

Las acciones disponibles durante una sesión dependen de la configuración de la conexión, las políticas aplicables, las credenciales disponibles y los privilegios en el endpoint. Esta distinción importa a la hora de interpretar la intrusión.

Qué cambiaron los atacantes dentro de Remote Support

La intrusión comenzó con la vulneración del appliance. Mandiant documentó una webshell maliciosa (un pequeño script que permite a un atacante ejecutar comandos en un servidor a través de su interfaz web), una escalada a privilegios de root (control total del sistema operativo del appliance) y mecanismos diseñados para mantener el acceso. Esos hallazgos explican cómo los atacantes se hicieron con el control del entorno operativo del appliance.

La siguiente etapa afectó a la propia aplicación Remote Support. Mandiant observó a los atacantes usar credenciales de administrador comprometidas para acceder a su portal web de administración. Los investigadores registraron un evento user_changed en el que cambiaron dos campos de rol:

Los campos de rol que cambiaron en el evento user_changed registrado

Campo registrado	Rol anterior	Rol nuevo
Default Jump Item Role	No Access	Administrator
Teams Jump Item Role	No Access	Administrator

Ambos cambios quedaron registrados como el paso del ID de rol 1 al ID de rol 3.

Son campos distintos de la configuración de Remote Support de la cuenta. No deben confundirse con una asignación de rol concreta entre un usuario y un Jump Group.

En la entrada de registro de Mandiant, los dos campos son jump_item_role:default y jump_item_role:teams, y Mandiant describe el cambio como una ampliación de los permisos sobre los Jump Items locales y sobre Team. La página Jump Item Roles de la v24.3 no describe estos dos campos, así que parecen ser un ajuste de rol general y un ajuste relacionado con los equipos. Otras asignaciones más específicas pueden seguir afectando a la autorización efectiva disponible para una conexión concreta.

Por tanto, los cambios observados establecen que se ampliaron los permisos de aplicación de la cuenta de administrador. No demuestran, por sí solos, un acceso sin restricciones a todos los Jump Items. Mandiant describe este cambio como la concesión de una autorización permanente y sin restricciones para lanzar sesiones remotas a los sistemas de la lista de Jump Items del appliance, y las sesiones y transferencias de archivos documentadas son la evidencia de lo que realmente se hizo.

Después, Mandiant observó a los atacantes establecer sesiones de soporte remoto con endpoints internos. La evidencia vincula cambios reales en la autorización administrativa con el uso posterior de las funciones de acceso remoto de la plataforma.

Los atacantes ya no dependían exclusivamente de comandos ejecutados a través del sistema operativo del appliance comprometido. También usaban la aplicación diseñada para administrar otros sistemas. Fuente: Mandiant, abuso de sesiones de administrador de BeyondTrust.

Cómo las sesiones remotas legítimas se convirtieron en una vía de acceso

Remote Support mantiene conexiones con sistemas que una organización ya ha configurado para administrarlos. El personal autorizado usa estas conexiones para resolver problemas, hacer mantenimiento y transferir archivos.

Tras los cambios de permisos, Mandiant observó a los atacantes usar esa infraestructura para llegar a endpoints internos. Los atacantes aprovecharon la capacidad de la plataforma de gestión para establecer sesiones, en lugar de instalar un mecanismo de acceso remoto independiente en cada máquina objetivo.

Qué observaron los investigadores en los endpoints internos

Mandiant documentó sesiones de soporte remoto con sistemas internos. Durante esas sesiones, los atacantes usaron las funciones integradas de BeyondTrust para solicitar acceso al sistema de archivos remoto. Después usaron la función nativa de transferencia de archivos para descargar documentos sensibles, entre ellos inventarios de software.

Fueron actividades observadas, no simples consecuencias potenciales de tener permisos más amplios.

La función de transferencia de archivos era legítima en sí misma. Los equipos de soporte pueden usarla para recopilar registros (logs), obtener material de diagnóstico o entregar archivos necesarios para resolver problemas. En este incidente, un operador no autorizado usó esa función para sacar información de endpoints internos.

El software cumplió la función técnica para la que estaba pensado. El problema era que el operador que la utilizaba no estaba autorizado.

Lo que la evidencia no establece

La investigación no demuestra que se accediera a todos los endpoints registrados en el inventario de Jump Items del appliance. Tampoco establece que los atacantes obtuvieran privilegios de administrador del sistema operativo en todos los endpoints a los que llegaron.

Las sesiones, el acceso al sistema de archivos y las transferencias de documentos observados demuestran una actividad no autorizada aguas abajo sin necesidad de esas afirmaciones más amplias. El acceso mediante una sesión remota y el control total del sistema operativo de destino siguen siendo hallazgos distintos.

Los cuatro límites de seguridad implicados

El incidente afectó a varias capas de control, cada una con una responsabilidad distinta.

Los cuatro límites de seguridad implicados en el incidente

Límite de seguridad	Qué controla	Importancia observada
Host del appliance	Archivos, servicios y privilegios del sistema operativo	Los atacantes obtuvieron acceso de nivel root
Administración de Remote Support	Cuentas de la aplicación, roles y configuración	Los atacantes ampliaron los permisos administrativos
Sesión remota	Conexiones y actividades de soporte permitidas	Los atacantes iniciaron sesiones y transfirieron archivos
Endpoint de destino	Privilegios locales y controles de seguridad del endpoint	Se accedió a endpoints internos. No se estableció una vulneración administrativa universal

Vulnerar un límite puede crear oportunidades para abusar de otro. No demuestra automáticamente que todos los demás límites también hayan caído.

En este caso, Mandiant documentó tanto los cambios de permisos administrativos como el uso posterior de las funciones de soporte remoto. Eso es lo que establece la conexión entre la vulneración del appliance y la actividad no autorizada en sistemas internos.

Una vía distinta a través del appliance

Los investigadores también descubrieron una vía que no dependía de las sesiones normales de Remote Support. Mandiant identificó BARECLAW, una herramienta de tunelización de red personalizada instalada en el appliance comprometido. La herramienta podía retransmitir tráfico de red a través de un proxy SOCKS5 transportado sobre conexiones WebSocket, una forma de llevar conexiones de red retransmitidas dentro de una conexión web.

Los atacantes también modificaron la configuración de HAProxy del appliance. HAProxy es un proxy inverso: acepta las solicitudes entrantes y las reenvía a los servicios internos configurados. Al modificar sus reglas de enrutamiento, los atacantes dirigieron las solicitudes que llegaban por una ruta web designada hacia el componente de tunelización. Esto proporcionaba una vía de comunicación alternativa a través del appliance comprometido.

Según nuestra lectura, este tráfico, a diferencia de una conexión normal de Remote Support, no dependía de que un operador lanzara una sesión a través de un Jump Item.

La diferencia importa al investigar la actividad. Los registros de sesión de la aplicación pueden establecer qué conexiones gestionadas se usaron mediante los flujos de trabajo normales de Remote Support. Pero, según nuestra lectura, el tráfico que pasa por una herramienta de tunelización instalada por el atacante puede no aparecer como una sesión de soporte normal.

Mandiant documentó ambos mecanismos. Sus hallazgos públicos no establecen que llegaran exactamente al mismo conjunto de endpoints. Fuente: Mandiant, hallazgos sobre BARECLAW y HAProxy.

Qué pueden verificar las organizaciones tras este tipo de vulneración

La investigación de BeyondTrust ofrece una forma práctica de rastrear las consecuencias de unos permisos de soporte remoto no autorizados. El punto de partida no es solo si el appliance era vulnerable. Es qué cambió dentro de la aplicación de gestión y qué ocurrió después.

Primero, establece el cambio administrativo.

Revisa las cuentas afectadas, los Jump Item Roles, las asignaciones de Jump Groups y las políticas de grupo. Identifica qué cuenta hizo un cambio, qué permisos se modificaron y si la acción tenía un propósito operativo autorizado. En el incidente investigado, la evidencia clave incluía un evento user_changed que mostraba dos campos de rol que pasaban de No Access a Administrator.

A continuación, establece qué sesiones vinieron después.

Revisa los endpoints a los que se accedió, las identidades que iniciaron esas conexiones y su momento en relación con los cambios de permisos inesperados. Un cambio de rol no demuestra que se produjera una sesión remota. La evidencia de sesión aporta el siguiente eslabón.

Después, examina lo que ocurrió durante esas sesiones.

Los registros relevantes pueden incluir el acceso al sistema de archivos, las transferencias nativas de archivos y la actividad de configuración de sesiones. La investigación de Mandiant vinculó las sesiones remotas con transferencias de documentos observadas.

Por último, identifica los endpoints que requieren investigación.

Que un endpoint aparezca en el inventario de la plataforma no significa automáticamente que esté comprometido. Sin embargo, un endpoint al que se accedió mediante una sesión no autorizada pasa a ser relevante para la investigación y debe evaluarse con los registros de actividad y la evidencia del endpoint disponibles.

La ruta de investigación resultante es:

Cambio de rol inesperado → sesión remota → acceso a archivos o transferencia → endpoint afectado.

Esto describe una forma de vincular la evidencia. No supone que todas las etapas se produjeran en todos los entornos.

También hay que examinar la actividad a nivel de host cuando el propio appliance ha sido comprometido. En el incidente de BeyondTrust, los atacantes borraron archivos de registro y establecieron un mecanismo de tunelización independiente. Por tanto, los registros almacenados únicamente en el appliance comprometido pueden estar incompletos.

Los logs recopilados de forma independiente, la telemetría de los endpoints y los registros de red pueden ayudar a corroborar los hallazgos, aunque no debe suponerse que ninguno de ellos ofrezca una visibilidad completa.

Aplicar el parche a la vulnerabilidad inicial resuelve el punto de entrada documentado. No establece qué conexiones de soporte legítimas había usado antes un atacante. El problema más amplio de la recuperación se trata en el artículo relacionado de TechiesJournal «Con parches» no significa «limpio»: qué hacer tras corregir un dispositivo perimetral explotado (en inglés).

El propósito aquí es más acotado: entender qué permisos de gestión remota cambiaron, qué conexiones se usaron y qué ocurrió en los sistemas a los que llegaron esas conexiones.

El límite de seguridad va más allá del servidor de gestión

Las plataformas de soporte remoto son útiles porque ofrecen a las organizaciones una forma centralizada de administrar muchos sistemas. Sus controles de acceso determinan quién puede usar esas conexiones y qué actividades están permitidas.

La investigación de BeyondTrust mostró cómo los atacantes que comprometieron la plataforma de gestión también podían abusar de esas funciones legítimas. Mandiant documentó cambios de roles administrativos, sesiones de soporte remoto no autorizadas y el uso de la transferencia nativa de archivos para obtener información de endpoints internos. Los investigadores también encontraron una vía de tunelización de red independiente a través del appliance comprometido.

La lección no es que las herramientas de soporte remoto sean inseguras por naturaleza.

Es que la seguridad de los endpoints gestionados depende en parte de la integridad de la plataforma autorizada a conectarse a ellos.

Cuando esa plataforma está comprometida, examinar solo el servidor de gestión no permite establecer las consecuencias. Las organizaciones también deben determinar qué permisos cambiaron, qué sesiones se establecieron y qué ocurrió en los sistemas a los que llegaron esas sesiones.

Para profundizar

Investigación revisada el 21 de octubre de 2026 y comprobada de nuevo el 22 de octubre de 2026. Este artículo se centra en la autorización del soporte remoto y en el acceso aguas abajo, no en el proceso completo de respuesta a vulnerabilidades.

Fuentes de la investigación y del proveedor

• ARMORY CASTLE Exploits BeyondTrust, Google Threat Intelligence Group y Mandiant, 15 de octubre de 2026, investigación original que describe los cambios administrativos, las sesiones de soporte remoto, las transferencias de archivos y la tunelización.
• BeyondTrust Security Advisory BT26-05, BeyondTrust, 15 de octubre de 2026, descripción oficial de la vulnerabilidad, versiones afectadas e información de mitigación de CVE-2026-102764.
• ARMORY CASTLE and BT26-05: What Security Teams Need to Know, BeyondTrust, 15 de octubre de 2026, investigación del proveedor, cronología de la respuesta e información sobre la contención.
• BeyondTrust Remote Support v24.3, Jump Item Roles, documentación del producto de BeyondTrust, revisada el 21 de octubre de 2026; explica el acceso a los Jump Items, la asignación de roles y la precedencia. La intrusión observada la establece Mandiant por separado.

Las organizaciones que evalúen una posible exposición deben consultar los avisos actuales de BeyondTrust y sus propios procedimientos de respuesta a incidentes. La intrusión documentada públicamente no establece que todas las instalaciones o todos los endpoints gestionados estuvieran comprometidos.

Lecturas relacionadas en TechiesJournal

• «Con parches» no significa «limpio»: qué hacer tras corregir un dispositivo perimetral explotado (en inglés), TechiesJournal, octubre de 2026, análisis relacionado de por qué corregir una vulnerabilidad no elimina automáticamente una vulneración ya existente.
• Cuando una aplicación en la nube de confianza se convierte en una vía de ataque (en inglés), otro caso en el que los atacantes usaron el propio acceso legítimo de una aplicación de confianza en lugar de atacar cada objetivo.