OAuth Consent Phishing: Wie bösartige Apps Passwortdiebstahl umgehen

OAuth Consent Phishing ist ein Identitätsangriff, bei dem ein Benutzer oder Administrator dazu gebracht wird, einer bösartigen OAuth-Anwendung Berechtigungen zu erteilen. Nachdem der Grant genehmigt wurde, benötigt der Angreifer nicht zwingend das Kennwort des Benutzers. Die Anwendung kann auf Microsoft 365 oder andere geschützte Ressourcen entsprechend der erteilten Berechtigungen zugreifen. Damit unterscheidet sich dieses Szenario von klassischem Credential Phishing, Password Spraying oder MFA Fatigue.

Der Umfang dieses Artikels ist Microsoft Entra ID, Microsoft 365 und anwendungsbezogene Zustimmung auf Basis von OAuth. Nicht jede bösartige Anmeldung ist Consent Phishing. Der Fokus liegt auf dem Consent Grant selbst: was die App erhält, wie Verteidiger es sehen können, wie es entfernt wird und wie derselbe Angriffspfad künftig blockiert wird.

Was ist OAuth Consent Phishing?

OAuth Consent Phishing missbraucht ein legitimes Consent-Modell. Microsoft beschreibt Consent Phishing als Angriffe, bei denen Benutzer dazu verleitet werden, bösartigen Cloud-Anwendungen Berechtigungen zu gewähren. Der Consent Screen zeigt die Berechtigungen an, die die Anwendung erhält. Trotzdem können ein realistischer Name, ein vertrautes Logo oder ein plausibler Geschäftskontext dazu führen, dass ein Benutzer oder Administrator Zugriff genehmigt, der nicht genehmigt werden sollte.

In der Microsoft Identity Platform erlaubt OAuth einer Anwendung, Zugriff auf eine geschützte Ressource anzufordern. RFC 6749 definiert OAuth 2.0 als Framework, mit dem eine Drittanbieteranwendung begrenzten Zugriff auf einen HTTP-Dienst erhalten kann, entweder im Namen eines Resource Owners oder im eigenen Namen. Microsoft Entra ID implementiert dieses Modell für Ressourcen wie Microsoft Graph, Exchange Online, SharePoint Online und andere APIs, die mit der Microsoft Identity Platform integriert sind.

Scope-Grenzen

Der wichtigste Punkt für Verteidiger ist: Consent Phishing zielt auf Autorisierung, nicht nur auf Authentifizierung. Bei einem Passwort-Phishing-Vorfall wird meist geprüft, ob Credentials gestohlen wurden, ob MFA erfüllt wurde und ob eine verdächtige Session existiert. Bei OAuth Consent Phishing muss zusätzlich geprüft werden, ob eine Anwendung einen dauerhaften Permission Grant erhalten hat, der nach der ursprünglichen interaktiven Sitzung weiterhin relevant bleibt.

Das Risiko liegt nahe bei Azure App Registrations: Over-Privileged Tenant Apps, aber der Angriffspfad ist anders. Überprivilegierte legitime Apps sind häufig ein internes Governance-Problem. OAuth Consent Phishing ist eine bösartige oder irreführende App, die Zugriff über einen Consent Prompt erhält.

Wie OAuth Consent Phishing funktioniert

Die Angriffskette beginnt mit einer normalen OAuth Authorization Request. Ein Benutzer folgt einem Link oder öffnet eine Anwendung, die ihn an die Microsoft Identity Platform weiterleitet. Der Benutzer authentifiziert sich, falls erforderlich. Wenn für die angeforderten Berechtigungen noch kein Consent vorliegt, zeigt Microsoft Entra einen Consent Prompt an. Dieser Prompt enthält die angeforderten Berechtigungen und Publisher-Informationen.

Consent-Zustand, nicht nur Sign-in-Zustand

Wenn der Benutzer oder Administrator die Anforderung genehmigt, speichert Microsoft Entra einen Grant für die Anwendung. Bei delegierten Microsoft-Graph-Berechtigungen wird das Ergebnis des Consent als OAuth2PermissionGrant dargestellt. Bei Application Permissions wird das Ergebnis als appRoleAssignment dargestellt. Diese beiden Objekte sind entscheidend, weil Verteidiger sie während der Bereinigung auflisten, prüfen und entfernen müssen.

