Autenticación RDP a nivel de red, modo Admin restringido, Active Directory: los tres ajustes que deciden quién controla tu sesión

Toda checklist de hardening de Remote Desktop termina con los mismos tres puntos: autenticación RDP a nivel de red, modo Admin restringido, Active Directory — credenciales en caché. Marcar los tres no convierte una sesión Remote Desktop en segura. Dos de ellos son mejoras defensivas reales, y el tercero — el modo Admin restringido — protege las credenciales que escribes mientras le da a un atacante que ya posee un hash una vía de entrada.

Este artículo separa los tres ajustes, muestra cómo se restringen entre sí, y ofrece los valores de registro, las rutas de Group Policy y los campos de evento necesarios para auditar cada uno.

Autenticación RDP a nivel de red, modo Admin restringido, Active Directory: las tres decisiones del hardening

Una conexión Remote Desktop a un host unido al dominio implica tres decisiones independientes, cada una configurada en un lugar distinto:

1. La autenticación a nivel de red (NLA) — ¿se autentica al usuario antes de establecer la sesión?
2. La capa de seguridad — ¿cómo se autentica y cifra el propio canal?
3. El modo de delegación de credenciales — ¿envía el cliente sus credenciales al host remoto, siquiera?

Un cuarto ajuste, el número de inicios de sesión en caché, decide cuánto material de credenciales queda en el host después. La mayoría de las herramientas de auditoría reportan estos elementos como cuatro casillas independientes. En la práctica interactúan: elegir la capa de seguridad equivocada desactiva NLA en silencio, y activar el modo de delegación "seguro" cambia lo que un atacante necesita para iniciar sesión.

La capa de seguridad va primero

Las tres capas de seguridad

Microsoft documenta tres capas de seguridad para una conexión RD Session Host. La distinción importa más de lo que parece, porque una de las tres es mutuamente excluyente con NLA:

Esa última frase es de Microsoft, de Configure Server Authentication and Encryption Levels. Es la razón por la que un host puede tener una política "NLA requerido" y aun así no tener NLA en juego realmente: cuando la capa negociada acaba cayendo en el cifrado RDP nativo, se aplica la propia exclusión de Microsoft y la autenticación a nivel de red no puede usarse.

Que Negotiate sea el valor por defecto es el problema silencioso, y no es un artefacto heredado: la referencia SecurityLayer actual de Microsoft sigue documentando 1 (negotiate) como "el valor por defecto". No impone TLS — acepta lo que el cliente ofrezca y degrada a la capa de seguridad RDP para un cliente que declara no soportar TLS. Un atacante que controle el lado cliente del handshake controla esa elección.

Niveles de cifrado

Un ajuste distinto, el nivel de cifrado, gobierna la fortaleza de la clave. Microsoft lista cuatro valores, con Client Compatible como valor por defecto:

Vale la pena decirlo claramente sobre Low: deja el tráfico servidor-a-cliente — el contenido de pantalla de una sesión administrativa — en texto claro.

Todos estos ajustes viven bajo Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security, y Microsoft señala que estos ajustes de Group Policy "tendrán precedencia sobre los ajustes configurados en Remote Desktop Session Host Configuration, con la excepción del ajuste de política Server Authentication Certificate Template".

Por qué importa la autenticación a nivel de red

NLA adelanta la autenticación del usuario antes del establecimiento de la sesión. La descripción original de Microsoft sigue siendo la más clara: "completa la autenticación del usuario antes de que establezcas una conexión Remote Desktop y aparezca la pantalla de inicio de sesión", y las ventajas indicadas son que el equipo remoto "usa un número limitado de recursos antes de autenticar al usuario" y que esto "puede ayudar a mejorar la seguridad reduciendo el riesgo de ataques de denegación de servicio" (Configure Network Level Authentication).

El valor de esa barrera de pre-autenticación no es teórico. En las mitigaciones publicadas junto a su aviso para CVE-2019-0708, la vulnerabilidad de ejecución remota de código pre-autenticación de Remote Desktop Services conocida comúnmente como BlueKeep, Microsoft escribió:

NLA convirtió un fallo pre-autenticación explotable de forma "gusano" en uno post-autenticación. Ese es todo el argumento para exigirlo — pone a cada futura vulnerabilidad RDP pre-autenticación detrás de una comprobación de credenciales.

El ajuste del lado del host es un único valor de registro:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication

1 exige NLA, 0 lo desactiva. La guía de resolución de problemas de VM de Azure de Microsoft usa exactamente este valor para desactivar y reactivar temporalmente NLA — que es también cómo tiende a quedar desactivado de forma permanente durante un incidente, sin volver a activarse nunca.

Modo Admin restringido: el control de doble filo

El modo Admin restringido cambia lo que envía el cliente. La documentación de Remote Credential Guard de Microsoft enumera con precisión sus beneficios de seguridad:

• Las credenciales no se envían al host remoto
• La sesión Remote Desktop se conecta a otros recursos con la identidad del host remoto
• Un atacante no puede actuar en nombre del usuario, y cualquier ataque queda local al servidor

