Google-Workspace-Konto kompromittiert? Leitfaden zur Analyse

Kurz gesagt. Eine Kontoübernahme in Google Workspace hinterlässt fast immer dieselbe Spur. Zuerst eine riskante Anmeldung im Anmelde-Log. Dann Persistenz, die einen Passwort-Reset übersteht: eine OAuth-Freigabe im Token-Log, eine externe Weiterleitung im Nutzerkonten-Log, ein Gmail-Filter, den nur die Gmail-Einstellungen zeigen. Danach folgen Datensammlung und Betrug in den Gmail- und Drive-Logs. Exportieren Sie diese Quellen für die 30 Tage vor der verdächtigen E-Mail und korrelieren Sie pro Konto. Behandeln Sie die Abfolge „riskante Anmeldung → Persistenz“ als Kompromittierung, bis jemand das Gegenteil belegt. Der kostenlose Analyzer im Browser führt genau diese Korrelation auf Ihren Exporten aus, ohne sie hochzuladen.

Die meisten Workspace-Untersuchungen beginnen gleich. Ein Lieferant ruft wegen einer Rechnung an, die auf ein „neues“ Bankkonto bezahlt wurde. Oder ein Nutzer erzählt, er habe sich auf einer seltsamen Dokumentenfreigabe-Seite angemeldet. Oder Google schickt eine Warnung zu einer verdächtigen Anmeldung. Die Frage der Geschäftsführung ist binär: Wurde das Konto kompromittiert, und was wurde abgegriffen? Die Logs beantworten beides, vorausgesetzt, Sie sichern die richtigen, bevor sie verfallen.

Schritte einer Kontoübernahme in Google Workspace und das Log, das jeden Schritt aufzeichnet

Die fünf Fragen der Untersuchung

Frage	Beweisquelle	Wichtige Ereignisse
Hat sich jemand anderes angemeldet?	Anmelde-Log (User log)	`login_success` mit `is_suspicious`, `suspicious_login`, IP / ASN / Land
Hat er den Zugang behalten?	OAuth-Token-Log, Nutzerkonten-Log, Gmail-Einstellungen	`authorize` (Scopes), `email_forwarding_out_of_domain`, Filter, Bevollmächtigte, Senden als
Hat er das Konto geschwächt?	Anmelde- / Nutzerkonten-Log, Admin-Log	`2sv_disable`, `recovery_email_edit`, `recovery_phone_edit`
Was hat er gelesen oder mitgenommen?	Gmail-, Token-`activity`-, Drive-, Takeout-Log	automatisch weitergeleitete Mails, Gmail-API-Aufrufe, `download`-Serien, `*_USER_TAKEOUT`
Hat er das Konto gegen andere eingesetzt?	Gmail-Log, Admin-Log	ausgehende Mails zu „Bankverbindung“, neue Admins, SSO- oder Delegierungsänderungen

Die Ereignisnamen stammen aus Googles Anhang der Reports API zu Anmeldeereignissen. Dieselben Ereignisse erscheinen in der Admin-Konsole unter Anzeigenamen (Reporting → Audit and investigation, Bezeichnungen der englischsprachigen Konsole).

Schritt 1: Die Anmeldegeschichte rekonstruieren

Beginnen Sie mit dem verdächtigen Konto und den 30 Tagen vor dem ersten Anzeichen. Listen Sie im Anmelde-Log jede erfolgreiche Anmeldung mit IP-Adresse, ASN und Land auf. Sie suchen drei Dinge:

Googles eigene Markierung. Die Ereignisse suspicious_login, suspicious_programmatic_login und user_signed_out_due_to_suspicious_session_cookie oder ein login_success mit is_suspicious = true. Google beschreibt sie als Anmeldungen außerhalb des üblichen Musters des Nutzers. Notieren Sie auch Kontowarnungen wie account_disabled_password_leak oder gov_attack_warning.
Ein Netz, das keiner Person gehört. Mitarbeitende melden sich aus dem Büro, von zu Hause oder über Mobilfunk an. Eine erfolgreiche Anmeldung aus einem Cloud- oder VPS-Netz (DigitalOcean, OVH, AWS …) ist der typische Fußabdruck eines Adversary-in-the-Middle-Phishing-Kits. Das Kit leitet Passwort und die Aufforderung zur Bestätigung in zwei Schritten durch und nutzt die Sitzung dann von seinem eigenen Server. Siehe Hosting-ASN.
Geografie, die nicht passt. Ein Land, das für diesen Nutzer neu ist, oder eine unmögliche Reise zwischen zwei Anmeldungen.