Eine bösartige App muss nicht alle Berechtigungen auf einmal anfordern. Microsoft dokumentiert Dynamic Consent als Fall, in dem eine Anwendung zur Laufzeit neue Berechtigungen anfordert. Consent Review ist deshalb keine einmalige Onboarding-Prüfung. Ein Tenant kann bei der initialen Prüfung unauffällig sein und später eine breitere Zugriffsanforderung erhalten, wenn die App so entwickelt wurde, dass sie zusätzliche Scopes anfordert.

Nuance zu offline_access

Der Scope offline_access verändert ebenfalls das Verteidigungsmodell. Microsoft dokumentiert offline_access als Zugriff auf Ressourcen im Namen des Benutzers über einen längeren Zeitraum. Auf der Consent-Seite erscheint dies als Berechtigung, den Zugriff auf bereits freigegebene Daten beizubehalten. Microsoft weist außerdem darauf hin, dass offline_access implizit erteilt wird, wenn eine delegierte Berechtigung gewährt wurde, und dass Refresh Tokens langlebig sind. Das bedeutet nicht, dass der Angreifer permanenten Zugriff hat. Es bedeutet, dass Incident Response die Entfernung der Grants und Token- oder Session-Bereinigung umfassen muss, nicht nur ein Passwort-Reset.

Deshalb liegt OAuth Consent Phishing in der Nähe anderer Entra-Identitätsangriffe, ist aber nicht identisch. Device Code Phishing: How OAuth Device Flow Compromises Entra ID Accounts missbraucht einen anderen OAuth Flow. Beide Angriffe sind OAuth-zentriert, aber Device Code Phishing autorisiert eine Session über den Device Code Flow, während Consent Phishing einer Anwendung Berechtigungen erteilt.

Delegated Permissions vs Application Permissions

Die wichtigste technische Trennung ist die zwischen Delegated Permissions und Application Permissions.

Delegated Access

Delegated Permissions werden verwendet, wenn eine Anwendung im Namen eines angemeldeten Benutzers handelt. Microsoft beschreibt sie als Berechtigungen, die es einer Anwendung ermöglichen, im Namen eines Benutzers zu handeln, wobei die Anwendung nicht auf etwas zugreifen kann, worauf der angemeldete Benutzer selbst keinen Zugriff hat. Wenn ein Benutzer eine delegierte Berechtigung zum Lesen von Mail erteilt, hängt der Zugriff der App davon ab, was dieser Benutzer lesen darf. Wenn ein privilegierter Administrator während einer Anmeldung delegierte Berechtigungen erteilt, kann die Auswirkung deutlich größer sein, weil die Benutzerprivilegien höher sind.

App-only Access

Application Permissions, auch App Roles oder App-only Permissions genannt, werden verwendet, wenn kein angemeldeter Benutzer vorhanden ist. Microsoft beschreibt App-only Access als Szenario, in dem die Anwendung mit ihrer eigenen Identität handelt. Application Permissions können breiten Tenant-Datenzugriff über Microsoft Graph oder eine andere Resource API ermöglichen. Microsoft dokumentiert, dass im Allgemeinen nur ein Administrator oder der Besitzer des API-Service-Principals Application Permissions genehmigen kann, die von dieser API offengelegt werden.

Triage nach Berechtigungstyp

Diese Unterscheidung bestimmt die Ermittlungspriorität. Ein verdächtiger delegierter Grant eines wenig privilegierten Benutzers kann dessen Mailbox, Dateien oder zugängliche Ressourcen offenlegen. Eine verdächtige Application Permission kann tenantweit wirken, abhängig von Berechtigung und Resource API. Microsoft nutzt Files.Read.All, um die Differenz zu zeigen: delegiertes Files.Read.All erlaubt der App, Dateien zu lesen, auf die der Benutzer persönlich zugreifen kann; Application Files.Read.All kann nach Grant jede Datei im Tenant über Microsoft Graph lesen.

