Kompromittierung in GCP: ein fiktives Fallbeispiel

Kurz gesagt. Dies ist ein fiktiver Vorfall: Firma, Personen, Projekt, Schlüssel und IP-Adressen sind erfunden (die IPs stammen aus den Dokumentationsbereichen von RFC 5737). Es ist der Datensatz hinter Beispiel testen auf der Tool-Seite. Ein Dienstkontoschlüssel der CI, erstellt für einen lokalen Test, gelangt nach außen; sechs Tage später wird er von einem VPS aus genutzt, der die Umgebung erkundet, einem Gmail-Konto roles/owner erteilt, ein Startskript platziert, 140 Objekte herunterlädt, den Bucket öffentlich macht und den Sink löscht, der das SIEM versorgt – alles in 55 Minuten. Jeder der folgenden Schritte ist ein echter Befund, den der Analyzer für dieses Beispiel erzeugt.

Bei einem solchen Durchgang geht es darum, die Überlegungen zu zeigen, nicht das Tool. Jeder Schritt nennt das Log-Feld, das den Beleg trägt, sodass Sie ihn auch mit dem Logs Explorer an Ihren eigenen Daten nachvollziehen können.

Die Ausgangslage

„Northwind Analytics“ (fiktiv) betreibt ein Projekt nw-analytics-prod mit:

• einem CI-Dienstkonto, ci-deployer@…, das Terraform nutzt;
• einer ETL-VM, etl-worker-1 in us-central1-a, die als etl-runner@… läuft und tägliche Exporte liest;
• einem Bucket nw-analytics-exports mit Kundenauszügen;
• einem Sink nw-audit-to-siem, der Audit-Logs über Pub/Sub an das SIEM exportiert;
• aktivierten Data-Access-Logs für Cloud Storage und VPC Flow Logs im Standard-Subnetz.

Der Export entspricht dem, was Sie beim Kopieren eines Sink-Buckets erhalten: 26 stündliche JSON-Lines-Shards unter cloudaudit.googleapis.com/… und compute.googleapis.com/vpc_flows/…, dazu ein Download aus dem Logs Explorer. Der Analyzer liest 215 Audit-Einträge und 65 Flow-Datensätze und legt 3 GKE-Einträge für Kubernetes Forensics beiseite.

Das Urteil

Kompromittiert, mit 16 Befunden: 3 kritisch, 8 hoch, 5 mittel. Der erste Grund ist die Korrelation „Angriffskette: gestohlener Zugang, dann Übernahme“, die den Zeitraum von 02:03 bis 02:57 UTC am 14. September abdeckt.

Ein Urteil ist eine Behauptung; der Rest dieses Artikels überprüft sie.

8. September: der Schlüssel entsteht

09:14:22  alex.martin@…  google.iam.admin.v1.CreateServiceAccountKey  from 198.51.100.24 (gcloud, macOS)

sa_key_created (mittel). Alex erstellt einen JSON-Schlüssel für ci-deployer, um Terraform lokal zu testen. Minuten später wird der Schlüssel von derselben Büro-IP mit dem User-Agent Terraform/1.9.5 genutzt: serviceAccountKeyName endet auf …/keys/6f1c2d9e…. Das löst sa_key_used_external (mittel) aus: Der Schlüssel wird außerhalb von Google Cloud verwendet. Für sich genommen ist das nichts Besonderes. Relevant wird es, weil die Büro-IP nun die erste bekannte IP des Schlüssels ist.

Die folgenden Tage sind Routine und erzeugen keine Befunde: Das ETL-Dienstkonto liest jeden Morgen vier Objekte von der internen IP der VM, Priya listet Instanzen auf, passt eine Firewall-Regel an den IAP-Bereich an und erteilt einer Kollegin roles/viewer; Google migriert die VM live (ein System-Event-Eintrag von system@google.com). Diese Baseline lässt den nächsten Tag hervorstechen. Exportieren Sie eine Baseline, wann immer es geht.

14. September, 02:03: der Schlüssel wird von woanders genutzt

02:03:11  ci-deployer@…  GetIamPolicy  from 203.0.113.66 (gcloud, Linux)  key 6f1c2d9e…

sa_key_new_ip (hoch, Erstzugriff, T1078.004). Derselbe Schlüssel, neue öffentliche IP, neuer Client: gcloud unter Linux statt Terraform unter macOS, um 2 Uhr nachts. Der Schlüssel wurde kopiert. Der Artikel zu geleakten Schlüsseln zeigt, wie Sie das vom Grundrauschen der CI unterscheiden.

02:04 bis 02:08: Erkundung

24 Aufrufe in vier Minuten, alle mit status.code: 7 (PERMISSION_DENIED): Zugriff auf das Secret prod-db-password, Lesen der IAM-Richtlinie und der Organisationsrichtlinien der Organisation, des Rechnungskontos, der Benachrichtigungskonfigurationen des Security Command Center, der Dienstkonten in einem anderen Projekt. permission_denied_burst (mittel, Erkundung). Hier lernt der Angreifer, was der Schlüssel kann, und stellt fest, dass er auf Organisationsebene wenig ausrichtet, auf dem Projekt aber setIamPolicy besitzt.

02:11: Owner für ein Gmail-Konto

02:11:07  ci-deployer@…  SetIamPolicy  ADD roles/owner user:nw.ops.backup@gmail.com

