Der Unterschied zum klassischen Phishing liegt in der Mechanik. Ein abgegriffenes Passwort muss irgendwo erneut eingespielt werden, und die meisten Identitätssysteme verlangen an dieser Stelle einen zweiten Faktor. Selbst Adversary-in-the-Middle-Baukästen erzeugen ein Session-Cookie, das an ein Anmeldeereignis gebunden ist – ein SIEM kann es gegen Geografie, Gerät und Reisemuster abgleichen.

Ein OAuth-Grant hinterlässt nichts davon. Der Nutzer authentifiziert sich beim legitimen Identitätsanbieter, schließt die MFA-Abfrage auf der echten Domain ab und klickt auf „Akzeptieren". Das Token, mit dem der Angreifer abzieht, ist das System, das wie vorgesehen arbeitet: signiert vom Identitätsanbieter, auf die zugestimmten Berechtigungen begrenzt und erneuerbar. MFA kann es nicht blockieren, weil MFA bereits stattgefunden hat.

Hinzu kommt die lange Wirkdauer. Die von EvilTokens ausgestellten Tokens überdauerten Passwort-Resets und blieben je nach Mandantenkonfiguration Wochen oder Monate gültig. Erst eine ausdrückliche Entziehung oder eine Conditional-Access-Richtlinie, die eine erneute Zustimmung verlangt, beendet den Zugriff.

Der Angriffsweg existiert, seit OAuth zum Standard wurde – verändert hat sich das Umfeld. Nutzer klicken Zustimmungsdialoge inzwischen so routiniert weg wie früher Cookie-Banner. Jeder KI-Agent, jede Produktivitätsintegration und jede Browser-Erweiterung mit SaaS-Zugriff blendet einen solchen Dialog ein. Auch die Sprache der Berechtigungen verschleiert das Risiko: Ein Scope namens „Ihre E-Mails lesen" klingt eng, deckt praktisch aber jede Nachricht, jeden Anhang und jeden geteilten Verlauf ab. „Auf Dateien zugreifen, während Sie abwesend sind" bedeutet ein langlebiges Token, das ausgestellt wird, ohne dass jemand am Bildschirm sitzt, um es zu widerrufen.

Besonders gefährlich wird es, wenn sich einzelne Zugriffe verketten. Ein Finanzmitarbeiter gewährt einem KI-Meeting-Zusammenfasser Zugriff auf Kalender und Postfach, später einem Produktivitätsassistenten Zugriff auf das gemeinsame Laufwerk, schließlich verbindet ein drittes Werkzeug ein CRM mit der Kundendatenbank. Jede Freigabe wurde einzeln erteilt, keine Anwendung hat die Kombination abgesegnet. Dieses Muster wird als „toxische Kombination" bezeichnet: ein Berechtigungsbruch quer über Anwendungen hinweg, überbrückt durch einen OAuth-Grant, eine Integration oder einen KI-Agenten – sichtbar in keinem einzelnen Audit-Log, weil die Brücke außerhalb aller Anwendungen liegt.

Als nächste Angriffsfläche dieser Art gelten Model-Context-Protocol-Server (MCP), über die Agenten denselben „einmal vertrauen"-Mechanismus nutzen wie Consent-Dialoge. Welches Ausmaß das annehmen kann, zeigte der Vorfall um Salesloft-Drift im Jahr 2025: Ein kompromittierter Connector breitete sich über legitim genehmigte OAuth-Tokens auf mehr als 700 Salesforce-Mandanten aus. Jeder Kunde hatte die Integration autorisiert – niemand die Kettenreaktion.

Als Gegenmaßnahme verweist der Quelltext auf eine neue Klasse von Plattformen, die OAuth-Grants, KI-Agenten und Drittanbieter-Integrationen unmittelbar bei der Ausstellung in einen Identitätsgraphen abbilden und Brücken, ungenutzte Tokens sowie Richtlinienabweichungen fortlaufend aufzeigen. Als Beispiel wird Reco genannt, dessen „Identity Knowledge Graph" menschliche und nicht-menschliche Identitäten mit den Anwendungen und Grants verknüpft, auf die sie zugreifen können, und Zugriffe auf Token-Ebene statt auf Kontoebene entzieht.