Beide Fälle dürfen nicht zu einem generischen OAuth-App-Risiko vermischt werden. Cleanup-Objekt, Blast Radius, Approval-Pfad und Validierung unterscheiden sich.

Warum MFA Consent Abuse nicht allein stoppt

MFA bleibt wichtig. Sie reduziert die Wahrscheinlichkeit, dass ein Angreifer sich als Benutzer anmeldet, Prompts als dieser Benutzer genehmigt oder andere interaktive Aktionen ausführt. Das Problem ist enger: MFA macht einen bereits erteilten OAuth Permission Grant nicht automatisch harmlos.

Wenn eine bösartige App einen gültigen Delegated Grant hat, kann sie Tokens entsprechend diesem Grant und dem Benutzer-/Ressourcenkontext anfordern. Wenn eine App Application Permissions hat, kann sie für die abgedeckten Daten ohne angemeldeten Benutzer arbeiten. Conditional Access und MFA Policies können in bestimmten Szenarien weiterhin beeinflussen, wie Tokens ausgestellt werden, aber die Existenz eines Consent Grant muss direkt untersucht werden.

Dies ist dieselbe Grundlinie wie in Azure Identity Security: Why MFA Alone Is Not Enough. MFA ist ein Control. Sie ersetzt nicht App-Consent-Governance, Berechtigungsprüfung, Audit-Log-Monitoring, Publisher-Bewertung oder Widerruf verdächtiger Grants. Wenn Ihr Team auch Push-basierte Social-Engineering-Angriffe verfolgt, behandelt MFA Fatigue: Detection and Prevention for Microsoft Entra ID ein separates Muster, das vor oder neben Consent Abuse auftreten kann.

Der praktische Fehler besteht darin, den Incident nach einem Passwort-Reset oder der Bestätigung aktivierter MFA zu schließen. Bei Consent Phishing ist das unvollständig. Die Response muss beantworten, ob ein Service Principal existiert, welche Grants daran hängen, welche Benutzer zugestimmt haben, ob Admin Consent gewährt wurde und ob die App deaktiviert, entfernt oder daran gehindert wurde, neue Grants zu erhalten.

Die Angriffskette

Eine realistische OAuth-Consent-Phishing-Kette hat mehrere Phasen. Der konkrete Köder kann variieren, aber die Kontrollpunkte bleiben gleich.

1. Der Angreifer erstellt oder kontrolliert eine Anwendung, die Microsoft-Identity-Platform-Berechtigungen anfordern kann.
2. Ein Benutzer oder Admin erhält eine Authorization URL, die eine von Microsoft gehostete Sign-in- und Consent-Erfahrung anzeigt.
3. Der Consent Prompt listet Berechtigungen und Publisher-Informationen auf. Benutzer oder Admin genehmigt die Anforderung.
4. Microsoft Entra speichert den Grant. Delegated Permissions erscheinen als OAuth2PermissionGrant; Application Permissions erscheinen als appRoleAssignment.
5. Die App verwendet Access Tokens und gegebenenfalls Refresh Tokens, um APIs wie Microsoft Graph entsprechend der erteilten Berechtigungen aufzurufen.
6. Der Angreifer behält Zugriff, bis Verteidiger Grants widerrufen, den bösartigen Service Principal bei Bedarf deaktivieren oder entfernen, Re-Consent blockieren, relevante Sessions/Tokens invalidieren oder Microsoft eine App deaktiviert, die gegen Servicebedingungen verstößt.

Was es nicht ist

Diese Kette ist kein Password Spraying, bei dem ein Angreifer Credentials gegen viele Konten testet. Sie ist kein Kerberoasting, bei dem Kerberos-Service-Ticket-Material in Active Directory das Ziel ist. Sie ist auch kein normales OAuth Device Code Phishing, bei dem ein Benutzer zur Device-Code-Autorisierung gedrängt wird. Diese Unterschiede sind wichtig, weil Telemetrie und Remediation verschieden sind.

Für Verteidiger geht es darum, dauerhaften Zustand zu erkennen. Ein verdächtiger Sign-in wird über Sign-in Logs untersucht. Ein verdächtiger Consent Grant wird über Application Objects, Permission Grants, Audit Logs und App-Governance-Controls untersucht.

