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
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.
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. |
|
Uso de sistema multifactor que genera cookie atacable |
Usar sistemas
multi factor que no generen cookie:
|
[1]Reglas condicionales efectivas
|
Método |
Protección |
|
|
|
|
|
|
|
|
Saludos
No hay comentarios:
Publicar un comentario