Durante la última DefCon que acaba de terminar, CON por excelencia que habitualmente se celebrada en Las Vegas, y que este año ha tenido que ser en modo remoto por culpa de esta pandemia que nos debe una visita a esa ciudad, presentamos la herramienta O365 Squatting, como parte del programa de la Blue Team Village, así que hoy vamos a hablaros de ella.
Sus autores somos J. Francisco Bolivar, CSE de ElevenPaths y autor del libro de 0xWord de "Infraestructuras Críticas y Sistemas Industriales: Auditorías de Seguridad y Fortificación" y Jose Miguel Gómez-Casero, y los dos trabajamos defendiendo a una multinacional del sector farmacéutico haciendo tareas de Blue Team.
 |
| Figura 1: O365 Squatting en el Blue Team Village de la DefCon 28 SafeMode: Detectar ataques de phishing desde la cloud de Microsoft Azure |
Sus autores somos J. Francisco Bolivar, CSE de ElevenPaths y autor del libro de 0xWord de "Infraestructuras Críticas y Sistemas Industriales: Auditorías de Seguridad y Fortificación" y Jose Miguel Gómez-Casero, y los dos trabajamos defendiendo a una multinacional del sector farmacéutico haciendo tareas de Blue Team.
 |
| Figura 2: Libro de "Infraestructuras Críticas y Sistemas Industriales: Auditorías de Seguridad y Fortificación" en 0xWord |
El día a día del Blue Team en una empresa pasa por gestionar todo tipo de alertas en los sistemas, nuevas amenazas que aparecen en la red, gestión de bloqueo, y como no, proteger uno de los pilares de entrada de problemas en toda organización, los ataques de Phishing y Spear Phishing. Estos, como es lógico, no paran de evolucionar y aparecen nuevos métodos continuamente que les permitan saltarse la primera barrera de protección, el perímetro. Al igual que las organizaciones legales, las organizaciones cibercriminales hacen uso de todo tipo de avance en tecnología para conseguir sus metas.
Figura 3: Ataques Sappo para robar tokens OAuth en Office 365
Por descontado, la nube se lleva la palma, dando un giro completo no solo a la seguridad y las capacidades que nos ofrece si no al tipo de ataques, como se demostró con Sappo y los ataques de para robar Tokens Oauth o el peligroso RansomCloud O365.
La causa raíz que nos hizo plantearnos la necesidad de hacer una herramienta nueva fue ver que nuestros empleados habían comenzado a recibir mensajes de Phishing mediante correo electrónico y que se habían saltado - una vez más - todas las protecciones del servicio de correo electrónico, es decir, SPF, DKIM, DMARC, filtro antispam, etcétera. Estos sistemas paran muchos de estos ataques, sin embargo, nos encontramos con un caso peculiar. Nos dimos cuenta de que empezábamos a recibir e-mails de onmicrosoft.com.
Como es habitual con este tipo de intentos una vez se detecta, se bloquea el dominio, pero en este caso no era posible bloquear *.onmicrosoft.com ya que es el dominio inicial con el que crean un Tenant de Office 365. Supongamos que mi dominio es jfranbolivar.com, Cuando configure mi Tenant de Office 365 tendré un dominio inicial llamado jfranbolivar.onmicrosoft.com. Por lo tanto, al ser onmicrosoft.com no era posible bloquearlo ya que provocaría que se bloquearan todos los mensajes de e-mail, incluso los legítimos.
El atacante estaba usando un servidor en su Tenant de Microsoft Azure para enviar los mensajes de Phishing, lo que hacía que fuera más complicado pararlo. Como se puede ver, las cabeceras del correo electrónico solo informaban que el mail provenía de direcciones IP de Microsoft. Así que tampoco por reputación de la dirección IP era posible bloquearlo
La configuración del registro SPF estaba a none, lo que tampoco ayuda mucho, ya que para el uso que Microsoft da al dominio onmicrosoft.com es difícil afinar más la configuración de los registros para los servidores de correo saliente. Por lo tanto, era necesario bloquear el dominio exacto, lo que no era factible hasta que se detectara el ataque.
Figura 3: Ataques Sappo para robar tokens OAuth en Office 365
Por descontado, la nube se lleva la palma, dando un giro completo no solo a la seguridad y las capacidades que nos ofrece si no al tipo de ataques, como se demostró con Sappo y los ataques de para robar Tokens Oauth o el peligroso RansomCloud O365.
La causa raíz que nos hizo plantearnos la necesidad de hacer una herramienta nueva fue ver que nuestros empleados habían comenzado a recibir mensajes de Phishing mediante correo electrónico y que se habían saltado - una vez más - todas las protecciones del servicio de correo electrónico, es decir, SPF, DKIM, DMARC, filtro antispam, etcétera. Estos sistemas paran muchos de estos ataques, sin embargo, nos encontramos con un caso peculiar. Nos dimos cuenta de que empezábamos a recibir e-mails de onmicrosoft.com.
 |
