Die Plattform EvilTokens, die nach dem Modell „Phishing-as-a-Service“ (PhaaS) arbeitet, nutzt laut Angaben der Cloud Security Alliance den Mechanismus OAuth device code flow in Microsoft 365 aus, um langlebige Refresh Tokens zu erhalten. Die Opfer durchlaufen eine legitime Authentifizierung mit MFA auf einer echten Microsoft-Domain, übermitteln dabei aber unbewusst dem Angreifer ein Token mit Zugriff auf E-Mail, Dateien, Kalender und Kontakte. Multi-Faktor-Authentifizierung kann diese Attacke nicht blockieren, da sie zum Zeitpunkt der Token-Ausgabe bereits erfolgreich abgeschlossen ist. Organisationen, die Microsoft 365 einsetzen, müssen ihre Richtlinien zur Verwaltung von OAuth-Zustimmungen und Tokens überarbeiten.

Angriffsmechanismus: Device Code Flow als Vektor

Der Angriff nutzt einen regulären Authentifizierungsmechanismus von Microsoft — den device code flow, der für Geräte ohne vollwertigen Browser vorgesehen ist. Das Opfer erhält eine Nachricht mit der Aufforderung, einen kurzen Code auf der Seite microsoft.com/devicelogin einzugeben und die standardmäßige MFA-Prüfung zu durchlaufen. Aus Sicht des Nutzers wirkt dies wie eine gewöhnliche Anmeldebestätigung.

Nach Abschluss der Authentifizierung stellt das System jedoch nicht dem Benutzer, sondern dem Betreiber der EvilTokens-Plattform ein Refresh Token aus. Wie in der Research Note der CSA berichtet wird, ist dieses Token:

• von einem legitimen Microsoft-Identity-Provider signiert
• für den Zugriff auf Postfach, OneDrive, Kalender und Kontakte gültig
• mit einer Lebensdauer versehen, die durch die Richtlinie des Tenants, nicht durch die Sitzung bestimmt wird
• vermutlich selbst nach einem Zurücksetzen des Benutzerpassworts weiterhin gültig

Das Kernproblem: Der Angreifer fängt keine Zugangsdaten ab und reproduziert keine Sitzung. Das Token ist das Resultat der regulären Arbeitsweise des Systems. Das Anmeldeereignis in den Logs wirkt legitim, da die Authentifizierung tatsächlich auf einer echten Microsoft-Domain mit einem echten zweiten Faktor erfolgt ist.

Warum MFA hier nicht schützt

Beim klassischen Credential-Phishing müssen Zugangsdaten erneut eingegeben werden, und genau an dieser Stelle baut MFA eine Hürde auf. Selbst Angriffe vom Typ „Adversary-in-the-Middle“ (AiTM) hinterlassen in den Logs Session-Cookies, die SIEM-Systeme mit Geografie und Endgerät korrelieren können.

Beim Consent-Phishing über OAuth schließt der Benutzer die Authentifizierung selbst beim legitimen Provider ab. MFA greift und wird erfolgreich durchlaufen — vor der Ausgabe des Tokens. Das Token, das der Angreifer erhält, ist kein Ergebnis einer Kompromittierung, sondern das Ergebnis einer vom Benutzer erteilten Zustimmung. Nach Angaben der Forscher reicht zum Widerruf eines solchen Zugriffs ein bloßer Passwortwechsel nicht aus: Es ist ein expliziter Token-Widerruf oder eine Conditional-Access-Richtlinie erforderlich, die eine erneute Zustimmung verlangt.

Normalisierung von Consent als Risikofaktor

Der Angriffsvektor über OAuth-Consent existiert seit Langem, seine Wirksamkeit hat sich jedoch durch verändertes Nutzerverhalten drastisch erhöht. Jeder AI-Agent, jede Integrationslösung zur Produktivitätssteigerung, jede Browser-Erweiterung, die mit SaaS-Accounts arbeitet, fordert ein OAuth-Consent an. Das Volumen legitimer Zustimmungsanfragen, mit denen ein Mitarbeiter im Monat konfrontiert ist, übersteigt deutlich das Niveau, das in den ursprünglichen Bedrohungsmodellen von OAuth vorgesehen war.