Die ausführliche Anleitung, einschließlich der Felder, die es nur in der Reports API gibt, finden Sie unter verdächtige Anmeldungen und 2SV-Änderungen.

Schritt 2: Persistenz suchen, die einen Passwort-Reset übersteht

Hier hören die meisten internen Untersuchungen zu früh auf. Ein Passwort-Reset entfernt nicht:

OAuth-Freigaben. Ein Nutzer, der bei einer Köder-App („PDF viewer“, ein gefälschter Signaturdienst) auf „Zulassen“ geklickt hat, hat ihr ein Aktualisierungstoken gegeben. Das OAuth-Token-Log zeichnet das Ereignis authorize mit App-Name, Client-ID und Scopes auf. Alles mit https://mail.google.com/ oder gmail.*-Scopes kann das Postfach über die API lesen, solange das Token lebt. Siehe verdächtige OAuth-Apps und unrechtmäßige Einwilligung.
Externe Weiterleitung. Das Nutzerkonten-Log zeichnet email_forwarding_out_of_domain mit der Zieladresse auf. Siehe externe automatische Weiterleitung.
Gmail-Filter, Bevollmächtigte und „Senden als“-Adressen. Sie stehen überhaupt nicht in den Audit-Logs. Sie müssen die Einstellungen des Postfachs lesen (Gmail API oder die Gmail-Einstellungen des Nutzers). Ein Filter auf „invoice OR payment“, der den Posteingang überspringt und nach außen weiterleitet, ist die Handschrift von Business E-Mail Compromise (BEC). Die vollständige Methode steht in die Gmail-Weiterleitungsregel eines Angreifers finden.
Geschwächte Authentifizierung. 2sv_disable, eine neue Wiederherstellungs-E-Mail oder -Telefonnummer, ein entfernter Sicherheitsschlüssel.

MITRE ATT&CK nennt diese Techniken T1114.003 Email Forwarding Rule, T1564.008 Email Hiding Rules und T1528 Steal Application Access Token.

Schritt 3: Eingrenzen, worauf zugegriffen wurde

Sobald Sie wissen, wann der Angreifer Zugang hatte und von wo, filtern Sie alle anderen Logs auf dieses Zeitfenster und seine IPs:

Gmail-Log. Nachrichten, die direkt nach dem Eingang automatisch weitergeleitet, archiviert oder gelöscht wurden, vor allem Lieferantenrechnungen. Außerdem ausgehende Nachrichten an externe Empfänger.
OAuth-Token-Log, activity-Ereignisse. Gmail-API-Aufrufe (gmail.users.messages.get, …settings.filters.create) über die Köder-App zeigen das Abgreifen des Postfachs in großem Umfang.
Drive-Log. Serien von download-Ereignissen, an externe Adressen freigegebene Dateien, Links für „Jeder mit dem Link“. Details in Drive-Massendownload und Takeout-Exfiltration.
Takeout-Log. Ein Google Takeout-Export des ganzen Kontos ist der schnellste Weg, alles mitzunehmen.

Schritt 4: Prüfen, ob es über ein Postfach hinausging

Ist das kompromittierte Konto ein Admin, oder hat der Angreifer einen erreicht, hat das Admin-Log Vorrang: neue Super-Admins, Rollenzuweisungen, SSO-Änderungen, einem API-Client erteilte domainweite Delegierung, Routing- oder Compliance-Regeln für E-Mail. Im Juni 2026 hat Google Threat Intelligence einen der VR China zugeordneten Akteur (UNC6508) beschrieben, der mit gestohlenen Admin-Zugangsdaten eine Regel zur Inhaltskonformität anlegte. Die Regel schickte passende Nachrichten unbemerkt in Blindkopie an eine externe Gmail-Adresse. Eine solche Änderung taucht nie in den Postfacheinstellungen eines Nutzers auf. Siehe Missbrauch von Admin-Rollen und SSO-Änderungen.

