Der Angriffsweg ist unspektakulär. Ein Nutzer erhält einen Link – per E-Mail, Chat, in einem geteilten Dokument oder in einem Ticketsystem. Der Link führt in einen echten OAuth-Autorisierungsablauf eines Cloud- oder SaaS-Anbieters. Die Anwendung wirkt harmlos: ein Produktivitäts-Connector, ein Reporting-Werkzeug, ein Workflow-Assistent. Weil die Sitzung bereits angemeldet ist, fühlt sich der Vorgang alltäglich an. Der Zustimmungsdialog fordert Berechtigungen an, der Nutzer bestätigt.

Ab diesem Punkt benötigt der Angreifer kein Passwort mehr. Je nach Anbieter, App-Typ, Mandantenrichtlinie und erteilten Scopes kann er Token oder App-Freigaben erhalten, die dauerhaften API-Zugriff ermöglichen – so lange, bis die Berechtigungen widerrufen oder die Token ungültig gemacht werden. Damit lassen sich Daten abrufen, Postfächer durchsuchen, Dateien auflisten, Quellcode extrahieren, Repository-Einstellungen ändern, CI/CD-Metadaten einsehen oder Geschäftsplattformen über freigegebene Schnittstellen ansprechen.

OAuth selbst ist dabei nicht defekt, betont der Autor: Das Protokoll tue genau das, wofür es entworfen wurde – Zugriff delegieren. Problematisch sei der organisatorische Umgang damit. Zustimmungsentscheidungen fallen innerhalb vertrauenswürdiger Sitzungen; Sicherheitsteams sehen erfolgreiche Anmeldungen, legitime Domains und unauffälligen API-Verkehr. Endpunkt- und Netzwerkwerkzeuge schlagen nicht an, weil weder Schadsoftware noch klassische Command-and-Control-Kommunikation im Spiel ist. Selbst ausgereifte SIEM-Programme übersehen das Risiko, wenn sie nicht gezielt auf neue App-Freigaben, riskante Scopes, ungewöhnliche Token-Aktivität und Verhaltensänderungen im API-Verkehr nach der Zustimmung achten.

Anzeige

Als erste Gegenmaßnahme nennt der Beitrag Consent-Governance: Die standardmäßige Freigabe von Drittanwendungen durch Endnutzer sollte eingeschränkt werden, hochriskante Scopes eine Administratorfreigabe erfordern, unverifizierte oder unbekannte Apps blockiert oder in eine Prüfung überführt werden. Besonders strikte Regeln empfiehlt er für E-Mail, Dateispeicher, Versionskontrolle, CRM, Identitätssysteme, Cloud-Konsolen und Automatisierungsplattformen.

Zweitens geht es um Berechtigungsdisziplin. Eine Kalenderintegration braucht keinen breiten Dateizugriff, ein Reporting-Connector keine Administrationsrechte an Repositories, ein Workflow-Werkzeug keine organisationsweiten Rechte ohne klaren Geschäftsgrund und verantwortlichen Eigentümer. OAuth-Scopes sollten so streng geprüft werden wie Firewall-Regeln, privilegierte Rollen oder Produktionszugänge – spezifisch, begründet, dokumentiert und regelmäßig revalidiert.

Drittens fordert der Autor Monitoring nach der Zustimmung. Relevante Signale sind neue App-Consents, neue Service Principals oder Enterprise-Apps, die Freigabe hochprivilegierter Scopes, Autorisierungen aus ungewöhnlichen Regionen, Refresh-Token-Aktivität aus unbekannter Infrastruktur sowie API-Verhalten, das vom üblichen Muster abweicht. Wer sonst nur wenige Dokumente liest, plötzlich aber Massendownloads, Repository-Änderungen, Postfachsuchen oder CI/CD-Anpassungen durchführt, sollte eine Untersuchung auslösen – auch bei authentifizierter Sitzung.

Viertens: Widerrufsbereitschaft. Viele Organisationen erkennen verdächtige OAuth-Freigaben, haben aber keine eingespielten Prozesse, sie schnell zu entfernen. Playbooks sollten abdecken, wie die Anwendung identifiziert wird, wer zugestimmt hat, welche Scopes erteilt wurden, wie App-Grants widerrufen und Refresh-Token invalidiert werden, wie offengelegte Geheimnisse rotiert und nachgelagerte Aktivitäten in verbundenen SaaS-Systemen geprüft werden. Dieser Ablauf gehört vor den Ernstfall getestet.

Auch Nutzerschulungen müssten konkreter werden: Der Hinweis, die URL zu prüfen, hilft nicht, wenn die URL legitim ist. Die bessere Frage laute nicht „Ist das Microsoft, Google, GitHub oder Salesforce?“, sondern: „Warum braucht diese App diese Berechtigung, wer hat sie veröffentlicht, und hat meine Organisation sie freigegeben?“ Der nächste Einbruch beginne womöglich nicht mit einer fehlgeschlagenen Anmeldung, sondern mit einer erfolgreichen – und einem unbedachten Klick auf „Zulassen“.