Windows: La línea base de seguridad que detiene el 80% de los ataques RDP

febrero 20, 2026 • febrero 20, 2026 • Lectura: 26 min • Views: 0

¿Te fue útil?

No te vulnera un mago. Te vulnera un puerto RDP expuesto a Internet, una contraseña de administrador local desactualizada y registros que nadie revisa hasta que el asegurador los pide.

RDP sigue siendo la herramienta de acceso remoto predominante en muchas instalaciones Windows. También es uno de los imanes de ataques más ruidosos en internet público. La buena noticia: puedes detener la mayoría de los ataques RDP con una línea base aburrida, estricta y medible. Y si lo haces bien, dormirás mejor—y el teléfono de guardia dejará de sonar con ese tono de “nueva ola de credential stuffing”.

El modelo de amenaza (lo que realmente te golpea)

Seamos honestos sobre cómo son los “ataques RDP” en entornos de producción reales:

Escaneo masivo + fuerza bruta: Escaneos automatizados detectan TCP/3389 (o tu “puerto alternativo” “ingenioso”) e intentan nombres de usuario comunes y contraseñas filtradas. Esto es la mayor parte del ruido básico.
Password spraying: Intentos lentos y distribuidos sobre muchas cuentas para evitar bloqueos. Esto es lo que impacta a organizaciones con políticas débiles y sin MFA.
Reproducción de credenciales: Credenciales válidas provenientes de phishing, malware o filtraciones previas. Con RDP, una única credencial válida puede bastar para establecer un punto de apoyo.
Recolección por mala configuración: NLA desactivado, configuraciones TLS antiguas, prácticas débiles de admin local, reglas de firewall entrantes amplias, acceso “temporal” de proveedores que se volvió permanente.
Escalada post-login: Una vez dentro, vuelcan credenciales, pivotan lateralmente, desactivan EDR y comienzan a cifrar. RDP es solo la puerta principal; la casa todavía necesita cerraduras internas.

La línea base de este artículo apunta a la parte que causa la mayoría de incidentes RDP: exposición a internet + autenticación débil + políticas débiles + sin monitorización. Eso es el 80%. El otro 20% mantiene ocupados a los equipos de seguridad.

Datos interesantes y contexto histórico (porque los patrones se repiten)

RDP existe desde finales de los años 90 (era de Windows NT 4.0 Terminal Server Edition), tiempo suficiente para que atacantes y defensores tengan memoria muscular sobre él.
TCP/3389 se convirtió en “el nuevo 22” para entornos Windows: un puerto administrativo remoto por defecto que es escaneado continuamente por bots, sin importar tu industria.
NLA (Network Level Authentication) se introdujo para reducir la superficie de ataque pre-autenticación exigiendo autenticación antes de crear una sesión completa.
Credential stuffing se volvió mainstream cuando las filtraciones de contraseñas se hicieron rutinarias y los usuarios reutilizaban contraseñas. RDP es un beneficiario directo de ese mal hábito.
BlueKeep (CVE-2019-0708) fue una llamada de atención: vulnerabilidades RDP pre-auth pueden ser wormables. Incluso si parcheaste, aprendiste que “RDP expuesto” es una elección de vida.
Existe RD Gateway porque las empresas aprendieron por las malas que RDP directo desde internet genera incidentes, no es una estrategia de acceso.
Los ID de evento de Windows para telemetría de inicio de sesión han sido estables por años (p. ej., 4624/4625), lo cual es bueno: tu detección y respuesta no deberían depender de la novedad.
Las políticas de bloqueo de cuentas se usaron ampliamente mucho antes del MFA moderno, pero los atacantes se adaptaron con spraying. Por eso los bloqueos son necesarios pero insuficientes.
Las líneas base de seguridad se productizaron (Microsoft security baselines, CIS Benchmarks) porque el “conocimiento tribal de admins” no escala—y falla auditorías.

La línea base: las pocas decisiones que aplastan la mayoría de ataques RDP

Esta es la parte opinionada. Quieres reducir tu superficie de ataque, hacer que la autenticación sea costosa para atacantes y hacer el abuso obvio en los registros. Haz esto, en orden.

1) Deja de exponer RDP a Internet público

Si haces una cosa, haz esta. RDP entrante directo desde internet es como dejar la puerta del vestíbulo de la oficina abierta porque la recepcionista “usualmente está aquí”.

Elige uno de estos patrones:

