Az - OAuth Apps Phishing
Last updated
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 están configuradas con los permisos que podrán usar cuando un usuario consienta la aplicación (como enumerar el directorio, acceder a archivos o realizar otras acciones). Tenga en cuenta que la aplicación actuará en nombre del usuario, por lo que incluso si la aplicación pudiera estar pidiendo permisos de administración, si el usuario que consiente no tiene ese permiso, la aplicación no podrá realizar acciones administrativas.
Por defecto, cualquier usuario puede dar consentimiento a las aplicaciones, aunque esto se puede configurar para que los usuarios solo puedan consentir aplicaciones de editores verificados para permisos seleccionados o incluso eliminar el permiso para que los usuarios consientan a las aplicaciones.
Si los usuarios no pueden consentir, los administradores como GA, Application Administrator o Cloud Application Administrator pueden consentir las aplicaciones que los usuarios podrán usar.
Además, si los usuarios solo pueden consentir aplicaciones que utilizan permisos de bajo riesgo, estos permisos son por defecto openid, profile, email, User.Read y offline_access, aunque es posible agregar más a esta lista.
Y si pueden consentir a todas las aplicaciones, pueden consentir a todas las aplicaciones.
No autenticado: Desde una cuenta externa, crear una aplicación con los permisos de bajo riesgo 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 sea capaz de aceptar aplicaciones OAuth de un inquilino externo.
Si el usuario phished es un administrador que puede consentir cualquier aplicación con cualquier permiso, la aplicación también podría solicitar permisos privilegiados.
Autenticado: Habiendo comprometido un principal con suficientes privilegios, crear 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 a las aplicaciones OAuth ningún permiso, por eso necesitas phishing solo a esos usuarios (más sobre qué roles/permisos otorgan este privilegio más adelante).
Ten en cuenta que necesitas ejecutar este comando desde un usuario dentro del inquilino, no puedes encontrar esta configuración de un inquilino desde uno externo. El siguiente cli puede ayudarte a entender los permisos de los usuarios:
Los usuarios pueden consentir a todas las aplicaciones: Si dentro de permissionGrantPoliciesAssigned puedes encontrar: ManagePermissionGrantsForSelf.microsoft-user-default-legacy entonces los usuarios pueden aceptar cada aplicación.
Los usuarios pueden consentir a aplicaciones de editores verificados o de tu organización, pero solo para los permisos que selecciones: Si dentro de permissionGrantPoliciesAssigned puedes encontrar: ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team entonces los usuarios pueden aceptar cada aplicación.
Deshabilitar el consentimiento del usuario: Si dentro de permissionGrantPoliciesAssigned solo puedes encontrar: ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat y ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team entonces los usuarios no pueden consentir ninguno.
Es posible encontrar el significado de cada una de las políticas comentadas en:
Verifique los usuarios que son considerados administradores de aplicaciones (pueden aceptar nuevas aplicaciones):
El ataque implica varios pasos dirigidos a una empresa genérica. Así es como podría desarrollarse:
Registro de dominio y alojamiento de la aplicación: 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 la aplicación en Azure AD: El atacante luego registra una Aplicación Multi-Tenant 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 que apunte 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 su consentimiento.
Registra una nueva aplicación. Puede ser solo para el directorio actual si estás usando un usuario del directorio atacado o para cualquier directorio si este es un ataque externo (como en la imagen siguiente).
También establece la URI de redirección a la URL esperada donde deseas recibir el código para obtener tokens (http://localhost:8000/callback por defecto).
Luego crea un secreto de aplicación:
Selecciona permisos de API (por ejemplo, Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read)
Ejecuta la página web (azure_oauth_phishing_example) que solicita los permisos:
Envía la URL a la víctima
En este caso http://localhost:8000
Las víctimas necesitan aceptar el aviso:
Usa el token de acceso para acceder a los permisos solicitados:
365-Stealer: Consulta https://www.alteredsecurity.com/post/introduction-to-365-stealer para aprender a configurarlo.
Dependiendo de los permisos solicitados, podrías acceder a diferentes datos del inquilino (lista de usuarios, grupos... o incluso modificar configuraciones) e información del usuario (archivos, notas, correos electrónicos...). Luego, puedes usar estos permisos para realizar esas acciones.
Consulta las secciones de Aplicaciones y Principal de Servicio de la página:
Az - EntraID PrivescAprende 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)
