La semana pasada, el grupo de ransomware BlackCat (también conocido como ALPHV) atacó las operaciones de MGM Resorts y los obligó a cerrar sus sistemas de TI. Lo que distingue a este ataque de los ataques de ransomware más tradicionales es que, en cierto punto, los atacantes pudieron aprovechar el dominio de su dominio en el entorno local para comprometer la nube. infraestructura de identidad, recopilando contraseñas de texto sin cifrar de los usuarios de Okta.
El ataque se suma ahora a otros, incluso contra Okta, Uber y Cisco – al marcar un nuevo patrón que explota la interconectividad de los entornos local y SaaS para comprometer el SaaS a través del local. Esto introduce un riesgo significativo para todas las organizaciones actuales que tienen un entorno híbrido (es decir, que emplean un directorio tanto local como en la nube) y enfatiza la necesidad de un directorio unificado. Protección de la identidad enfoque.
MGM Breach: Recorriendo las etapas del ataque
A partir de datos disponibles públicamente podemos construir el siguiente flujo:
- Los atacantes obtuvieron información en LinkedIn sobre un empleado, llamaron al servicio de asistencia técnica y utilizaron ingeniería social para obtener acceso a la red.
- A continuación realizaron movimiento lateral hasta que obtuvieron acceso a un controlador de dominio (los detalles sobre las técnicas exactas utilizadas en esta etapa aún no están claros) y robaron las contraseñas de usuario almacenadas allí.
- En ese momento, los atacantes pidieron el rescate y, cuando se lo negaron, instalaron posteriormente ransomware en los servidores ESXi de MGM, luego persistieron en su movimiento lateral hasta obtener acceso al servidor Okta.
- Una vez allí, los atacantes extrajeron contraseñas en texto sin formato de los servidores que luego les dieron la posibilidad de iniciar sesión. Okta y acceder a cualquiera de las aplicaciones SaaS que administra.
Dominio de dominio local utilizado como trampolín hacia el entorno SaaS
Lo interesante de este ataque es que, si bien los piratas informáticos tenían acceso a Active Directory (AD), no tenían acceso a las contraseñas. Los atacantes utilizaron AD para pasar a Okta y lograron robar contraseñas en texto plano. Esencialmente, Active Directory sirvió como puerta de entrada a Okta. Esto resalta la necesidad de que las organizaciones identifiquen y aborden cualquier debilidad y configuración incorrecta en su infraestructura de identidad. Muchas organizaciones se conectan Active Directory a Okta, pero a menudo pasan por alto asegurar esta conexión, lo que en este caso brindó a los atacantes la oportunidad de explotar la debilidad.
La brecha crítica de la infraestructura de identidad híbrida: conectada pero no protegida
Esta brecha resalta una debilidad inherente que comúnmente se ignora: la naturaleza fragmentada y aislada de la infraestructura de identidad en el entorno híbrido. Profundicemos ahora en esto con más detalle.
La mayoría de las organizaciones administran sus usuarios locales en Active Directory. Paralelamente, administran los mismos usuarios en un directorio en la nube de un servidor de federación (por ejemplo, Entra ID, Okta, Ping, etc.). Para permitir que los usuarios tengan una experiencia de inicio de sesión perfecta, estos dos proveedores de identidad diferentes están sincronizados, lo que significa que se utiliza la misma combinación de nombre de usuario y contraseña para acceder a los recursos locales y SaaS. Además, el directorio utilizado para las aplicaciones SaaS a menudo tiene cierta huella en el entorno local (por ejemplo, el servidor Okta en el caso de esta infracción).
Esta conexión implica que si un atacante ha logrado usuario comprometido credenciales en el entorno local, luego pueden usarlas para iniciar sesión directamente en aplicaciones SaaS, así como moverse lateralmente y comprometer los componentes de la infraestructura de identidad de la nube en el entorno local.
La exposición del sistema local a amenazas de identidad lo convierte en el vector de ataque definitivo para comprometer SaaS
El reciente libro blanco publicado por Investigación de Osterman, "El estado de la superficie de ataque a la identidad: información sobre las brechas críticas de seguridad" muestra claramente que el entorno local es críticamente vulnerable al uso de credenciales comprometidas para acceso malicioso.
Como detalla el informe, tradicional autenticación de múltiples factores (MFA) y las soluciones de gestión de acceso privilegiado (PAM) no proporcionan suficiente protección en tiempo real contra amenazas de identidad para la gran mayoría de las organizaciones.
Los actores de amenazas son dolorosamente conscientes de estos puntos ciegos y los aprovechan para realizar movimientos laterales dentro del entorno local, encontrando poca o ninguna resistencia. Y el movimiento lateral es el factor X que convierte un evento local (como una sola máquina comprometida) en un incidente a nivel empresarial, como lo ilustra la violación de MGM.
Conclusión: La protección de la identidad local es igual a la protección de la identidad en la nube
Cualquier cadena es tan fuerte como su eslabón más débil. Y el entorno híbrido es una cadena en la que lo local y la nube están estrechamente entrelazados. Por lo tanto, fortalecer el entorno local significa fortalecer toda la cadena. Independientemente de lo lejos que haya llegado en su migración a la nube, si todavía tiene una parte local, esta es una exposición grave que debe abordar.
Pero, ¿cómo pueden exactamente las organizaciones abordar esta brecha? Al fin y al cabo, incluso antes de que existiera la nube, no existía ninguna solución de seguridad que pudiera mitigar el riesgo de movimiento lateral y prevenirlo en tiempo real.
Silverfort Plataforma unificada de protección de identidad: bloqueo del movimiento lateral en tiempo real
Silverfort ha sido pionero en la primera Protección de identidad unificada plataforma diseñada específicamente para prevenir amenazas a la identidad en tiempo real en cualquier usuario, sistema y entorno. Silverfort se integra con la infraestructura de identidad local y en la nube para proporcionar monitoreo continuo, análisis de riesgos y controles como MFA o bloqueo de acceso en cada autenticación e intento de acceso.
De esta manera, Silverfort puede brindar protección de identidad a recursos que nunca antes podrían haberse protegido. Un ejemplo es el acceso a estaciones de trabajo y servidores a través de la línea de comandos mediante herramientas como PsExec o PowerShell remoto. Este tipo de acceso es la forma predeterminada en que los atacantes realizan movimientos laterales y está fuera del alcance de las soluciones MFA tradicionales. Silverfort es la primera solución capaz de requiere MFA para detectar y bloquear accesos maliciosos de este tipo.
Cómo Silverfort Podría haber evitado un escenario de ataque similar al de MGM
Como se indicó anteriormente, no está claro exactamente cómo los atacantes realizaron el ataque de movimiento lateral en la red. Pero es probable que Silverfort podría haber evitado esta infracción de dos maneras:
- Silverfort probablemente habría detectado el movimiento lateral hacia Active Directory, deteniendo a los atacantes antes de que pudieran comprometerlo.
- Alternativamente, Silverfort probablemente habría detectado que los atacantes se movían de AD a Okta, evitando así el compromiso del servidor Okta.
El siguiente diagrama ilustra cómo SilverfortLa protección habría detenido el ataque en sus primeras etapas:
¿Su organización tiene un entorno híbrido? Descubra más sobre cómo Silverfort puede ayudar a reducir su riesgo. Programar una llamada con uno de nuestros expertos.