OAuth Consent Phishing:
MFA-Bypass in Microsoft 365

Was passiert gerade

Am 7. April 2026 veröffentlichte die italienische Cybersicherheitsbehörde ACN (Agenzia per la Cybersicurezza Nazionale) über CSIRT Italia das Bulletin BL01/260407, das eine gezielte Phishing-Kampagne auf Basis des OAuth 2.0 Device Code Grant-Flows gegen italienische Microsoft-365- und Entra-ID-Tenants dokumentiert. Es ist die jüngste Variante einer größeren Familie — des OAuth Consent Phishings — die in den letzten Monaten auch bei KMU im Inland in realen Vorfällen beobachtet wurde.

Das gemeinsame Merkmal ist die Fähigkeit, die MFA vollständig zu umgehen: Der Benutzer authentifiziert sich regulär auf der echten Microsoft-Seite, die MFA wird eingehalten, und das OAuth-Token wird nach der Authentifizierung für eine vom Angreifer kontrollierte Anwendung ausgestellt. Von diesem Moment an stoppen Passwortänderungen oder geschlossene Sitzungen den Zugriff nicht mehr: Es ist ein expliziter Grant-Widerruf im Tenant erforderlich.

Wie Consent Phishing funktioniert

Anders als das klassische Credential-Phishing fragt OAuth Consent Phishing nie nach dem Passwort. Der Mechanismus ist geradlinig:

• 1Köder — der Benutzer erhält eine E-Mail, die scheinbar von einem bekannten Dienst stammt (ein Produktivitätstool, ein Signaturdienst, eine Fachanwendung) mit einem Link zu einer App mit glaubwürdigem Branding.
• 2Authentische Microsoft-Seite — der Link leitet zu login.microsoftonline.com weiter. Die URL ist legitim, das Zertifikat ist gültig, die Seite ist die echte. Der Benutzer meldet sich mit seinen Zugangsdaten und der MFA an.
• 3Zustimmungsanfrage — nach der Authentifizierung erscheint die OAuth-Zustimmungsseite: Die App fordert Berechtigungen wie Mail.ReadWrite, Files.ReadWrite.All, offline_access. Die meisten Benutzer lesen die Berechtigungen nicht und klicken auf Akzeptieren.
• 4Token-Ausstellung — Microsoft stellt ein gültiges Access-Token und Refresh-Token aus. Der Angreifer erhält sie und greift über die Microsoft-Graph-APIs auf Postfach, Dateien und Tenant-Ressourcen zu — ohne Passwort und ohne MFA.
• 5Persistenz — der Scope offline_access ermöglicht die automatische Erneuerung des Access-Tokens. Die Angreifersitzung überlebt Passwortänderungen, Abmeldung und den Widerruf der Entra-ID-Sitzungen. Der App-Grant selbst muss widerrufen werden.

Device Code Grant: die Variante aus dem CSIRT-Bulletin

Das CSIRT-Bulletin BL01/260407 vom 7. April 2026 beschreibt eine spezifische Variante. Der Angreifer kontaktiert den Benutzer (per E-Mail, Nachricht oder Telefon), bittet ihn, die Seite aka.ms/devicelogin zu öffnen und einen Code einzugeben, der sich alle paar Minuten ändert. Das ist der Device Code Grant Flow, gedacht für IoT-Geräte oder Terminals ohne vollständige Tastatur (Smart-TVs, Konsolen, Drucker). Wenn der Benutzer bestätigt, autorisiert er faktisch einen Client des Angreifers.

Die Methode ist besonders wirksam, weil der Benutzer keinen verdächtigen Drittanbieter-App-Bildschirm sieht: Er gibt nur einen Code auf einer Microsoft-Domain ein. Die CSIRT-Empfehlung lautet, den Device Code Flow für Benutzer zu deaktivieren, die ihn nicht benötigen — über eine Conditional-Access-Richtlinie, die den Grant-Type urn:ietf:params:oauth:grant-type:device_code für alle nicht explizit autorisierten Clients blockiert.

Gegenmaßnahmen: Was in Entra ID zu konfigurieren ist

Keine Einzelmaßnahme löst das Problem. Es braucht ein koordiniertes Set an Konfigurationen, fast alle kostenlos, wenn der Tenant bereits eine Microsoft-365-Business-Standard-Lizenz hat:

