MFA no basta en Windows: descubre los caminos de autenticación que aún permiten moverse por la red

Muchas organizaciones han celebrado la llegada de la autenticación multifactor (MFA) como la panacea que cerraría de golpe el problema de las credenciales robadas. Sin embargo, en entornos Windows esa confianza a veces resulta prematura: los atacantes siguen accediendo a redes con cuentas válidas porque gran parte de la autenticación en Windows no pasa por el proveedor de identidad en la nube y, por tanto, no obliga a un segundo factor.

No es que MFA falle; el problema es que no cubre todos los caminos por los que Windows valida identidades. Cuando las sesiones se verifican contra controladores de dominio locales mediante Kerberos o NTLM, las políticas aplicadas en Azure AD, Okta u otros IdP no se activan. Microsoft describe estos protocolos y sus implicaciones en su documentación sobre Kerberos y NTLM, que sirve como referencia para entender por qué ciertos inicios de sesión quedan fuera del alcance de las soluciones en la nube: Kerberos y NTLM.

Firmar directamente en un equipo Windows unido al dominio —ya sea un portátil del usuario o un servidor— suele ser un proceso gestionado por Active Directory. Si la organización no ha integrado mecanismos de segundo factor para el inicio de sesión local (por ejemplo, Windows Hello for Business o tarjetas inteligentes), ese acceso queda validado con la contraseña o con el hash almacenado en memoria. En consecuencia, un atacante que obtenga esa contraseña o su representación criptográfica puede moverse por la red sin activar las políticas de acceso condicional impuestas en el IdP. Microsoft explica las opciones para modernizar el inicio de sesión y reducir este riesgo en la documentación de Windows Hello for Business y en guías sobre protección de credenciales como Credential Guard.

Otro vector habitual son las sesiones de Escritorio Remoto (RDP). Aunque no se exponga RDP a Internet, los atacantes suelen usarlo para desplazarse lateralmente tras un acceso inicial. Una conexión RDP a un servidor no garantiza que se atraviese la capa de control de acceso del IdP; muchas veces la autenticación se resuelve localmente con AD, dejando el acceso expuesto a credenciales robadas. Por eso es clave aplicar controles de acceso en el perímetro y en la teleadministración, así como soluciones que integren MFA en esos flujos.

NTLM, legado pero aún presente por compatibilidad, sigue siendo un blanco atractivo. Técnicas como el “pass-the-hash” aprovechan el hecho de que NTLM permite autenticar con el hash en lugar de la contraseña en texto claro, por lo que un atacante no necesita conocer la contraseña para validarse. MITRE documenta estas técnicas y sus variantes, lo que ayuda a entender la mecánica de abuso en entornos Windows: Pass-the-Hash y Pass-the-Ticket.

Kerberos tampoco es inmune. En lugar de robar contraseñas, los intrusos pueden extraer tickets de autenticación de la memoria o forjar tickets a partir de credenciales privilegiadas, creando escenarios conocidos como Golden Ticket o Silver Ticket. Estos ataques permiten acceso persistente y lateralidad con un menor número de autenticaciones visibles, y pueden sobrevivir a cambios de contraseña si no se remedia la causa raíz. Las implicaciones operativas y de detección están bien recogidas por MITRE y en la literatura especializada sobre abusos de Kerberos.

Un factor recurrente en las intrusiones son las cuentas locales con privilegios administrativos y la reutilización de contraseñas. Muchas organizaciones mantienen cuentas locales para soporte o recuperación, y cuando esas credenciales se repiten en varios equipos, una sola filtración puede abrir muchas puertas. Microsoft ofrece herramientas para mitigar este problema, entre ellas Local Administrator Password Solution (LAPS), que automatiza la rotación de contraseñas locales y reduce el riesgo derivado de contraseñas estáticas: LAPS.

El protocolo SMB, utilizado para compartir archivos y gestionar recursos remotos, es otro vector de movimiento lateral muy utilizado. Con credenciales válidas, un atacante puede acceder a recursos administrativos y moverse por la red con rapidez. Por eso los controles de autenticación sobre servicios como SMB y las auditorías de tráfico interno son fundamentales; el catálogo de técnicas de MITRE incluye las vías de servicios remotos y cómo se emplean para lateralidad: SMB / Windows Admin Shares.

