GCP-Kryptomining und Startskript-Hintertüren erkennen
Missbrauch von Compute Engine in GCP-Audit-Logs erkennen: Startskript-Hintertüren, SSH-Schlüssel, deaktiviertes OS Login, GPU-VMs und ungenutzte Regionen.
Kurz gesagt. Der Missbrauch von Compute Engine hinterlässt klare Spuren in Admin Activity. Persistenz: Einträge zu setMetadata / setCommonInstanceMetadata, deren Delta startup-script, startup-script-url oder ssh-keys hinzufügt oder enable-oslogin / block-project-ssh-keys entfernt. Mining: compute.instances.insert mit guestAccelerators oder Maschinentypen a2-/a3-/g2-, Wellen von Erstellungen, VMs in Regionen, die Sie nie nutzen. Der Audit-Eintrag sagt Ihnen, welche Metadatenschlüssel sich geändert haben; den Inhalt holen Sie sich von der VM oder ihrer Festplatte.
Bei Compute wird aus einem kompromittierten Google-Cloud-Projekt am häufigsten eine Rechnung. Googles Threat Horizons Report vom November 2021 stellte fest, dass 86 % einer Stichprobe von 50 kürzlich kompromittierten Google-Cloud-Instanzen für das Schürfen von Kryptowährung genutzt wurden und dass, wo Zeitleisten vorlagen, in 58 % der Fälle Mining-Software innerhalb von 22 Sekunden nach der Kompromittierung heruntergeladen wurde. Das ist die Seite der „Auswirkung“ (T1496, Resource Hijacking). Die Seite der Persistenz, Hintertüren in den Metadaten von VMs, ist leiser und gefährlicher.
Startskripte: root bei jedem Start
Ein Startskript ist ein Metadatenwert, den die Gastumgebung unter Linux als root bei jedem Start ausführt (Startskripte auf Linux-VMs). Wer compute.instances.setMetadata für eine VM oder compute.projects.setCommonInstanceMetadata für das Projekt besitzt, kann auf diesen VMs daher beim nächsten Neustart Code als root ausführen und diesen Neustart mit reset selbst auslösen. Typische Nutzlasten: eine Reverse Shell, ein Miner oder ein Skript, das das Token des Dienstkontos vom Metadatenserver liest.
Die Schlüssel, die Code ausführen:
| Betriebssystem | Metadatenschlüssel |
|---|---|
| Linux | startup-script, startup-script-url, shutdown-script, shutdown-script-url |
| Windows | windows-startup-script-ps1, -cmd, -bat, -url, sysprep-specialize-script-ps1, -cmd |
Suchen Sie im Audit-Log nach:
protoPayload.methodName=("v1.compute.instances.setMetadata" OR "v1.compute.projects.setCommonInstanceMetadata")
und lesen Sie protoPayload.metadata.instanceMetadataDelta (oder projectMetadataDelta), das addedMetadataKeys, modifiedMetadataKeys und deletedMetadataKeys auflistet. Compute-Operationen sind langlaufend, eine Änderung kann also zwei Einträge erzeugen (operation.first und operation.last); zählen Sie sie nur einmal.
Erwarten Sie das Skript selbst nicht im Log. Rufen Sie es mit gcloud compute instances describe VM --format=json ab (oder project-info describe für Projektmetadaten) und erstellen Sie vor allem anderen einen Snapshot der Boot-Festplatte, damit Sie untersuchen können, was ausgeführt wurde. Das Security Command Center hat eine vergleichbare Erkennung, Persistence: GCE Admin Added Startup Script. MITRE ordnet dies T1037 zu und, für das Ausführen von Befehlen über die Control Plane der Cloud, T1651.
SSH-Schlüssel und OS Login
Zwei Wege zu einer Shell, ohne IAM anzufassen:
- SSH-Schlüssel in den Metadaten: Eine zusätzliche Zeile in
ssh-keysin den Instanz- oder Projektmetadaten gewährt SSH-Zugriff auf die VMs (SSH-Schlüssel zu VMs hinzufügen). Projektweite Schlüssel gelten für jede VM, die sie nicht blockiert. MITRE T1098.004. - OS Login abschalten: Mit
enable-oslogin=TRUEwird der SSH-Zugriff über IAM gesteuert, und Schlüssel aus den Metadaten werden ignoriert. Werenable-oslogin(oderblock-project-ssh-keys) löscht oder ändert, bringt die Metadatenschlüssel wieder ins Spiel. Das ist der Schritt, der den SSH-Schlüssel erst nutzbar macht, und im normalen Betrieb kommt er selten vor.
Die Kombination „ssh-keys hinzugefügt und enable-oslogin gelöscht im selben Aufruf von setCommonInstanceMetadata“ ist so eindeutig, wie Cloud-Beweise nur sein können. Die Abhilfe: OS Login wieder aktivieren und die Organisationsrichtlinie compute.requireOsLogin erzwingen (OS Login).
Mining: GPU-VMs, Wellen und ungenutzte Regionen
Die Erstellungseinträge sind v1.compute.instances.insert, bulkInsert und instanceTemplates.insert. Die Anfrage zeigt, was angefordert wurde:
guestAccelerators(angehängte GPUs) oder beschleunigeroptimierte Maschinentypen (Familiena2-,a3-,a4-,g2-) inmachineType;- eine Anzahl: viele Instanzen derselben Identität in kurzer Zeit;
- eine Zone in einer Region, in der das Projekt sonst keine Aktivität hat. Angreifer wählen Regionen, die niemand beobachtet (T1535, Unused/Unsupported Cloud Regions).
Auch Kontingentfehler sind ein Hinweis: Ein Angreifer, der an GPU-Kontingentgrenzen stößt, hinterlässt fehlgeschlagene insert-Aufrufe. Und prüfen Sie die Abrechnung: Miner, die stundenlang laufen, tauchen dort auf, bevor irgendjemand ein Log liest.
Firewalls zum Internet geöffnet
v1.compute.firewalls.insert, patch oder update mit sourceRanges, die 0.0.0.0/0 (oder ::/0) enthalten, öffnet einen Port für alle: SSH für den Angreifer oder einen Port für eine Web Shell. Zugeordnet zu T1562.007.
Bestätigung durch Netzwerkbelege
Metadatenänderungen sagen, was konfiguriert wurde. VPC Flow Logs, sofern im Subnetz aktiviert, sagen, was passiert ist: eine eingehende SSH-Sitzung von der Angreifer-IP nach dem Reset, ausgehende Verbindungen der VM zu dieser IP oder zu Mining-Pools, das ausgehende Volumen.
Was der Analyzer markiert
| Regel | Schweregrad | Bedingung |
|---|---|---|
startup_script_changed | Hoch | Ein Schlüssel für Start-, Shutdown- oder Sysprep-Skripte in Instanz- oder Projektmetadaten hinzugefügt oder geändert |
oslogin_changed | Hoch | enable-oslogin, enable-oslogin-2fa oder block-project-ssh-keys geändert oder entfernt |
ssh_key_added | Mittel | ssh-keys / sshKeys hinzugefügt oder geändert |
gpu_instance_created | Mittel | Instanz oder Vorlage mit Beschleunigern oder einem beschleunigeroptimierten Maschinentyp erstellt |
instance_burst | Hoch | Mindestens 5 Instanzerstellungen durch dieselbe Identität innerhalb von 30 Minuten |
new_zone_instance (Analyse) | Mittel | Instanz in einer Region erstellt, für die es in den Logs keine frühere Aktivität gibt |
firewall_opened | Mittel | Firewall-Regel mit Quelle 0.0.0.0/0 oder ::/0 erstellt oder geändert |
Die Metadatenschlüssel werden bei jedem Ereignis als +startup-script, ~enable-oslogin, -block-project-ssh-keys angezeigt. Die Maßnahmenliste verlangt, Snapshots zu erstellen und zu untersuchen, die VMs dann neu aufzubauen statt zu bereinigen und die Anmeldedaten der VM zu rotieren.
Behebung
Erstellen Sie für die Forensik Snapshots der Festplatten betroffener VMs und bauen Sie die VMs dann aus einem vertrauenswürdigen Image neu auf; entfernen Sie unbekannte SSH-Schlüssel und Startskripte aus den Instanz- und Projektmetadaten; aktivieren und erzwingen Sie OS Login wieder; stoppen Sie Instanzen, die niemand genehmigt hat; begrenzen Sie GPU-Kontingente; beschränken Sie die Standorte mit gcp.resourceLocations. Das Token des Dienstkontos der VM ist als gestohlen zu betrachten: Prüfen Sie, was dieses Dienstkonto tun konnte.
Häufige Fragen
Wie finde ich eine Startskript-Hintertür in Google Cloud?
Durchsuchen Sie die Admin-Activity-Logs nach Einträgen zu v1.compute.instances.setMetadata und v1.compute.projects.setCommonInstanceMetadata, deren Metadaten-Delta startup-script, startup-script-url oder die Windows-Entsprechungen hinzufügt oder ändert. Lesen Sie dann den aktuellen Wert des Schlüssels auf der VM oder im Projekt aus und erstellen Sie einen Snapshot der Festplatte.
Wie häufig ist Kryptomining nach einer Kompromittierung in Google Cloud?
Googles Threat Horizons Report vom November 2021 stellte fest, dass 86 % einer Stichprobe von 50 kürzlich kompromittierten Google-Cloud-Instanzen für das Schürfen von Kryptowährung genutzt wurden.
Weiterführende Links
- Compute Engine audit logging – Dokumentation von Google Cloud.
- About OS Login – Dokumentation von Google Cloud.
- Incident Response in Google Cloud: kompromittiertes Projekt.