VPN + RDP restringido: Permitir RDP solo desde el espacio de direcciones VPN. Limpio, común, efectivo.
RD Gateway: Termina HTTPS externamente; RDP se proxifica. Mejor para acceso gestionado, políticas y auditoría.
Estaciones de trabajo de acceso privilegiado (PAW) + jump host: Los administradores hacen RDP solo desde una estación controlada a un jump box, y luego siguen. Molesto. Correcto.
Acceso remoto basado en SSO: Si lo tienes, bien. Aun así restringe RDP entrante en el firewall.

Qué no hacer: “Cambiamos el puerto de 3389 a 53389.” Eso no es seguridad; solo obliga a los bots a hacer un escaneo SYN adicional.

2) Exigir NLA y TLS moderno

NLA reduce la superficie RDP pre-auth y corta algunas clases de abuso. Combínalo con una configuración TLS moderna para no negociar criptografía antigua por nostalgia.

Además: deshabilitar “Allow connections only from computers running Remote Desktop with Network Level Authentication” solo si disfrutas explicarte en la revisión de incidentes. No lo hagas.

3) Habilitar MFA para caminos de administración remota

RDP por sí solo no hace MFA mágicamente. Aplicas MFA a través del camino de acceso:

VPN con MFA
RD Gateway con integración MFA
Acceso condicional / cumplimiento de dispositivo cuando aplique

MFA no solucionará una segmentación pésima, pero detiene una cantidad deprimente de incidentes “la credencial funcionó, fin del juego”.

4) Usar política de cuentas fuerte: bloqueos, longitud de contraseña y no compartir admins

El Administrador local compartido entre servidores sigue siendo dolorosamente común. También es la forma en que una caja comprometida se convierte en cuarenta. Usa LAPS/Windows LAPS para que cada máquina tenga una contraseña de administrador local única.

Configura umbrales de bloqueo sensatos. Pero entiende el trade-off: los bloqueos pueden convertirse en vector de denegación de servicio si tienes mucha exposición pública (otra razón para eliminar exposición pública).

5) Restringe quién puede RDP (y elimina al resto)

No permitas que “Domain Users” o grupos amplios hagan RDP. Usa un grupo dedicado, privilegios mínimos y mantenlo pequeño. Si necesitas acceso de proveedor, crea un grupo específico para proveedores, acceso con límite temporal y audítalo como si importara.

6) Endurece el endpoint: Defender/EDR, parcheo y reducir movimiento lateral

Los ataques RDP suelen ser solo el comienzo. Una vez que acceden a un host, los atacantes intentan escalar y pivotar. Haz que eso sea difícil:

Parchea regularmente (especialmente componentes relacionados con RDP y la pila de autenticación de Windows)
Deshabilita protocolos legacy (cuando sea factible)
Bloquea SMB entrante desde segmentos no confiables
Usa reglas del Firewall de Windows explícitas y acotadas

7) Registra como si lo necesitaras a las 3 a.m.

RDP sin registro es una casa encantada: oyes pasos, pero no puedes probar nada. Recopila:

Eventos de inicio de sesión de Seguridad (éxito/fallo, tipo de inicio, IP de origen)
Registros TerminalServices RemoteConnectionManager y LocalSessionManager
Registros de firewall (al menos en el perímetro; preferiblemente también en el host)

Una cita que merece estar en la pared de cada equipo de operaciones:

“La esperanza no es una estrategia.” — Gene Kranz

Broma #1: Cambiar el puerto RDP es como ponerle un bigote falso a tu servidor y llamarlo “StealthHost01”. Internet no se engaña.

Tareas prácticas (comandos, salidas y qué decides)

Estos están diseñados para ejecutarse en Windows (localmente o vía gestión remota). La etiqueta del prompt es solo una convención de shell—no le des más vueltas.

Tarea 1: ¿Está habilitado RDP en este host?

cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
    fDenyTSConnections    REG_DWORD    0x0

Qué significa la salida: 0x0 significa que se permiten conexiones RDP. 0x1 significa negado.

Decisión: Si esta máquina no tiene una razón de negocio para RDP, configúrala para negar y elimina cualquier regla de firewall entrante. Si la tiene, continúa con el endurecimiento.

Tarea 2: ¿Se requiere NLA?

cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
    UserAuthentication    REG_DWORD    0x1

Qué significa la salida: 0x1 generalmente indica que NLA es obligatorio. 0x0 indica que no es obligatorio.

Decisión: Si es 0x0, activa NLA a menos que tengas un requisito de cliente legacy específico—y si lo tienes, arréglalo. No lo institucionalices.

Tarea 3: ¿En qué puerto escucha RDP (y está abierto)?

cr0x@server:~$ netstat -ano | findstr ":3389"
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       1148
  TCP    [::]:3389              [::]:0                 LISTENING       1148

