OAuth Consent Phishing 2026 beschreibt eine gefährliche Art von Microsoft-365-Angriff, bei der nicht unbedingt ein Passwort gestohlen werden muss. Stattdessen bringt ein Angreifer Mitarbeitende dazu, einer fremden Anwendung weitreichende Berechtigungen zu erteilen. Die Anfrage kann auf einer echten Microsoft-Anmeldeseite erscheinen und deshalb vertrauenswürdig wirken. Nach einer erfolgreichen Zustimmung kann die App über legitime OAuth-Zugriffstokens auf erlaubte Daten zugreifen, beispielsweise E-Mails, Kontakte oder Dateien. Microsoft dokumentiert diese sogenannten illicit consent grants als eigenständiges Risiko. Dieser Leitfaden erklärt die Angriffsidee, die Unterschiede zu normalem Phishing und einen sicheren Prüf-, Präventions- und Incident-Response-Prozess in Microsoft Entra ID.
Autor: Salman Dolatpanah Gortlar · GORTNET · 5. November 2026
Sicherheitskern: MFA schützt die Anmeldung, aber eine bösartige OAuth-Einwilligung erfordert separate App-Governance und Berechtigungsprüfung.
OAuth Consent Phishing 2026: Wie funktioniert die Falle?
Eine Anwendung fordert über Microsoft Entra ID bestimmte Rechte an. Der Nutzer sieht eine Einwilligungsseite und entscheidet je nach Organisationsrichtlinie, ob er die angefragten Berechtigungen gewähren darf. Ein Angreifer kann eine scheinbar nützliche App erstellen, ihr einen vertraut wirkenden Namen geben und Beschäftigte zur Zustimmung verleiten. Danach erhält die Anwendung im zugelassenen Umfang Zugriffstokens.
Die Microsoft-Anmeldeseite selbst muss dabei nicht gefälscht sein. Das macht die Methode besonders tückisch: Selbst eine korrekt angezeigte Domain und ein erfolgreiches MFA-Verfahren beweisen noch nicht, dass die angeforderte Anwendung vertrauenswürdig ist. Die eigentliche Sicherheitsentscheidung betrifft die App-Identität, den Herausgeber und die konkret angefragten Rechte. Eine legitime technische Zustimmung kann inhaltlich eine gefährliche Fehlentscheidung sein.
Warum MFA und Passwortwechsel allein nicht helfen
Bei klassischem Credential Phishing versucht ein Angreifer, Kennwörter oder Sitzungstokens zu stehlen. Bei einem bösartigen Consent Grant liegt die Berechtigung dagegen direkt bei einer registrierten Anwendung. Microsoft weist darauf hin, dass normale Passwortänderungen und erneute MFA-Anmeldungen den Zugriff einer fremden App nicht automatisch entfernen. Der Zugriff muss über die betreffenden App- und Einwilligungsobjekte widerrufen werden.
Das bedeutet nicht, dass OAuth MFA vollständig „umgeht“ oder Sicherheitsmaßnahmen wertlos sind. Vielmehr nutzt der Angriff einen anderen autorisierten Mechanismus. Verteidiger müssen deshalb sowohl Benutzerkonten als auch Enterprise Applications und Service Principals kontrollieren. Die Berechtigungslandschaft eines Tenants ist eine zusätzliche Angriffsfläche, die in vielen klassischen Passwort-Audits übersehen wird.
Delegated Permissions und Application Permissions
Delegierte Berechtigungen erlauben einer App bestimmte Aktionen im Kontext eines angemeldeten Benutzers. Application Permissions können je nach App und Genehmigung unabhängig von einem konkreten Benutzer verwendet werden. Diese beiden Modelle unterscheiden sich in Wirkung, Einwilligungsanforderungen und Möglichkeiten zur Einschränkung. Ein Zugriff auf grundlegende Profildaten ist nicht mit breit angelegten Mail- oder Dateirechten gleichzusetzen.
Prüfen Sie konkrete Microsoft-Graph-Scopes und App-Rollen, statt nur ein allgemeines Häkchen „Zugriff erteilt“ zu betrachten. Manche Rechte verlangen eine Administratorzustimmung; andere können je nach Tenant-Policy durch den Benutzer genehmigt werden. Auch eine bereits früher bewilligte App kann nach Änderungen eine neue Risikobewertung erfordern. Die Berechtigungen müssen sich an der tatsächlichen Geschäftsaufgabe orientieren.
Verifizierter Publisher: wichtig, aber keine Sicherheitsgarantie
Microsoft empfiehlt, Benutzerzustimmungen auf Anwendungen von verifizierten Herausgebern und ausgewählte niedrig riskante Berechtigungen einzuschränken. Die Verifizierung hilft, die Identität eines Herausgebers besser einzuordnen. Sie garantiert jedoch nicht, dass eine App frei von Fehlern, kompromittierten Konten oder missbräuchlichen Funktionen ist. Unternehmen sollten deshalb zusätzlich die benötigten Berechtigungen und den fachlichen Eigentümer prüfen.
Ein pauschales Vertrauen in einen bekannten Namen ist besonders gefährlich bei Integrationen, die sensible Mailboxen oder große SharePoint-Bibliotheken erreichen. Nutzen Sie eine dokumentierte App-Freigabe mit Sicherheitsprüfung und Verantwortlichkeit. Auch wenn die technische Freigabe bereits früher erteilt wurde, sollte sie bei Änderungen der App, der Rechte oder des Geschäftsprozesses erneut geprüft werden.
User Consent sicher beschränken
Microsoft Entra bietet Einstellungen für User Consent und App Consent Policies. Administratoren können verhindern, dass Beschäftigte beliebigen externen Apps umfangreiche Berechtigungen erteilen. Abhängig von Version und Lizenz lassen sich Regeln auf überprüfte Publisher und klassifizierte Berechtigungstypen begrenzen. Die konkrete Konfiguration erfolgt im Entra Admin Center unter Enterprise Applications und Consent and Permissions.
Eine globale Sperre aller Benutzerzustimmungen kann geschäftliche Abläufe beeinträchtigen, wenn notwendige Anwendungen nicht vorbereitet wurden. Deshalb sollten Unternehmen bestehende Integrationen inventarisieren und ein genehmigtes Verfahren für neue Anfragen bereitstellen. Eine restriktive Policy ist dann wirksam, wenn berechtigte Nutzer weiterhin einen verständlichen, zeitnahen Freigabeweg besitzen. Sonst entstehen Schattenlösungen außerhalb des dokumentierten Prozesses.
Admin Consent Workflow als kontrollierter Freigabeprozess
Mit dem Admin Consent Workflow können Benutzer eine Genehmigung für neue Anwendungen anfordern, ohne selbst weitreichende Rechte vergeben zu können. Das IT-Team sieht den Antrag und kann Publisher, Berechtigungen und Geschäftszweck prüfen. Die Entscheidung sollte nicht nur nach App-Name und Logo erfolgen; relevant sind insbesondere benötigte Datenkategorien und der verantwortliche Hersteller.
Dokumentieren Sie pro Freigabe Antragsteller, Eigentümer, Zweck, Berechtigungsumfang und nächstes Review. Bei übermäßigen Forderungen kann eine Alternative mit geringeren Rechten sinnvoll sein. Ein zu großzügig eingerichteter Admin-Consent-Prozess kann neue Risiken schaffen, wenn Anträge ohne inhaltliche Prüfung automatisiert bestätigt werden. Freigabe ist eine Sicherheitsentscheidung, kein reiner Helpdesk-Klick.
Microsoft 365 Audit Logs auf Consent Grants überprüfen
Microsoft beschreibt die Suche nach verdächtigen Consent-to-Application-Ereignissen in Microsoft Purview Audit und weiteren Defender-Ansichten. Ein ungewöhnlicher neuer Service Principal, eine plötzlich vergebene Graph-Berechtigung oder eine Genehmigung durch einen unerwarteten Benutzer können Ermittlungsansätze liefern. Die genaue Verfügbarkeit historischer Protokolle hängt von Auditkonfiguration, Lizenz und Aufbewahrung ab.
Ein Sicherheitsteam sollte bekannte legitime Anwendungen von unbekannten oder unregelmäßig genutzten Apps unterscheiden. Prüfen Sie, welche Identität die Genehmigung erteilte, wann dies geschah und welche Daten die Anwendung dadurch erreichen konnte. Eine bloße Liste aller Enterprise Applications reicht nicht aus, um den Vorfallumfang zu klären. Historische Audit-Ereignisse helfen, die zeitliche Entwicklung und mögliche Datenzugriffe nachzuvollziehen.
Wie ein verdächtiger Grant sicher entfernt wird
Bei bestätigtem Missbrauch sollten die betroffenen Berechtigungen nach einem dokumentierten Incident-Verfahren widerrufen beziehungsweise die Anwendung und ihre Service-Principal-Zugänge deaktiviert werden. Microsoft beschreibt dafür administrative Wege über Entra ID. Je nach Fall sind ergänzende Maßnahmen notwendig, um bestehende Tokens und zugehörige Zugänge zu behandeln. Die konkrete Reaktion sollte sich am tatsächlichen Risiko orientieren.
Sichern Sie forensische Informationen, bevor relevante Objekte entfernt werden, soweit dies mit dem Schutz der Daten vereinbar ist. Prüfen Sie anschließend, welche Postfächer, Kontakte oder Dateien möglicherweise gelesen wurden. Ein Passwortwechsel kann zusätzlich sinnvoll sein, ersetzt aber nicht den Entzug der App-Berechtigung. Stimmen Sie Meldepflichten und rechtliche Auswirkungen mit den verantwortlichen Datenschutzstellen ab.
Least Privilege für interne App-Registrierungen
Auch selbst entwickelte Unternehmensapps können übermäßige Rechte besitzen. Ein Dienst, der nur einen ausgewählten Kalender lesen muss, sollte nicht vorsorglich vollständigen Zugriff auf alle Microsoft-365-Daten erhalten. Nutzen Sie getrennte Identitäten für Entwicklung und Produktion, passende Ressourcengrenzen und kurzlebige, kontrollierte Anmeldeverfahren. Prüfen Sie zusätzliche Exchange- oder SharePoint-spezifische Scoping-Mechanismen, wo diese unterstützt werden.
Ersetzen Sie langlebige Client Secrets nach Möglichkeit durch geeignete Zertifikate oder verwaltete Identitäten, wenn die Plattform das unterstützt. Überwachen Sie Änderungen an Credentials und privilegierten App-Rollen. Eine saubere App-Inventarisierung ist genauso wichtig wie ein Benutzerverzeichnis. Nur so ist nachvollziehbar, welcher technische Dienst auf welche Unternehmensdaten zugreifen darf.
Mitarbeiter für Consent-Phishing sensibilisieren
Schulungen sollten nicht nur vor Links und Passwortformularen warnen. Mitarbeitende müssen verstehen, dass eine echte Microsoft-Einwilligungsseite eine Sicherheitsentscheidung darstellen kann. Vermitteln Sie den Unterschied zwischen erfolgreicher Identitätsprüfung und dem Vertrauen in eine fremde Anwendung. Warnzeichen sind unerwartete Apps, unplausible Berechtigungen oder dringende Aufforderungen, einen neuen Dienst zu autorisieren.
Bieten Sie einen unkomplizierten Meldeweg an, wenn jemand versehentlich zugestimmt hat. Schnelle Transparenz hilft mehr als Schuldzuweisungen. Ein gut vorbereitetes IT-Team kann die betroffene App kontrollieren, Zugänge entziehen und mögliche Datenzugriffe bewerten. Die Melderoutine sollte regelmäßig getestet werden, damit Mitarbeiter bei Unsicherheit wissen, wen sie kontaktieren.
30-Tage-Checkliste für Entra-App-Sicherheit
Woche eins: User-Consent-Einstellungen, Enterprise Applications und auffällige OAuth-Berechtigungen inventarisieren. Woche zwei: Admin-Consent-Workflow und klare Freigaberollen etablieren. Woche drei: Audit-Ereignisse, Alerts und einen Test des Widerrufs einer ungefährlichen Pilot-App prüfen. Woche vier: Fachabteilungen schulen und Besitzer sowie Review-Termine für bestehende privilegierte Apps festlegen.
Als Kennzahlen eignen sich Apps ohne Verantwortliche, übermäßig berechtigte Registrierungen, unerklärte Einwilligungen und Zeit bis zum Entzug einer verdächtigen Berechtigung. Das Ziel besteht nicht darin, jede Cloud-Anwendung zu verbieten, sondern geschäftliche Integrationen mit nachvollziehbarer Identität, minimalen Rechten und kontrollierbaren Änderungen zu betreiben.
FAQ zu OAuth Consent Phishing 2026
Kann OAuth Consent Phishing ohne Passwortdiebstahl funktionieren?
Ja. Der Zugriff kann aus einer wirksam erteilten App-Einwilligung entstehen, ohne dass der Angreifer das Benutzerpasswort kennt.
Beendet ein Passwortwechsel den Zugriff der bösartigen App?
Nicht zuverlässig. Die App-Berechtigung muss separat widerrufen oder gesperrt werden.
Garantiert ein verifizierter Publisher die Sicherheit?
Nein. Verifizierung ist ein Signal zur Herausgeberidentität, aber keine vollständige Code- oder Berechtigungsprüfung.
Wo finde ich verdächtige Grants?
Unter anderem in Microsoft Entra Enterprise Applications und den entsprechenden Microsoft-Purview-Audit-Ereignissen.
Fazit: App-Identitäten als Sicherheitsgrenze behandeln
Gegen OAuth Consent Phishing 2026 helfen restriktive User-Consent-Regeln, kontrollierte Admin-Freigaben, minimal berechtigte Apps und belastbare Auditlogs. Eine sichere Microsoft-365-Umgebung verwaltet nicht nur Benutzerkonten, sondern auch die von ihnen autorisierten Anwendungen.
Weitere GORTNET-Beiträge
Für eine Sicherheitsprüfung von Microsoft Entra und den Unternehmensapps GORTNET kontaktieren.
Offizielle Microsoft-Dokumentation
- Microsoft: Protect Against Consent Phishing
- Microsoft: Detect and Remediate Illicit Consent Grants
- Microsoft: Manage User Consent
- Microsoft: Consent Management Overview
Stand 5. November 2026. Verfügbare Auditfunktionen und Freigaberichtlinien hängen von Tenant-Einstellungen und Lizenzen ab.