Schritt 5: Korrelieren, dann entscheiden

Einzelne Ereignisse sind verrauscht. Menschen reisen, nutzen VPNs und installieren legitime Apps. Das Signal ist die Abfolge auf demselben Konto:

riskante Anmeldung → Weiterleitung / versteckender Filter / App mit Gmail-Scope / Mail zu geänderter Bankverbindung → Business E-Mail Compromise;
riskante Anmeldung → Admin-, SSO-, Delegierungs- oder 2SV-Änderung → mögliche Übernahme des Tenants.

Der Analyzer auf der Startseite bildet beide Ketten als Regeln mit einem Zeitfenster von 14 Tagen ab. Er meldet „Wahrscheinlich kompromittiert“, wenn eine Kette auslöst oder wenn Befunde hoher Schwere aus zwei verschiedenen Kategorien dasselbe Konto betreffen. Seine Regeln sind lesbares JSON, sodass Sie genau nachvollziehen können, was ausgelöst hat.

Was „unauffällig“ bedeutet und was nicht

Ein unauffälliges Ergebnis allein auf Basis des Anmelde-Logs sagt nichts über OAuth-Freigaben oder Filter. Bevor Sie den Fall schließen, prüfen Sie, dass Sie Folgendes hatten:

jede relevante Quelle für das gesamte Zeitfenster (das Tool listet fehlende Quellen auf);
die Gmail-Einstellungen jedes beteiligten Postfachs;
Netzwerkinformationen (ASN und Land), die nur manche Exporte enthalten.

Audit-Daten sind außerdem endlich. Google bewahrt die meisten Ereignisse sechs Monate auf, und Exporte haben Zeilenobergrenzen. Details in Grenzen der Audit-Logs.

Wie es weitergeht

Die nächste Stunde, als Maßnahmen: Checkliste für die erste Stunde der Incident Response.
Die Daten sichern: Google-Workspace-Audit-Logs exportieren.
Die Analyse durchführen: Google-Workspace-Audit-Logs Schritt für Schritt analysieren.
Ein vollständiger fiktiver Fall: BEC-Untersuchung als Beispiel.

Dasselbe Muster zeigt sich in anderen Clouds. Wer einen Microsoft-365-Tenant untersucht, findet die entsprechende Analyse von Posteingangsregeln auf m365forensics.com.

FAQ

Wie erkenne ich, ob ein Google-Workspace-Konto kompromittiert wurde?

Suchen Sie nach einer Anmeldung, die nicht zum Nutzer passt (Hosting-Netz, neues Land, Googles eigene Verdachtsmarkierung), gefolgt von Persistenz auf demselben Konto: externe Weiterleitung, ein Filter, der Rechnungen versteckt, eine neue Drittanbieter-App mit Gmail-Zugriff oder abgeschaltete Bestätigung in zwei Schritten. Jedes Element allein kann legitim sein. Die Abfolge macht den Fall.

Beendet ein Passwort-Reset die Kompromittierung?

Nein. Offene Sitzungen, OAuth-Tokens von Drittanbieter-Apps, Weiterleitungsadressen und Gmail-Filter überleben einen Passwort-Reset. Widerrufen Sie Sitzungen und Tokens, entfernen Sie die Persistenz im Postfach und setzen Sie erst dann das Passwort zurück. Googles Anleitung für kompromittierte Konten folgt derselben Reihenfolge.

Welche Google-Workspace-Logs brauche ich, um ein kompromittiertes Konto zu untersuchen?

Mindestens das Anmelde-Log (User log), das OAuth-Token-Log und das Gmail-Log des Kontos sowie seine Gmail-Einstellungen (Filter, Weiterleitung, Bevollmächtigte, Senden als). Ergänzen Sie Drive, Admin, SAML, Takeout und Groups, um Datenzugriffe und Admin-Änderungen einzugrenzen.