| Figura 4: Mensajes de phishing desde onmicrosoft.com |
Como es habitual con este tipo de intentos una vez se detecta, se bloquea el dominio, pero en este caso no era posible bloquear *.onmicrosoft.com ya que es el dominio inicial con el que crean un Tenant de Office 365. Supongamos que mi dominio es jfranbolivar.com, Cuando configure mi Tenant de Office 365 tendré un dominio inicial llamado jfranbolivar.onmicrosoft.com. Por lo tanto, al ser onmicrosoft.com no era posible bloquearlo ya que provocaría que se bloquearan todos los mensajes de e-mail, incluso los legítimos.
 |
| Figura 5: Los mensajes provienen de servidores en IPs de Microsoft |
El atacante estaba usando un servidor en su Tenant de Microsoft Azure para enviar los mensajes de Phishing, lo que hacía que fuera más complicado pararlo. Como se puede ver, las cabeceras del correo electrónico solo informaban que el mail provenía de direcciones IP de Microsoft. Así que tampoco por reputación de la dirección IP era posible bloquearlo
 |
| Figura 6: Direcciones IP de Microsoft |
La configuración del registro SPF estaba a none, lo que tampoco ayuda mucho, ya que para el uso que Microsoft da al dominio onmicrosoft.com es difícil afinar más la configuración de los registros para los servidores de correo saliente. Por lo tanto, era necesario bloquear el dominio exacto, lo que no era factible hasta que se detectara el ataque.
 |
| Figura 7: Info de la validación SPF |
Además, el atacante, y con intención de engañar a los usuarios finales creaba los dominios similares al atacado, ej.: empresa.onmicrosoft.com y empres.onmicrosoft.com, aplicando técnicas clásicas de typosquatting. Con cambios muy rápidos en la creación, lo que hace que los dominios no aparezcan rápidamente en listas negras de reputación hasta que el ataque ha sido detectado, por lo que sería demasiado tarde, como se puede ver en maltiverse.com el motor abierto de indicadores el cual nos facilita la identificación de dominios maliciosos:
Por lo que la única solución que se encontró fue anticiparnos al atacante, creando un listado de dominios considerando las modificaciones empresa, empresb, empresia… sin embargo, cual fue nuestra sorpresa cuando al realizar la petición DNS, siempre nos daba el mismo resultado, ya que pertenecía a onmicrosoft.com
La detección seguía igual, hasta que descubrimos que cada vez que se crea un Tenant nuevo, onmicrosoft no es la única dirección que se asigna, sino también una xxx.sharepoint.com. Este caso era distinto, ya que en función de si el dominio existía o no, la respuesta era diferente. Es decir, te crea el de Office 365 y el de SharePoint. En caso de que el dominio existiera, (empresa.sharepoint.com) se redirige a la página de login de O365, en caso de que no exista se dirige a un error (503, Service unavailable).
Al fin habíamos encontrado un patrón que sin el uso de DNS nos permitía identificar dominios potencialmente peligrosos en Microsoft Azure. Ahora quedaba la automatización, para ello se empleó Python, la creación de la herramienta "O365 Squatting", que podéis descargar de nuestro GitHub y utilizar en vuestro entorno.
O365 Squatting puede ser configurada mediante cron para que se lance de forma periódica, y permita conocer los dominios tan pronto como se creen. Además, está preparada para integrarse con SIEM, ya que permite exportar los resultados en formato CEF y JSON. Es posible chequear un único dominio, en caso de que sea necesario para la investigación o activar el modo debug, para ver las peticiones que realiza la herramienta.
Queremos que la herramienta sirva a la mayor cantidad de Blue Teams posible, estamos seguros que, mientras leéis esto, otras organizaciones están siendo suplantadas utilizando la infraestructura de Microsoft Azure, como hacen con otras clouds.
 |