La tabla comparativa de Microsoft marca el modo Admin restringido como preventivo de Pass-the-Hash, y para escenarios de helpdesk lo recomienda explícitamente: "las conexiones RDP solo deberían iniciarse usando el modificador /RestrictedAdmin". Nótese también que el acceso RDP bajo Admin restringido se concede por pertenencia al grupo Administrators en el host remoto, no al grupo Remote Desktop Users.

Tanto el modo como Remote Credential Guard dependen de un único valor del lado del host:

reg.exe add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 /t REG_DWORD

La inversión

Aquí es donde las dos lecturas divergen, y la distinción es direccional.

La afirmación de Microsoft trata sobre las credenciales que salen del cliente: con Admin restringido, nada llega al host remoto, así que nada puede recolectarse ahí y reproducirse después. Eso es cierto.

La consecuencia trata sobre las credenciales que entran al host. Como el cliente ya no envía una contraseña, el inicio de sesión se satisface con material de credenciales que el cliente ya posee — lo que significa que un hash NTLM es suficiente. Una investigación pública documentó esto el mismo año en que se lanzó la funcionalidad. Portcullis Labs (autor MRL, 20 de octubre de 2013) describió que el cliente enviaba "empty credentials in the TSPasswordCreds structure" en Windows 8.1 y Windows Server 2012 R2, y demostró la autenticación pasando un hash en lugar de la contraseña. Su prueba de concepto no era un cliente estándar: requería FreeRDP-pth, una versión parcheada de FreeRDP cuyo argumento -p lleva un hash NT en lugar de una contraseña.

# FreeRDP-pth, el cliente parcheado de 2013 — -p lleva el hash NT
xfreerdp -u test -p 36374BD2767773A2DD4F6B010EC5EE0D 192.168.226.129

Un cliente estándar no aceptará esto: trata el hash como una contraseña en texto claro y el inicio de sesión falla. FreeRDP actual implementa esta capacidad de forma nativa, con la opción documentada como "Pass the hash (restricted admin mode)":

xfreerdp3 /u:test /pth:36374BD2767773A2DD4F6B010EC5EE0D /v:192.168.226.129

La misma publicación señala que la técnica solo funciona para administradores — los miembros del grupo Remote Desktop Users no pueden autenticarse así. Con el cliente nativo de Windows, el equivalente es inyectar primero el hash en una sesión de inicio de sesión:

sekurlsa::pth /user:Administrator /domain:CORP /ntlm:<hash> /run:"mstsc.exe /restrictedadmin"

Así que ambas afirmaciones son ciertas a la vez. El modo Admin restringido evita que tus credenciales sean robadas desde el host remoto, y baja el listón para iniciar sesión en ese host, de una contraseña en texto claro a un simple hash. Si el pass-the-hash ya es viable en tu entorno, activar el modo Admin restringido a nivel de dominio lo extiende al acceso RDP interactivo en cada host donde esté activado.

Hay una segunda consecuencia. Como la autenticación se evalúa contra un token en lugar de una contraseña escrita, los controles aplicados en el destino pueden eludirse. SpiderLabs (Apurva Goenka, 15 de noviembre de 2023 — publicado bajo Trustwave, desde entonces adquirida por LevelBlue) documentó que la autenticación "no ocurre en el servidor Remote Desktop sino en el propio cliente", así que "los factores de autenticación aplicados en el servidor de destino, como MFA vía Duo, Okta... quedan sin efecto" (Restricted Admin Mode – Circumventing MFA On RDP Logons).

Inicios de sesión en caché: qué queda atrás

Las credenciales de dominio en caché permiten a un usuario iniciar sesión cuando no hay un controlador de dominio accesible. La guía de Microsoft sobre Interactive logon: Number of previous logons to cache (in case domain controller is not available) plantea el riesgo directamente: "Un atacante capaz de acceder al sistema de archivos del servidor podría localizar esta información en caché y usarla en un ataque de fuerza bruta para intentar determinar las contraseñas de los usuarios." La información en caché "no expira, pero puede sobrescribirse".

El valor por defecto es 10 inicios de sesión en servidores miembro y equipos cliente, y el rango aceptado va de 0 a 50. La tabla de valores por defecto de Microsoft indica que el valor efectivo por defecto en un controlador de dominio es Sin efecto — el ajuste simplemente no se aplica ahí.

Hay que citar la recomendación con cuidado, porque la propia página de Microsoft no habla con una sola voz. Su sección Countermeasure dice configurar el valor a 0, desactivando el caché local. Su sección Best practices dice que las líneas base de seguridad de Windows "no recomiendan configurar este ajuste" en absoluto. Su sección Potential impact sugiere 2 para equipos de usuario final, para que los usuarios móviles puedan seguir iniciando sesión fuera de la red. La postura defendible para un servidor miembro Tier 0 es un valor bajo; para portátiles, 0 rompe por completo el inicio de sesión sin conexión. Un matiz que se malinterpreta con frecuencia: este ajuste no se aplica a los controladores de dominio, cuyo valor efectivo por defecto Microsoft lista como "Sin efecto" — los DC alojan el directorio y no cachean inicios de sesión de dominio.

