Verdächtige Anmeldung in Google Workspace und 2SV-Änderungen
Verdächtige Anmeldung in Google Workspace untersuchen: is_suspicious, Hosting-ASNs, neue Länder, unmögliche Reisen, Fehlversuche und 2SV-Änderungen.
Kurz gesagt. Prüfen Sie im Anmelde-Log (User log) vier Signale für das verdächtige Konto: Googles eigene Markierung (suspicious_login, is_suspicious=true, Warnungen zu deaktivierten Konten), eine erfolgreiche Anmeldung aus einer Hosting-ASN, ein neues Land oder eine unmögliche Reise und Serien von Fehlversuchen. Prüfen Sie dann, was die Sitzung am Konto geändert hat: 2sv_disable, recovery_email_edit, recovery_phone_edit. Eine erfolgreiche Anmeldung von einem VPS direkt nach dem Klick des Nutzers auf einen Link ist der Fußabdruck von Adversary-in-the-Middle-Phishing.
Mit der Anmeldung beginnt die Zeitleiste einer Workspace-Kompromittierung, und oft liegen dort ihre einzigen klaren Netzwerkindikatoren. Dieser Beitrag zeigt, was das Anmelde-Log aufzeichnet, wie Sie es lesen und wo die Fallstricke liegen.
Was das Anmelde-Log aufzeichnet
Die Anmelde- (und Nutzerkonten-)Ereignisse sind in Googles Anhang Login audit activity events dokumentiert. Die für eine Übernahme relevanten:
| Ereignis | Bedeutung |
|---|---|
login_success, login_failure | Ergebnis der Anmeldung, mit login_type, login_challenge_method, is_suspicious |
login_challenge, login_verification | 2SV- oder Risiko-Abfrage angezeigt / bestanden |
suspicious_login, suspicious_login_less_secure_app, suspicious_programmatic_login | Googles Risikoerkennung hat den Versuch blockiert oder markiert |
user_signed_out_due_to_suspicious_session_cookie | Google hat ein verdächtiges Sitzungs-Cookie erkannt und den Nutzer abgemeldet |
account_disabled_password_leak, account_disabled_hijacked, gov_attack_warning | Kontowarnungen |
risky_sensitive_action_allowed / _blocked | Sensible Aktion nach einer riskanten Anmeldung |
2sv_disable, 2sv_enroll, titanium_unenroll, passkey_removed | Änderungen an 2SV und Erweitertem Schutz |
recovery_email_edit, recovery_phone_edit, password_edit | Änderungen an Wiederherstellung und Passwort |
Jeder Datensatz enthält außerdem die IP-Adresse. In der Reports API kommt networkInfo mit ASN der IP und einem Regionscode hinzu. Diese Netzwerkdaten machen die nächsten drei Prüfungen erst möglich.
Signal 1: Google hat es schon markiert
Beginnen Sie mit dem günstigsten Beleg. Googles Risikoerkennung entscheidet, wann eine Anmeldung „außerhalb des üblichen Musters“ liegt (Warnungen zu verdächtigen Anmeldungen). Ein login_success mit is_suspicious = true bedeutet, dass der Versuch trotzdem durchging. user_signed_out_due_to_suspicious_session_cookie ist in AiTM-Fällen besonders interessant: Die Sitzung wurde gestohlen, und Google hat es bemerkt.
Diese Markierungen sind nicht vollständig. Viele AiTM-Anmeldungen werden nicht markiert, weil das Opfer die Abfrage tatsächlich bestanden hat.
Signal 2: ein Hosting-Netz
AiTM-Kits (Reverse-Proxys nach Art von Evilginx) sitzen zwischen Opfer und Google. Das Opfer gibt das Passwort ein und bestätigt die Aufforderung auf der durchgereichten Seite. Google sieht die Anmeldung vom Server des Proxys kommen, typischerweise einem VPS bei DigitalOcean, OVH, Hetzner, Vultr, AWS oder ähnlichen. MITRE führt das als T1557 Adversary-in-the-Middle, das zu T1078.004 Cloud Accounts führt.
Der Analyzer gleicht die ASN jeder erfolgreichen Anmeldung (auch per SAML) mit einer geprüften Liste von Hosting-Anbietern ab und markiert Treffer mit hoher Schwere. Bevor Sie eskalieren, schließen Sie Ihre eigene Infrastruktur aus: Unternehmens-VPN-Konzentratoren, Cloud-Desktops und Sicherheits-Proxys gehen alle über solche Netze.
Signal 3: Geografie
- Neues Land. Nach mindestens drei Anmeldungen aus bekannten Ländern ein Erfolg aus einem Land, das für diesen Nutzer neu ist. Für sich allein mittlere Schwere: Menschen reisen.
- Unmögliche Reise. Zwei erfolgreiche Anmeldungen aus Ländern, die mehr als 500 km auseinanderliegen, bei einer rechnerischen Geschwindigkeit über 900 km/h. Eine der beiden Sitzungen ist nicht der Nutzer, oder ein VPN ist im Spiel.
Beides setzt einen Regionscode pro Ereignis voraus. Die Reports API liefert ihn. Viele CSV-Exporte der Konsole nicht. Ohne ihn können diese Prüfungen nicht laufen. Siehe Grenzen der Audit-Logs.
Signal 4: Serien von Fehlversuchen
Zehn oder mehr login_failure-Ereignisse in zehn Minuten gegen ein Konto deuten auf Passwortraten oder Password Spraying hin (T1110). Allein ist das ein Befund mittlerer Schwere. Wichtig wird er, wenn darauf ein Erfolg von derselben IP folgt.
Danach: Was hat die Sitzung verändert?
Nach der Anmeldung macht der Angreifer seinen Zugang dauerhaft:
2sv_disable(odertitanium_unenrollfür den Erweiterten Schutz) erleichtert die nächste Anmeldung. MITRE: T1556.006 Multi-Factor Authentication. Ein Admin kann dasselbe über das Admin-Log tun (TURN_OFF_2_STEP_VERIFICATION,UNENROLL_USER_FROM_STRONG_AUTH).recovery_email_edit/recovery_phone_editerlauben dem Angreifer, das Konto nach Ihrem Passwort-Reset zurückzuholen. Prüfen Sie die neuen Werte immer mit dem Nutzer.
Der Analyzer markiert beide Gruppen und stuft die Kette „riskante Anmeldung → Sicherheitsänderung“ als kritisch ein, wenn sie auf eine riskante Anmeldung am selben Konto folgen.
Warum die 2SV nicht gereicht hat und was hilft
SMS-Codes, Codes aus Authenticator-Apps und Aufforderungen auf dem Smartphone lassen sich alle durchreichen: Das Opfer erledigt sie auf dem Proxy des Angreifers. Phishingresistente Verfahren (Sicherheitsschlüssel und Passkeys nach FIDO2/WebAuthn) sind an den echten Ursprung gebunden und funktionieren nicht über einen Proxy. Das CISA-Merkblatt zu phishingresistenter MFA erklärt den Unterschied. Google erlaubt Admins, Sicherheitsschlüssel zu erzwingen, pro Organisationseinheit oder Gruppe. Beginnen Sie mit Buchhaltung und Admins. Siehe auch Bestätigung in zwei Schritten.
Reaktion
- Setzen Sie die Anmelde-Cookies des Nutzers zurück, um die gestohlene Sitzung zu beenden.
- Prüfen Sie, was folgte: OAuth-Freigaben, Weiterleitung, Filter. Siehe den Untersuchungsleitfaden.
- Setzen Sie das Passwort zurück, nachdem die Persistenz entfernt ist, und stellen Sie 2SV und Wiederherstellungsoptionen wieder her.
- Pivotieren Sie im Tab Entitäten des Analyzers über die IPs des Angreifers, um weitere betroffene Konten zu finden.
Als Nächstes in dieser Serie: Gmail-Weiterleitungsregeln von Angreifern. Meldet sich Ihr Workspace über Okta an, behandelt oktaforensics.com die IdP-Seite derselben Anmeldung.
FAQ
Warum kam der Angreifer trotz Bestätigung in zwei Schritten hinein?
Adversary-in-the-Middle-Phishing-Kits reichen die echte Google-Anmeldeseite über einen Proxy durch. Das Opfer gibt das Passwort ein und bestätigt die Aufforderung oder tippt den Code, und das Kit behält die entstandene Sitzung. Nur phishingresistente Verfahren wie Sicherheitsschlüssel und Passkeys sind an die echte Website gebunden und halten dem stand.
Ist eine Anmeldung von einem VPS oder Cloud-Anbieter immer bösartig?
Nein. Unternehmens-VPNs, Secure Web Gateways und manche Remote-Desktop-Dienste gehen über Cloud-Netze ins Internet. Gleichen Sie die IP zuerst mit Ihrer eigenen Infrastruktur ab. Für einen normalen Nutzer ohne eine solche Konfiguration ist eine erfolgreiche Anmeldung aus einem Hosting-Netz ein starkes Signal für eine Übernahme.