Erkennung

Kein einzelnes Microsoft-Entra-Event beweist OAuth Consent Phishing allein. Ein legitimer Administrator kann einer legitimen App zustimmen. Ein legitimer Benutzer kann eine Low-Risk Delegated Permission genehmigen. Erkennung benötigt Korrelation über Consent-Aktivität, App-Metadaten, Berechtigungen, Benutzerkontext und nachfolgendes API-Verhalten.

Audit-Log-Pivots

Beginnen Sie mit Microsoft Entra Audit Logs. Microsoft dokumentiert diese Application-Permission-Aktivitäten im Core Directory Service und in der Kategorie ApplicationManagement:

Korrelationsfragen

Nutzen Sie diese Events als Pivot, nicht als endgültiges Urteil. Eine brauchbare Detection Pipeline fragt:

• Wurde die App neu zum Tenant hinzugefügt?
• Ist der Publisher verifiziert, und passt er zum angegebenen Geschäftszweck?
• Welche Berechtigungen wurden angefordert, und sind es Low-Risk- oder High-Impact-Datenberechtigungen?
• War der Actor ein normaler Benutzer, ein Admin, ein Break-Glass-Konto oder ein Konto außerhalb seines Normalverhaltens?
• Wurde Consent kurz nach einem verdächtigen Sign-in, Impossible-Travel-Signal, Risky-User-Signal oder Phishing Report gewährt?
• Hat die Anwendung begonnen, Microsoft Graph, Exchange, SharePoint oder andere APIs in einer Weise aufzurufen, die nicht zu einem genehmigten Geschäftsprozess passt?
• Haben mehrere Benutzer dieselbe ungewöhnliche Anwendung autorisiert?

Defender for Cloud Apps kann eine weitere Ebene liefern, wenn verfügbar. Microsoft dokumentiert OAuth App Policies, die auf Apps mit Kriterien wie hohem Permission Level, vielen autorisierenden Benutzern, uncommon usage, misleading names, misleading publisher names oder potenziell bösartigem OAuth App Consent alerten können. Behandeln Sie diese Alerts als Priorisierungssignale und prüfen Sie weiterhin den darunterliegenden Service Principal und die Grants.

Eine reife Detection überwacht auch Governance Drift. Wenn User-Consent-Einstellungen gelockert, App Consent Policies geändert oder Reviewer aus dem Admin Consent Workflow entfernt werden, wird der Tenant leichter missbrauchbar. Diese Änderungen beweisen nicht allein eine bösartige App, senken aber die Kontrollstärke für künftige Consent Requests. Kombinieren Sie diese Überwachung mit How to Audit Microsoft Entra ID Security, damit App Consent zusammen mit Conditional Access, privilegierten Rollen, riskanten Benutzern und tenantweiten Identitätseinstellungen geprüft wird.

Bei hybriden Untersuchungen sollte die Grenze klar bleiben: Dieser Artikel fokussiert Entra-Audit-Aktivität, aber Active Directory Monitoring: Security Event IDs That Matter kann Incident Respondern helfen, On-Premises-Identitätsaktivität zu korrelieren, wenn derselbe Benutzer oder Admin betroffen ist.

Remediation

Remediation hat zwei Spuren: bestätigten bösartigen Zugriff entfernen und anschließend den Consent-Pfad schließen, der ihn ermöglicht hat.

Bestehende Grants entfernen

Identifizieren Sie zuerst das Application Object und den Service Principal in Enterprise Applications. Prüfen Sie die Tabs Admin consent und User consent auf erteilte Berechtigungen. Microsoft dokumentiert, dass Administratoren organisationsweite Berechtigungen im Admin-consent-Tab widerrufen können, während User-Consent-Grants möglicherweise Microsoft Graph API oder PowerShell benötigen. Für vollständiges Cleanup müssen sowohl Delegated Permissions als auch Application Permissions enumeriert werden.

