Un técnico necesita entrar en una estación de una sucursal a las seis de la tarde. Abre la herramienta de acceso remoto, escribe la credencial y cierra el ticket en diez minutos. Nadie pregunta nada más, porque es rutina.
Ahora imagine que esa misma herramienta, instalada para facilitar la vida de TI, es la puerta que usa un intruso. Ya está en la red, ya es de confianza, ya tiene permiso para controlar equipos. Es el camino ideal.
No es una hipótesis. En 2026, una falla crítica en un producto corporativo de acceso remoto mostró cómo el atajo de TI se convierte en el atajo del ataque.
Lo que dejó claro la CVE-2026-1731
La CVE-2026-1731 afecta a BeyondTrust Remote Support y Privileged Remote Access. Según el catálogo de vulnerabilidades explotadas de la CISA, es una inyección de comandos del sistema operativo que permite a un atacante remoto ejecutar comandos sin autenticación y sin interacción del usuario. La CISA la incluyó en el catálogo el 13 de febrero de 2026.
La velocidad llama la atención. Según el reportaje de SecurityWeek del 20 de febrero de 2026, la explotación activa comenzó en menos de 24 horas tras la publicación de una prueba de concepto, el 10 de febrero. En la noche del 19 de febrero, la CISA marcó la entrada como utilizada en campañas de ransomware.
Los informes de Unit 42, de Palo Alto Networks, describen lo que vino después del ingreso: reconocimiento de la red, creación de cuentas, web shells, herramientas de gestión remota instaladas por el intruso, movimiento lateral y robo de datos.
El intruso no necesitó inventar un camino. Usó lo que TI ya había abierto para sí misma.
El acceso remoto es la puerta de mayor valor de la red
No es un caso aislado. El informe Active Adversary de Sophos, del primer semestre de 2024, analizó más de 150 casos de respuesta a incidentes de 2023. El abuso de RDP apareció en el 90% de los ataques, y los servicios remotos externos fueron la vía de acceso inicial en el 65% de los casos.
Es un dato de 2023, anterior al episodio de 2026, pero apunta en la misma dirección: quien ataca busca el servicio que ya fue hecho para controlar equipos a distancia.
¿Por qué sirve tanto? Por tres razones:
- ya tiene privilegio para actuar en muchas estaciones;
- su tráfico parece trabajo normal de soporte;
- casi nadie mira su registro hasta el día del incidente.
El resultado es que una falla en la herramienta y una política débil a su alrededor terminan en el mismo lugar: alguien entra con un acceso que parece legítimo y la primera señal es el daño. Parchear es necesario, pero no responde quién más ya tiene una llave.
Cuatro preguntas que TI debe saber responder
Antes de hablar de herramientas, conviene probar la operación actual. Si el equipo no responde con seguridad a alguna de estas, el acceso remoto es un punto ciego:
¿Quién entró, en qué equipo y cuándo?
“El equipo de soporte” no vale. Vale el nombre, el equipo y la hora de cada sesión, de modo que la auditoría pueda reconstruir el día.
¿Quién puede entrar fuera de horario?
Un tercero con credencial permanente y sin ventana de atención es un riesgo que nadie recuerda revisar. La pregunta es si el acceso a un servidor de madrugada se niega, o solo se espera que no ocurra.
¿El usuario sabe que alguien está en su equipo?
En una estación con datos personales, una sesión sin aviso es difícil de explicar después. Cuando la política lo exige, el consentimiento debe ser parte del flujo, no un acuerdo informal.
¿Dónde queda el registro de la sesión?
Si la traza está en el servicio de un tercero, la evidencia depende de otra empresa, de otro plazo y de otra política de retención. Si está en un servidor propio, depende de usted.
Cómo trata el acceso Tz0 Remote
Tz0 Remote parte de la idea de que el acceso remoto sin registro es confianza, no control. La página del módulo describe un flujo de cinco pasos: solicitar, autorizar, atender, registrar y auditar.
En la práctica, según la página, la política verifica nivel, horario y alcance antes de la sesión. Las credenciales tienen niveles distintos para soporte, infraestructura y terceros, y la ventana de atención define cuándo se puede acceder a cada grupo, registrando los intentos fuera de ella. Donde la política lo exija, el usuario ve quién lo solicita, el motivo y el ticket, y decide; sin su aceptación, no hay sesión.
La sesión ocurre dentro de la red, sin intermediario, y se abre con SiN, la herramienta para Windows del administrador. La auditoría queda en el Dashboard, por usuario y por dispositivo, con línea de tiempo y traza detallada: apertura de la conexión, programas usados, tiempo ocioso y cierre, cada evento con su hora.
La traza de la sesión queda en el servidor del propio cliente, junto con el resto de la evidencia. Eso no vuelve al módulo inmune a fallas: sigue siendo software que necesita actualización, y su servidor debe seguir la política de parches de la casa. Lo que cambia es quién custodia el registro y las reglas.
Antes de abrir la próxima sesión
Haga un ejercicio simple esta semana: elija una estación de una sucursal e intente reconstruir quién la accedió en los últimos treinta días, por cuánto tiempo y para hacer qué. Si lleva más de una tarde, el acceso remoto de su operación depende de la memoria y de la buena voluntad.
Luego repítalo con los terceros: liste cada empresa externa con credencial, a qué llega cada una y en qué horario. Las lagunas suelen aparecer en esa segunda lista.
Para la parte de investigación, también puede leer lo que escribimos sobre lo que pagar el rescate no explica del equipo y sobre tres días hábiles para explicar la máquina.
Si opera un parque grande y quiere ver esa traza funcionando en su entorno, solicite una evaluación de Trauma Zer0.