El caso que publiqué la semana pasada — una sesión RDP lenta porque el firewall bloqueaba UDP 3389 — terminó siendo más interesante de lo que parecía al principio.
No por el problema técnico en sí, que era relativamente simple de resolver una vez que encontré la evidencia en los logs, sino por lo que apareció al costado mientras investigaba: una lista de sesiones activas hacia ese servidor que yo no había autorizado, desde equipos que no deberían estar conectados a ese segmento y en horarios que no correspondían a ningún turno.
Nadie había abierto esas sesiones con mala intención.
Eran accesos legítimos de colegas y proveedores que, en algún momento, alguien habilitó para resolver algo puntual. El problema es que nunca se cerraron formalmente.
El servidor seguía aceptando conexiones porque nadie le había dicho que dejara de hacerlo.
Era acceso remoto acumulado: sin inventario claro, sin revisión periódica y sin fecha de vencimiento.
Lo que me llamó la atención fue que esa situación, que en mi caso no tuvo consecuencias más allá de una alerta temprana, se parece mucho a uno de los patrones que más se repiten en incidentes de ciberseguridad industrial: accesos remotos mal gestionados.
No siempre se trata de vulnerabilidades de día cero ni de ataques extremadamente sofisticados. Muchas veces el punto de entrada es más simple: una credencial antigua, una regla de firewall olvidada, una cuenta de proveedor que nunca se deshabilitó o una sesión RDP que sigue disponible mucho después de haber cumplido su propósito.
Este post no es un manual formal de ciberseguridad. Es el resultado de lo que hice después de ese hallazgo: una auditoría práctica del acceso remoto en un entorno OT, realizada con herramientas disponibles, sin detener producción y sin depender de una plataforma especializada.
Lo que encontré, lo que revisé y por qué creo que este ejercicio es uno de los más útiles que puedes hacer hoy si trabajas cerca de servidores, redes o sistemas industriales.
Este artículo se basa en una experiencia real de trabajo, pero los nombres de servidores, redes y sistemas han sido modificados o anonimizados. Las situaciones descritas se presentan con fines educativos y no representan a ninguna empresa, cliente o proveedor.
Contexto rápido
| Entorno | Operación industrial con segmentos de red OT y corporativo |
| Sistemas involucrados | Servidores Windows en red de planta, acceso remoto por RDP |
| Disparador | Sesiones no documentadas detectadas durante el diagnóstico de otro problema |
| Hallazgo principal | Acceso remoto acumulado sin inventario ni política clara de vencimiento |
| Acción tomada | Revisión manual de sesiones, cuentas, puertos y reglas de firewall |
| Resultado | No hubo incidente de seguridad; fue una detección preventiva |
Por qué el acceso remoto puede convertirse en un problema
Hay una paradoja en cómo la industria adoptó el acceso remoto.
Lo implementamos para ganar agilidad: resolver problemas sin ir físicamente al servidor, dar soporte a proveedores sin que tengan que viajar, monitorear sistemas desde otro punto de la red o atender una emergencia fuera de horario.
Todo eso tiene sentido operativo.
El problema aparece cuando cada acceso que se habilita para resolver una urgencia queda abierto indefinidamente.
En entornos IT maduros, esto suele estar controlado mediante inventarios de activos, políticas de identidad, revisiones periódicas y herramientas de gestión de accesos.
En OT, la realidad muchas veces es distinta.
Los servidores de planta pueden llevar años operando con configuraciones que nadie quiere tocar porque “si funciona, no lo muevas”. Las cuentas se crean para resolver una emergencia. Los accesos de proveedores se habilitan durante un proyecto. Las reglas de firewall se abren para una prueba. Y cuando el proyecto termina, el acceso queda ahí.
No porque alguien quiera dejar una puerta abierta.
Sino porque no existe un proceso formal para cerrarla.
El resultado es una superficie de ataque que crece poco a poco, casi sin que nadie la vea.
Lo que encontré cuando empecé a mirar
El punto de partida fue un servidor de visualización de cámaras.
Mientras revisaba logs para entender por qué una sesión RDP se comportaba lento, vi algo que no estaba buscando: conexiones desde IPs que pertenecían a un segmento que, en teoría, no debía tener acceso directo a ese servidor.
Mi primer instinto fue asumir que se trataba de algún sistema de monitoreo interno que yo no conocía.
Pero cuando fui a verificarlo, no encontré una justificación documentada.
Las conexiones eran reales. Los equipos existían. Y el firewall las estaba permitiendo porque, en algún momento, alguien había abierto esa regla y nunca la había cerrado.
Eso me llevó a hacer algo que debería ser rutinario, pero que rara vez se hace con suficiente disciplina en entornos de planta:
revisar manualmente qué equipos pueden conectarse a qué servidores, por qué puertos, con qué protocolos y con qué usuarios.
Nota importante: los comandos mostrados en este artículo deben ejecutarse únicamente en sistemas propios, autorizados o bajo responsabilidad operativa. No deben usarse sobre equipos, redes o servidores donde no tengas permiso explícito.
Paso 1: revisar sesiones activas en servidores
El primer comando que ejecuté en los servidores revisados fue:
query session /server:NOMBRE-SERVIDOR
Este comando permite ver sesiones activas o desconectadas en un servidor Windows.
Lo que me interesaba no era solo ver quién estaba conectado en ese momento, sino identificar sesiones en estado Disc, es decir, sesiones desconectadas pero no cerradas.
Una sesión desconectada puede parecer inofensiva, pero sigue siendo una sesión autenticada. Dependiendo de la configuración del servidor, podría reconectarse sin volver a pedir credenciales o quedar ocupando recursos innecesarios.
En algunos servidores encontré sesiones abiertas desde hacía varias horas. En otros, sesiones de usuarios que ya no tenían una razón operativa clara para seguir conectados.
Eso no significa automáticamente un incidente.
Pero sí significa una mala práctica que debe revisarse.
Paso 2: revisar historial de conexiones RDP
Para revisar inicios de sesión remotos recientes, usé el visor de eventos de Windows y también PowerShell.
Un punto útil es filtrar el evento 4624 con Logon Type: 10, que corresponde a un inicio de sesión remoto interactivo, típico de RDP.
Get-WinEvent -LogName Security |
Where-Object { $_.Id -eq 4624 -and $_.Message -like "*Logon Type: 10*" } |
Select-Object TimeCreated,
@{n='Usuario';e={$_.Properties[5].Value}},
@{n='IP Origen';e={$_.Properties[18].Value}} |
Sort-Object TimeCreated -Descending |
Select-Object -First 50
Esto no reemplaza una plataforma SIEM ni una auditoría formal, pero permite tener una primera fotografía.
Lo importante aquí no era encontrar “hackers”, sino responder preguntas básicas:
- ¿Quién se conectó?
- ¿Desde dónde?
- ¿A qué hora?
- ¿Ese acceso tiene sentido operativo?
- ¿Está documentado?
- ¿Sigue siendo necesario?
En algunos casos, las IPs eran conocidas. En otros, no había una justificación clara.
Y ese fue el primer hallazgo: no todo acceso autorizado está necesariamente bien gestionado.
Paso 3: revisar puertos abiertos en los servidores
Luego revisé qué servicios estaban escuchando en cada servidor.
No solo RDP. También otros puertos que, en algunos casos, correspondían a herramientas antiguas de soporte remoto o servicios instalados durante algún proyecto.
netstat -ano | findstr LISTENING
Para cruzar el puerto con el proceso asociado:
Get-NetTCPConnection -State Listen |
Select-Object LocalAddress, LocalPort,
@{n='Proceso';e={(Get-Process -Id $_.OwningProcess).Name}} |
Sort-Object LocalPort
Aquí encontré algo típico: herramientas legítimas instaladas por proveedores o integradores durante una puesta en marcha, una prueba o una etapa de soporte.
No eran malware.
No eran necesariamente peligrosas por sí mismas.
Pero seguían corriendo aunque ya no tenían una función operativa vigente.
En ciberseguridad OT, muchas veces el problema no es que una herramienta sea maliciosa. El problema es que nadie recuerda por qué sigue ahí.
Paso 4: revisar reglas de firewall
El firewall que separa la red corporativa de la red de planta es uno de los controles más importantes.
Pero su valor depende de que sus reglas reflejen la realidad operativa actual.
Una regla creada hace dos años para un proveedor que ya no trabaja en la operación sigue siendo técnicamente válida si nadie la elimina. El firewall no sabe que el proyecto terminó. Solo sigue permitiendo lo que alguien configuró.
Solicité el listado de reglas activas hacia los servidores de planta.
Lo que encontré fue una mezcla de reglas bien documentadas y reglas con nombres genéricos, del tipo:
ACCESO-TEMPORAL
PROVEEDOR-2023
SOPORTE-RDP
PRUEBA-SERVIDOR
Algunas reglas tenían sentido.
Otras requerían validación.
Y otras simplemente ya no tenían una justificación clara.
No todas se podían cerrar de inmediato. En OT, cerrar una regla sin validar puede afectar operación, monitoreo, soporte o integraciones. Pero identificarlas ya era el primer paso.
La pregunta correcta no era:
“¿Puedo cerrar todo?”
La pregunta correcta era:
“¿Qué acceso sigue teniendo una razón operativa válida hoy?”
Paso 5: revisar cuentas locales
Los servidores de planta suelen tener cuentas locales creadas para accesos específicos.
Algunas son necesarias. Otras fueron temporales. Otras nadie recuerda por qué existen.
Para revisarlas usé:
Get-LocalUser | Select-Object Name, Enabled, LastLogon,
PasswordLastSet, PasswordExpires |
Sort-Object LastLogon -Descending
Lo que buscaba:
- cuentas habilitadas sin uso reciente;
- cuentas cuyo
LastLogonera muy antiguo; - cuentas que nunca habían iniciado sesión;
- cuentas con contraseña sin expiración;
- cuentas genéricas asociadas a proveedores o soporte.
Una cuenta local sin fecha de vencimiento, sin dueño claro y con acceso a un servidor de planta no es solo un detalle administrativo.
Es una deuda técnica de seguridad.
El panorama detrás de esto
Lo que encontré no es raro.
Diversos reportes de ciberseguridad industrial vienen señalando que el acceso remoto mal gestionado sigue siendo uno de los vectores más usados para ingresar a entornos OT o moverse dentro de ellos.
En muchos incidentes no hay una vulnerabilidad espectacular de por medio.
Hay credenciales reutilizadas.
Hay accesos antiguos.
Hay reglas de firewall demasiado permisivas.
Hay herramientas de soporte remoto instaladas y olvidadas.
Hay sesiones RDP abiertas sin política clara de cierre.
Y hay sistemas industriales que fueron diseñados para operar de forma estable durante años, no necesariamente para convivir con el nivel actual de exposición y amenaza.
En operaciones industriales, una interrupción no programada puede tener impacto directo en producción, seguridad, calidad, cumplimiento o continuidad operativa. Por eso, el acceso remoto no gestionado no debe verse solo como una comodidad operativa mal documentada.
Debe verse como una superficie de riesgo.
Qué aprendí de esta revisión
El acceso remoto que nadie revisó puede ser más peligroso que el acceso remoto que nadie tiene.
Una operación sin acceso remoto tiene una superficie de ataque más pequeña. Una operación con acceso remoto no gestionado tiene una superficie que creció sola, sin diseño, sin dueño claro y sin fecha de cierre.
Eso fue lo que más me quedó dando vueltas.
No encontré un incidente.
Encontré algo que pudo haberse convertido en uno.
No necesitas una herramienta especializada para empezar.
Una auditoría formal de ciberseguridad requiere metodología, herramientas, alcance y responsables. Pero una primera revisión práctica puede empezar con lo que ya tienes:
- logs de Windows;
- PowerShell;
- visor de eventos;
- listado de reglas de firewall;
- inventario de cuentas;
- conocimiento de la operación.
No es perfecto, pero es muchísimo mejor que no mirar.
Cada acceso sin fecha de cierre es una deuda técnica.
En IT esto está bastante interiorizado.
En OT todavía muchas veces se trata como un detalle menor: “es solo un acceso”, “es para soporte”, “el proveedor lo necesitó”, “lo dejamos por si vuelve a fallar”.
Pero cada acceso que queda abierto después de cumplir su propósito se convierte en una excepción permanente.
Y las excepciones permanentes son difíciles de defender.
El firewall solo es efectivo si sus reglas siguen teniendo sentido.
Una regla desactualizada no es neutral.
Otorga acceso.
Permite tráfico.
Mantiene abierta una ruta.
Por eso revisar reglas no es solo tarea del área de redes o seguridad. En OT, también debe participar quien conoce la operación, porque no basta con saber qué puerto está abierto; hay que saber si ese acceso todavía tiene sentido para el proceso.
Acciones implementadas
Después de la revisión, estas fueron las acciones principales:
- Se documentó un inventario inicial de sesiones activas y cuentas de usuario en servidores de planta.
- Se revisaron conexiones RDP recientes para identificar usuarios, horarios e IPs de origen.
- Se solicitó al equipo de redes una revisión de reglas de firewall asociadas a servidores de planta.
- Se identificaron reglas sin justificación operativa clara para su validación y posible cierre.
- Se revisaron cuentas locales habilitadas, especialmente aquellas con último acceso antiguo o sin fecha de expiración.
- Se deshabilitaron cuentas que ya no tenían uso operativo documentado.
- Se configuraron tiempos máximos para sesiones RDP desconectadas, evitando que queden abiertas indefinidamente.
- Se dejó pendiente establecer un proceso formal para altas y bajas de accesos remotos de proveedores, con fecha de vencimiento explícita por proyecto.
Checklist práctico para empezar
Si tuviera que convertir esta experiencia en una revisión rápida, empezaría por estas preguntas:
- ¿Qué servidores aceptan RDP?
- ¿Desde qué segmentos de red se puede llegar a ellos?
- ¿Quién se conectó en los últimos 30 días?
- ¿Existen sesiones desconectadas que nunca se cierran?
- ¿Qué cuentas locales están habilitadas?
- ¿Qué cuentas no tienen fecha de expiración?
- ¿Qué reglas de firewall fueron creadas como temporales?
- ¿Qué proveedores externos mantienen acceso?
- ¿Qué accesos ya no tienen dueño claro?
- ¿Quién aprueba y quién revoca los accesos remotos?
No necesitas resolver todo en un día.
Pero sí necesitas saber qué existe.
Cierre
El caso del RDP lento pudo haber terminado con una conclusión simple:
“Faltaba permitir UDP 3389 en el firewall.”
Técnicamente, eso resolvía el síntoma.
Pero si me hubiera quedado solo con eso, habría pasado por alto lo más importante: un conjunto de accesos remotos que seguían vivos porque nadie los había revisado en meses.
En entornos OT, los problemas de acceso remoto rara vez aparecen con una alarma evidente.
Aparecen en un log que nadie estaba leyendo, en una cuenta que nadie recuerda haber creado, en una regla temporal que nunca volvió a revisarse o en una sesión desconectada que todos asumieron cerrada.
La pregunta no es si existe algo así en tu operación.
Probablemente existe.
La pregunta es si alguien lo va a revisar antes de que lo encuentre alguien más.
Aviso de independencia
Este artículo tiene fines educativos y refleja aprendizajes técnicos generales a partir de una experiencia real anonimizada. No representa la posición de ninguna empresa, cliente, proveedor o fabricante.
Los comandos y recomendaciones deben aplicarse únicamente en entornos propios o autorizados, siguiendo los procedimientos internos, políticas de seguridad y validaciones correspondientes.
Lección de cierre
En sistemas industriales, una señal congelada, una cámara lenta o una interfaz caída rara vez se explican con una sola causa. El valor está en ordenar síntomas, evidencias, cambios recientes y dependencias técnicas antes de intervenir.
Este artículo tiene fines educativos. Los casos pueden estar simplificados o anonimizados y no representan a ninguna empresa, cliente o proveedor.
Member discussion