Für Delegated Permissions entfernen Sie verdächtige OAuth2PermissionGrant-Objekte. Für Application Permissions entfernen Sie verdächtige appRoleAssignment-Einträge. Microsofts Dokumentation zur Permission Review bietet Graph- und PowerShell-Wege für beide Fälle. Wenn Benutzer oder Gruppen der Anwendung zugewiesen waren, prüfen und entfernen Sie diese Assignments als Teil der Eindämmung.

Service Principal eindämmen

Deaktivieren oder entfernen Sie danach den Service Principal, wenn die Anwendung als bösartig oder nicht autorisiert bestätigt ist. Vorsicht bei Anwendungen mit gleichzeitig verdächtiger und legitimer Nutzung: Das Entfernen eines Service Principals kann Geschäftsabläufe brechen. Wenn Microsoft eine OAuth-Anwendung wegen Verstoß gegen Servicebedingungen deaktiviert hat, dokumentiert Microsoft, dass neue Token Requests und Refresh-Token-Requests abgelehnt werden, bestehende Access Tokens aber bis zum Ablauf gültig bleiben. Deshalb darf Response nicht von einer einzigen Aktion abhängen.

Behandeln Sie anschließend Tokens und Sessions. Bei delegiertem Missbrauch widerrufen Sie Refresh Tokens oder invalidieren Benutzer-Sessions, wo angemessen. Bei App-only Missbrauch konzentrieren Sie sich auf das Entfernen der App Role Assignments, das Entfernen von Credentials des Service Principals, wenn er tenant-owned ist, das Deaktivieren des Service Principals und die Validierung, dass kein App-only Grant verbleibt. Passwort-Reset kann relevant sein, wenn der Benutzer ebenfalls gephisht wurde, entfernt aber keinen OAuth Grant.

Künftigen Consent härten

Härten Sie anschließend die Consent Governance:

• Prüfen Sie User-Consent-Einstellungen und vermeiden Sie breiten User Consent für Anwendungen und Berechtigungen, die Admin Review erfordern sollten.
• Nutzen Sie App Consent Policies, um zu steuern, wozu Benutzer anhand von Kriterien wie Verified-Publisher-Status und Permission Risk consenten dürfen.
• Aktivieren und konfigurieren Sie den Admin Consent Workflow, damit Benutzer Zugriff auf genehmigungspflichtige Apps anfordern können, statt informelle Wege zu nutzen.
• Begrenzen Sie, wer tenantweiten Admin Consent erteilen kann. Microsoft empfiehlt Least-Privilege-Rollen und weist darauf hin, dass Global Administrator hoch privilegiert ist.
• Bewerten Sie Publisher Verification als Signal, nicht als vollständige Sicherheitsfreigabe. Microsoft sagt ausdrücklich, dass ein Verified-Publisher-Badge keine Aussage über App-Qualität, Zertifizierungen, Compliance oder Security Best Practices impliziert.
• Verwenden Sie Defender for Cloud Apps OAuth App Policies, wenn verfügbar, um auf riskante, ungewöhnliche, hochprivilegierte oder potenziell bösartige Apps zu alerten.

Erstellen Sie keine pauschale Regel, die jede Drittanbieter-App ohne Ausnahmeprozess blockiert. Das führt häufig zu unmanaged Workarounds. Stärker ist ein kontrollierter Consent-Pfad: erlaubte Low-Risk Delegated Permissions, Admin Review für sensible Delegated Scopes und Application Permissions sowie regelmäßige Review bereits genehmigter Apps.

Validierung nach Cleanup

Validierung ist der Punkt, an dem viele Consent-Phishing-Responses scheitern. Ein Ticket sollte nicht geschlossen werden, weil die App aus einer sichtbaren Portalansicht verschwunden ist. Es sollte geschlossen werden, weil die dauerhaften Autorisierungspfade geprüft wurden.

Abschluss-Checkliste

Nutzen Sie diese Validierungssequenz:

