Google Workspace: Ein Angriff kann bei OAuth beginnen – nicht bei der E-Mail

Die neue Angriffskette: zuerst das Token, dann Gmail

Eine am 14. August 2026 veröffentlichte Analyse legt nahe, dass sich die Sicherheitsverletzungen im Zusammenhang mit Vercel und Composio auf ein gemeinsames Muster zurückführen lassen: Der Zugriff auf Google Workspace beginnt nicht zwangsläufig mit dem E-Mail-Postfach, sondern kann von einem kompromittierten OAuth-Token oder einer autorisierten Integration ausgehen.

Diese Unterscheidung verändert das traditionelle Modell der Account-Übernahme. Früher bestand die häufigste Abfolge aus einer Phishing-Nachricht, dem Diebstahl von Zugangsdaten, dem Zugriff auf Gmail und Drive und schließlich der lateralen Bewegung zu weiteren Diensten. In diesem Szenario kann der Angreifer dagegen über eine verbundene Anwendung in die Umgebung gelangen und erst danach auf die E-Mail zugreifen.

E-Mail bleibt damit zentral, aber nicht immer als Einstiegspunkt. Sobald ein Angreifer Zugriff erhält, kann sie den Vorfall erheblich verstärken: Sie enthält häufig Links zum Zurücksetzen von Passwörtern, Magic Links, in Konversationen gespeicherte Zugangsdaten und Verweise auf interne Anwendungen.

Die Analyse stammt von Rajan Kapoor, VP Security bei Material Security, dem Unternehmen, das die Veröffentlichung initiiert hat. Technische Details zu den Vorfällen bei Vercel und Composio wurden nicht veröffentlicht. Es liegen weder CVE-Kennungen noch zugeordnete Kampagnen oder bekannte Bedrohungsgruppen vor.

Warum OAuth ein Zurücksetzen des Passworts überstehen kann

Ein OAuth-Token ermöglicht einer Anwendung, im Namen des Benutzers auf Grundlage der in den Scopes festgelegten Berechtigungen zu agieren. Wird das Token gestohlen, kann der Angreifer damit auf die freigegebenen Ressourcen zugreifen, ohne das Passwort kennen zu müssen.

Das stellt Sicherheitsteams vor ein operatives Problem. Das Zurücksetzen des Passworts reicht möglicherweise nicht aus, um den Zugriff zu unterbrechen, da das Token weiterhin gültig sein kann. Der Analyse zufolge können einige Token zudem keine klar erkennbare Ablaufzeit besitzen und schwer zu identifizieren sein, wenn eine Organisation lediglich Logins, Passwörter und Benutzeraktivitäten überwacht.

Das Risiko steigt, wenn das Token zu einer Drittanbieteranwendung gehört. Eine Kompromittierung des Anbieters oder der Integration kann sich zu einem Supply-Chain-Angriff entwickeln und einen scheinbar legitimen Zugriff auf die Unternehmensumgebung ermöglichen.

Die vermutete Angriffskette umfasst mehrere Schritte:

1. Ein OAuth-Token wird kompromittiert.
2. Der Angreifer nutzt die von der Anwendung gewährten Scopes.
3. Gmail und Drive werden zugänglich.
4. Das Konto wird angegriffen, ohne dass zunächst ein Passwort gestohlen werden muss.
5. Inhalte aus E-Mails und Dokumenten werden genutzt, um weitere Systeme zu erreichen.
6. Daten werden gesammelt oder an Dritte übertragen.

Besonders schwer zu erkennen ist die formale Legitimität des Zugriffs. Die Anwendung kann autorisiert und das Token gültig sein, ohne dass der Benutzer in seinem Konto offensichtliche Warnsignale wahrnimmt.

KI-Agenten verwandeln Berechtigungen in automatische Aktionen

Dasselbe Muster kann auch ohne ein gestohlenes Token auftreten. Immer mehr Benutzer verbinden KI-Agenten über OAuth mit Google Workspace und geben ihnen damit die Möglichkeit, E-Mails zu lesen, Dokumente in Drive zu suchen und im Namen realer Personen zu handeln.

Ein Agent kann somit auf Daten und Dienste zugreifen, die durch die zugewiesenen Scopes freigegeben sind. Das Problem beschränkt sich nicht auf bösartiges Verhalten oder Prompt Injection. Ein System kann wie vorgesehen funktionieren und dennoch über unverhältnismäßig weitreichende Berechtigungen für die jeweilige Aufgabe verfügen.

Ein Agent, der Informationen aus einem Postfach abrufen soll, könnte beispielsweise auch Konversationen mit Zugangsdaten oder Dokumente in geteilten Drives durchsuchen. Trifft er auf mehrdeutige Anweisungen, manipulierte Inhalte oder eine von den Entwicklern nicht vorgesehene Entscheidungskette, kann er diese Informationen für weitere Aktionen verwenden.

Die Angriffskette kann Folgendes umfassen:

• Lesen von Nachrichten oder Ordnern außerhalb des erforderlichen Umfangs;
• Auffinden von Zugangsdaten, personenbezogenen Daten oder vertraulichen Informationen;
• Öffnen von Links und Senden von Anfragen an andere Dienste;
• Wechsel von einer Anwendung zu einer anderen;
• Übertragung von Daten an Dritte.

