La autenticación multifactor (MFA) se ha convertido hace mucho tiempo en una práctica de seguridad estándar. Con un amplio consenso sobre su capacidad para defenderse de más del 99 % de los ataques de apropiación de cuentas, no es de extrañar que los arquitectos de seguridad lo consideren imprescindible en sus entornos. Sin embargo, lo que parece menos conocido son las limitaciones de cobertura inherentes a las soluciones MFA tradicionales. Si bien es compatible con la conexión RDP y los inicios de sesión de escritorio locales, no ofrecen protección a las herramientas de acceso remoto a la línea de comandos como PsExec, Remote PowerShell y similares.
En la práctica, significa que las estaciones de trabajo y los servidores siguen siendo vulnerables al movimiento lateral, la propagación del ransomware y otras amenazas de identidad a pesar de tener una solución MFA en pleno funcionamiento. Para el adversario, solo es cuestión de tomar la ruta de la línea de comando en lugar del RDP para iniciar sesión como si no hubiera ninguna protección instalada. En este artículo, exploraremos este punto ciego, comprenderemos su causa raíz y sus implicaciones, y veremos las diferentes opciones que los equipos de seguridad pueden superar para mantener sus entornos protegidos.
El propósito principal de MFA: evitar que los adversarios accedan a sus recursos con credenciales comprometidas
MFA, la medida de seguridad más eficiente contra la apropiación de cuentas. La razón por la que tenemos MFA en primer lugar es para evitar que los adversarios accedan a nuestros recursos con credenciales comprometidas. Entonces, incluso si un atacante pudiera apoderarse de nuestro nombre de usuario y contraseña, que es un escenario más que plausible, aún no podrá aprovecharlos para el acceso malicioso en nuestro nombre. Por lo tanto, es la última línea de defensa definitiva contra el compromiso de credenciales, que tiene como objetivo anular este compromiso de cualquier ganancia.
El punto ciego: MFA no es compatible con las herramientas de acceso a la línea de comandos en el entorno de Active Directory
Si bien MFA puede cubrir completamente el acceso a SaaS y aplicaciones web, es significativamente más limitado cuando se trata del entorno administrado de Active Directory. Esto se debe a que los protocolos de autenticación clave que se utilizan en este entorno, NTLM y Kerberos, se escribieron mucho antes de que existiera MFA y no lo admiten de forma nativa. Lo que significa es que todos los métodos de autenticación que implementan estos protocolos no se pueden proteger con MFA. Eso incluye todas las herramientas de acceso remoto basadas en CMD y PowerShell, de las cuales las más destacadas son PsExec y Remote PowerShell. Estas son las herramientas predeterminadas que usan los administradores para conectarse de forma remota a las máquinas de los usuarios con fines de resolución de problemas y mantenimiento y, por lo tanto, se encuentran prácticamente en cualquier entorno de AD.
Las implicaciones de seguridad cibernética: el movimiento lateral y los ataques de ransomware no encuentran resistencia.
Esta ruta de conexión remota principal está, por definición, desprotegida de un escenario de credenciales comprometidas y, como resultado, se usa en la mayoría de los ataques de propagación de ransomware y movimiento lateral. No importa que haya una solución MFA que proteja la conexión RDP y evite que se abuse de ella. Para un atacante, pasar de la máquina del paciente cero a otras estaciones de trabajo en el entorno con PsExec o Remote PowerShell es tan fácil como hacerlo con RDP. Es solo cuestión de usar una puerta en lugar de la otra.
¿Estás tan protegido como deberías estarlo? Tal vez sea hora de que vuelva a evaluar su MFA. Como seguimiento, explore este libro electrónico para aprender Obtenga más información sobre el enfoque de protección de identidad unificada de Silverfort para MFA y obtenga información sobre cómo evaluar sus protecciones existentes y la exposición al riesgo relativo.
La dura verdad: la protección parcial de MFA es ninguna protección en absoluto
Por lo tanto, si ha pasado por el dolor de instalar agentes MFA en todos sus servidores y estaciones de trabajo críticos, lo más probable es que haya logrado poco para protegerlos de las amenazas de identidad. Este es uno de los casos en los que no puedes ir a la mitad. O estás protegido o no lo estás. Cuando hay un agujero en el fondo del bote, poco importa que todo el resto sea de madera maciza. Y de la misma manera, si los atacantes pueden moverse lateralmente en su entorno proporcionando credenciales comprometidas a las herramientas de acceso a la línea de comandos, ya no importa que tenga protección MFA para RDP e inicio de sesión de escritorio.
Las limitaciones de MFA en el entorno local también ponen en riesgo los recursos de la nube
A pesar del cambio a la nube, más del 90 % de las organizaciones mantienen una infraestructura de identidad híbrida con estaciones de trabajo y servidores administrados por AD, así como aplicaciones SaaS y cargas de trabajo en la nube. Por lo tanto, no solo los recursos locales centrales, como las aplicaciones heredadas y los recursos compartidos de archivos, están expuestos al uso de credenciales comprometidas debido a la falta de protección MFA, sino también las aplicaciones SaaS.
La práctica común hoy en día es sincronizar contraseñas entre todos estos recursos, por lo que se usa el mismo nombre de usuario y contraseña para acceder tanto a un servidor de archivos local como a una aplicación SaaS organizacional. Esto significa que cualquier ataque local que incluya el compromiso y el uso de las credenciales de los usuarios puede cambiar fácilmente para acceder a los recursos de SaaS directamente desde las máquinas atacadas.
El cambio de paradigma: de la MFA tradicional a la protección de identidad unificada
La brecha que hemos descrito se deriva de cómo se diseña e implementa la MFA tradicional. La limitación clave es que las soluciones MFA de hoy se conectan al proceso de autenticación de cada recurso individual, por lo que si el software que realiza esta autenticación no es compatible con MFA, como en las herramientas de acceso a la línea de comandos de AD, no puede haber protección en blanco.
Sin embargo, hoy existe un nuevo enfoque que cambia el enfoque de colocar MFA en cada recurso individual al directorio, superando así la barrera por completo.
Silverfort es pionera en la primera plataforma de Protección de Identidad Unificada que puede extender MFA a cualquier recurso, independientemente de si admite MFA de forma nativa o no. Utilizando una tecnología sin agente y sin proxy, Silverfort se integra directamente con AD. Con esta integración, cada vez que AD recibe una solicitud de acceso, espera su veredicto y lo reenvía a Silverfort. Luego, Silverfort analiza la solicitud de acceso y, si es necesario, desafía al usuario con MFA. Según la respuesta del usuario, Silverfort determina si confiar o no en el usuario y pasa el veredicto a AD que concede o deniega el acceso, respectivamente.
La innovación en este enfoque es que ya no importa si esta solicitud de acceso se realizó a través de RDP o línea de comando y si es compatible con MFA o no. Siempre que se haya hecho a AD, AD puede pasárselo a Silverfort. Por lo tanto, al pasar de la protección MFA a nivel de recursos a la protección MFA a nivel de directorio, el punto ciego del que abusan los adversarios durante años finalmente se resuelve y protege.
¿Desea obtener más información sobre cómo aplicar MFA a todos sus recursos? Visitanos en https://www.silverfort.com/