Las cuentas de servicio constituyen un riesgo discreto pero grave. Están diseñadas para automatizar tareas, integraciones y servicios, por lo que suelen tener contraseñas largas vigentes durante años y permisos amplios. Al no poder incorporar MFA en procesos automatizados con facilidad, estas cuentas se convierten en objetivos privilegiados para los atacantes. Auditar, rotar y minimizar privilegios en cuentas de servicio son medidas indispensables que muchas organizaciones posponen y que, por desgracia, facilitan la escalada y la persistencia de amenazas.

¿Qué pueden hacer los equipos de seguridad para cerrar estos huecos? La respuesta pasa por tratar la autenticación de Windows como una superficie de riesgo con sus propias reglas y controles. Empezar por endurecer las políticas de contraseñas en Active Directory, promoviendo el uso de frases de paso más largas y evitando la reutilización, ya reduce la probabilidad de compromiso por fuerza bruta o reutilización de credenciales. El NIST recomienda enfoques modernos en la gestión de contraseñas y cribado de credenciales comprometidas, cuya lectura aclara por qué las contraseñas largas y la verificación frente a filtraciones son prácticas recomendadas: NIST SP 800-63B.

Complementariamente, implementar controles que detecten y bloqueen contraseñas conocidas por estar expuestas en brechas reduce aún más la ventana de vulnerabilidad. Servicios como Have I Been Pwned han popularizado la verificación de contraseñas contra grandes repositorios de credenciales comprometidas, y muchas soluciones comerciales incorporan esa función para prevenir que los usuarios elijan claves ya filtradas: Have I Been Pwned – Passwords.

Avanzar hacia la eliminación o restricción de protocolos antiguos —sobre todo NTLM— y habilitar medidas que integren MFA en los flujos locales (por ejemplo, Windows Hello for Business o soluciones de terceros que añaden MFA a RDP y a inicios de sesión locales) es otra pieza clave. Microsoft y otros proveedores explican cómo combinar identidad híbrida y controles en el perímetro para que los accesos remotos y administrativos también requieran verificación adicional: Acceso condicional en Azure AD.

Además, la higiene de identidades sigue siendo imprescindible: inventariar y auditar cuentas de servicio, segregar cuentas con privilegios mínimos, rotar credenciales periódicamente y retirar accesos innecesarios son prácticas que limitan la superficie de ataque. Herramientas de gestión de contraseñas y de acceso privilegiado ayudan a automatizar muchas de estas tareas y a reducir la probabilidad de que una sola cuenta comprometa todo el entorno.

Por último, la detección y respuesta rápida son no negociables. Controles de telemetría que alerten sobre movimientos laterales, usos atípicos de tickets Kerberos, extracción de hashes en memoria o accesos a recursos compartidos desde hosts inusuales aumentan la probabilidad de interrumpir una intrusión antes de que explote cuentas en múltiples sistemas. Complementar políticas preventivas con tecnologías de protección de endpoints y monitoreo del comportamiento puede marcar la diferencia entre un incidente aislado y una brecha extendida.

Existen soluciones comerciales que se centran precisamente en extender MFA y controles de contraseña al mundo Windows tradicional, así como en bloquear contraseñas filtradas y fortalecer las políticas de contraseña en Active Directory. Si se evalúan productos, conviene compararlos con la documentación técnica y las guías de buenas prácticas citadas aquí para entender cómo encajan en la estrategia global de identidad y acceso. Entre los enfoques recomendados están la integración de MFA en inicios de sesión locales, la eliminación de NTLM cuando sea posible, la rotación automática de contraseñas locales y la monitorización continua de anomalías en los flujos de autenticación.

En resumen, adoptar MFA es un avance imprescindible, pero no basta por sí mismo. Hay que identificar y proteger los caminos de autenticación que quedan fuera del alcance del IdP, modernizar protocolos, gestionar con rigor cuentas privilegiadas y dotar al equipo de seguridad de detección y remediación efectivas. Solo así se reduce de forma sostenida el riesgo derivado de credenciales comprometidas en entornos Windows.

Fuentes y lecturas recomendadas: documentación de Microsoft sobre Kerberos y NTLM (Kerberos, NTLM), guías de acceso condicional en Azure AD (Conditional Access), NIST SP 800-63B sobre autenticación (NIST SP 800-63B), repositorios de contraseñas filtradas como Have I Been Pwned y el catálogo MITRE ATT&CK para técnicas de abuso de credenciales y movimiento lateral (MITRE ATT&CK).