| Figura 8: Ejemplo de dominio no registrado en maltiverse.com (esta comprobación también la pueden hacer los malos) |
Por lo que la única solución que se encontró fue anticiparnos al atacante, creando un listado de dominios considerando las modificaciones empresa, empresb, empresia… sin embargo, cual fue nuestra sorpresa cuando al realizar la petición DNS, siempre nos daba el mismo resultado, ya que pertenecía a onmicrosoft.com
 |
| Figura 9: Typosquatiing y mismo DNS Record |
La detección seguía igual, hasta que descubrimos que cada vez que se crea un Tenant nuevo, onmicrosoft no es la única dirección que se asigna, sino también una xxx.sharepoint.com. Este caso era distinto, ya que en función de si el dominio existía o no, la respuesta era diferente. Es decir, te crea el de Office 365 y el de SharePoint. En caso de que el dominio existiera, (empresa.sharepoint.com) se redirige a la página de login de O365, en caso de que no exista se dirige a un error (503, Service unavailable).
 |
| Figura 10: El dominio de .sharepoint.com nos sirve de selector |
Al fin habíamos encontrado un patrón que sin el uso de DNS nos permitía identificar dominios potencialmente peligrosos en Microsoft Azure. Ahora quedaba la automatización, para ello se empleó Python, la creación de la herramienta "O365 Squatting", que podéis descargar de nuestro GitHub y utilizar en vuestro entorno.
 |
| Figura 11: O365 Squatting en GitHub |
O365 Squatting puede ser configurada mediante cron para que se lance de forma periódica, y permita conocer los dominios tan pronto como se creen. Además, está preparada para integrarse con SIEM, ya que permite exportar los resultados en formato CEF y JSON. Es posible chequear un único dominio, en caso de que sea necesario para la investigación o activar el modo debug, para ver las peticiones que realiza la herramienta.
 |
| Figura 12: O365 Squatting |
Queremos que la herramienta sirva a la mayor cantidad de Blue Teams posible, estamos seguros que, mientras leéis esto, otras organizaciones están siendo suplantadas utilizando la infraestructura de Microsoft Azure, como hacen con otras clouds.
 |
| Figura 13: Libro de Python para Pentesters |
Al margen de las mejoras que iremos dando a O365 Squatting (convertir en contenedor, comprobar reputación y/o reportar en bases de datos públicas de Abuse…) y de que tú puedes colaborar que es Open Source y está escrito en Python - el lenguaje de los pentesters -, tenemos intención de trabajar con el resto de los “grandes” del Cloud Computing (Google, Amazon, Oracle, etc..). En este vídeo tenéis un ejemplo del funcionamiento de O365 Squatting.
Figura 14: Demo de funcionamiento de O365 Squatting
Y todo esto que hemos contado en este post, lo tienes explicado en la charla que dimos en la DefCON 28 SafeMode en el Blue Team Village que está en este vídeo. Son poco menos de 20 minutos y en inglés, pero tienes la explicación completa.
Figura 15: O365 Squatting en DefCON 28 SafeMode Blue Team Village
Como conclusión final por nuestra parte, haber trabajado contra este tipo de ataques y desarrollar O365 Squatting para hacerles frente, nos hace tener presentes una vez más, que la mayor protección para las organizaciones siempre será anticiparse a los atacantes.
Autores: José Miguel Gómez-Casero y Juan Francisco Bolivar
No hay comentarios:
Publicar un comentario