• 1Benutzerzustimmung für Drittanbieter blockieren — in Entra ID, Enterprise Applications → Consent and permissions → User consent settings, auf Do not allow user consent setzen. Mit dem Admin consent workflow kombinieren, um legitime Apps nicht zu blockieren.
• 2Conditional Access — erfordert Entra ID Premium P1. Wesentliche Richtlinien: Blockierung von Zugriffen aus Ländern außerhalb der Whitelist, MFA-Pflicht für externe IPs, Blockierung des Device Code Flows für Benutzer, die ihn nicht benötigen, Blockierung veralteter Authentifizierungsclients.
• 3Token-Lifetime-Richtlinie — Access-Token auf 1 Stunde verkürzen (Standard: 60–90 Minuten, aber unbegrenzt erneuerbar). So muss sich der Angreifer ständig neu authentifizieren und das Zugriffsfenster nach einer Kompromittierung verengt sich.
• 4Defender for Office 365 Plan 2 — Safe Links analysiert Links vor dem Klick in einer Sandbox, Safe Attachments detoniert Anhänge. Die Presets Standard oder Strict aktivieren Dutzende von Anti-Phishing-Schutzmaßnahmen mit einem Klick. Email Security Gateway ACN fügt eine zusätzliche vorgelagerte Schicht hinzu.
• 5Automatische externe Weiterleitung blockieren — in der Exchange-Online-Outbound-Antispam-Richtlinie Automatic forwarding = Off setzen. Verhindert, dass ein Angreifer E-Mails über Weiterleitungsregeln an externe Domänen exfiltriert.
• 6Dedizierte Admin-Konten, ohne Postfach — Global Administratoren müssen Verwaltungskonten sein, getrennt von Arbeitskonten. Wenn Consent Phishing ein normales Konto trifft, umfasst der Schaden nicht die Kontrolle über den Tenant.
• 7Schulung zur Erkennung der Zustimmungsseite — die Microsoft-Zustimmungsseite ist echt und von einer legitimen Anmeldung visuell nicht zu unterscheiden. Benutzer müssen wissen, dass es sie gibt, und die angeforderten Berechtigungen lesen, bevor sie auf Akzeptieren klicken.

Monitoring: Wonach Sie in den Logs suchen

Das Purview Unified Audit Log von Microsoft 365 erfasst alle relevanten Ereignisse auch im Basisplan, mit 90 Tagen Aufbewahrung. Zu überwachende Ereignisse:

• Consent to application — jedes Mal, wenn ein Benutzer eine OAuth-App autorisiert. Eine Zustimmung für einen unbekannten Herausgeber mit hohen Berechtigungen ist das deutlichste Signal.
• New-InboxRule von ausländischer IP — Postfachregeln mit verschleierten Namen (Folgen von Punkten oder nicht-alphabetischen Zeichen) sind eine typische Signatur von BEC-Angriffen nach der Kompromittierung.
• UserLoggedIn aus unerwarteten Ländern — aktive Sitzungen von IPs in Ländern, in denen das Unternehmen nicht tätig ist, besonders wenn sie sich alle paar Stunden wiederholen (ein für automatisierte Skripte typisches Muster).
• SoftDelete und HardDelete — die Massenlöschung von E-Mails ist typisch für die Spurenbeseitigungsphase.

Protokolle allein reichen nicht: Echtzeit-Alarmierung ist erforderlich. Selbst eine einfache Microsoft-Sentinel-Regel oder eine automatische Benachrichtigung bei kritischen Ereignissen reduziert die mittlere Erkennungszeit von Wochen auf Stunden.

Operative Unterstützung

AtWorkStudio betreibt Microsoft-365-Tenants für KMU und öffentliche Verwaltungen seit 2000, von Piacenza aus. Wir sind zertifiziert nach ISO/IEC 27001, 27017, 27018 und ISO 9001, mit ACN-QC1-Qualifikation für drei Dienste im italienischen Cloud-Katalog für die öffentliche Verwaltung, darunter das Email Security Gateway und das unveränderliche Microsoft-365-Backup. Wir sind Mitglieder des Clusit (italienischer Verband für Informationssicherheit) und assoziiert bei Confindustria Piacenza im RICT-Cluster.

Wenn Ihr Microsoft-365-Tenant noch nicht gegen OAuth Consent Phishing gehärtet ist, können wir ein gezieltes Audit durchführen: Inventur der aktiven OAuth-Grants, Prüfung der User consent settings, Analyse der Conditional-Access-Richtlinien, Kontrolle des Outbound-Forwardings, Überprüfung der Defender-for-Office-365-Konfiguration und einen schrittweisen Remediation-Plan ohne Serviceunterbrechung.