Detección

El evento 4624 lleva los campos necesarios para distinguir estos inicios de sesión. La versión 2 del evento (Windows 10 y posteriores) añadió un campo RestrictedAdminMode, que según Microsoft "solo se rellena para sesiones de inicio de sesión de tipo RemoteInteractive" y es un indicador Sí/No que señala si se usó el modo Admin restringido.

Ese detalle importa para escribir una regla correcta: una sesión RDP en Admin restringido sigue siendo Logon Type 10 (RemoteInteractive), no Type 3. El modo es visible en el indicador, no en el tipo de inicio de sesión.

La recomendación de monitorización de Microsoft en esa misma página merece adoptarse literalmente: si el modo Admin restringido debe usarse por ciertas cuentas, monitoriza los inicios de sesión de esas cuentas con Logon Type = 10 y Restricted Admin Mode = "Yes", y dispara una alerta cuando Restricted Admin Mode = "No" para ellas. Invertirlo es igual de útil — alertar cuando RestrictedAdminMode = "Yes" para cuentas que nunca deberían usarlo, ya que las herramientas de atacantes recurren a /restrictedadmin precisamente porque acepta un hash.

Auditar la configuración

Auditar la configuración en sí es una lectura de registro en cada host:

$ts = "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp"
Get-ItemProperty -Path $ts -Name UserAuthentication, SecurityLayer, MinEncryptionLevel
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name DisableRestrictedAdmin -ErrorAction SilentlyContinue

Que el valor DisableRestrictedAdmin esté ausente significa que el modo no está activado; un valor de 0 significa que sí lo está.

Remediación

1. Exigir TLS como capa de seguridad. Activa Require use of specific security layer for remote (RDP) connections y selecciona SSL, bajo Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security. Emite los certificados de RD Session Host desde tu CA interna en lugar de aceptar el certificado autofirmado por defecto.

2. Exigir NLA. En la misma ruta de política, activa Require user authentication for remote connections by using Network Level Authentication. Group Policy tiene precedencia sobre la configuración local, que es lo que quieres para controlar el desvío de configuración.

3. Elevar el nivel de cifrado. Configura Set client connection encryption level en High para que el tráfico sea de 128 bits en ambas direcciones, y confirma que ningún host quede en Low.

4. Decidir el modo Admin restringido de forma deliberada, por tier. No lo actives a nivel de dominio por reflejo. Donde los administradores se conecten a hosts de menor confianza, prefiere Remote Credential Guard vía la política Restrict delegation of credentials to remote servers configurada en Require Remote Credential Guard. Donde sea genuinamente necesario para trabajo de helpdesk, actívalo solo en esos hosts y alerta sobre su uso en cualquier otro lugar. Ten en cuenta la advertencia de Microsoft: cuando Restrict Credential Delegation está activado, "el modificador /restrictedAdmin será ignorado" y en su lugar se usa Remote Credential Guard.

5. Habilitar la delegación de credenciales no exportables en hosts remotos — requerido tanto para Admin restringido como para Remote Credential Guard — vía Remote host allows delegation of nonexportable credentials.

6. Reducir los inicios de sesión en caché en servidores. Configura Interactive logon: Number of previous logons to cache en un valor bajo bajo Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. Valídalo frente a tus requisitos de inicio de sesión sin conexión antes de aplicarlo a portátiles.

7. Desplegar LAPS. Microsoft asocia su guía sobre Admin restringido con Windows LAPS, que "mitiga el riesgo de escalada lateral" derivado de contraseñas de administrador local compartidas — exactamente la condición que hace útil un único hash robado en cada host.

Verificar el resultado

Verifica el resultado en lugar de confiar en el informe de la GPO:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" |
    Select-Object UserAuthentication, SecurityLayer, MinEncryptionLevel

UserAuthentication debería ser 1 y SecurityLayer debería ser 2 (TLS).

Estos controles se refuerzan entre sí junto con el resto de tu hardening de autenticación — exigir TLS en RDP es el mismo argumento que exigir firma SMB y firma LDAP en las rutas de NTLM relay, y restringir quién puede alcanzar Tier 0 vía RDP es inseparable de restringir la delegación Kerberos y la política de contraseñas.

Cómo lo detecta EtcSec

EtcSec audita estos cuatro ajustes de forma independiente, porque fallan de forma independiente. PA038_RDP_NLA_NOT_REQUIRED genera un hallazgo cuando ninguna GPO del dominio configura UserAuthentication a 1. PA038_RDP_SECURITY_LAYER_WEAK se dispara a menos que una política fije la capa de seguridad en TLS, de modo que el valor por defecto Negotiate, que puede degradarse en silencio, también se reporta. TERMINAL_SERVICES_NOT_HARDENED cubre la superficie más amplia de configuración de Terminal Services y RDP, y CACHED_LOGONS_EXCESSIVE se dispara cuando Winlogon\CachedLogonsCount supera 4. Son comprobaciones a nivel de política: un resultado limpio significa que la política existe, y confirmar que realmente se aplicó en cada host sigue siendo la lectura de registro anterior.