Hacking Office 365: Usas MFA? Herramientas de ataque y consejos de remediación

 Estimados amigos de Inseguros !!!

En el post de hoy os voy a mostrar una herramienta muy sencilla que viene siendo usada por malos y buenos desde hace mucho tiempo, pero que a menudo me doy cuenta que no es todo lo conocida que debería ser, al menos por los administradores que conozco.

Se trata de Evilgnix2. Una herramienta diseñada para realizar campañas de phishing, con sus plantillas y sus cosas, pero que incorpora la facilidad de hacer de proxy o de mitm, como quieras llamarlo, de nuestras peticiones falsas, contra las reales, y así es capaz de interceptar no solo los usuarios y contraseñas, sino los token del mfa.

Con esta imagen lo entenderás mejor.

Tiene varios "modulos" preparados como Twitter, Linkedin, pero podemos realizar nuestras modificaciones para cambiarlos y adaptarlos para "pescar" nuestros proveedores favoritos.

Lo primero que hacemos es intarlar golang en nuestro linux, y a continuación git y make.

Bajamos el repositorio, entramos en el directorio y ejecutamos make para compilar el proyecto.

Podemos usar la versión dockerizada, esto ya al gusto del consumidor.

Para realizar esta prueba de concepto, vamos a usar las plantillas que vienen por defecto, en concreto en esta ocasión la de O365 para seguir con el propósito del post.

Para poder hacer el ataque tenemos que contar con un nombre de dominio que será el usado en la suplantación, y que apuntará a nuestro servidor de phishing publicado en internet.sudo ./bin/evilginx -p ./phishlets/

Hacemos un config domain nombre_dominio y config ip la_ip . Para evitar tráfico de bots le indicamos al sistema que haga una bloqueo a los visitantes que no hagan autenticación, que no entren credenciales, lo hacemos con blacklist unauth.

Creamos lo que sería la "campaña" y la activamos, con la ejecución de phishlets hostname 0365 midominio y phishlets enable o365. 

En este momento podemos usar un certificado instalado y ubicado en la ruta que indica, o dejar que la herramienta haga una solicitud a let´s encrypt ella solita :-) interesante. 

Te recomiendo que si has creado el dominio recientemente, dejes que es "propague" por todos los servidores DNS, porque si intentas hacer el certificado, y aún no está publicado el registro DNS, Letsencrypt te va a banear un rato si lo intentas más de 5 veces en una hora. Mejor tener paciencia y crear el DNS un rato antes.

Si quieres pedir un certificado LetsEncrypt de manera sencilla, este post es muy útil y directo.

Una vez has creado el certificado, seguimos con el proceso. Ejecutamos lures create o365, lures edit 0 redirect_url https://portal.office.com y lures get-url 0

Ya tenemos nuestra url de phishing preparada. Vamos a empezar a hacer cosas. Como vimos en una imagen anterior, todas las peticiones que hagamos se lanzarán contra el portal real. En mi primera prueba intento meter un usuario y contraseña que no existe, y me devuelve el error, bieeeen.

Ahora metemos las credenciales de uno bueno, de un usuario sin MFA, y accedemos tanto al correo, como a la contraseña en la aplicación.

Ahora pruebo con el MFA activado, y funciona a la perfección. Fíjate como la url cuando me pide el token por SMS es la de la campaña.

Y otra vez más, dentro. En esta ocasión, tenemos el token de autenticación con el MFA "aprobado".

Como puedes ver, es muy sencillo hacer un phishing a un usuario, y por mucho que tenga doble factor de autenticación,  podemos realizar nuestras maldades.

Como puedes ver, es muy importante la parte de formación al usuario, pero lo bueno es que hay otras medidas para protegernos contra estos ataques.

Se ha creado un poco de revuelo con este post, y he decidido hacer algunas modificaciones, en primer lugar, el título.

En segundo lugar, no voy a esperar a sacar más post sobre esto contando como protegernos, ya he tenido suficiente historias con esto. Pero si, por responsabilidad, se me ocurren varias maneras.

La primera manera es usar el acceso condicional, es decir, si nunca nos logueamos desde Paises Bajos, no permitir hacerlo ( en el caso de la demo uso una ip que sale de ahí). 

Tambien podemos usar Acceso condicional para impedir que dispositivos no "managed" puedan realizar esta autenticación o con Intunes.

Puedes usar Defender para proteger las apps mediante un certificado de origen en tu cliente.

Puedes pararlo si usas un MFA de terceros o usas FIDO2 en algún hardware.

La manera más sencilla, es usar Branding en tu portal de autenticación, y educar a tus usuarios a que no "todo es Azure" y que puede parecer un portal de Login, pero si no tiene el branding, no funciona...

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