Im Februar 2026 ging die **EvilTokens**-Plattform live und demonstrierte schnell die Gefahren unkontrollierter OAuth-Einwilligungen. Ziele wurden dazu verleitet, einen Code auf `microsoft.com/devicelogin` einzugeben und eine MFA-Herausforderung zu absolvieren, wodurch Angreifer unwissentlich einen Refresh-Token mit weitreichenden Berechtigungen erhielten, einschließlich des Zugriffs auf Mailboxen, Laufwerke, Kalender und Kontakte. Dieser Token blieb gemäß der Mandantenrichtlinie bestehen und übertraf damit bei weitem die Lebensdauer einer typischen Sitzung. Dieser Angriff umgeht traditionelle Sicherheitsmaßnahmen, da er keine gestohlenen Passwörter oder verdächtigen Anmeldeereignisse beinhaltet. Stattdessen nutzt er die Normalisierung von OAuth-Einwilligungsbildschirmen aus, bei denen Benutzer oft instinktiv auf 'Akzeptieren' klicken, ohne die gewährten Berechtigungen vollständig zu verstehen. ## Warum MFA bei Missbrauch von OAuth-Berechtigungen versagt Traditionelles Credential Phishing setzt auf die Wiedergabe gestohlener Benutzernamen und Passwörter, was MFA-Aufforderungen auslöst und eine Spur für Security Information and Event Management (SIEM)-Systeme zur Erkennung hinterlässt. Missbrauch von OAuth-Berechtigungen erzeugt jedoch keine solche Wiedergabe. Der Benutzer authentifiziert sich beim legitimen Identitätsanbieter, schließt MFA ab und erteilt die Einwilligung. Der resultierende Token ist gültig, vom Identitätsanbieter signiert und kann aktualisiert werden, was MFA zur Blockierung des Angriffs unwirksam macht. <table><tbody><tr><td></td></tr><tr><td>Abbildung 1: Credential Phishing hinterlässt eine Anmeldespur, die das SIEM korrelieren kann.</td></tr></tbody></table> <table><tbody><tr><td></td></tr><tr><td>Abbildung 2: Eine OAuth-Berechtigung hinterlässt keine Wiedergabe, nur einen aktualisierbaren Token.</td></tr></tbody></table> Darüber hinaus blieben von **EvilTokens** ausgestellte Refresh-Tokens auch nach Passwortzurücksetzungen gültig und blieben je nach Mandantenkonfiguration wochen- oder monatelang bestehen. Nur eine explizite Widerrufung oder bedingte Zugriffrichtlinien, die eine erneute Einwilligung erfordern, konnten die Berechtigung beenden. ## Die Normalisierung der Einwilligung Der OAuth-Einwilligungsangriffsvektor ist nicht neu, aber seine Wirksamkeit hat aufgrund der Desensibilisierung der Benutzer zugenommen. Benutzer werden mit Einwilligungsbildschirmen von KI-Agenten, Produktivitätsintegrationen und Browser-Erweiterungen bombardiert, was zu einer Klickmentalität führt, die mit Cookie-Bannern vergleichbar ist. Die in den Einwilligungsumfängen verwendete Sprache verschleiert oft das wahre Ausmaß der gewährten Berechtigungen. Beispielsweise kann 'Ihre E-Mails lesen' jede Nachricht, jeden Anhang und jeden geteilten Thread umfassen. Diese Diskrepanz zwischen der Einwilligungssprache und der operativen Reichweite wird von Angreifern ausgenutzt. ## Toxische Kombinationen: Risikoübergreifende Anwendungen Die eigentliche Gefahr liegt in der Kombination mehrerer OAuth-Einwilligungen über verschiedene Anwendungen hinweg, was Forscher als "toxische Kombinationen" bezeichnen. Beispielsweise schafft ein Finanznutzer, der einem KI-Meeting-Zusammenfasser Zugriff auf seinen Kalender und seine Mailbox gewährt, und dann einem Produktivitätsassistenten Zugriff auf das freigegebene Laufwerk des Unternehmens gewährt, eine Angriffsfläche, auf der eine Kompromittierung in einer Anwendung auf andere übergreifen kann. <table><tbody><tr><td></td></tr><tr><td>Abbildung 3: Eine toxische Kombination zwischen zwei SaaS-Apps, die kein Eigentümer gemeinsam genehmigt hat.</td></tr></tbody></table> Der **Salesloft**-**Drift**-Vorfall im Jahr 2025 verdeutlichte dieses Risiko im großen Maßstab. Ein kompromittierter nachgelagerter Konnektor verbreitete sich über legitime OAuth-Tokens in über 700 **Salesforce**-Mandanten und zeigte die kaskadierenden Auswirkungen kompromittierter Integrationen. ## Proaktive Maßnahmen zur Minderung von OAuth-Risiken Organisationen müssen OAuth-Einwilligungen mit der gleichen Strenge behandeln wie die Authentifizierung. Wichtige Bereiche, die überprüft werden müssen, sind: * **OAuth-Anwendungsbestand:** Kontinuierliche Überwachung aller Drittanbieter-Apps, die Refresh-Tokens halten. * **Alter der Berechtigungen und erneute Einwilligung:** Kennzeichnung von lange ausgestellten Tokens ohne erneute Einwilligung. * **Identitäten übergreifend für Anwendungen:** Identifizierung von Identitäten, die Berechtigungen für mehrere SaaS-Anwendungen halten. * **Agenten- und Integrationsbrücken:** Erkennung von KI-Agenten und Integrationen, die Systeme ohne ausdrückliche Genehmigung verbinden. * **Bedingter Zugriff auf Einwilligungen:** Implementierung von Richtlinien, die durch Einwilligungsereignisse ausgelöst werden, nicht nur durch Anmeldeereignisse. * **Token-basierte Widerrufung:** Erstellung von Playbooks zur Widerrufung einzelner OAuth-Tokens. Diese Maßnahmen erfordern eine Plattform, die die Laufzeitschicht, auf der diese Brücken entstehen, kontinuierlich überwachen kann, da allein prozedurale Disziplin nicht ausreicht, um die Geschwindigkeit zu bewältigen, mit der diese Risiken entstehen. ## KI-Sicherheitsplattformen Eine neue Klasse von Plattformen entsteht, um einen Großteil dieses Prozesses zu automatisieren, indem OAuth-Berechtigungen, KI-Agenten und Drittanbieter-Integrationen abgebildet werden, um eine umfassende Sichtbarkeit und Kontrolle über die OAuth-Landschaft zu bieten.