Qué significa la salida: El host escucha en 3389 en todas las interfaces; el PID 1148 posee el socket.

Decisión: Si el host escucha en una interfaz pública, debes restringir las rutas de red entrantes (VPN/RD Gateway/firewall perimetral) y reglas de firewall host. “Lo vamos a monitorear” no es un control.

Tarea 4: Confirma la postura de reglas entrantes del Firewall de Windows para RDP

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Get-NetFirewallAddressFilter | Select-Object Name,RemoteAddress"
Name                           RemoteAddress
----                           -------------
RemoteDesktop-UserMode-In-TCP   Any
RemoteDesktop-UserMode-In-UDP   Any

Qué significa la salida: Las reglas integradas de RDP permiten desde Any dirección remota. Eso es la configuración por conveniencia, no por seguridad.

Decisión: Cambia RemoteAddress a tus subredes VPN o IPs de jump host. Si no puedes articular los rangos origen permitidos, no estás listo para permitir RDP.

Tarea 5: Restringir RDP a subredes origen conocidas (firewall host)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallRule -DisplayName 'Remote Desktop - User Mode (TCP-In)' -RemoteAddress 10.8.0.0/24,10.9.0.0/24; Get-NetFirewallRule -DisplayName 'Remote Desktop - User Mode (TCP-In)' | Get-NetFirewallAddressFilter | Select-Object RemoteAddress"
RemoteAddress
-------------
{10.8.0.0/24, 10.9.0.0/24}

Qué significa la salida: Solo clientes en esas subredes pueden alcanzar RDP TCP.

Decisión: Si no puedes restringir a orígenes conocidos, no deberías exponer RDP. Implementa VPN o RD Gateway primero.

Tarea 6: Comprueba quién puede iniciar sesión vía RDP

cr0x@server:~$ powershell -NoProfile -Command "Get-LocalGroupMember -Group 'Remote Desktop Users' | Select-Object Name,ObjectClass"
Name                      ObjectClass
----                      ----------
CONTOSO\IT-RemoteAdmins    Group

Qué significa la salida: Solo el grupo especificado está en el grupo local “Remote Desktop Users”.

Decisión: Si ves grupos amplios o usuarios individuales añadidos ad hoc, ajusta. Usa grupos dedicados. Elimina excepciones que existen solo porque alguien no quiso abrir una solicitud de acceso.

Tarea 7: Revisa la política de bloqueo de cuentas (dominio o local)

cr0x@server:~$ net accounts
Force user logoff how long after time expires?:       Never
Minimum password age (days):                          1
Maximum password age (days):                          90
Minimum password length:                              14
Length of password history maintained:                24
Lockout threshold:                                    10
Lockout duration (minutes):                           15
Lockout observation window (minutes):                 15

Qué significa la salida: La longitud de contraseña, historial y configuraciones de bloqueo son visibles. Estos pueden estar sobrescritos por políticas de dominio.

Decisión: Si el umbral de bloqueo es 0 (nunca bloquear) o la longitud de contraseña es corta, corrige la política. Si estás expuesto a internet, también corrige la exposición—los bloqueos por sí solos son un parche.

Tarea 8: Verificar la política de auditoría para eventos de inicio de sesión

cr0x@server:~$ auditpol /get /subcategory:"Logon"
System audit policy
Category/Subcategory                      Setting
Logon                                    Success and Failure

Qué significa la salida: Los eventos de inicio de sesión se registran para intentos exitosos y fallidos.

Decisión: Si no es “Success and Failure”, actívalo. No puedes investigar lo que no registraste.

Tarea 9: Identificar inicios de sesión RDP fallidos en el registro de Seguridad (últimos 50)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 | Select-Object TimeCreated,@{n='User';e={$_.Properties[5].Value}},@{n='Ip';e={$_.Properties[19].Value}} | Format-Table -Auto"
TimeCreated             User               Ip
-----------             ----               --
1/28/2026 2:11:05 AM    Administrator      203.0.113.44
1/28/2026 2:10:58 AM    admin              203.0.113.44
1/28/2026 2:10:52 AM    test               203.0.113.44
1/28/2026 2:10:45 AM    svc_backup         203.0.113.44
1/28/2026 2:10:39 AM    user               203.0.113.44

Qué significa la salida: El ID de evento 4625 muestra intentos fallidos; la IP indica la fuente. Ver IPs públicas aquí es un olor si habías planeado que RDP fuera privado.

Decisión: Si las fuentes no son tus rangos VPN/jump, tu historia de firewall está equivocada. Bloquea en el borde y en el host. Luego busca inicios de sesión exitosos desde la misma fuente.