1. Bestätigen, dass der verdächtige Service Principal deaktiviert oder entfernt wurde, wenn die App als bösartig bestätigt ist.
2. Bestätigen, dass kein verdächtiger delegierter OAuth2PermissionGrant für den Client Service Principal verbleibt.
3. Bestätigen, dass kein verdächtiges appRoleAssignment für App-only Permissions verbleibt.
4. Bestätigen, dass Benutzer- und Gruppen-Assignments zur Anwendung entfernt wurden, wenn sie zum Zugriff beitrugen.
5. Bestätigen, dass Audit Logs die erwarteten Removal Events zeigen, etwa entfernte Delegated Permission Grants oder entfernte App Role Assignments.
6. Bestätigen, dass User-Consent-Einstellungen, App Consent Policies und Admin Consent Workflow dem Zielmodell entsprechen.
7. Bestätigen, dass relevante Benutzer-Sessions oder Tokens widerrufen wurden, wenn Delegated Access involviert war.
8. Bestätigen, dass Defender for Cloud Apps oder App Governance, falls bereitgestellt, die App nicht mehr als autorisiert oder aktiv zeigen.
9. Bestätigen, dass neue Versuche, denselben Permission-Pfad zu erteilen, den erwarteten Admin Workflow benötigen oder durch Policy blockiert werden.

Für tenantweite Untersuchungen kombinieren Sie dies mit Azure Identity Protection: Blocking Leaked Credentials. Consent Phishing ist nicht dasselbe wie geleakte Credentials, aber Risky-User- und Risky-Sign-in-Signale können helfen zu entscheiden, ob der Benutzer, der Consent erteilt hat, ebenfalls kompromittiert war.

Wie EtcSec verwandte Exposition erkennt

EtcSec sollte OAuth Consent Phishing als Expositionsmuster über Application Inventory, Identity Governance und Monitoring Readiness behandeln. Die nützliche Frage ist nicht nur, ob eine bösartige App existiert. Die nützliche Frage ist, ob der Tenant bösartigen Consent leicht erhältlich, schwer erkennbar oder langsam widerrufbar machen würde.

Expositionssignale

Relevante Checks umfassen:

• Enterprise Applications mit breiten Delegated Permissions oder App-only Microsoft-Graph-Berechtigungen.
• Anwendungen, die von vielen Benutzern autorisiert wurden, aber keinen klaren Owner oder Geschäftszweck haben.
• Anwendungen ohne Verified Publisher, besonders wenn sie sensible Berechtigungen anfordern.
• User-Consent-Einstellungen, die mehr als Low-Risk Delegated Permissions erlauben.
• Fehlender oder schwacher Admin Consent Workflow.
• Fehlende regelmäßige Review von Admin Consent und User Consent Grants.
• Application Permissions, die nicht zum angegebenen Zweck der App passen.
• Privilegierte Benutzer, die Drittanbieteranwendungen aus weniger vertrauenswürdigen Geräten oder Kontexten genehmigt haben.
• Monitoring-Lücken rund um Consent to application, Add delegated permission grant und Add app role assignment to service principal.

Das Thema liegt nahe bei Azure Conditional Access: MFA Bypass With Stolen Passwords, aber die Remediation ist anders. Conditional Access bleibt Teil der Identitätsverteidigung, aber OAuth-Consent-Härtung benötigt App Governance, Permission Review, Consent Policies und Service-Principal-Cleanup.

Verwandte Controls

OAuth Consent Phishing wird besser als Control-Set behandelt als als einzelner Schalter.

Diese Controls reduzieren auch die Exposition durch überberechtigte legitime Anwendungen. Consent Governance ist damit Teil normaler Entra-Sicherheitsoperationen, nicht nur Incident Response nach einem Phishing Report.

Primärquellen

Die technischen Claims in diesem Artikel basieren auf Primärdokumentation und Standards:

• Microsoft Learn: Protect against consent phishing
• Microsoft Learn: Permissions and consent overview
• Microsoft Learn: Scopes and permissions in the Microsoft identity platform
• Microsoft Learn: Configure the admin consent workflow
• Microsoft Learn: Manage app consent policies
• Microsoft Learn: Review permissions granted to enterprise applications
• Microsoft Learn: View activity logs of application permissions
• Microsoft Learn: Microsoft Entra audit log activity reference
• Microsoft Learn: Publisher verification
• Microsoft Defender for Cloud Apps: Create policies to control OAuth apps
• RFC 6749: The OAuth 2.0 Authorization Framework
• RFC 6819: OAuth 2.0 Threat Model and Security Considerations