jueves, 25 de agosto de 2022

Uso de AAInternals para ataques a O365: Device Code Auth.

 Estimados Amigos de Inseguros !!!

En el post de hoy vamos a usar una de las herramientas más usadas para auditar los sistemas O365 y Azure de la mano del @drazuread. Me refiero a AAD Internals.

La herramienta es un completo set de procesos, enumerados en su web. En esta ocasión nos vamos a centrar en una técnica de phishing basada en una funcionalidad denominada Device Code Auth.

La función nativa de Azure Ad lo que hace es que genera un token de acceso (Refresh Token) válido para dispositivos que a priori no son susceptibles de pedir autenticación cada vez que se usan. Me explico, Outlook? una televisión? un dispositivo IoT? 

El proceso es sencillo.

Abres tu aplicación, conectas con el AAD, le pide verificación, el usuario autentica y se crea el access token para el que el dispositivo pueda funcionar. Digamos que se usa una autenticación impersonada en el dispositivo.

La herramienta nos permite realizar todo el ciclo, desde el envío de correo hasta la explotación. Pero como siempre, vamos a verlo.

Los pasos para su instalación son tan sencillos como install-module AADInternals y luego un import-module AADInternals.

Ejecutamos las opción indicada.


Como puedes ver, estamos enviando a una VICTIMA un mail desde un ATACANTE.

*en mi caso he usado como atacante un hotmail, que requiere autenticación. El script por defecto o las instrucciones que nos muestra el autor son usando un servidor SMTL local, que no es mi caso. Necesito autenticación, decirle el puerto, etc...

He tenido que modificar el script original y añadir algunos parámetros así a fuego para que permita realizar el proceso con un SMTP autenticado.

Se ha notificado al autor y no se si lo cambiará en futuras releases.

El cambio ha sido este:

*

Una vez lanzado el comando, se envía el mail a la víctima. Con un formato que por supuesto podemos cambiar, es más, ya he visto plantillas por ahí :-)



Si entramos al link e introducimos el código ( paso 4 del esquema) estaremos autorizando el uso del dispositivo. Si no estamos autenticados, nos pedirá como siempre login.

Aquí es donde tenemos la detección, el login, la ubicación del login, es la del atacante. Si la víctima no suele usar esa localización, es por donde podría cantar. Es más, la única manera de parar este ataque, es usar el Acceso Condicional, para controlar desde donde se pueden conectar nuestros clientes.

También tienes que tener en cuenta que el Device Auth Code vive 15 minutos, por lo que la víctima del pishing debe caer pronto.



Y con esto tenemos el token de acceso "secuestrado".


Ahora vamos a hacer uso de él no? ya sabes que esto no significa tener las claves, sino el acceso.

Vamos a enviar un mail desde la cuenta VICTIMA.



Y deberíamos poder hacer lo mismo para que le llegue un Teams. En mi caso no he podido probarlo por mi configuración de O365 y no tengo todo el nivel de acceso que necesito para hacer unos cambios, pero el comando es así.


Como puedes ver, es una ataque muy interesante, y la herramienta es un "siguiente,siguiente,siguiente".

Los usuarios están acostumbrados ya al MFA y que les pidan "códigos" por lo que un phishing que le pide un code que va en el mail... no es muy complejo que se lo traguen :-)

Toda la autenticación y la entrada del CODE es desde el dominio legítimo de Microsoft, no hay que registrar dominios, ni hacer webs ni nada.

Aparte de la concienciación al usuario, debemos tener políticas que sean capaces de bloquear estas acciones. Por ejemplo, con acceso condicional, podríamos ver que la petición de LOGIN viene de PAISES BAJOS ( en la imagen) que es la IP del atacante.

Si usamos servicios de control de dispositivos, controlar que no se lanza desde un dispositivo conocido.

Una buena solución de proteccíon de correo que nos ayude con el phishing...

Al final, son ataques de capa de usuario que si, que tenemos maneras técnicas de solucionarlo, pero el factor humano es MUY importante.

En este caso un MFA de otro fabricante no funcionaría, ya que el cliente por un lado se autentica con su sistema, por ejemplo OKTA, para validar el code que a su vez, valida al dispositivo del atacante

Como siempre, espero que os guste, que os sirva y gracias por leerme !!!

Y debo añadír, que mi propósito es ayudar, ayudar a los departamentos IT y CIberseguridad a entrenar a su personal. Esta herramienta se puede usar para atacar, o para auditar y concienciar, formar, no es mi propósito alentar a nadie a cometer ilegalidades. 

Y aunque parezca mentira, debo decirlo.

Estas técnicas o debilidades son conocidas por los malos, y la seguridad por obscuridad de los 90 no funcionan. 


Y si te gusta este contenido, te animo a que te registre para estar al día de nuevos post, cursos, webinars, eventos etc.