Tarea 10: Encontrar inicios de sesión RDP exitosos (Tipo de inicio 10) en el registro de Seguridad

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 20 | Where-Object { $_.Properties[8].Value -eq 10 } | Select-Object TimeCreated,@{n='Account';e={$_.Properties[5].Value}},@{n='Ip';e={$_.Properties[18].Value}} | Format-Table -Auto"
TimeCreated             Account            Ip
-----------             -------            --
1/27/2026 9:14:22 PM    CONTOSO\j.smith    10.8.0.24

Qué significa la salida: El Tipo de inicio 10 normalmente indica RemoteInteractive (RDP). La IP de origen debe ser la ruta de gestión esperada.

Decisión: Cualquier inicio de sesión RDP exitoso desde una IP inesperada es un incidente hasta que se demuestre lo contrario. Contén primero, debate después.

Tarea 11: Revisar logs operativos de TerminalServices para intentos de conexión

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational' -MaxEvents 5 | Select-Object TimeCreated,Id,Message | Format-List"
TimeCreated : 1/28/2026 2:12:01 AM
Id          : 1149
Message     : Remote Desktop Services: User authentication succeeded: CONTOSO\j.smith

TimeCreated : 1/28/2026 2:11:55 AM
Id          : 1149
Message     : Remote Desktop Services: User authentication succeeded: CONTOSO\it-admin

Qué significa la salida: Estos logs ayudan a correlacionar eventos de autenticación RDP con comportamiento de sesión; son útiles cuando los registros de Seguridad están ruidosos.

Decisión: Si este registro está deshabilitado o no se recoge centralmente, arréglalo. Es una señal barata.

Tarea 12: Validar el estado del servicio RDP

cr0x@server:~$ sc query TermService
SERVICE_NAME: TermService
        TYPE               : 20  WIN32_SHARE_PROCESS
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Qué significa la salida: Remote Desktop Services está en ejecución. Si está en máquinas que no deberían aceptar RDP, eso es drift.

Decisión: Para endpoints/servidores no administrativos, considera deshabilitar el servicio RDP y eliminar permisos en lugar de dejarlo “disponible por si acaso”.

Tarea 13: Confirma que no aceptas capas de seguridad RDP antiguas y débiles

cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
    SecurityLayer    REG_DWORD    0x2

Qué significa la salida: Los valores varían según la configuración; generalmente quieres TLS y no fallback a “RDP Security Layer”. (El mapeo exacto puede variar por build y política.)

Decisión: Si ves configuraciones que permiten fallback a capas más débiles, aplica política para TLS-only y elimina excepciones. Las excepciones son cómo la “compatibilidad temporal” se vuelve “exposición permanente”.

Tarea 14: Verificar el registro del Firewall de Windows Defender (visibilidad del host)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile | Select-Object Name,LogAllowed,LogBlocked,LogFileName | Format-Table -Auto"
Name    LogAllowed LogBlocked LogFileName
----    ---------- ---------- -----------
Domain  False      True       %systemroot%\system32\logfiles\firewall\pfirewall.log
Private False      True       %systemroot%\system32\logfiles\firewall\pfirewall.log
Public  False      True       %systemroot%\system32\logfiles\firewall\pfirewall.log

Qué significa la salida: Se registran las conexiones bloqueadas. Las conexiones permitidas no se registran (a menudo está bien; registrar todo puede ser ruidoso).

Decisión: Si estás solucionando exposición o ataques, el registro de bloqueos ayuda a validar si las reglas funcionan. Si los registros no están habilitados en ningún lado, estás depurando a ciegas.

Tarea 15: Comprobar exposición entrante 3389 en el perímetro desde un jump Linux (vista externa)

