Defensa contra ataques en Azure AD: Adiós firewall, hola protección de identidad
No hace mucho tiempo, proteger el acceso a la red era la principal línea de defensa de los equipos de seguridad. Los potentes cortafuegos aseguraron que los atacantes externos fueran bloqueados, mientras que el interior podría ensuciarse, lo que dejaba a los usuarios con bastante libertad. Estos cortafuegos eran la última defensa: no se permitía el acceso a nadie que no fuera deseado.
Hasta que lo hicieron. Con la llegada de la computación en la nube, el borde de una red ya no está protegido por un firewall. De hecho, la red ya no tiene una ventaja: en nuestro entorno de trabajo desde cualquier lugar, donde cada centro de datos ahora es un límite, ya no podemos confiar en los mecanismos de protección tradicionales. La seguridad se trata más de proteger la identidad que la propia red.
Microsoft discutió varias de las tendencias en la protección de la seguridad de la identidad de Azure Active Directory (Azure AD) en una entrada de blog reciente que muchas secuencias de ataque ahora comienzan con el individuo para hacerse un hueco en la organización y luego lanzar ransomware u otros ataques. (Para obtener más información sobre las tendencias de autenticación clave, consulte los videos en la autenticacióncon Sitio web.)
Las contraseñas siguen siendo el talón de Aquiles de la seguridad
Como señala el vicepresidente de seguridad de identidad de Microsoft, Alex Weinert, en el blog mencionado anteriormente, las contraseñas siguen siendo el talón de Aquiles de la seguridad, con tres tipos principales de secuencias de ataque en juego:
- Spray de contraseñas: adivine contraseñas compartidas contra muchas cuentas.
- Phishing: engañar a alguien para que ingrese sus credenciales en un sitio web falso o en respuesta a un mensaje de texto o correo electrónico.
- Reintento de incumplimiento: confíe en la reutilización de contraseñas ubicuas para tomar contraseñas comprometidas en un sitio web y probarlas contra otros.
Los atacantes solían apuntar a las vulnerabilidades en una red, pero ahora apuntan a las vulnerabilidades de autenticación y protección. Reutilizamos las contraseñas con demasiada frecuencia, y los atacantes lo saben, por lo que toman una contraseña de una base de datos previamente pirateada e intentan usarla en otro lugar. Si bien la mayoría de los ataques de contraseña se dirigen a cuentas sin autenticación multifactor (MFA), los ataques más sofisticados se dirigen a MFA. Los atacantes persiguen lo siguiente:
- SIM jacking y otras vulnerabilidades en telefonía.
- Martillo MFA o ataques de duelo.
- Ataques de adversario en el medio que engañan a los usuarios para que realicen una interacción MFA.
Microsoft: aléjese de MFA, proteja las contraseñas
Para defenderse de estos tres ataques, Microsoft recomienda alejarse de MFA y proteger mejor las contraseñas. agresor Sé que fallamos con demasiada frecuencia. debido a la fatiga de autenticación y puede ser engañado para ingresar contraseñas en sitios web que imitan nuestras plataformas de autenticación normales. La fatiga de la contraseña es una de las razones por las que Microsoft está cambiando la configuración predeterminada de su aplicación de autenticación para que coincida con un número en lugar de solo un «pop» de autenticación que debe aprobar.
Se encontró un excelente recurso que analiza los diferentes tipos de ataques en una último blog junto con técnicas de saneamiento. Como señala Microsoft, uno de los ataques, pass-the-cookie, es similar a los ataques pass-the-hash o pass-the-ticket en Azure AD. Después de autenticarse en Azure AD a través de un navegador, se crea y almacena una cookie para esa sesión. Si un atacante puede comprometer un dispositivo y extraer las cookies del navegador, puede enviar esa cookie a un navegador web separado en un sistema diferente, eludiendo los controles de seguridad. Los usuarios que acceden a los recursos corporativos con dispositivos personales están particularmente en riesgo porque a menudo tienen controles de seguridad más débiles que los dispositivos administrados por la empresa, y el personal de TI no puede ver esos dispositivos para determinar si están comprometidos.
Compruebe quién puede acceder a sus sistemas
Al redactar una revisión de protección de MFA, es importante considerar quién tiene acceso a qué sistemas y realizar revisiones jerárquicas de sus cuentas. Primero, revise a sus usuarios y segméntelos según el riesgo y a qué tienen acceso. Los atacantes a menudo se dirigen a un usuario específico o a alguien en su espacio de trabajo. Por ejemplo, LinkedIn se usa a menudo para identificar las conexiones entre los empleados de una empresa, por lo que debe conocer estas relaciones e identificar los recursos adecuados para proteger a las personas importantes.
Las organizaciones generalmente implementan computadoras para satisfacer las necesidades de un trabajo, no en función de los riesgos asociados con un rol, y asignan estaciones de trabajo según el presupuesto. Pero, ¿qué sucede si debe regresar y escanear su red en función de cómo la ve un atacante? Como sabe, Windows 11 ahora exige hardware adicional para proteger mejor los inicios de sesión basados en la nube. El módulo de plataforma segura se usa para proteger y asegurar mejor las credenciales que se usan en una máquina. Sin embargo, si no implementó hardware compatible con Windows 11 o, lo que es más importante, no se aseguró de tener la licencia adecuada para aprovechar Windows 11 para estas funciones clave, es posible que no esté protegiendo su red de manera adecuada.
Cómo defender Azure AD de los ataques
La protección de su red de los ataques al estilo de Azure AD comienza con asegurarse de haber configurado los ajustes de forma adecuada. Mientras que los autores de un ultima publicación Para hacer una larga lista de configuraciones, comenzaré con una con la que muchos de nosotros hemos luchado durante mucho tiempo: dejar de implementar estaciones de trabajo con privilegios de administrador local. Con demasiada frecuencia, comenzamos asignando nuestras compilaciones a una estación de trabajo de administración local y luego (con suerte) usamos el kit de herramientas de contraseña de administrador local para asignar una contraseña aleatoria a cada administrador local. Deberíamos considerar no asignar ningún administrador local, sino unirnos directamente a Azure AD.
Como señalan los investigadores Sami Lamppu y Thomas Naunheim, la mayoría de los ataques conocidos comienzan cuando la estación de trabajo tiene acceso de administrador local. La conclusión es que debe revisar y analizar continuamente los pasos adicionales que necesita tomar para proteger la identidad, ya que este es el nuevo punto de entrada a nuestras redes modernas.
Aquí hay algunos remedios recomendados por los autores del blog:
- Cree reglas de reducción de superficie de ataque (ASR) en Microsoft Intune para proteger el proceso LSAAS.
- Implemente Microsoft Defender para Endpoint para recibir alertas automáticas cuando se detecten actividades o herramientas sospechosas.
- Habilite la Protección contra manipulaciones para proteger la configuración de seguridad de su cliente (por ejemplo, Protección contra amenazas y AV en tiempo real). Impedir que los usuarios realicen acciones como Por ejemplo, deshabilitar la protección contra virus y amenazas, la protección en la nube o las acciones automáticas contra las amenazas detectadas. desactivar la supervisión del comportamiento; o eliminar las actualizaciones de inteligencia de seguridad.
- Cree una política de cumplimiento de dispositivos para requerir Microsoft Defender Antimalware y Defender Realtime Protection y aplique la verificación de cumplimiento de inmediato.
- Requerir una evaluación mínima del riesgo de la máquina en la política de cumplimiento del equipo sin largos períodos de gracia.
- Utilice un atributo único en el objeto de dispositivo que se actualiza cada vez que se registra o cancela el registro de un punto final. Esto se puede usar como un filtro de grupo dinámico para crear una asignación de política de cumplimiento de dispositivos para requerir una evaluación de riesgos de la computadora. De lo contrario, el cumplimiento del dispositivo fallará.
- Consideración en escenarios de dispositivos de acceso privilegiado, como B. Estación de trabajo de administración segura (SAW) o estación de trabajo de acceso privilegiado (PAW): requiere que el dispositivo esté bajo una clasificación de riesgo de máquina «clara». Cuando los cambios de la política de cumplimiento se aplican de inmediato, los cambios entran en vigencia en un período de tiempo de 5 minutos (según nuestras pruebas).
- Supervise activamente sus terminales para detectar herramientas maliciosas de robo de credenciales (como Mimikatz y AADInternals).
- Ejecute un libro de jugadas de Microsoft Sentinel para «poner en cuarentena» el dispositivo cuando se detecte actividad sospechosa.
Se puede recibir una lista de los usuarios que iniciaron sesión en el dispositivo afectado mediante llamadas a la API de Microsoft 365 Defender. Esto debe ejecutarse como parte de un libro de jugadas de Microsoft Sentinel para iniciar acciones SOAR cuando se detectan herramientas de robo de identidad no autorizadas en el punto final.
Derechos de autor © 2023 IDG Communications, Inc.
Hemos recibido este contenido de ciberseguridad de: CSO Online
Encontrarás la noticia original en el siguiente enlace: https://www.csoonline.com/article/3688108/defending-against-attacks-on-azure-ad-goodbye-firewall-hello-identity-protection.html#tk.rss_news
