Super-Admin in Google Workspace kompromittiert: Admin-Log
Super-Admin in Google Workspace kompromittiert: Admin-Log-Ereignisse zu neuen Admins, Rollen, SSO, Delegierung, Mail-Routing und Regeln zur Inhaltskonformität.
Kurz gesagt. Ein kompromittiertes Admin-Konto macht aus einem Postfach-Vorfall einen Tenant-Vorfall. Prüfen Sie im Admin-Log alles, was dieses Konto im Zeitfenster getan hat. Die Prioritäten: neue Super-Admins und Rollenvergaben (GRANT_ADMIN_PRIVILEGE, ASSIGN_ROLE), SSO-/SAML-Änderungen (CHANGE_SSO_SETTINGS, TOGGLE_SSO_ENABLED), domainweite Delegierung (AUTHORIZE_API_CLIENT_ACCESS), Mail-Routing, E-Mail-Überwachung und Regeln zur Inhaltskonformität, abgeschaltete 2SV für Nutzer, Passwort-Resets und neue Konten. Jeder Punkt ist ein Persistenzmechanismus, den die Bereinigung auf Nutzerebene nicht berührt.
Die meisten Workspace-Kompromittierungen bleiben auf Postfachebene. Wenn nicht, liegt es meist an einem Admin, der wie alle anderen auf Phishing hereingefallen ist, oder an wiederverwendeten Zugangsdaten. Der Bericht von Google Threat Intelligence zu UNC6508 vom Juni 2026 beschreibt einen Akteur, der anderswo abgegriffene Zugangsdaten wiederverwendete, um an ein Workspace-Administratorkonto zu kommen. Danach legte er eine Regel zur Inhaltskonformität an, die passende Nachrichten in Blindkopie an eine externe Gmail-Adresse schickte. Die Postfacheinstellungen der Nutzer zeigten nichts.
Das Admin-Log in Kürze
Jede Änderung über die Admin-Konsole und das Admin SDK wird im Admin-Log aufgezeichnet (Admin log events; API-Namen im Anhang zu Admin-Ereignissen). Jeder Datensatz enthält den handelnden Admin, die IP, den Ereignisnamen und die Parameter (betroffener Nutzer, Name der Einstellung, alter und neuer Wert). Google dokumentiert es als nahezu Echtzeit, mit der üblichen sechsmonatigen Aufbewahrung.
Worauf Sie achten sollten, und warum
| Änderung | Ereignisse im Admin-Log | Warum der Angreifer das tut | Schwere im Analyzer |
|---|---|---|---|
| Neuer Super-Admin | GRANT_ADMIN_PRIVILEGE | Ein Reserve-Admin, der den Reset des ursprünglichen Kontos übersteht | Hoch |
| Admin-Rolle / delegierter Admin | ASSIGN_ROLE, GRANT_DELEGATED_ADMIN_PRIVILEGES, ADD_PRIVILEGE | Unauffälliger als Super-Admin, trotzdem mächtig | Mittel |
| SSO | CHANGE_SSO_SETTINGS, TOGGLE_SSO_ENABLED, UPLOAD_OAUTH_CERTIFICATE | Anmeldungen an einen eigenen IdP schicken oder das eigene Zertifikat vertrauen lassen | Hoch |
| Domainweite Delegierung | AUTHORIZE_API_CLIENT_ACCESS | Per API jeden Nutzer imitieren | Hoch |
| App-Kontrollen | ADD_TO_TRUSTED_OAUTH2_APPS, UNBLOCK_ALL_THIRD_PARTY_API_ACCESS, … | Die eigene OAuth-App durchlassen | Mittel |
| Mail-Routing / -Überwachung | MAIL_ROUTING_DESTINATION_ADDED, CREATE_EMAIL_MONITOR, Änderungen an Gmail-Einstellungen zu Routing, Weiterleitung oder Konformität | Mails von Nutzern oder der ganzen Domain kopieren | Hoch |
| 2SV für einen Nutzer abgeschaltet | TURN_OFF_2_STEP_VERIFICATION, UNENROLL_USER_FROM_STRONG_AUTH | Ein Zielkonto schwächen | Hoch |
| Passwort-Reset | CHANGE_PASSWORD | Einen anderen Nutzer übernehmen | Niedrig |
| Neuer oder wiederhergestellter Nutzer | CREATE_USER, UNSUSPEND_USER, UNDELETE_USER | Hintertür-Konto | Niedrig |
MITRE-Zuordnung: T1098.003 Additional Cloud Roles, T1484.002 Trust Modification, T1556 Modify Authentication Process, T1136.003 Create Cloud Account.
Die Zeilen mit niedriger Schwere sind normales Helpdesk-Geschäft. Sie zählen nur im Kontext: derselbe Admin, derselbe Tag, nach einer riskanten Anmeldung. Genau das erfasst die Kettenregel des Analyzers. Eine riskante Anmeldung, auf die innerhalb von 14 Tagen eine Admin-, SSO-, Delegierungs-, Routing- oder 2SV-Änderung am selben Konto folgt, ist kritisch.
SSO: die leise Hintertür
Workspace kann die Authentifizierung über SSO-Profile an einen externen Identitätsanbieter übergeben (Security → Authentication → SSO with third-party IdP, Bezeichnungen der englischsprachigen Konsole; siehe Googles SSO-Einrichtungsanleitung). Ein Angreifer, der die Anmelde-URL ändert oder ein eigenes Prüfzertifikat hochlädt, kann Anmeldungen für Nutzer erzeugen, ohne ein einziges Passwort zu kennen. Weder Passwort-Resets noch 2SV helfen dagegen.
Prüfungen:
- Vergleichen Sie Anmeldeseiten-URL, Entitäts-ID und Zertifikate jedes Profils mit den echten Werten Ihres IdP.
- Prüfen Sie, welchen Organisationseinheiten oder Gruppen jedes Profil zugewiesen ist.
- Korrelieren Sie mit dem SAML-Log: Anmeldungen über ein Profil, das niemand erwartet hat.
Eine Grenze, die Sie nennen sollten: Der Analyzer erkennt die oben genannten SSO-Ereignisnamen. Neuere Operationen an SSO-Profilen können unter anderen Namen protokolliert werden. Suchen Sie bei einem Vorfall im Admin-Log manuell nach „SSO“. Ist Ihr IdP Okta, prüfen Sie auch die IdP-Seite. oktaforensics.com behandelt das System Log von Okta.
Mail-Routing und Konformitätsregeln
Mail-Regeln auf Admin-Ebene gelten für viele Postfächer gleichzeitig und sind in den Gmail-Einstellungen der einzelnen Nutzer unsichtbar:
- Routing kann Empfänger hinzufügen oder den Zielserver ändern.
- Inhaltskonformität kann Ausdrücke erkennen und Empfänger hinzufügen. Das ist die Technik von UNC6508.
- E-Mail-Überwachungen (email monitors, eine ältere API-Funktion) kopieren die Mails eines Nutzers an eine andere Adresse.
Der Analyzer markiert MAIL_ROUTING_DESTINATION_ADDED, CREATE_EMAIL_MONITOR sowie das Anlegen oder Ändern von Gmail-Einstellungen, deren Name Routing, Weiterleitung, Konformität oder Umgehung erwähnt. Prüfen Sie auch die Regeln selbst unter Apps → Google Workspace → Gmail → Compliance und Routing. Das Log sagt Ihnen, wann. Die Konsole sagt Ihnen, was heute aktiv ist.
Reaktion auf eine Admin-Kompromittierung
- Admin-Konto eindämmen: Anmelde-Cookies zurücksetzen, Tokens widerrufen, Passwort zurücksetzen, Sicherheitsschlüssel erzwingen. Googles Seite zur 2SV-Erzwingung für Admins ist hier relevant.
- Änderungen erfassen: Filtern Sie das Admin-Log für das ganze Zeitfenster auf diesen Akteur und exportieren Sie es.
- Rückgängig machen: Jede unerklärte Änderung zurückdrehen, also Admins und Rollen entfernen, SSO-Profile wiederherstellen, Delegierungen löschen, Routing- und Konformitätsregeln entfernen, 2SV wiederherstellen.
- Konten zweiter Ordnung suchen: Vom Angreifer angelegte Nutzer oder Nutzer mit zurückgesetztem Passwort sind unter seiner Kontrolle. Wiederholen Sie die Untersuchung für jedes dieser Konten.
- Härten: wenige Super-Admins, nicht für die tägliche Arbeit genutzt, nur Sicherheitsschlüssel und, wo verfügbar, Mehrparteien-Genehmigung. Die SCuBA-Baselines der CISA für Google Workspace bieten eine geprüfte Referenzkonfiguration.
Damit endet die Serie zu Angriffstechniken. Das Gegenstück auf Nutzerebene finden Sie unter Gmail-Weiterleitungsregeln, die vollständige Methode im Untersuchungsleitfaden. Um einen Admin-Log-Export schnell zu sichten, nutzen Sie den Analyzer.
FAQ
Wie sehe ich, was ein Google-Workspace-Admin geändert hat?
Öffnen Sie in der Admin-Konsole Reporting → Audit and investigation → Admin log events und filtern Sie auf die E-Mail-Adresse des Admins als Akteur und auf den Vorfallszeitraum, oder fragen Sie die Reports API mit applicationName=admin ab. Jede Einstellungsänderung, Rollenvergabe und Nutzeränderung ist dort aufgezeichnet.
Warum sollte ein Angreifer die SSO-Einstellungen von Google Workspace ändern?
Wer SSO auf einen selbst kontrollierten Identitätsanbieter umleitet oder ein eigenes Signaturzertifikat hinzufügt, kann sich ohne Passwort und 2SV als Nutzer anmelden, und das übersteht Passwort-Resets. Behandeln Sie jede ungeplante SSO-Änderung als Vorfall.