domingo, 23 de octubre de 2022

Tratando de evitar ataques AITM (Adversary in the middle) a identidades cloud.

 

Dado que está resultando realmente exitoso para los atacantes. Empresas como Zscaler y el mismo Microsoft, han publicado diversos estudios y análisis sobre los ataques que se están llevando a cabo mediante AITM. Este formato consiste en situarse entre el usuario y el portal de validación para recoger una cookie de inicio de sesión que prevalece válida mientras dura la sesión del usuario validado.


Links de los estudios:

AITM Attack Targeting Microsoft Email Users | Zscaler

From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud - Microsoft Security Blog

Una vez he repasados estos estudios, destaco lo siguiente. 

Los ataques se están produciendo con aplicaciones tales como: Evilginx2 -utilizado en mi video- Muraena y Modlishka. Todos ellos funcionan siendo un proxy entre la víctima y el servicio de destino, pudiendo ser desde Spotify hasta O365, pasando por Paypal, Instagram, Twitter, etc.

Buscando soluciones a este ataque, primeramente veo que como casi todo phising, suele llegar vía correo electrónico indicando al usuario que ha de validarse en una url. Por lo que aconsejo la puesta en marcha de Safe Links en Advanced Threath Management que forma parte de la protección avanzada de Microsoft Defender.

La diferencia entre Defender y Defender en versión avanzada, es que el segundo, protege al hacer click en urls peligrosas a día del mismo click en correos pero que pasaron a la bandeja de entrada del usuario, siendo validadas por un Defender más básico y no declarar estas peligrosas, por no estar localizadas en ese momento.


También observé en el piloto que construí, que Google Chrome marcó bastante antes mi URL maliciosa -yo registré el dominio Outloook.tk- mientras que Edge tardó algo más de 24 horas en avisarme.

A día de hoy, se mantiene activa una list de dominios utilizados como urls proxy que se puede consultar aquí: https://github.com/threatlabz/iocs/blob/main/aitm_phishing/microsoft_iocs.

Dado que en los análisis hechos por Zscaler existen inicios de sesión tras 8 minutos después de robar al  usuario su información y no existen registro de acciones realizadas, como pueden ser enviar mails u otras y viendo también en mi piloto, que el software proxy me devolví la contraseña del usuario en texto plano. Me inclino a pensar que el atacante, registra un nuevo segundo factor en la configuración del usuario, para garantizarse futuros accesos con su usuario y contraseña + doble factor registrado.


Protección en Azure AD ante este ataque

Una vez el correo ha llegado al usuario y mientras nuestro sistema de detección de URLs no indique que la dirección es peligrosa, Estamos expuestos a que el usuario haga click y se valide en la ventana de login, por lo que cabe entender el funcionamiento de Azure AD en cuanto a la sesión del usuario, para protegernos ante la adquisición de la cookie.


PIM

Por supuesto, ya que nos podemos caer en la trampa y nos pueden secuestrar una credencial. Lo que es muy aconsejable es que ninguna de ellas, tenga roles privilegiados asociados. Esto lo conseguimos utilizando y activando PIM, tal y como expliqué en este Webinar.


De forma general podemos tener en cuenta lo siguiente:

Situación de riesgo

Herramienta para la remediación

 

El mail llegó al buzón del usuario y días después, habiendo sido marcado el dominio como peligroso, aun pudo hacer click visitando la web del atacante.

 

 

Activación de Advanced Threath Management para garantizar control de urls actualizado en el día del acceso.

 

La propia realización de inicio de sesión.

Acceso por parte del atacante al existir una regla de permisividad del Login, excesivamente abierta. Permitiendo acceso desde su localización, lugar y dispositivo.

 

 

Este login se ha podido realizar al cumplir reglas, las cuales por defecto son, “cualquier parte del mundo”, “cualquier lugar”, cualquier dispositivo”. [1]

 

Se aconseja la creación reglas de acceso condicionar para delimitar países, lugares específicos como la oficina y dispositivos, distinguiendo entre logins desde equipos corporativos, sincronizados con AdConnect y considerados híbridos, y los no corporativos, considerados Register en Azure AD.

 

 

Posibilidad del inicio de sesión del atacante durante el periodo de validez de la cookie.

 

La cookie es válida mientras la sesión no se revoque.

 

 

 

Requerir re autenticación cada cierto tiempo si se realiza en equipos no corporativos.

 

https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime#user-sign-in-frequency-and-multifactor-authentication

 

 

Uso de sistema multifactor que genera cookie atacable

 

Usar sistemas multi factor que no generen cookie:

  •  Fido2 Security Keys
  • Windows Hello for Business
  • Certificado

 El resto, sms, llamada y mobile app, generan cookie utilizable.

[1]Reglas condicionales efectivas

Método

Protección

  • Requerir dispositivo como “compliant”

  • Protege

  • Requerir dispositivo híbrido o unido a Azure AD

  • Protege

  • Regla condicional de control de sesión

  • Protege solo durante una ventana de tiempo

  • Regla condicional en la que permitir login solo desde sitios de confianza

  • Protege


Saludos

No hay comentarios: