Az - Illicit Consent Grant
Phishing de Aplicaciones OAuth
Azure Applications solicitan permisos para acceder a los datos del usuario (información básica, pero también acceso a documentos, enviar correos...).
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 inicio de sesión básico 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 App maliciosa y con un phishing, hacer que el usuario acepte la App y robe sus datos.
2 Tipos de Ataques de Illicit Consent Grant
No autenticado: Desde una cuenta externa crear una aplicación con los permisos
User.Read
yUser.ReadBasic.All
por ejemplo, hacer 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, crear una aplicación dentro de la cuenta y hacer 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 un administrador para otorgarlos, porque el usuario común no puede otorgar a las aplicaciones OAuth ningún permiso, por eso necesitas hacer phishing solo a esos usuarios (más sobre qué roles/permisos otorgan este privilegio más adelante)
Verificar si los usuarios pueden otorgar consentimiento
El siguiente comando de PowerShell se utiliza para verificar la configuración de consentimiento para los usuarios en Azure Active Directory (Azure AD) con respecto a su capacidad para otorgar consentimiento a aplicaciones:
Deshabilitar el consentimiento de usuarios: Esta configuración prohíbe a los usuarios otorgar permisos a aplicaciones. No se permite el consentimiento de usuarios a aplicaciones.
Los usuarios pueden consentir 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 aplicaciones publicadas por un editor verificado y aplicaciones registradas en su propio tenant. Agrega una capa de control al permitir el consentimiento solo para permisos específicos.
Los usuarios pueden consentir todas las aplicaciones: Esta configuración es más permisiva y permite a todos los usuarios consentir cualquier permiso para aplicaciones, siempre que esos permisos no requieran consentimiento administrativo.
Política de consentimiento de aplicaciones personalizada: 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.
Entendiendo el Ataque de Concesión de Consentimiento Ilícito
En un ataque de concesión 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 saberlo 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.
Resumen del Flujo del Ataque
El ataque involucra varios pasos dirigidos a una empresa genérica. Así es como podría desarrollarse:
Registro de Dominio y Alojamiento de Aplicación: El atacante registra un dominio que se asemeja a un sitio confiable, 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-Tenant en su Tenant de Azure AD, nombrándola como la empresa objetivo para que parezca 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 crea un enlace que contiene el id del cliente de la aplicación maliciosa y lo comparte con los usuarios objetivo, engañándolos para que otorguen su consentimiento.
Utilización de Herramientas para el Ataque
El ataque puede ser facilitado usando herramientas como 365-Stealer.
Preparación Previa al Ataque:
Si el atacante tiene algún nivel de acceso a un usuario en la organización víctima, podrían 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 App en su Azure Tenant (en App registrations), configurada con los permisos:
User.ReadBasic.All
está dentro de Microsoft Graph
en Delegated permissions
. (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 incluyapermiso para otorgar permisos a aplicaciones
pueden proporcionar consentimiento a nivel de tenant. Por lo tanto, deberías hacer phishing a un usuario con uno de esos roles si quieres que apruebe una App que requiere consentimiento de administrador.
También podrías crear una App vía cli con:
Consulta https://www.alteredsecurity.com/post/introduction-to-365-stealer para aprender cómo configurarlo.
Ten en cuenta que el access token obtenido será para el graph endpoint 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.
Post-Explotación
Una vez que tengas acceso al usuario, puedes hacer cosas como robar documentos sensibles e incluso subir archivos de documentos con puertas traseras.
Referencias
Last updated