GCP-Log-Sink gelöscht? Spurenverwischung in Logs erkennen

Kurz gesagt. Ein Angreifer mit Owner-Rechten wird versuchen, Sie blind zu machen: DeleteSink oder UpdateSink auf dem Sink, der Ihr SIEM versorgt, CreateExclusion, UpdateBucket / DeleteBucket auf Log-Buckets, DeleteLog, eine Änderung der IAM-Richtlinie, die die Data-Access-Audit-Konfiguration entfernt (auditConfigDeltas REMOVE), und gelöschte Benachrichtigungskonfigurationen des Security Command Center. Jede dieser Aktionen ist selbst ein Admin-Activity-Eintrag und wird 400 Tage in einem Bucket aufbewahrt, den der Angreifer nicht anfassen kann. Suchen Sie zuerst danach: Ihr Zeitstempel markiert oft das Ende des sichtbaren Teils des Angriffs.

In MITRE ATT&CK ist diese Umgehung von Abwehrmaßnahmen (Defense Evasion) T1562.008, Impair Defenses: Disable or Modify Cloud Logs, und T1070, Indicator Removal, wenn Logs gelöscht werden.

Was ein Angreifer nicht entfernen kann

Beginnen wir mit der guten Nachricht, denn sie prägt die Untersuchung. Cloud Logging leitet Admin-Activity-, System-Event- und Access-Transparency-Logs über den Sink _Required, der laut Google weder geändert noch gelöscht werden kann, in den Bucket _Required; der Bucket bewahrt sie 400 Tage auf (Routing-Übersicht, Kontingente).

Selbst nach einer vollständigen Übernahme enthält das Projekt also noch eine Aufzeichnung jeder Konfigurationsänderung, auch derjenigen, die alles andere abgeschaltet haben. Was der Angreifer beeinflussen kann, ist alles außerhalb von _Required: Ihre Exporte, Ihre Data-Access-Logs, Ihre Alarmierung.

Die Techniken und ihre Log-Einträge

Zwei weitere Änderungen verdienen eine Prüfung, auch wenn sie streng genommen nicht das Logging betreffen: für 0.0.0.0/0 geöffnete v1.compute.firewalls (T1562.007) und gelockerte Organisationsrichtlinien (siehe SetIamPolicy-Missbrauch).

Das Delta der Audit-Konfiguration lesen

Das Data-Access-Logging wird im Abschnitt auditConfigs der IAM-Richtlinie konfiguriert (Data-Access-Audit-Logs konfigurieren). Es abzuschalten ist daher ein Aufruf von SetIamPolicy, und die Änderung erscheint im Policy-Delta neben den Binding-Deltas:

"policyDelta": {
  "auditConfigDeltas": [
    { "action": "REMOVE", "service": "storage.googleapis.com", "logType": "DATA_READ" }
  ]
}

Ein REMOVE für allServices oder für storage.googleapis.com unmittelbar vor einer Aktivitätswelle ist ein starkes Signal. Subtiler ist das Hinzufügen eines ausgenommenen Mitglieds: Diese Identität erzeugt für den Dienst keine Data-Access-Logs mehr, während alle anderen weiter protokolliert werden.

Was der Zeitstempel verrät

Die Umgehung von Abwehrmaßnahmen kommt oft spät im Angriff: Der Angreifer erledigt, wofür er gekommen ist, und räumt dann auf. In der Praxis heißt das:

• Alles vor diesem Schritt ist überall sichtbar (SIEM, Sink-Bucket, Projekt).
• Alles danach ist nur in dem sichtbar, was der Angreifer nicht ändern konnte: _Required im Projekt und jeder aggregierte Sink auf Organisationsebene, auf den er keine Rechte hatte.

Schließen Sie nach einem DeleteSink also nicht aus dem SIEM, dass die Aktivität aufgehört hat. Exportieren Sie direkt aus dem Projekt und, falls vorhanden, aus dem Sink der Organisation.

Logging, das ein Angreifer nicht abschalten kann

Die langfristige Lösung ist architektonisch, und Google beschreibt die Bausteine:

• Ein aggregierter Sink auf Organisations- oder Ordnerebene, der die Audit-Logs aller Projekte in ein zentrales Projekt leitet, auf das die Verantwortlichen der Workloads keine Rechte haben (zentrale Log-Speicherung).
• Ein Log-Bucket mit gesperrter Aufbewahrungsrichtlinie in diesem Projekt (Log-Buckets konfigurieren); die Sperre ist unumkehrbar, und ein gesperrter Bucket kann erst gelöscht werden, wenn jeder Eintrag darin die Aufbewahrungsfrist erreicht hat.
• Auf Organisationsebene aktivierte Data-Access-Logs, mindestens für IAM, Cloud Storage und Secret Manager.
• Alarme auf die methodNames aus der Tabelle oben.

Was der Analyzer markiert

Stammen diese Befunde von derselben IP oder Identität wie frühere Zugriffsbefunde, meldet der Analyzer die kritische Korrelation „Angriffskette“. Die Maßnahmenliste verlangt dann, die Sinks und die Audit-Konfiguration wiederherzustellen und einen Sink auf Organisationsebene in einen gesperrten Bucket einzurichten.

Legitime Änderungen

Plattform-Teams ändern durchaus Sinks und Ausschlüsse, typischerweise über Terraform, aus der CI, zu Bürozeiten, mit einem Change-Ticket. Ein Ausschluss, der laute Load-Balancer-Logs verwirft, ist normal; ein Ausschluss, der auf protoPayload.authenticationInfo.principalEmail eines einzelnen Benutzers filtert, ist es nicht. Lesen Sie den Filter.

Häufige Fragen

Kann ein Angreifer Audit-Logs in Google Cloud löschen?

Nicht die Admin-Activity- und System-Event-Logs im Bucket _Required: Dessen Sink kann weder geändert noch gelöscht werden, und der Bucket bewahrt sie 400 Tage auf. Ein Angreifer mit ausreichenden Rechten kann jedoch Sinks löschen, die Logs an andere Orte kopieren, Ausschlüsse anlegen, den Sink _Default deaktivieren, Log-Buckets ändern, Log-Einträge im Bucket _Default löschen und das Data-Access-Logging abschalten.

Wird das Löschen eines Log-Sinks selbst protokolliert?

Ja. google.logging.v2.ConfigServiceV2.DeleteSink ist ein Admin-Activity-Audit-Log-Eintrag; die Löschung wird also mit Aufrufer und IP im Bucket _Required erfasst.

Weiterführende Links

• Route log entries (routing overview) – Dokumentation von Google Cloud.
• Best practices for Cloud Audit Logs – Dokumentation von Google Cloud.
• GCP-Data-Access-Logs: standardmäßig aus – und andere Lücken.