MFA para RDP: bloquee el acceso remoto no autorizado
El Remote Desktop Protocol (RDP) sigue siendo uno de los protocolos de acceso remoto más explotados en los entornos empresariales. Los atacantes escanean continuamente en busca del puerto 3389 expuesto, usan credenciales robadas e intentan el movimiento lateral a través de sesiones RDP. Una contraseña por sí sola ya no es suficiente.
Protectimus ofrece una solución de MFA específica para Remote Desktop. El componente Protectimus Winlogon intercepta la autenticación a nivel del Windows Credential Provider, añadiendo un segundo factor sólido directamente en el flujo de inicio de sesión de RDP, sin cambiar la arquitectura de acceso remoto existente.
Índice
- Por qué RDP es el vector de ataque nº 1 en las redes empresariales
- Cómo funciona la MFA de Protectimus con el Remote Desktop Protocol
- Métodos de autenticación compatibles para RDP
- Escenarios de implementación de la MFA para RDP
- Requisitos del sistema y compatibilidad
- Paso a paso: cómo añadir MFA a RDP en 4 pasos
- Opciones de configuración avanzada
- Cumplimiento y estándares de seguridad
- Casos de clientes y casos de uso
- Preguntas frecuentes
- Empiece hoy con la MFA para RDP
Respuesta rápida
Despliegue el Protectimus Winlogon Agent en sus servidores RDP, conéctelo al servicio en la nube de Protectimus o a la plataforma on-premises, y aplique la MFA obligatoria para las sesiones RDP. La mayoría de las organizaciones completan la configuración de un solo servidor en menos de 2 horas.
Datos clave
Las credenciales robadas alimentan el ransomware
El 73% de las víctimas de ransomware sufrió una filtración de credenciales o una infección por infostealer en el año previo al ataque
RDP: el punto de entrada favorito del ransomware
Más del 90% de los incidentes de ransomware involucran RDP como vector de acceso inicial
Alerta CISA AA22-074A
CISA señala RDP como un vector de ataque principal y recomienda la MFA como la mitigación más importante
Ventajas clave
Sin dependencia de VPN
El desafío de MFA ocurre a nivel del Windows Credential Provider, antes de que se abra la sesión.
Acceso de emergencia
Los códigos de respaldo de un solo uso ofrecen una opción de recuperación segura cuando no se puede realizar la validación normal de la MFA.
Compatibilidad total con NLA
Funciona con Network Level Authentication habilitada, la línea base de seguridad recomendada para toda implementación de RDP.
Amplia cobertura de servicios
Protege AD, puertas de enlace VPN, aplicaciones federadas mediante ADFS, el inicio de sesión de Windows y RDP, OWA, y aplicaciones web personalizadas.
Implementación escalable
El componente Protectimus Winlogon admite la implementación centralizada mediante GPO, simplificando el despliegue en entornos Windows grandes.
Flexibilidad de implementaciónDeployment flexibility
SaaS en la nube o plataforma de MFA on-premises con control total sobre la residencia de los datos.
Por qué RDP es el vector de ataque nº 1 en las redes empresariales
En los primeros días de la pandemia, las organizaciones se apresuraron a exponer RDP a internet. Muchas nunca lo volvieron a cerrar. Hoy, los escáneres de seguridad encuentran constantemente millones de hosts con el puerto 3389 accesible desde internet público, y los atacantes saben exactamente dónde buscar.
El modelo de amenazas contra los sistemas expuestos mediante RDP se divide en tres categorías, ninguna de las cuales puede detener una contraseña por sí sola:
Credential stuffing y fuerza bruta.Los atacantes recorren listas de credenciales de brechas anteriores: miles de millones de pares usuario/contraseña que se comercian en foros de la dark web y canales de Telegram. Una contraseña robusta no ofrece ninguna protección si se reutilizó de un sitio ya vulnerado. Herramientas como Hydra y Medusa prueban miles de combinaciones de inicio de sesión RDP por minuto contra endpoints sin limitación de intentos.
Pass-the-hash y Kerberoasting.En cuanto un atacante consigue un punto de apoyo en cualquier máquina Windows de su entorno —mediante phishing, una aplicación web vulnerable, lo que sea—, puede extraer hashes NTLM de la memoria con Mimikatz y autenticarse en otros sistemas Windows vía RDP sin conocer nunca la contraseña en texto plano. Una contraseña de un solo uso basada en tiempo (TOTP), generada de nuevo cada 30 segundos, no se almacena en ningún lugar al que el pass-the-hash pueda llegar.
Vulnerabilidades de RDP. CVE-2019-0708 (BlueKeep) y CVE-2019-1181/1182 (DejaBlue) demostraron que el propio RDP puede contener vulnerabilidades de corrupción de memoria previas a la autenticación. Aplicar parches sigue siendo el control principal, pero la defensa en profundidad exige una segunda capa de autenticación incluso en servidores completamente actualizados.
El filtrado por lista de IP permitidas no sustituye a la MFA. Las reglas de firewall que solo permiten IP corporativas conocidas fallan en cuatro situaciones habituales: empleados con IP domésticas dinámicas del ISP; viajes de trabajo; acceso de proveedores externos; y, lo más crítico, cualquier atacante que ya haya comprometido una máquina dentro del rango permitido. Un atacante interno que se mueve lateralmente vía RDP llega a la misma lista de permitidos que usa su administrador.
NIST SP 800-63B lo deja claro: cualquier endpoint RDP accesible desde más de una ubicación física de confianza debería exigir MFA.
Cómo funciona la MFA de Protectimus con el Remote Desktop Protocol
El Protectimus Winlogon Agent se integra en la capa del Windows Credential Provider, el subsistema de autenticación entre la entrada del usuario y el proceso de inicio de sesión de Windows (winlogon.exe / LogonUI). El desafío de MFA ocurre después de enviar las credenciales, pero antes de que Windows conceda la sesión.
Flujo de autenticación
Compatibilidad con NLA
NLA autentica al usuario antes de que se abra la sesión de escritorio completa. El agente de Protectimus es totalmente compatible con NLA y no requiere desactivarla. Los usuarios introducen sus credenciales de Windows y el OTP como parte del mismo flujo de autenticación. Mantenga NLA habilitada junto con la MFA: cada una cubre una parte distinta de la superficie de ataque (NLA reduce la exposición a denegación de servicio; la MFA detiene el abuso de credenciales).
Como Protectimus opera en la capa del Windows Credential Provider, protege tanto los inicios de sesión locales de Windows como las sesiones de Remote Desktop mediante el mismo mecanismo de autenticación. Tras validar correctamente el OTP, las credenciales originales de Windows continúan por el proceso estándar de autenticación de Windows, preservando la compatibilidad con los flujos existentes de Active Directory y de autenticación de cuentas locales.
Métodos de autenticación compatibles para RDP
Método | App / dispositivo | Recomendado para | Disponible para registro automático |
|---|---|---|---|
App autenticadora TOTP | Protectimus SMART, Google Authenticator, etc. | La mayoría de usuarios e implementaciones RDP estándar | Sí |
SMS OTP | Usuarios que no pueden usar apps autenticadoras | Sí | |
Email OTP | Usuarios sin acceso a smartphones o tokens hardware | Sí | |
OTP por chatbot | Protectimus BOT (Telegram, Viber, Facebook Messenger) | Usuarios que prefieren recibir OTP en apps de mensajería | No |
Notificaciones push | Usuarios que prefieren la autenticación con un solo toque | No | |
Token hardware (llavero) | Entornos industriales, sanitarios y sin smartphones | No | |
Token hardware (tarjeta) | Empleados que ya llevan tarjetas de acceso o identificación | No |
Nota: el registro automático actualmente admite Protectimus SMART OTP, SMS OTP y Email OTP. Las notificaciones push, los tokens hardware y la entrega de OTP mediante chatbots en apps de mensajería pueden asignarse manualmente por los administradores.
Los tokens hardware TOTP resultan especialmente relevantes para RDP en entornos industriales o sanitarios donde los smartphones están prohibidos. Protectimus Slim NFC y Protectimus FLEX pueden reprogramarse por NFC cuando sea necesario, lo que permite reutilizar el mismo token en lugar de sustituirlo.
Escenarios de implementación de la MFA para RDP
Escenario 1: servidor Windows independiente
Instale el Protectimus Winlogon Agent en el servidor Windows, conéctelo al servicio de Protectimus o a la plataforma on-premises, y configure los usuarios y los métodos de autenticación. Todas las sesiones RDP —y los inicios de sesión de consola local— en ese servidor requieren ahora un segundo factor. Es habitual en oficinas remotas, jump hosts o servidores de pequeñas empresas.
Escenario 2: entorno con varios servidores
En entornos con varios servidores Windows, instale el Protectimus Winlogon Agent en cada servidor que acepte inicios de sesión de usuario. Todos los servidores pueden conectarse al mismo Resource de Protectimus, lo que permite a los administradores gestionar de forma centralizada las políticas de MFA, los usuarios y los métodos de autenticación, protegiendo cada endpoint RDP.
Escenario 3: implementación en Active Directory mediante GPO
Para entornos más grandes, Protectimus admite la implementación centralizada mediante Política de Grupo. Los administradores pueden instalar el componente en un controlador de dominio y crear una GPO para el despliegue automático en los servidores y estaciones de trabajo seleccionados. Esto reduce considerablemente el esfuerzo de despliegue y garantiza una protección MFA coherente en todo el entorno Windows.
Nota: Protectimus Winlogon protege los inicios de sesión de Windows y el acceso RDP en los sistemas donde está instalado el componente. Las organizaciones que buscan protección MFA en todos los servicios integrados con Active Directory pueden considerar también la MFA para Active Directory mediante el componente Protectimus DSPA, que aplica contraseñas de un solo uso dinámicas a nivel de directorio.
Requisitos del sistema y compatibilidad
Sistemas operativos Windows compatibles (host RDP)
SO | Estado |
|---|---|
Windows Server 2022 | Totalmente compatible |
Windows Server 2019 | Totalmente compatible |
Windows Server 2016 | Totalmente compatible |
Windows Server 2012 / 2012 R2 | Totalmente compatible |
Windows 10 / 11 | Totalmente compatible |
Windows 8 / 8.1 | Totalmente compatible |
Se admiten tanto servidores unidos a AD como servidores independientes en grupo de trabajo. No se requieren cambios en el esquema de Active Directory ni extensiones de directorio personalizadas.
Requisitos del servidor Protectimus (on-premises)
Componente | Mínimo |
|---|---|
CPU | 2 vCPU |
RAM | 8 GB |
Almacenamiento | 20 GB |
SO | Linux, Windows, FreeBSD |
Java | JDK 8+ |
Base de datos | PostgreSQL 10+ |
Para la implementación en la nube, no se requiere infraestructura de servidor más allá del Winlogon Agent en el host RDP.
Paso a paso: cómo añadir MFA a RDP en 4 pasos
Paso 1: Implemente el servidor de autenticación de Protectimus
Elija su modelo de implementación:
Nube: regístrese en service.protectimus.com. No se requiere infraestructura de servidor. El plan gratuito incluye hasta 10 usuarios, y las cuentas nuevas reciben un crédito de prueba de $25 para evaluar los métodos de autenticación y filtros de pago.
On-Premises: instale la Protectimus On-Premise Platform en su propia infraestructura. Configure la base de datos, cree una cuenta de administrador y verifique el acceso a la consola de gestión.
Después de la implementación, cree un Resource que se usará para gestionar usuarios, tokens y políticas de acceso de Winlogon.
Paso 2: Configure las políticas de acceso de Winlogon
Abra la configuración del Resource y vaya a la pestaña Winlogon.
Configure las políticas de acceso necesarias, entre ellas:
- Habilite el acceso para los inicios de sesión locales de Windows y/o las sesiones RDP.
- Habilite la autenticación de dos factores.
- Configure el registro automático de usuarios.
- Configure la activación automática de tokens.
- Seleccione los métodos de autenticación disponibles para el registro automático (Protectimus SMART OTP, SMS OTP o Email OTP).
- Configure direcciones IP de confianza, si es necesario.
- Elija si la MFA debe exigirse a todos los usuarios o solo a las cuentas seleccionadas.
Para la mayoría de las implementaciones, Protectimus recomienda habilitar el registro automático de usuarios y tokens.
Paso 3: Instale el Protectimus Winlogon Agent
Descargue la última versión del Protectimus Winlogon installer y ejecútelo en el servidor Windows que desea proteger..
Durante la instalación, proporcione:
- URL de la API
- Usuario de la cuenta
- Clave de API
- ID del recurso
También puede configurar:
- Políticas de MFA para inicios de sesión locales y RDP
- Ajustes de acceso sin conexión
- Generación de códigos de respaldo
- Aplicación de MFA exclusiva para RDP
En entornos de Active Directory, los administradores pueden además implementar el componente mediante Política de Grupo (GPO) o realizar la instalación remota desde un controlador de dominio.
Paso 4: Registre a los usuarios y pruebe la autenticación
Si el registro automático está habilitado, se pedirá a los usuarios que registren un método de autenticación durante su primer inicio de sesión exitoso.
Las organizaciones que usan tokens OTP hardware, autenticación por notificación push o mediante chatbot pueden crear usuarios y asignar tokens manualmente.
Después del registro, verifique tanto los inicios de sesión locales de Windows como los inicios de sesión por Remote Desktop para confirmar que las políticas de MFA se aplican correctamente. Antes de cerrar la sesión actual del administrador, pruebe la autenticación con una cuenta secundaria para evitar un bloqueo accidental causado por errores de configuración..
Para capturas de pantalla detalladas y ejemplos de implementación, consulte la guía completa de integración de RDP paso a paso.
Opciones de configuración avanzada
Opción | Qué hace |
|---|---|
Políticas separadas para inicios de sesión locales y RDP | Configure reglas de acceso distintas para los inicios de sesión locales de Windows y las sesiones de Remote Desktop. Por ejemplo, exija MFA solo para el acceso RDP mientras permite inicios de sesión locales estándar. |
Registro automático de usuarios | Crea automáticamente cuentas de usuario en Protectimus cuando los usuarios inician sesión por primera vez. |
Activación automática de tokens | Solicita a los usuarios que activen un método de autenticación compatible durante su primer inicio de sesión |
Direcciones IP de confianza | Permite a los usuarios iniciar sesión sin un OTP al conectarse desde direcciones IP de confianza especificadas. |
Implementación mediante GPO | Implementa, actualiza y elimina el componente Winlogon de forma centralizada mediante la Política de Grupo de Active Directory. |
Instalación remota | Instala el componente Winlogon directamente en los equipos de dominio seleccionados desde un controlador de dominio sin esperar al procesamiento de la GPO. |
Protección de instalación | Impide la eliminación no autorizada del componente Winlogon de las estaciones de trabajo gestionadas. |
Cumplimiento y estándares de seguridad
La MFA para RDP se corresponde directamente con los requisitos de autenticación de los principales marcos:
NIST SP 800-63B — el nivel de garantía 2+ exige MFA para el acceso remoto. Los autenticadores basados en TOTP satisfacen el requisito de “algo que usted tiene”. Vea NIST SP 800-63B.
HIPAA Security Rule — exige controles técnicos contra el acceso no autorizado a ePHI a través de una red. El RDP a servidores sanitarios transmite ePHI; la MFA es el control principal. Vea la guía de HHS.
PCI DSS v4.0 — el Requisito 8.4.2 exige MFA para todo acceso administrativo no consola al entorno de datos de titulares de tarjetas. RDP es explícitamente no consola.
SOC 2 (Type II)— CC6.1 (controles de acceso lógico). Los auditores señalan el RDP sin MFA como un hallazgo. Una implementación documentada con registro de eventos suele satisfacer el requisito de evidencia.
ISO 27001:2022 — el control A.8.5 del Anexo A exige autenticación robusta para el acceso privilegiado y remoto.
NIS2 Directive (EU) — el artículo 21 exige MFA para las entidades esenciales e importantes. El RDP a sistemas de producción entra claramente en el alcance.
Casos de clientes y casos de uso
Servicios financieros: refuerzo tras un incidente en más de 200 servidores
Una entidad regional de servicios financieros sufrió un incidente de credential stuffing: un atacante se autenticó en un servidor Windows vía RDP usando credenciales procedentes de una brecha de SaaS no relacionada, y se movió lateralmente durante 40 minutos antes de que saltara una alerta del SIEM. El CISO necesitaba desplegar la protección en más de 200 servidores en menos de dos semanas sin modificar el esquema de AD, ya que una modificación del esquema habría llevado meses según su proceso de control de cambios. El equipo desplegó el Winlogon Agent mediante un MSI de Política de Grupo. Los usuarios registraron sus métodos de autenticación durante su primer inicio de sesión exitoso en Windows o RDP. En 10 días, todos los servidores accesibles por RDP exigían un segundo factor; 15 administradores sénior de la sala de operaciones recibieron tokens hardware en lugar de apps de smartphone.
Sanidad: preparación para la auditoría de HIPAA
Un proveedor sanitario con varias sedes tenía una carencia en su revisión de la HIPAA Security Rule: acceso RDP a servidores EMR sin MFA. Su equipo legal exigía que todos los datos de autenticación permanecieran on-premises, ya que los registros de autenticación contendrían información sensible de acceso de usuarios y marcas de tiempo relacionadas con sistemas que procesan ePHI. La plataforma on-premises de Protectimus estuvo operativa en menos de tres horas. El auditor externo aceptó la exportación del registro de eventos como parte de las evidencias de la organización para los controles de auditoría de HIPAA bajo 45 CFR § 164.312(b).
Manufactura: implantación de tokens hardware sin smartphones
Un fabricante de piezas de automóvil necesitaba MFA para los servidores Windows de la planta de producción, donde los operarios no llevan smartphones y la señal móvil no es fiable. La empresa se estandarizó en los tokens Protectimus Slim NFC, en formato tarjeta, que se llevan junto con las tarjetas de acceso. Los tokens fueron preaprovisionados por el administrador; no se requirió ningún paso de registro por parte del usuario final. Los tokens hardware TOTP siguen generando contraseñas de un solo uso sin internet ni cobertura móvil, lo que los hace idóneos para entornos donde los smartphones están prohibidos o la cobertura móvil no es fiable.
Preguntas frecuentes
¿Funciona la MFA de Protectimus con NLA (Network Level Authentication)?
Sí, y NLA debe permanecer habilitada. El Protectimus Winlogon Agent se integra en la capa del Windows Credential Provider, que es compatible con NLA. Los usuarios introducen sus credenciales de Windows y el OTP como parte del flujo de autenticación antes de que se abra la sesión de escritorio remoto.
¿Qué ocurre si el servidor de Protectimus no está disponible?
Si el servicio o la plataforma on-premises de Protectimus no están disponibles temporalmente, los usuarios no pueden completar la MFA mediante los métodos de autenticación estándar hasta que se restablezca la conectividad.
Para escenarios de emergencia, Protectimus admite códigos de respaldo de un solo uso que pueden usarse en lugar de un OTP para acceder a los sistemas Windows protegidos. Los códigos de respaldo se generan durante la instalación de Winlogon, y se emite automáticamente un nuevo código de respaldo cada vez que se usa el anterior. Los códigos de respaldo deben almacenarse de forma segura como parte del plan de continuidad del negocio de la organización.
¿Puedo usar tokens hardware en lugar de un smartphone?
Sí. Protectimus admite todos los tokens hardware OATH-TOTP, incluidos Protectimus TWO, FLEX, SHARK y Slim NFC. Los tokens hardware funcionan en entornos donde los smartphones están prohibidos y operan de forma independiente de la conectividad de red.
¿Cuánto se tarda en implementar en 50 servidores?
Una implementación por script o mediante Política de Grupo en 50 servidores suele completarse en un solo día laboral. El instalador admite la instalación silenciosa con parámetros de línea de comandos. El registro de usuarios se ejecuta en paralelo con el despliegue, y los usuarios registran sus métodos de autenticación durante su primer inicio de sesión exitoso en Windows o RDP.
¿Existe una opción on-premises para los requisitos de residencia de datos?
Sí. La plataforma completa de Protectimus puede implementarse en su propia infraestructura, incluidos entornos Linux, Windows y FreeBSD. Todos los datos de autenticación, registros y datos de usuarios permanecen dentro del perímetro de su red, ofreciendo el mismo conjunto de funciones que el servicio en la nube.
¿Cuál es la diferencia entre la MFA para RDP y Winlogon?
El componente Protectimus Winlogon protege tanto los inicios de sesión locales de Windows como las sesiones de Remote Desktop mediante un único agente. La página /winlogon/ cubre todos los escenarios de autenticación de Windows compatibles. Esta página se centra específicamente en el acceso por Remote Desktop, incluido el modelo de amenazas de RDP, la compatibilidad con Network Level Authentication (NLA), los escenarios de implementación y las mejores prácticas para proteger entornos RDP. Para la guía de instalación completa, consulte MFA para el inicio de sesión de Windows y RDP.
Empiece hoy con la MFA para RDP
El servicio en la nube de Protectimus incluye un plan gratuito para hasta 10 usuarios, lo que permite a las organizaciones validar una implementación completa en un servidor representativo antes de un despliegue más amplio. Las cuentas nuevas también reciben un crédito de prueba de $25 para evaluar métodos de autenticación adicionales. La plataforma de MFA on-premises está disponible para organizaciones con requisitos de residencia de datos.
Si su alcance va más allá de RDP —VPN, inicio de sesión local de Windows, ADFS—, la misma plataforma cubre todo esto desde una única consola de administración. La MFA para Active Directory mediante el componente DSPA y la MFA RADIUS para VPN están disponibles como parte del ecosistema más amplio de Protectimus.
Conclusión
RDP sigue siendo el camino más directo desde internet hacia su infraestructura Windows. Una contraseña robada es todo lo que un atacante necesita para atravesarlo. Un segundo factor —un código TOTP de 30 segundos generado por una app móvil o un token hardware— hace que esa credencial no sirva de nada por sí sola.
El Protectimus Winlogon Agent añade la MFA en la capa del Windows Credential Provider, protegiendo tanto los inicios de sesión locales de Windows como las sesiones de Remote Desktop, mientras permanece totalmente compatible con Network Level Authentication (NLA). La solución puede implementarse en horas y escalarse en entornos Windows grandes mediante herramientas de despliegue centralizado.
Para el recorrido de instalación completo, consulte la guía completa de integración de RDP paso a paso →
