Hace unos años, la arquitectura de red convencional incluía un Directorio Activo y algunos servicios importantes como: correo electrónico, aplicaciones, servicios compartidos, etc. Sin embargo, como todos estamos viendo a diario, ese modelo ya forma parte de la prehistoria informática. Ahora, lo que más nos encontramos son entornos Cloud. Ambos permiten a los usuarios acceder a los recursos corporativos desde cualquier parte del mundo y desde cualquier dispositivo, evitando la necesidad de tener que pasar por la VPN y reduciendo así los costes que conlleva mantener estos servicios. ¡Lo que tampoco viene nada mal, ¿no?!
Entre los componentes que forman parte del escenario híbrido, debemos tener en cuenta un agente conocido como ADConnect, ya que es el que permite que se sincronicen ciertos recursos locales con los servicios SaaS de Microsoft 365, como por ejemplo el correo electrónico.
Por tanto, si recapitulamos, hemos pasado de tener un servicio crítico, que era el Directorio Activo de la organización, a tres servicios críticos: Directorio Activo local u On-Premise, Directorio Activo en Azure y servicios de Microsoft 365. Sin embargo, obviamente todos estos cambios en los entornos han afectado a otros ámbitos de la ciberseguridad:
- La seguridad perimetral conocida hasta ahora se ha tenido que adaptar. La perpetua herramienta de monitorización y prevención de ataques, nuestro querido SNORT (NIDS) y la monitorización de conexiones basadas en direcciones IP, se echan a un lado para dar paso a una nueva era basada en la geolocalización y las identidades de los usuarios.
- Los atacantes se han visto obligados a cambiar las técnicas que utilizaban hasta ahora para poder enfrentarse a sus nuevos y desconocidos objetivos, y precisamente eso es lo que hemos venido a aprender aquí: una técnica de ataque basada en la cadena de suministros (Supply Chain Attack) para un entorno de Microsoft Azure.
Para ello, vamos a detallar la taxonomía del ataque, elaborada a partir de MITRE | ATT&CK, y que habrá que adaptar en función de la arquitectura de cada organización:
| ID | Táctica | Técnica |
| 1 | Reconnaissance | T1591-Gather Victim Org Information |
| 2 | Reconnaissane | T1589-Gather Victim Identity Information |
| 3 | Resource Development | T1583-Acquire Infrastructure |
| 4 | Initial Access | T1566-Phishing |
| 5 | Persistence | T1098-Account Manipulation |
| 6 | Discovery | T1087-Account Discovery |
| 7 | Lateral Movement | T1534-Internal Spearphishing |
| 8 | Privilege Escalation | T1184-Domain Policy Modification |
| 9 | Persistence | T1199-Account Manipulation |
| 10 | Exfiltration | T1048-Exfiltration Over Alternative Protocol |
1 y 2: Reconnaissance- Gather Victim Identity Information y Gather Victim Org Information
Al igual que en cualquier ataque convencional, la primera fase consiste en realizar un reconocimiento de nuestro objetivo, llamado DON TARTAS. Sin embargo, además de la información habitual (sedes, sector, personal, madurez en ciberseguridad, etc), en esta ocasión también nos hemos centrado en identificar los proveedores de DON TARTAS.
Esto se debe a que, aparte de que los entornos estén compartidos entre las organizaciones y Microsoft, hemos aprendido que en muchas ocasiones la administración del entorno de Azure se subcontrata a un proveedor externo, como puede ser un Gold Partner, y que por tanto será quien posea los usuarios con roles privilegiados.
Primero, utilizamos fuentes públicas para identificar qué servicios tiene DON TARTAS. Confirmamos así el uso de “Azure DNS” como servicio de DNS y que por tanto tienen alguna suscripción de un tenant de Microsoft Azure:
Segundo, con una pizca de Google Dorking y otra pizca de picardía, no solo hemos sido capaces de localizar al Gold Partner de DON TARTAS, llamadoDON CAFÉ, sino también al arquitecto de Azure y que muy probablemente tenga asignado un rol de administración en el entorno.
Con esta información, junto con otras herramientas y técnicas de information gathering exhaustivas, hemos sido capaces de encontrar la información suficiente del objetivo para conocerlo en profundidad y diseñar un perfil, así como obtener cuentas de correo electrónico y redes sociales, números de teléfono, y hasta… ¡SORPRESA! ¡Contraseñas en leaks! – SPOILER ALERT!: No las hemos utilizado. Más tarde entenderemos por qué.
3. Resource Development – Acquire Infrastructure
¿Os hemos contado que DON TARTAS es una multinacional? ¿No? Pues para nuestra desgracia, sí… por lo que debemos dar por hecho que tendrá mecanismos de prevención y protección de la infraestructura y que necesitaremos diseñar una arquitectura que permita evadir sus capacidades de seguridad. ¿y qué hacemos todos cuando queremos pasar desapercibidos? Camuflarnos con el entorno.
Pues con Microsoft podemos hacer lo mismo: hagamos uso de los propios servicios de Microsoft para que no sean capaces de identificarnos: servicios DNS, espacio de IPs, etc.
4 y 5: Initial Access – Phishing y Persistence – Account Manipulation
El siguiente paso es definir cuál será nuestro vector de ataque: phishing 2.0.
Pero como hemos dicho, vamos a camuflarnos con Microsoft para que ningún equipo sea capaz de detectarnos. Para ello, y aquí viene lo interesante, utilizaremos un enlace de Microsoft L E G Í T I M O (https://microsoft.com/devicelogin) para el registro de los dispositivos, una técnica que se ha sido utilizada por el grupo APT Nobelium.
A continuación, creamos un código de registro de dispositivo. Para llevar a cabo esta tarea, es necesario hacer una llamada a la API del registro de dispositivos de Microsoft (https://login.microsoftonline.com/common/oauth2/devicecode?api-version=1.0) con los siguientes parámetros:
“client_id” = “d3590ed6-52b3-4102-aeff-aad2292ab01c”
“resource” = “https://graph.windows.net”
Donde el Client ID representa la aplicación Microsoft Office (más adelante explicaremos por qué usamos este ID) y el resource es la API de Microsoft Graph (necesaria para acceder a los datos del tenant).
Después, enviaremos a DON CAFÉ un correo electrónico suplantando a Microsoft como remitente “no-reply” (sí… aun funciona). En él, solicitaremos que registre su dispositivo en el enlace legítimo con el código de registro que hemos preparado previamente:
Ojo, el token únicamente será válido 15 minutos, por lo que la decisión de cuándo enviar el correo es MUY importante. Si tenemos suerte, introducirá el código que registrará nuestro dispositivo y ¡voilá!, obtenemos el token de la sesión del usuario y la persistencia suficiente para continuar con el ataque, sin haber tenido que lidiar con los mecanismos de 2FA.
Además, al haber utilizado recursos legítimos de Microsoft, habremos sido capaces de evitar cualquier problema que pudiéramos tener con el proceso de autenticación y con los mecanismos de seguridad como filtros de SPAM y de enlaces maliciosos o IPs sospechosas.
Y te estarás preguntando, ¿y el SOC no se dará cuenta que se ha registrado un dispositivo desconocido? Pues posiblemente sí porque cada vez que se accede al enlace aparecerá el siguiente registro:
Con una buena regla de detección esto cantaría mucho, pues no todos los días se accede al portal del Endpoint Manager de Microsoft pero, ¿y si te dijera que podemos sustituir la aplicación que hace la petición por una que no haga tanto ruido? Por ejemplo, Microsoft Office.
Si revisamos los inicios de sesión de Microsoft Office y los inicios de sesión de Endpoint Manager (Microsoft Intune Company Portal) en una organización, y los comparamos, podemos ver que es mucho más difícil de identificar un acceso no legítimo a Microsoft Office que a Endpoint Manager.
Para realizar el cambio, simplemente cambiamos el ClientID en la petición de autenticación que enviamos al interactuar con la API Graph de Microsoft, siendo este el mismo ClientID que utilizamos en las fases previas.
Una vez modificamos el ClientID, confirmamos que hemos podido interactuar con el token del 2FA y hacer un bypass del Acceso Condicional de Microsoft (una capa de seguridad adicional para validar los inicios de sesión de los usuarios en función del país, IPs, aplicaciones, etc. ¿Recordamos las credenciales leakeadas que identificamos en la primera fase? Pues el culpable de no haber intentado aprovecharlas es el Acceso Condicional):
Y por si te estás preguntando si una IP desconocida no destacaría, la respuesta es no. Un usuario regular en una organización puede tener más de 50 cambios de IPs en 30 días, por lo que utilizar una única IP diferente no va a llamar la atención del Blue Team, por lo que, mientras que la detección del ataque es muy compleja, un atacante ya ha podido obtener el token del usuario y haber establecido sesión a través de una shell.
6 y 7: Discovery – Account Discovery y Lateral Movement – Internal Spearphishing
Para obtener los roles que tiene asignados nuestro usuario, podríamos consultar la API del Azure AD con simplemente ejecutar el siguiente cmdlet y obtener todos los roles de la organización.
Get-AzureADDirectoryRole
Sin embargo, cmdlets como Get-AzureADDirectoryRole o Get-MsolRole son equivalentes a un “whoami” en entornos Windows y Linux, por lo que son muy perseguidos por los equipos defensivos. Para evitar la detección, es preferible acceder al portal de administración del Azure Active Directory (https://portal.azure.com) y hacer la enumeración de forma manual.
En el caso de que no posea roles de administrador, el siguiente paso sería identificar el administrador global y utilizar la misma técnica de robo de sesión, pero esta vez, contando con acceso a cientos de recursos de la organización e información interna, por lo que podríamos diseñar un phishing interno y “Lateral movement”.
En nuestro caso, hemos tenido suerte y el usuario es administrador global del tenant de DON TARTAS (una mala práctica habitual de utilizar cuentas de administración para las tareas diarias.), por lo que podemos pasar directamente a la siguiente táctica “Persistence”.
En este punto habremos alcanzado el primer flag: somos administradores del tenant, la víctima NO se ha percatado y el equipo defensivo de DON TARTAS NO ha detectado lo que ha sucedido porque no puede tener control sobre lo que ocurre en DON CAFÉ.
8 Privilege Escalation- Domain Policy Modification
Nuestro siguiente objetivo es lograr una persistencia a largo plazo en DON CAFÉ y para esto vamos a crear un dominio customizado y federado para lograr la confianza con el objetivo. El Directorio Activo de Azure permite la creación de dominios de forma muy fácil; solamente se necesita un buen nombre y esperar unos minutos mientras Microsoft te lo valida. Esto nos permitirá crear usuarios, aplicaciones, servicios, etc., que nos ayudarán a mantener una persistencia a largo plazo.
Te preguntarás ¿no harás mucho ruido? Es posible que sí, pero es que una organización promedio puede tener más de 50 dominios customizados y no llamaría la atención añadir uno más.
Además, hay que tener en cuenta que los administradores globales (aka nosotros) pueden añadir técnicas de “Defense Evasion”, lo que nos permitiría impersonar los equipos de seguridad y eliminar o modificar correos relacionados con las actividades sospechosas, deshabilitar conectores de datos del SIEM, deshabilitar registros, etc.
9 Persistence-Account Manipulation
Ahora que somos administradores y que contamos con una persistencia estable en el tenant de DON CAFÉ, debemos ir a por nuestro objetivo real: DON TARTAS.
Para ello, vamos a registrar una aplicación externa en el Directorio Activo de Azure y concederle permisos de la organización. De esta manera lograríamos una segunda persistencia directa en el tenant de DON TARTAS, lo que nos permitirá llevar a cabo la última fase del ataque: la exfiltración de información interna.
¿Por qué hacemos esto? Pues porque algo que hemos visto que ocurre mucho en las organizaciones es que los usuarios utilizan las cuentas corporativas para registrarse en servicios como: Netflix, HBO, Linkedin, Gmail… que asumimos que tienen suficiente madurez, u otras como DON TOMATE que quizás no tanto. Esta sería la primera de nuestras opciones: comprometer a una de las aplicaciones que los usuarios ya han registrado y a partir de ella acceder a los recursos de la organización. La segunda opción, que es la que vamos a seguir, es directamente crear una aplicación sobre el Directorio Activo en Azure con los permisos que deseemos sobre los recursos de la organización. Esto nos permitirá hacer consultas, modificar políticas, cerrar alertas de seguridad, crear usuarios, crear mineros, y exfiltrar información, entre muchas otras.
Para registrar la aplicación simplemente se debe acceder al portal https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Re gisteredApps y registraremos una aplicación dándole el nombre que deseemos y un token. Es importante establecer que el tiempo de vida del token sea lo suficientemente grande para que no se termine la persistencia.
Dicho token será lo que utilicemos para conectarnos a la aplicación mediante la API Graph de Microsoft y pasar a la siguiente fase.
10 Exfiltration – Exfiltration Over Alternative Protocol
Una vez estamos dentro de DON TARTAS, podemos iniciar la última fase del ataque. Simplemente con realizar búsquedas automatizadas sobre la API Graph de Microsoft se puede extraer toda la información de interés de la organización y podríamos llegar hasta donde nuestra imaginación nos permita. Un ejemplo sencillo sería implementar una tarea programada que se ejecute cada hora y realice la siguiente consulta a Microsoft Teams: https://graph.microsoft.com/v1.0/groups/IDdegrupo/drive/items/XXXXXX/XXXXX y obtendríamos resultados como los que aparecen en la imagen siguiente: una muestra de los ficheros que se han compartido en Teams, habiendo conseguido nuestro objetivo.
Como conclusión, hemos mostrado cómo se puede realizar un ataque de cadena de suministro aprovechando los propios servicios de Microsoft y evitando la necesidad de diseñar algún artefacto malicioso que tendríamos que introducir en la organización. Un atacante que replique estos pasos de forma exitosa podría llegar a obtener acceso a toda la información interna de una organización y una persistencia muy elaborada sin que el equipo de defensa pueda detectarlo fácilmente. Además, se evidencia el riesgo que representa tener servicios externalizados con otros proveedores y que debemos analizar en manos de quién dejamos nuestra seguridad y los servicios.