In diesem Fall muss ein Angreifer den Agenten nicht unbedingt direkt kontrollieren. Das Risiko entsteht durch das Zusammenspiel zu weitreichender Berechtigungen, in der Umgebung vorhandener Inhalte und der Fähigkeit des Systems, Aktionen automatisch auszuführen.

Ein menschlicher Mitarbeiter mit denselben Berechtigungen kann vor der Verwendung einer Information interne Richtlinien und gesunden Menschenverstand berücksichtigen. Ein Agent führt die Aufgabe dagegen tendenziell auf Grundlage der verfügbaren Anweisungen und Zugriffsrechte aus. Ein einer Person zugewiesenes OAuth-Token und ein Token für ein automatisiertes System können daher ähnliche Berechtigungen gewähren, aber auf sehr unterschiedliche Weise eingesetzt werden.

Gmail und Drive werden zu Ausgangspunkten für die Ausweitung des Angriffs

In diesem Modell sind Gmail und Drive nicht nur Informationsspeicher. Sie werden zu Infrastrukturen für laterale Bewegungen.

Eine Nachricht kann einen Link zum Zurücksetzen eines Passworts enthalten. Ein Dokument kann einen Zugriffsschlüssel, eine Arbeitsanweisung oder einen Verweis auf einen internen Dienst enthalten. Ein geteilter Drive kann Daten für mehr Benutzer und Anwendungen zugänglich machen als vorgesehen.

Die Folge: Eine scheinbar begrenzte Kompromittierung kann sich schnell ausweiten. Der Zugriff auf eine autorisierte Anwendung ermöglicht das Lesen von Inhalten. Diese Inhalte können anschließend die Mittel liefern, um weitere Konten und Systeme zu erreichen.

Das potenzielle Ausmaß umfasst E-Mails, Unternehmensdokumente, Zugangsdaten, personenbezogene Informationen und Daten aus verbundenen Anwendungen. Automatisierung kann Geschwindigkeit und Umfang der Operationen erhöhen, insbesondere wenn KI-Tools dabei helfen, nützliche Informationen zu identifizieren und über mehrere Dienste hinweg zu kombinieren.

Die Quelle nimmt keine formale Einstufung des Schweregrads vor und nennt keine zu suchenden Indicators of Compromise. Ebenso werden weder betroffene Softwareversionen noch bestimmte verwundbare Produkte oder Fristen für die Behebung genannt. Der Fall betrifft das Zugriffs- und Kontrollmodell, nicht eine durch eine CVE erfasste Schwachstelle.

So lässt sich das Risiko in einer Workspace-Umgebung reduzieren

Die Abwehr sollte sich nicht nur auf Phishing-Filter oder den Schutz einzelner Benutzerkonten konzentrieren. Der erste Schritt besteht darin, Anwendungen, OAuth-Token und tatsächlich gewährte Scopes zu erfassen und auch das Verhalten der Integrationen im Zeitverlauf zu überprüfen.

Es reicht nicht zu wissen, dass eine Anwendung autorisiert ist. Es muss beobachtet werden, welche Daten sie liest, wie häufig sie dies tut, auf welche Benutzer sie zugreift und ob sich ihre Aktivitäten gegenüber dem erwarteten Verhalten verändern. Ein ungewöhnlicher Zugriff kann sowohl auf die Nutzung eines gestohlenen Tokens als auch auf einen legitimen Agenten hinweisen, der über seine eigentliche Aufgabe hinaus agiert.

Erforderlich sind außerdem Kontrollen für die Daten:

• E-Mails mit Zugangsdaten, personenbezogenen Daten und Wiederherstellungslinks identifizieren;
• die Zugänglichkeit geteilter Drives überprüfen;
• nicht erforderliche OAuth-Scopes reduzieren;
• das Prinzip der geringsten Rechte auf Benutzer, Anwendungen und automatisierte Agenten anwenden;
• plötzliche Veränderungen bei den Aktivitäten von Integrationen überwachen.

E-Mail erfordert einen spezifischen Schutz. Neben der Abwehr von Phishing, ausweichenden Payloads und Attacker-in-the-Middle-Angriffen sollte verhindert werden, dass ein kompromittiertes Postfach automatisch zu einem operativen Archiv für den Angreifer wird. Besonders sensible Inhalte können maskiert oder vor dem Zugriff einer zusätzlichen Step-up-Prüfung unterzogen werden.

Dasselbe Prinzip muss für KI-Agenten gelten. Ein System, das Informationen in E-Mails suchen darf, sollte ohne zusätzliche Kontrollen keine Zugangsdaten, Reset-Links oder für seine Aufgabe nicht erforderlichen Daten abrufen können.

Die Überwachung muss schließlich E-Mail-, OAuth-, Drive- und Kontenereignisse zusammenführen. Eine getrennte Überwachung dieser Bereiche lässt die Übergänge zwischen Anwendungen unentdeckt – genau jene Übergänge, durch die ein legitimes oder kompromittiertes Token einen ersten Zugriff in Datenexfiltration und laterale Bewegungen verwandeln kann.