Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Las aplicaciones de Azure piden permisos para acceder a los datos del usuario (información básica, pero también acceso a documentos, enviar correos electrónicos...).
Si se permite, un usuario normal puede otorgar consentimiento solo para "permisos de bajo impacto". En todos los demás casos, se requiere consentimiento de administrador.
GA, ApplicationAdministrator, CloudApplication Administrator y un rol personalizado que incluya permiso para otorgar permisos a aplicaciones pueden proporcionar consentimiento a nivel de inquilino.
Solo los permisos que no requieren consentimiento de administrador se clasifican como bajo impacto. Estos son los permisos requeridos para inicios de sesión básicos que son openid, profile, email, User.Read y offline_access. Si una organización permite el consentimiento del usuario para todas las aplicaciones, un empleado puede otorgar consentimiento a una aplicación para leer lo anterior de su perfil.
Por lo tanto, un atacante podría preparar una Aplicación maliciosa y con un phishing, hacer que el usuario acepte la Aplicación y robe sus datos.
No autenticado: Desde una cuenta externa, crea una aplicación con los permisos User.Read y User.ReadBasic.All, por ejemplo, phishing a un usuario, y podrás acceder a la información del directorio.
Esto requiere que el usuario phished pueda aceptar aplicaciones OAuth de entornos externos.
Autenticado: Habiendo comprometido un principal con suficientes privilegios, crea una aplicación dentro de la cuenta y phishing a algún usuario privilegiado que pueda aceptar permisos OAuth privilegiados.
En este caso, ya puedes acceder a la información del directorio, por lo que el permiso User.ReadBasic.All ya no es interesante.
Probablemente estés interesado en permisos que requieren que un administrador los otorgue, porque un usuario normal no puede dar ningún permiso a las aplicaciones OAuth, por eso necesitas phishing solo a esos usuarios (más sobre qué roles/permisos otorgan este privilegio más adelante).
El siguiente comando de PowerShell se utiliza para verificar la configuración de consentimiento para los usuarios en Azure Active Directory (Azure AD) respecto a su capacidad para consentir a aplicaciones:
Deshabilitar el consentimiento del usuario: Esta configuración prohíbe a los usuarios otorgar permisos a aplicaciones. No se permite el consentimiento del usuario a aplicaciones.
Los usuarios pueden consentir a aplicaciones de editores verificados o de su organización, pero solo para los permisos que seleccione: Esta configuración permite a todos los usuarios consentir solo a aplicaciones que son publicadas por un editor verificado y aplicaciones registradas en su propio inquilino. Agrega una capa de control al permitir el consentimiento solo para permisos específicos.
Los usuarios pueden consentir a todas las aplicaciones: Esta configuración es más permisiva y permite a todos los usuarios consentir a cualquier permiso para aplicaciones, siempre que esos permisos no requieran consentimiento administrativo.
Política de consentimiento de aplicaciones personalizadas: Esta configuración indica que hay una política personalizada en vigor, que puede adaptarse a requisitos organizacionales específicos y puede involucrar una combinación de restricciones basadas en el editor de la aplicación, los permisos que solicita la aplicación y otros factores.
En un ataque de consentimiento ilícito, los atacantes engañan a los usuarios finales para que otorguen permisos a una aplicación maliciosa registrada en Azure. Esto se hace haciendo que la aplicación parezca legítima, llevando a las víctimas a hacer clic sin saber en un botón de "Aceptar". Como resultado, Azure AD emite un token al sitio del atacante, permitiéndoles acceder y manipular los datos de la víctima, como leer o enviar correos electrónicos y acceder a archivos, sin necesidad de una cuenta organizacional.
El ataque implica varios pasos dirigidos a una empresa genérica. Así es como podría desarrollarse:
Registro de Dominio y Alojamiento de Aplicaciones: El atacante registra un dominio que se asemeja a un sitio de confianza, por ejemplo, "safedomainlogin.com". Bajo este dominio, se crea un subdominio (por ejemplo, "companyname.safedomainlogin.com") para alojar una aplicación diseñada para capturar códigos de autorización y solicitar tokens de acceso.
Registro de Aplicación en Azure AD: El atacante luego registra una Aplicación Multi-Tenante en su Inquilino de Azure AD, nombrándola como la empresa objetivo para parecer legítima. Configuran la URL de Redirección de la aplicación para apuntar al subdominio que aloja la aplicación maliciosa.
Configuración de Permisos: El atacante configura la aplicación con varios permisos de API (por ejemplo, Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Estos permisos, una vez otorgados por el usuario, permiten al atacante extraer información sensible en nombre del usuario.
Distribución de Enlaces Maliciosos: El atacante elabora un enlace que contiene el id del cliente de la aplicación maliciosa y lo comparte con usuarios específicos, engañándolos para que otorguen consentimiento.
El ataque puede ser facilitado utilizando herramientas como 365-Stealer.
Si el atacante tiene algún nivel de acceso a un usuario en la organización víctima, podría verificar si la política de la organización permite al usuario aceptar aplicaciones:
Para ejecutar el ataque, el atacante necesitaría crear una nueva aplicación en su inquilino de Azure (en Registros de aplicaciones), configurada con los permisos:
User.ReadBasic.All está dentro de Microsoft Graph en Permisos delegados. (Los permisos de aplicación siempre necesitarán aprobación adicional).
User.ReadBasic.All es el permiso que te permitirá leer información de todos los usuarios en la organización si se concede.
Recuerda que solo GA, ApplicationAdministrator, CloudApplication Administrator y un rol personalizado que incluya permiso para otorgar permisos a aplicaciones pueden proporcionar consentimiento a nivel de inquilino. Así que, deberías phishing a un usuario con uno de esos roles si quieres que apruebe una aplicación que requiere consentimiento de administrador.
También podrías crear una aplicación a través de cli con:
Consulta https://www.alteredsecurity.com/post/introduction-to-365-stealer para aprender cómo configurarlo.
Ten en cuenta que el token de acceso obtenido será para el punto final de graph con los alcances: User.Read y User.ReadBasic.All (los permisos solicitados). No podrás realizar otras acciones (pero esos son suficientes para descargar información sobre todos los usuarios en la organización).
También podrías usar esta herramienta para realizar este ataque.
Una vez que tengas acceso al usuario, puedes hacer cosas como robar documentos sensibles e incluso subir archivos de documentos con puerta trasera.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
