Muchas organizaciones dan por hecho que, tras implantar la autenticación multifactor (MFA), el riesgo de compromiso de cuentas cae drásticamente. En entornos de nube esto suele cumplirse. Sin embargo, en redes basadas en Windows y Active Directory (AD) la realidad es más compleja: los atacantes siguen logrando acceso diario a redes corporativas utilizando usuarios y contraseñas válidos, sin que se les exija ningún factor adicional.
Limitaciones del MFA en la autenticación de Windows y Active Directory
El modelo dominante hoy es la arquitectura híbrida: un identity provider (IdP) en la nube —como Microsoft Entra ID, Okta o Google Workspace— protege aplicaciones SaaS y accesos web con MFA. No obstante, una parte crítica de los inicios de sesión en la infraestructura Windows sigue dependiendo de los mecanismos clásicos de autentificación de AD, principalmente Kerberos y NTLM, que no interactúan con el IdP en la nube y, por tanto, no disparan un reto MFA.
Inicio de sesión local y controladores de dominio on-premises
Cuando un usuario inicia sesión directamente en una estación de trabajo unida al dominio o en un servidor, la validación de sus credenciales la realiza un controlador de dominio on-premises. Si no se han desplegado tecnologías como Windows Hello for Business, tarjetas inteligentes u otra forma de MFA integrada en Windows, el inicio de sesión se basa únicamente en la contraseña o en su hash.
Desde la perspectiva del controlador de dominio, esto es una petición de autenticación estándar y las políticas de MFA del proveedor en la nube no se aplican. De este modo, si un atacante obtiene la contraseña de un usuario o su hash NTLM, puede autenticarse en un equipo del dominio y moverse por la red eludiendo por completo los mecanismos de protección en la nube que sí blindan portales web y SSO.
RDP y VPN: vectores preferidos para el acceso sin MFA
El Escritorio Remoto (RDP) y las conexiones VPN siguen siendo dos de los puntos de entrada más atacados en redes Windows. Incluso cuando RDP no está expuesto a Internet, los atacantes suelen llegar a este servicio mediante lateral movement tras una intrusión inicial. Un acceso RDP directo a un servidor suele depender de credenciales de dominio y, al no pasar por el IdP en la nube, el inicio de sesión suele producirse sin MFA.
Para cerrar esta brecha, cada vez más organizaciones recurren a soluciones especializadas que permiten forzar MFA en el propio inicio de sesión de Windows, RDP y VPN, e incluso proteger el inicio de sesión sin conexión mediante códigos de un solo uso. Así, el robo de una sola contraseña deja de ser suficiente para obtener acceso efectivo al sistema.
NTLM, Kerberos y movimiento lateral basado en credenciales
Riesgos de NTLM y ataques pass-the-hash
A pesar del esfuerzo prolongado de la industria por abandonar NTLM en favor de Kerberos, este protocolo sigue muy presente por motivos de compatibilidad. NTLM resulta especialmente atractivo porque permite la técnica pass-the-hash: el atacante no necesita conocer la contraseña en texto claro, basta con capturar o extraer el hash NTLM y presentarlo al sistema como prueba de autenticidad.
En estos escenarios, MFA no aporta protección: si la aplicación o el servicio aceptan el hash como credencial válida, no se solicita ningún segundo factor. El riesgo aumenta porque la autenticación NTLM suele esconderse en servicios internos y aplicaciones heredadas, y sus usos solo salen a la luz durante un incidente o una auditoría de seguridad.
Kerberos y robo de tickets en entornos Active Directory
Kerberos es el protocolo de autenticación principal en AD. En este contexto, el objetivo del atacante ya no son las contraseñas, sino los tickets Kerberos. Con acceso a la memoria de un host comprometido o a una cuenta con altos privilegios, es posible robar o falsificar tickets, incluyendo los conocidos golden tickets y silver tickets.
Estas técnicas permiten mantener acceso persistente a largo plazo y desplazarse lateralmente por la red sin necesidad de volver a introducir credenciales, reduciendo así las oportunidades de detección. Incluso cambiar la contraseña de las cuentas afectadas puede no bastar si la causa raíz —por ejemplo, un controlador de dominio comprometido— no se ha solucionado.
Cuentas privilegiadas, SMB y cuentas de servicio: el eslabón débil
En muchas organizaciones siguen existiendo cuentas de administrador local con la misma contraseña reutilizada en decenas o cientos de equipos. Comprometer un solo host es entonces suficiente para escalar el acceso a gran parte del entorno. Estas cuentas se autentican localmente y no están cubiertas por MFA ni por las políticas de acceso condicional de Entra ID.
El protocolo SMB, ampliamente utilizado para compartir ficheros y para administración remota, continúa siendo uno de los canales de movimiento lateral más eficaces: con credenciales válidas, un atacante puede aprovechar recursos administrativos como C$ y la ejecución remota de comandos. En este nivel, rara vez se aplica MFA, al asumirse que el tráfico interno es de confianza.
Las cuentas de servicio representan otra categoría de alto riesgo. Se utilizan para ejecutar servicios, tareas programadas e integraciones entre sistemas. Sus contraseñas suelen tener una caducidad muy laxa (o ninguna), suelen disponer de amplios privilegios y apenas se someten a monitorización. Implementar MFA en estas cuentas es complejo porque la autenticación es automatizada y muchas aplicaciones heredadas no soportan métodos modernos.
Estrategias prácticas para reforzar la autenticación en Windows
Un primer pilar es una política de contraseñas reforzada en Active Directory. Se recomienda el uso de frases de contraseña largas (15 caracteres o más), evitar el reciclaje de contraseñas antiguas y bloquear patrones predecibles. Es crucial considerar que una parte significativa de las credenciales corporativas ya aparece en bases de datos de contraseñas filtradas, empleadas por los atacantes en ataques de credential stuffing.
Herramientas específicas de gestión de contraseñas para AD permiten ir más allá de las capacidades estándar de Microsoft. Funcionalidades como la comparación automática con bases de datos de contraseñas comprometidas —que en algunos casos superan los 5.400 millones de registros— advierten al usuario cuando intenta elegir una contraseña ya expuesta en incidentes previos.
En paralelo, es recomendable minimizar al máximo el uso de NTLM: inventariar dónde se utiliza, deshabilitarlo o restringirlo donde sea posible, y endurecer los controles en los casos en que deba mantenerse. Del mismo modo, conviene tratar la autenticación de Windows como una superficie de ataque independiente e implantar MFA específicamente en el inicio de sesión del sistema operativo, en RDP y en VPN mediante soluciones especializadas.
Las cuentas de servicio y las cuentas administrativas deben gestionarse como activos de alto riesgo: inventariarlas, aplicar least privilege, rotar sus contraseñas de forma periódica, eliminar las que no se utilicen y monitorizar con especial atención cualquier actividad asociada.
Las organizaciones que conciben el MFA como algo más que un requisito para acceder a aplicaciones en la nube y fortalecen de forma sistemática la autenticación en Windows —desde la política de contraseñas y el control de NTLM hasta el MFA a nivel de logon, RDP y VPN— reducen de manera significativa la probabilidad de ataques exitosos basados en credenciales. El siguiente paso lógico es auditar el entorno de Active Directory, identificar las “zonas ciegas” de autenticación y evaluar herramientas especializadas que permitan cerrar, en la práctica, estos huecos críticos de seguridad.