Drei Befunde für einen einzigen Eintrag: owner_to_consumer (kritisch), owner_editor_granted (hoch), consumer_account_granted (hoch). Der Name wurde so gewählt, dass er wie ein internes Backup-Konto aussieht; die Domain verrät ihn. Sieben Minuten später listet dieses Gmail-Konto Instanzen auf, von derselben VPS-IP, in einem Browser: Der Angreifer ist auf eine Identität umgestiegen, die die Deaktivierung des Schlüssels übersteht. Siehe SetIamPolicy-Missbrauch.

02:24 bis 02:26: Hintertür auf der VM

02:24:40  nw.ops.backup@gmail.com  v1.compute.instances.setMetadata  +startup-script  etl-worker-1
02:25:10  nw.ops.backup@gmail.com  v1.compute.projects.setCommonInstanceMetadata  +ssh-keys  -enable-oslogin
02:26:02  nw.ops.backup@gmail.com  v1.compute.instances.reset  etl-worker-1

startup_script_changed (hoch), ssh_key_added (mittel), oslogin_changed (hoch). Ein Startskript läuft beim Booten als root; der Reset sorgt dafür, dass es sofort läuft. Ein projektweiter SSH-Schlüssel plus entferntes OS Login ergibt Shell-Zugriff auf jede VM. Das Audit-Log nennt die Schlüssel, nicht das Skript: In einer echten Untersuchung würden Sie einen Snapshot der Festplatte erstellen und die Metadaten auslesen. Siehe Missbrauch von Compute Engine.

Ab 02:27: das Netzwerk bestätigt es

VPC Flow Logs zeigen um 02:27 eine eingehende SSH-Sitzung von 203.0.113.66 zur VM auf Port 22, danach bis 02:54 36 ausgehende HTTPS-Flows von etl-worker-1 zur selben IP, insgesamt etwa 1,9 GiB, Ziel per Geolokalisierung in den Niederlanden.

flow_large_egress (mittel) und flow_ioc_match (hoch): Die IP, die den geleakten Schlüssel genutzt hat, ist auch die Gegenstelle der VM mit der Hintertür. Das ist die Verbindung zwischen der Control Plane und dem, was die VM tatsächlich getan hat. Siehe Analyse von VPC Flow Logs.

02:33 bis 02:40: der Bucket

140 storage.objects.get auf nw-analytics-exports, Objekte ab customers/2026/q3/customer-extract-0000.csv.gz, in sechseinhalb Minuten, durch das Gmail-Konto: bulk_object_reads (hoch). Dann:

02:40:15  nw.ops.backup@gmail.com  storage.setIamPermissions  ADD roles/storage.objectViewer allUsers

public_access_granted (kritisch). Ab 02:40 ist der Bucket öffentlich; Lesezugriffe anonymer Nutzer würden nicht in den Audit-Logs erscheinen. Der Bericht muss ein Expositionszeitfenster angeben, nicht nur die 140 nachgewiesenen Lesezugriffe. Siehe Exfiltration aus GCS und BigQuery.

02:57: Spuren verwischen

02:57:42  nw.ops.backup@gmail.com  google.logging.v2.ConfigServiceV2.DeleteSink  nw-audit-to-siem

sink_deleted (hoch). Ab hier erhält das SIEM nichts mehr. Die Löschung selbst liegt im Bucket _Required, ebenso wie jeder Admin-Activity-Eintrag davor und danach. Siehe Umgehung von Abwehrmaßnahmen.

Die Pivots, die alles verbinden

• IP 203.0.113.66: 173 Audit-Einträge unter zwei Identitäten (erst das CI-Dienstkonto, dann das Gmail-Konto), dazu die Flow-Datensätze. Ein Klick im Reiter „Entitäten“ filtert die Ereignistabelle darauf.
• Schlüssel 6f1c2d9e…: von Alex erstellt, von zwei IPs genutzt, die zweite feindlich.
• Identität nw.ops.backup@gmail.com: 147 Einträge, alle vom VPS, zuerst gesehen um 02:18.

Die Maßnahmenliste, die das Tool erzeugt

In dieser Reihenfolge: Sicherheitsvorfall ausrufen und Logs sichern; die IP blockieren; die IAM-Bindung entfernen und Mitglieds-Domains beschränken; den Bucket wieder privat machen und die Datenexposition bewerten; den Schlüssel deaktivieren und rotieren, was das CI-Dienstkonto lesen konnte; von der VM einen Snapshot erstellen, sie untersuchen und neu aufbauen; OS Login wieder erzwingen; den Sink wiederherstellen; die Schlüsselerstellung verbieten; die Erkundung prüfen; SSH-Schlüssel entfernen. Die Eindämmungsschritte stehen vorn, weil der Angreifer noch zwei Identitäten besitzt.

Was dieser Fall lehrt

• Der Leak war nicht der Angriff; der Angriff begann sechs Tage später. Ereignisse zur Schlüsselerstellung verdienen für sich genommen eine Prüfung.
• Der Angreifer wechselte innerhalb von acht Minuten die Identität. Pivotieren Sie über IPs, nicht nur über Identitäten.
• Data-Access-Logs und Flow-Logs machten aus „vielleicht“ die Aussage „140 Dateien und 1,9 GiB“. Ohne sie gilt, was im Artikel zu den Grenzen der Data-Access-Logs steht.

Zum Nachvollziehen öffnen Sie den Analyzer, klicken auf Beispiel testen und folgen der Schritt-für-Schritt-Anleitung.

Weiterführende Links

• Incident Response in Google Cloud: kompromittiertes Projekt.
• Respond to compromised Google Cloud credentials – Dokumentation von Google Cloud.
• MITRE-ATT&CK-Matrix für IaaS.