cr0x@server:~$ nmap -Pn -p 3389 198.51.100.10
Starting Nmap 7.80 ( https://nmap.org ) at 2026-01-28 02:14 UTC
Nmap scan report for 198.51.100.10
Host is up (0.020s latency).

PORT     STATE SERVICE
3389/tcp open  ms-wbt-server

Nmap done: 1 IP address (1 host up) scanned in 0.45 seconds

Qué significa la salida: El host es alcanzable en 3389 desde el lugar donde ejecutaste este escaneo. Si esa ubicación es internet público o una red no confiable, tienes un problema.

Decisión: Ciérralo en el firewall perimetral/grupo de seguridad. No confíes solo en el firewall del host. La defensa en profundidad no es un eslogan; es tu línea temporal de incidentes futuros.

Tarea 16: Enumerar sesiones RDP activas (¿quién está en la máquina?)

cr0x@server:~$ quser
 USERNAME              SESSIONNAME        ID  STATE   IDLE TIME  LOGON TIME
 j.smith               rdp-tcp#12          2   Active          .  1/27/2026 9:14 PM
 it-admin              rdp-tcp#13          3   Disc            8  1/28/2026 1:58 AM

Qué significa la salida: Puedes ver sesiones activas y desconectadas. Las sesiones desconectadas pueden persistir y ser abusadas si no las gestionas.

Decisión: Si ves administradores inesperados o sesiones desconectadas de larga duración, investiga y considera configurar timeouts de sesión y políticas de “cerrar sesión en desconexión”.

Tarea 17: Confirma que el equipo no está en perfil de red “Public” (común en imágenes de cloud)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Select-Object InterfaceAlias,NetworkCategory"
InterfaceAlias NetworkCategory
-------------- ---------------
Ethernet0       DomainAuthenticated

Qué significa la salida: DomainAuthenticated usualmente significa que aplican políticas de dominio y los perfiles de firewall son adecuados.

Decisión: Si es Public inesperadamente, corrige la identificación de red y la aplicación de perfil de firewall; puede que te falten GPO de dominio o que se apliquen reglas incorrectas.

Broma #2: RDP en internet abierto es el equivalente en seguridad de “vamos a guardar las contraseñas en una hoja de cálculo, pero en una pestaña oculta.” A los atacantes les encantan las pestañas ocultas.

Tres mini-historias corporativas desde el frente

Mini-historia 1: El incidente causado por una suposición errónea

La empresa migró un conjunto de servidores Windows a una VPC en la nube. El equipo de red juraba que “nada es público a menos que lo pongamos explícitamente público”. Suena razonable. También fue incorrecto en la práctica.

Un equipo de proyecto necesitaba que un proveedor realizara una instalación puntual en un servidor de aplicación legacy. Alguien añadió una regla entrante temporal en un grupo de seguridad para permitir TCP/3389 “desde el rango IP del proveedor”. Ese rango era más amplio de lo que cualquiera imaginaba—porque el proveedor usaba una piscina rotativa y el ticket se tradujo en “permitir desde cualquier lado por ahora”. La regla nunca se eliminó. Nadie lo notó porque nada se rompió. Y que nada se rompa es cómo el riesgo se institucionaliza.

Dos meses después, el registro de Seguridad se llenó de fallos 4625 contra cuentas locales. El SOC lo vio pero lo categorizó como ruido de fondo de internet. Después de todo, “RDP no es público”. La compromisión vino por una contraseña reutilizada para una cuenta de administrador local que también existía en otros servidores. El atacante inició sesión una vez, luego enumeró la red, recolectó credenciales y usó RDP lateralmente donde estaba permitido internamente.

El informe posterior al incidente fue brutal en el buen sentido. La falla primaria no fue “mala contraseña.” Fue la suposición de que el entorno hacía imposible la exposición. La solución fue igualmente contundente: cheques automatizados que verificaran continuamente qué hosts eran alcanzables en 3389 desde fuera de la red de gestión, más un requisito estricto de que todo RDP debía venir de VPN o RD Gateway, aplicado en el perímetro y en el host.

Las suposiciones erróneas no se anuncian. Aparecen después como “inicios de sesión inesperados” y un calendario lleno de reuniones incómodas.

Mini-historia 2: La optimización que salió mal

Un equipo de operaciones decidió reducir llamadas al helpdesk relajando los bloqueos de cuentas. Pensaron: trabajadores remotos suelen equivocarse al teclear contraseñas, y los bloqueos generan cola de soporte. Así que aumentaron sustancialmente el umbral de bloqueo y acortaron la duración del bloqueo. Lo enmarcaron como “mejorar productividad”. Mejoró la productividad—para los atacantes.

Al mismo tiempo, estaban incorporando contratistas y no quisieron emitir dispositivos gestionados. Los contratistas recibieron credenciales VPN (sin MFA entonces) y se les indicó RDP a un jump host. El jump host tenía RDP abierto a la subred VPN, lo que sonaba razonable. Pero la subred VPN era enorme, compartida entre socios y poco monitorizada.

Luego llegó el password spraying. No una fuerza bruta rápida que dispare alarmas. Un spray paciente y distribuido sobre muchas cuentas desde muchas IP VPN. Con los bloqueos relajados, el atacante tuvo suficiente pista. Finalmente, una cuenta de contratista con una contraseña débil fue acertada. Desde allí: RDP al jump host, luego a servidores internos, luego volcado de credenciales.

El equipo revirtió los cambios de bloqueo, implementó MFA en VPN y segmentó las piscinas VPN para que “contratistas” no estuvieran en el mismo océano que los admins. La lección no fue “los bloqueos lo solucionan todo.” La lección: optimizar para menos tickets sin entender el comportamiento de amenaza es cómo pagas por silencio con seguridad.

Buena operaciones reduce el trabajo manual sin aumentar el radio de impacto. Si tu optimización reduce trabajo y aumenta el radio de impacto, no optimizaste; pediste problemas a futuro.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Otra empresa tenía una práctica persistente y casi anticuada: cada trimestre ejecutaban una revisión de accesos y una revisión de exposición de firewall. No una presentación. Una revisión real con cambios ejecutados y validados.

Tenían una regla: RDP no es un método de acceso; es un protocolo interno. El método de acceso es VPN con MFA, y solo desde dispositivos gestionados. Los firewalls de host aceptaban RDP solo desde jump hosts y una pequeña VLAN de administradores. Además, el firewall perimetral tenía un deny global para 3389 entrante. Si querías una excepción, tenías que explicarlo por escrito a dos equipos a los que les gusta decir “no”.

Un fin de semana, su SIEM alertó sobre un estallido de fallos 4625 contra unas cuentas administrativas en un servidor que no debería haber sido alcanzable excepto desde la VLAN administrativa. El SRE de guardia revisó los logs de firewall del host y vio intentos bloqueados desde un rango de red de un socio. Eso debería haber sido imposible.

Resultó que un cambio de red había enrutado por accidente el rango del socio hacia un segmento interno que podía alcanzar el servidor. El firewall del host bloqueó los intentos y los logs lo demostraron. Arreglaron la ruta antes de cualquier inicio de sesión exitoso. El informe del incidente fue corto, aburrido y satisfactorio—el mejor tipo. El control preventivo funcionó, el control detector dijo la verdad y la recuperación fue “cambiar una ruta, cerrar el ticket”.

Las prácticas aburridas no llenan conferencias. Mantienen tu nombre fuera de los avisos de brechas.

Guion de diagnóstico rápido (encuentra el cuello de botella rápido)

Esta es la secuencia “estás de guardia, RDP está ‘fallando’ y alguien grita”. El objetivo es determinar rápidamente si el problema es exposición, autenticación, política o recursos.

Primero: verifica exposición y ruta

Desde fuera de la red de gestión, prueba alcanzabilidad a 3389 (o tu puerto configurado). Si es alcanzable públicamente, eso no es un “problema de conectividad”—es una falla de política.
En el servidor, verifica sockets en escucha (netstat -ano) y el alcance del firewall (RemoteAddress no Any).
Confirma la ruta del cliente: ¿Los usuarios se conectan vía VPN o RD Gateway? Si no pueden responder, tú tampoco.

Segundo: revisa controles de autenticación y política

¿Se exige NLA? Revisa UserAuthentication y políticas de grupo.
¿Hay bloqueos de cuentas? Revisa inicios fallidos (4625), eventos de bloqueo (4740 en dominios) e identifica si es error de dedo o tráfico de ataque.
¿Se aplica MFA en la ruta de acceso (VPN/RD Gateway)? Si no, asume que las credenciales eventualmente serán reproducidas.

Tercero: confirma salud del servicio y sesiones

Revisa el estado de TermService. Si está detenido, pregunta por qué se detuvo (crash, parche, política?).
Revisa sesiones activas/desconectadas (quser). Demasiadas sesiones pueden degradar la experiencia y ocultar abuso.
Revisa presión de CPU y memoria (Task Manager/PerfMon). La “lentitud” de RDP suele ser una VM con CPU saturada.

Cuarto: busca intención maliciosa, rápido

Ráfaga de fallos 4625 desde IPs inesperadas → trátalo como tráfico de ataque; bloquea en perímetro y host.
Cualquier 4624 Logon Type 10 desde IP fuente inesperada → incidente hasta que se limpie.
Correlaciona con logs operativos de TerminalServices para identificar la línea temporal de usuario/sesión.

Errores comunes: síntoma → causa raíz → solución

1) “Deshabilitamos RDP, pero sigue siendo alcanzable”

