Verdächtige OAuth-App in Google Workspace untersuchen

Kurz gesagt. Eine unrechtmäßige Einwilligung ist Phishing, das um Erlaubnis bittet statt um ein Passwort. Der Nutzer klickt auf „Zulassen“, und eine vom Angreifer kontrollierte App erhält für sein Postfach oder Drive ein Token, das einen Passwort-Reset übersteht. Suchen Sie im OAuth-Token-Log nach authorize-Ereignissen mit Gmail-, Drive- oder Admin-Scopes, unbekannten App-Namen, Freigaben von einer riskanten IP und activity-Ereignissen, die zeigen, wie die App in großem Umfang Mails liest. Widerrufen Sie das Token, blockieren Sie die Client-ID für die ganze Organisation und grenzen Sie dann ein, was die App gelesen hat.

Der OAuth-Weg ist attraktiv, weil er das meiste umgeht, worauf Verteidiger achten. Es wird kein Passwort gestohlen, die 2SV gilt nicht für API-Aufrufe, und der Zugang bleibt bestehen. MITRE führt den Diebstahl solcher Tokens als T1528 Steal Application Access Token und das Abgreifen von Mails darüber als T1114.002 Remote Email Collection.

Was das OAuth-Token-Log aufzeichnet

Googles Seite OAuth log events und der Anhang zu Token-Ereignissen beschreiben die Ereignisse:

Google nennt für dieses Log eine Verzögerung von ein paar Stunden (Tabelle der Verzögerungen). Exportieren Sie eine Stunde nach dem Klick, fehlt die Freigabe womöglich noch.

Ein authorize-Ereignis bewerten

Fünf Fragen, der Reihe nach:

1. Welche Scopes? Die Scope-Liste erzählt die ganze Geschichte.

   Scope	Reichweite	Schwere im Analyzer
   https://mail.google.com/, gmail.readonly, gmail.modify, gmail.send, gmail.settings.* …	Postfach lesen, senden oder umkonfigurieren	Hoch
   drive, drive.readonly	Jede Datei, auf die der Nutzer zugreifen kann	Mittel
   admin.directory.*, cloud-platform	Aktionen auf Organisationsebene	Hoch
   openid, userinfo.email, drive.file	Anmeldeidentität, von der App selbst erstellte Dateien	Nicht markiert

2. Wann und von wo? Eine Freigabe Minuten nach einer riskanten Anmeldung, von derselben Hosting-IP: Das ist der Angreifer, der mit der gestohlenen Sitzung seine eigene App freigibt. Eine Freigabe aus dem üblichen Netz des Nutzers nach einer Phishing-Mail ist Consent-Phishing.

3. Wie heißt sie? Köder-Namen imitieren Hilfsprogramme: „PDF Viewer“, „Document Signer“, „Secure Mail“. Den Namen wählt der Entwickler der App, er beweist nichts.

4. Wer hat sie noch freigegeben? Pivotieren Sie über die Client-ID. Ein legitimes SaaS-Tool hat viele Nutzer über lange Zeit. Eine Köder-App taucht in einer Serie auf, oder auf einem einzigen Konto.

5. Ist sie bestätigt und genehmigt? Prüfen Sie Status und Bestätigung der App unter Security → Access and data control → API controls → Manage third-party app access (Bezeichnungen der englischsprachigen Konsole).

activity-Ereignisse lesen

activity zeigt das Token im Einsatz. Für Gmail sehen Sie api_name = gmail und Methoden wie gmail.users.messages.list, gmail.users.messages.get, gmail.users.settings.filters.create. Letztere bedeutet, dass die App einen Gmail-Filter angelegt hat, oft den versteckenden Filter eines BEC.

Der Analyzer markiert eine App, die für denselben Nutzer 20 oder mehr Gmail-API-Aufrufe in 60 Minuten macht, mit dem Befund App liest Gmail in großem Umfang über die API. Das ist Datensammlung, kein Mailclient, der gelegentlich synchronisiert. Die IPs dieser Ereignisse sind die API-Infrastruktur des Angreifers. Nehmen Sie sie in Ihren IP-Pivot auf.

Reaktion

1. Für den Nutzer widerrufen: Konsole → Nutzer → Security → Connected applications → App entfernen. Das ist auch Teil von Googles Verfahren für kompromittierte Konten.
2. Für alle blockieren: Setzen Sie die App in den API-Steuerelementen per Client-ID auf Blocked. Sonst gibt sie der nächste gephishte Nutzer wieder frei.
3. Nicht konfigurierte Apps einschränken: Mit Googles App-Zugriffssteuerung können Sie verhindern, dass Nutzer Apps freigeben, die Sie nicht geprüft haben, oder sie auf reine Anmelde-Scopes beschränken. Nutzer können dann eine Prüfung beantragen.
4. Schaden eingrenzen: Listen Sie aus den activity-Ereignissen Methoden und Zeiträume auf. Prüfen Sie im Gmail-Log, was im selben Fenster weitergeleitet oder gesendet wurde. num_response_bytes gibt eine grobe Vorstellung vom Umfang.
5. Die Admin-Seite im Blick behalten: Der Analyzer markiert auch Admins, die App-Kontrollen lockern (ADD_TO_TRUSTED_OAUTH2_APPS, UNBLOCK_ALL_THIRD_PARTY_API_ACCESS und ähnliche), mit dem Befund App-Zugriffskontrollen gelockert.

Freigabe pro Nutzer oder domainweite Delegierung

Alles oben betrifft die Einwilligung pro Nutzer: ein Nutzer, ein Token, begrenzt auf das, was dieser Nutzer erreicht. Domainweite Delegierung ist etwas anderes. Ein Super-Admin erlaubt einem API-Client, sich für die genannten Scopes als beliebiger Nutzer auszugeben, ganz ohne Einwilligung. Das steht im Admin-Log, nicht im Token-Log. Dazu gibt es einen eigenen Beitrag.

Häufige Fehlalarme

• Backup-, Archivierungs-, E-Signatur- und CRM-Tools verlangen legitim vollen Gmail- oder Drive-Zugriff. Dokumentieren Sie sie und blockieren Sie den Rest.
• Mailclients, die OAuth nutzen, besitzen ebenfalls https://mail.google.com/.
• Interne Apps Ihrer eigenen Entwickler. Prüfen Sie den Eigentümer des Google-Cloud-Projekts zur Client-ID.

Der Analyzer hat noch keine Zulassungsliste, bekannte Apps lösen also aus. Behandeln Sie diese Befunde als Inventurprüfung.

Als Nächstes: Risiken der domainweiten Delegierung. Zurück zum Untersuchungsleitfaden, oder lassen Sie Ihr Token-Log durch den Analyzer laufen.

FAQ

Widerruft ein Passwort-Reset den Zugriff einer Drittanbieter-App?

Verlassen Sie sich nicht darauf. Eine vom Nutzer freigegebene App funktioniert weiter, bis ihr Token widerrufen wird. Widerrufen Sie sie für den Nutzer (Admin-Konsole → Nutzer → Security → Connected applications) und blockieren Sie die App für die Organisation in den API-Steuerelementen.

Welche OAuth-Scopes sind in Google Workspace am gefährlichsten?

Voller Gmail-Zugriff (https://mail.google.com/), gmail.readonly / gmail.modify / gmail.send und die Scopes für Gmail-Einstellungen, volles Drive (drive, drive.readonly) sowie Admin-Directory- oder cloud-platform-Scopes. Sie geben einer App dieselbe Reichweite wie dem Nutzer oder mehr.