Die Formulierungen der angeforderten Berechtigungen verschärfen das Problem zusätzlich. Der Scope „Lesen Ihrer E-Mails“ umfasst in der Praxis alle Nachrichten, Anhänge und freigegebenen Konversationsthreads. Der Scope „Zugriff auf Dateien, wenn Sie offline sind“ bedeutet die Ausgabe eines langlebigen Tokens, das ohne Anwesenheit des Benutzers gültig bleibt. Die Lücke zwischen der Sprache des Consents und dem tatsächlichen Umfang des Zugriffs ist genau der Raum, in dem Angreifer operieren.

Toxische Kombinationen von Berechtigungen

Ein einzelner OAuth-Grant verschafft dem Angreifer nur ein begrenztes Standbein in einer Anwendung. Systemisches Risiko entsteht, wenn mehrere Grants über eine Benutzeridentität zusammenlaufen. Beispiel: Ein Mitarbeiter der Finanzabteilung gewährt einem AI-Assistenten Zugriff auf Kalender und E-Mail, einem anderen Tool Zugriff auf den Unternehmensspeicher, einem dritten auf die CRM-Kundendatenbank. Jede Zustimmung wird separat erteilt, kein einzelner Application Owner hat die Gesamtheit dieser Berechtigungen abgesegnet. Die Kompromittierung eines dieser Tools kann potenziell über dieselbe Identität den Zugang zu Verträgen und Kundendaten eröffnen.

Dieses Risiko ist in keinem einzelnen Anwendungs-Auditlog sichtbar, da die Verbindung zwischen ihnen auf Identitätsebene entsteht und außerhalb des Perimeters der jeweiligen Anwendung liegt. Analysten stellen fest, dass Server des Model Context Protocol (MCP) eine ähnliche Angriffsoberfläche bilden, indem sie AI-Agenten über denselben Mechanismus einmaliger Zustimmung Zugriff gewähren.

Praktische Empfehlungen

Zum Schutz vor Consent-Phishing über OAuth muss die Kontrolle von der Ebene der Authentifizierung auf die Ebene der Zustimmung verlagert werden:

1. Registrierung von Anwendungen in Entra ID einschränken: Benutzern untersagen, Anwendungen eigenständig Zugriff zu gewähren. Einen administrativen Genehmigungs-Workflow für alle OAuth-Grants einrichten, die Zugriff auf E-Mail, Dateien und Kalender anfordern.
2. Conditional-Access-Richtlinien für Tokens konfigurieren: die Lebensdauer von Refresh Tokens verkürzen, eine erneute Authentifizierung für besonders schützenswerte Ressourcen verlangen und Richtlinien für Continuous Access Evaluation konfigurieren.
3. Audit bestehender OAuth-Grants durchführen: in Entra ID den Bereich „Unternehmensanwendungen“ → „Zustimmungen und Berechtigungen“ prüfen. Anwendungen mit weitreichenden Scopes (Mail.Read, Files.ReadWrite.All, offline_access) identifizieren und ungenutzte oder verdächtige Grants widerrufen.
4. Device Code Flow deaktivieren: falls dieser Authentifizierungsmechanismus für Geschäftsprozesse nicht erforderlich ist, ihn über Conditional-Access-Richtlinien blockieren. Damit wird der konkrete Vektor beseitigt, den EvilTokens nutzt.
5. Consent-Ereignisse überwachen: SIEM-Benachrichtigungen für die Erteilung von OAuth-Grants einrichten, insbesondere für Anwendungen, die außerhalb des Tenants registriert sind, sowie für Grants mit breiten Scopes.
6. Überschneidungen von Grants inventarisieren: Benutzer identifizieren, deren OAuth-Zustimmungen in Summe Brücken zwischen kritischen Systemen (E-Mail + Speicher + CRM) bilden, und das daraus entstehende Gesamtrisiko bewerten.

Consent-Phishing über OAuth ist keine theoretische Bedrohung, sondern ein real genutzter Angriffsvektor, für den es eine kommerzielle Infrastruktur gibt. Die derzeit wichtigste Maßnahme ist, Benutzern zu untersagen, eigenständig OAuth-Zustimmungen zu erteilen in Microsoft 365, und alle bestehenden Grants mit weitreichenden Scopes zu überprüfen. Organisationen, die weiterhin ausschließlich auf MFA als Grenze für den Identitätsschutz setzen, lassen genau jene Schicht offen, durch die moderne Angriffe verlaufen.