Síntoma: El puerto 3389 sigue apareciendo abierto en escaneos; los usuarios todavía pueden conectarse.

Causa raíz: Deshabilitaste conexiones de usuario en un lugar (registro/UI) pero dejaste reglas de firewall o un camino RD Gateway, o estás escaneando otro host/objetivo NAT.

Solución: Valida en el host fDenyTSConnections, estado del servicio y reglas de firewall; valida en el perímetro (grupo de seguridad/firewall) y confirma mapeos NAT. Asegúrate de que no haya un listener alterno ni un balanceador que reenvíe.

2) “Habilitamos NLA, pero clientes legacy no pueden conectar”

Síntoma: Thin clients antiguos o sistemas embebidos fallan al conectarse tras el cambio.

Causa raíz: El cliente no soporta NLA/CredSSP.

Solución: Actualiza o reemplaza los clientes. Si debes soportarlos temporalmente, aísla los hosts destino, restringe IPs origen estrictamente y pon una fecha límite. No generalices la excepción.

3) “RDP sigue bloqueando cuentas”

Síntoma: Usuarios se bloquean repetidamente; tickets al helpdesk se disparan.

Causa raíz: Password spraying o una credencial guardada (tarea programada, servicio, unidad mapeada) falla repetidamente. A veces es un atacante; a veces es tu propia automatización.

Solución: Inspecciona logs de Seguridad: patrones 4625 y IPs origen. Si vienen de rangos externos/inesperados, bloquea. Si vienen de hosts internos, encuentra la fuente de la credencial almacenada (tarea, servicio, credencial RDP caché). Resetea y actualiza.

4) “Restringimos firewall a subred VPN, pero la gente se conecta desde casa sin VPN”

Síntoma: Las conexiones tienen éxito desde IPs públicas.

Causa raíz: Otra regla de firewall lo está permitiendo (mayor prioridad), o hay un allow upstream en el perímetro con NAT hairpinning, o restringiste la regla equivocada (UDP vs TCP, o nombre de visualización distinto).

Solución: Enumera todas las reglas entrantes que referencian 3389 y grupos de Remote Desktop; verifica la política efectiva; deshabilita reglas amplias; registra tráfico bloqueado y vuelve a probar desde una red externa.

5) “Movimos RDP a otro puerto y los ataques pararon” (por ahora)

Síntoma: Menos entradas en logs; menos alertas.

Causa raíz: Redujiste ruido, no riesgo. Los atacantes escanean todos los puertos; solo dejaste de estar en la lista de fruta más baja temporalmente.

Solución: Devuélvelo si te gusta la estandarización. Más importante: elimina exposición a internet, exige NLA, aplica MFA vía camino de acceso, restringe fuentes y monitoriza. Reducir ruido no es un control.

6) “RDP es lento e inestable”

Síntoma: Desconexiones frecuentes, lag, pantallas negras.

Causa raíz: A menudo falta de recursos (CPU/memoria), o problemas de ruta de red (pérdida de paquetes, problemas MTU en VPN), o host de sesión sobrecargado.

Solución: Revisa conteo de sesiones, CPU/memoria y eventos para razones de desconexión. Trata rendimiento separado de seguridad, pero no permitas que “arreglos” de rendimiento suavicen controles de seguridad.

7) “Tenemos RD Gateway, así que estamos seguros”

Síntoma: RDP directo sigue abierto “para emergencias”, y se usa.

Causa raíz: Workaround cultural. El camino de emergencia se vuelve el principal porque es más fácil.

Solución: Elimina RDP entrante directo. Si necesitas un método break-glass, debe ser con límite temporal, registrado y requerir aprobación explícita con MFA.

Listas de comprobación / plan paso a paso

Fase 0: Decide qué RDP está permitido

Política: “RDP es solo interno.” Escríbelo.
Método de acceso: Elige VPN+MFA o RD Gateway+MFA (o ambos).
Modelo de administración: Cuentas administrativas dedicadas; nada de admins locales compartidos; usa LAPS/Windows LAPS.
Registro: Seguridad + registros TerminalServices recogidos centralmente, con alertas por anomalías.

Fase 1: Eliminar exposición

En el perímetro, bloquea TCP/3389 entrante (y UDP/3389 si aplica) desde internet.
Si no puedes bloquear globalmente, bloquea por host y documenta excepciones con propietarios y expiración.
En cada host, limita reglas de firewall RDP a subredes VPN/jump hosts únicamente.
Valida desde una red externa que 3389 está cerrado.

Fase 2: Endurecer autenticación

Activa NLA en todas partes.
Implementa MFA en VPN/RD Gateway.
Exige longitud mínima de contraseña e historial; evita excepciones débiles para cuentas de servicio.
Configura umbrales/ventanas/duración de bloqueo apropiados (y reduce exposición primero para evitar DoS por bloqueos).

Fase 3: Reducir radio de impacto

Usa cuentas administrativas separadas (sin email, sin navegación) y restringe dónde pueden iniciar sesión.
Limita la membresía de “Remote Desktop Users” a grupos dedicados.
Segmenta redes para que subredes de usuarios no puedan RDP a servidores por defecto.
Asegura que EDR/Defender esté habilitado y la protección contra manipulación configurada según el estándar de la organización.

Fase 4: Hacerlo observable

Activa política de auditoría para éxitos/errores de inicio de sesión.
Reúne 4624/4625 y logs operativos de TerminalServices centralmente.
Alerta sobre:
- Ráfagas de 4625 desde una única IP o muchas IPs
- 4624 Logon Type 10 desde rangos IP no administrativos
- Inicios de sesión RDP fuera de ventanas de cambio esperadas para servidores sensibles
Ejecuta cheques mensuales de exposición (escaneo externo + verificación interna).

Preguntas frecuentes

1) ¿Cambiar el puerto RDP ayuda?

Reduce ruido, no riesgo. Puede ser un pequeño obstáculo, pero los escáneres lo encuentran. Hazlo solo si apoya la estandarización en tu entorno, no como control principal.

2) ¿Es NLA suficiente para asegurar RDP?

No. NLA es necesario. No es suficiente. Aún necesitas acceso de red restringido (VPN/RD Gateway), MFA y controles adecuados de cuentas.

3) ¿Debo permitir RDP solo desde una lista de IPs permitidas?

Sí, si la lista es estable (subredes VPN, IPs de jump hosts, VLANs administrativas). Evita permitir IPs caseras aleatorias; eso se vuelve inadministrable y fomenta excepciones.

4) ¿Qué IDs de evento importan más para investigaciones RDP?

Empieza con el registro de Seguridad 4624 (inicio de sesión exitoso) y 4625 (fallido). En entornos de dominio, también vigila bloqueos de cuenta (4740). Añade los logs operativos de TerminalServices RemoteConnectionManager para correlación específica de RDP.

5) Necesitamos que proveedores entren por RDP. ¿Cuál es el enfoque menos malo?

Usa RD Gateway o VPN con MFA, restringe por membresía de grupo, acceso limitado en el tiempo y restringe a hosts destino específicos. Registra y revisa. “Proveedor admin local permanente” es cómo terminas con respuesta a incidentes permanente por proveedores.

6) ¿Necesito UDP/3389 abierto?

Muchos entornos pueden funcionar solo con TCP, pero características de rendimiento pueden usar UDP. Desde seguridad, trata la exposición UDP igual: restringe fuentes y evita exposición a internet. Prueba con tu base de clientes antes de deshabilitar.

7) ¿Cuál es la ganancia más rápida si heredé un entorno desordenado?

Bloquea RDP entrante en el perímetro, luego limita reglas de firewall host a redes de gestión. Eso corta instantáneamente escaneo masivo y fuerza bruta desde internet.

8) Si usamos RD Gateway, ¿podemos dejar RDP directo abierto como respaldo?

No. Los respaldos se vuelven primarios bajo presión. Si requieres un camino break-glass, debe ser temporal, protegido con MFA y auditado con aprobación explícita.

9) ¿Cómo saber si nuestros “ataques RDP” son reales o solo ruido de internet?

Si ves intentos fallidos (4625) desde IPs públicas, eso es ruido pero sigue siendo un problema porque indica exposición. Si ves cualquier inicio de sesión exitoso (4624 tipo 10) desde fuentes inesperadas, eso es real.

10) ¿Deberíamos deshabilitar RDP completamente en servidores?

Si puedes gestionar servidores por canales más seguros (herramientas de gestión remota, administración just-in-time, acceso a consola), sí—reduce el número de máquinas donde RDP es siquiera posible. Para el resto, mantenlo privado y controlado.

Próximos pasos prácticos

Haz esto en las próximas dos semanas, no “este trimestre”. Los atacantes no esperan a que tu calendario de ventanas de cambios esté emocionalmente listo.

Inventario: Encuentra cada host Windows con RDP habilitado y cada camino que pueda alcanzarlo (interno y externo).
Cierra exposición: Bloquea RDP entrante en el perímetro. Luego limita reglas de firewall host a fuentes VPN/jump.
Exige NLA: Actívalo en todas partes, elimina excepciones, actualiza clientes.
Pon MFA en la ruta de acceso: VPN o RD Gateway, con política de que administradores usen dispositivos gestionados.
Corrige higiene administrativa: Cuentas administrativas separadas, elimina permisos RDP amplios, despliega LAPS/Windows LAPS.
Operacionaliza telemetría: Activa auditoría de inicio de sesión, recoge logs centralmente y alerta sobre las señales pequeñas que importan.
Pruébalo: Vuelve a ejecutar los comandos anteriores después de los cambios. Si no puedes demostrar la línea base, no tienes una línea base—tienes sensaciones.