Bedrohungen untersuchen und darauf reagieren

Dieses Thema bietet informelle Anleitungen zum Untersuchen und Reagieren von Bedrohungen. Verwenden Sie zusätzliche Ressourcen, um den Security Command Center-Ergebnissen Kontext hinzuzufügen. Mit den folgenden Schritten können Sie verstehen, was bei einem potenziellen Angriff passiert ist, und mögliche Antworten für die betroffenen Ressourcen entwickeln.

Die Techniken auf dieser Seite können nicht garantiert werden, dass sie vor vorherigen, aktuellen oder zukünftigen Bedrohungen wirksam sind. Unter Bedrohungen beheben erfahren Sie, warum Security Command Center keine offizielle Korrekturmaßnahme für Bedrohungen bietet.

Hinweise

Sie benötigen ausreichende IAM-Rollen (Identity and Access Management), um Ergebnisse und Logs aufzurufen oder zu bearbeiten und Google Cloud-Ressourcen zu ändern. Wenn in Security Command Center Zugriffsfehler auftreten, wenden Sie sich an Ihren Administrator und lesen Sie die Informationen zur Zugriffssteuerung. Informationen zum Beheben von Ressourcenfehlern finden Sie in der Dokumentation für betroffene Produkte.

Ergebnisse zu Bedrohungen

Event Threat Detection ermittelt Sicherheitsergebnisse, indem Ereignisse in Ihren Cloud Logging-Logstreams mit bekannten Gefahrenindikatoren abgeglichen werden. IoCs, die von internen Google-Sicherheitsquellen entwickelt wurden, identifizieren potenzielle Sicherheitslücken und Angriffe. Event Threat Detection identifiziert Bedrohungen auch durch bekannte Angreifertaktiken, -techniken und -verfahren in Ihrem Logging-Stream sowie durch die Erkennung von Abweichungen vom bisherigen Verhalten Ihrer Organisation oder Ihres Projekts. Wenn Sie die Premium-Stufe von Security Command Center auf Organisationsebene aktivieren, kann Event Threat Detection auch Ihre Google Workspace-Logs scannen.

Container Threat Detection generiert Ergebnisse, indem das Low-Level-Verhalten im Gast-Kernel von Containern erfasst und analysiert wird.

Die Ergebnisse werden in Security Command Center geschrieben. Wenn Sie die Premium-Stufe von Security Command Center auf Organisationsebene aktivieren, können Sie Ergebnisse auch so konfigurieren, dass sie in Cloud Logging geschrieben werden.

Ergebnisse prüfen

So prüfen Sie die gefundenen Bedrohungen in der Google Cloud Console:

1. Rufen Sie in der Google Cloud Console die Seite Ergebnisse von Security Command Center auf.

   Zu Ergebnissen

2. Wählen Sie bei Bedarf Ihr Google Cloud-Projekt, Ihren Ordner oder Ihre Organisation aus.

   

3. Klicken Sie im Bereich Schnellfilter auf einen geeigneten Filter, um das gewünschte Ergebnis in der Tabelle Ergebnisse der Ergebnisabfrage anzuzeigen. Wenn Sie beispielsweise im Unterabschnitt Anzeigename der Quelle die Option Event Threat Detection oder Container Threat Detection auswählen, werden nur Ergebnisse des ausgewählten Dienstes in den Ergebnissen angezeigt.

   Die Tabelle enthält die Ergebnisse für die ausgewählte Quelle.

4. Klicken Sie auf den Namen des Ergebnisses unter Category, um Details zu einem bestimmten Ergebnis aufzurufen. Der Bereich mit den Ergebnisdetails wird erweitert und zeigt eine Zusammenfassung der Details des Ergebnisses an.

5. Klicken Sie auf den Tab JSON, um die JSON-Definition des Ergebnisses aufzurufen.

Die Ergebnisse liefern die Namen und numerischen Kennzeichnungen der an einem Vorfall beteiligten Ressourcen sowie Umgebungsvariablen und Asset-Attribute. Mit diesen Informationen können Sie betroffene Ressourcen schnell isolieren und den potenziellen Umfang eines Ereignisses feststellen.

Bedrohungsergebnissen enthalten auch Links zu den folgenden externen Ressourcen, um Sie bei der Untersuchung zu unterstützen:

• MITRE ATT&CK-Framework-Einträgen. Das Framework erklärt Techniken für Angriffe auf Cloud-Ressourcen und bietet Anleitungen zur Problembehebung.
• VirusTotal, ein Alphabet-eigener Dienst, der Kontext zu potenziell schädlichen Dateien, URLs, Domains und IP-Adressen bereitstellt.

In den folgenden Abschnitten werden potenzielle Antworten auf Bedrohungsergebnisse beschrieben.

Deaktivierung der gefundenen Bedrohungen

Nachdem Sie ein Problem behoben haben, das ein Bedrohungsergebnis ausgelöst hat, setzt Security Command Center den Status des Ergebnisses nicht automatisch auf INACTIVE. Der Status eines Bedrohungsergebnisses bleibt ACTIVE, sofern Sie die Eigenschaft state nicht manuell auf INACTIVE setzen.

Bei einem falsch positiven Ergebnis können Sie den Status des Ergebnisses als ACTIVE belassen und stattdessen das Ergebnis stummschalten.

Erstellen Sie für dauerhafte oder wiederkehrende falsch positive Ergebnisse eine Ausblendungsregel. Das Festlegen einer Ausblendungsregel kann die Anzahl der Ergebnisse reduzieren, die Sie verwalten müssen. Dadurch ist es leichter, eine echte Bedrohung zu erkennen, wenn eine solche eintritt.

Bevor Sie bei einer echten Bedrohung den Status des Ergebnisses auf INACTIVE setzen, sollten Sie die Bedrohung beseitigen und die erkannte Bedrohung, das Ausmaß des Angriffs und alle anderen damit in Verbindung stehenden Ergebnisse und Probleme gründlich untersuchen.

Informationen zum Ausblenden eines Ergebnisses oder zum Ändern seines Status finden Sie in den folgenden Themen:

• Ergebnisse ausblenden.
• Status eines Ergebnisses ändern

Event Threat Detection-Antworten

Weitere Informationen zu Event Threat Detection finden Sie unter Funktionsweise von Event Threat Detection.

Dieser Abschnitt enthält keine Antworten auf Ergebnisse, die von benutzerdefinierten Modulen für Event Threat Detection generiert wurden, da Ihre Organisation die empfohlenen Maßnahmen für diese Detektoren definiert.

Evasion: Access from Anonymizing Proxy

Der anomale Zugriff von einem anonymen Proxy wird durch Untersuchung der Cloud-Audit-Logs auf Google Cloud-Dienständerungen erkannt, die von anonymen Proxy-IP-Adressen wie Tor-IP-Adressen stammen.

So reagieren Sie auf diese Ergebnisse:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Evasion: Access from Anonymizing Proxy-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Bereich für die Ergebnisdetails wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Prüfen Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung die Werte in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: Das Konto, über das die Änderungen vorgenommen wurden (ein potenziell manipuliertes Konto).
     • IP: Die Proxy-IP-Adresse, von der aus die Änderungen vorgenommen werden.
   • Betroffene Ressource
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

3. Klicken Sie optional auf den Tab JSON, um zusätzliche Ergebnisfelder anzusehen.

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Proxy: Multi-Hop-Proxy.
2. Wenden Sie sich im Feld principalEmail an den Inhaber des Kontos. Bestätigen Sie, dass die Aktion vom legitimen Inhaber ausgeführt wurde.
3. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Defense Evasion: Breakglass Workload Deployment Created

Vorschau

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Breakglass Workload Deployment Created wird durch Prüfen von Cloud-Audit-Logs erkannt, ob es Deployments für Arbeitslasten gibt, die das Break-Glass-Flag zum Überschreiben der Binärautorisierungseinstellungen verwenden.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Defense Evasion: Breakglass Workload Deployment Created, wie unter Ergebnisse prüfen beschrieben. Der Bereich für die Ergebnisdetails wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: das Konto, über das die Änderung vorgenommen wurde.
     • Methodenname: Die aufgerufene Methode.
     • Kubernetes-Pods: Pod-Name und Namespace.
   • Betroffene Ressource, insbesondere das folgende Feld:
     • Anzeigename der Ressource: der GKE-Namespace, in dem das Deployment stattgefunden hat.
   • Weitere Informationen:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

Schritt 2: Protokolle prüfen

1. Rufen Sie in der Google Cloud Console auf dem Tab Zusammenfassung der Ergebnisdetails den Log-Explorer auf, indem Sie auf den Link im Feld Cloud Logging-URI klicken.
2. Prüfen Sie den Wert im Feld protoPayload.resourceName, um die jeweilige Anfrage zur Zertifikatsignierung zu identifizieren.

3. Prüfen Sie mithilfe der folgenden Filter auf andere Aktionen, die vom Hauptkonto ausgeführt wurden:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Ersetzen Sie Folgendes:

   • CLUSTER_NAME: der Wert, den Sie in den Ergebnisdetails im Feld Anzeigename der Ressource notiert haben.

   • PRINCIPAL_EMAIL: der Wert, den Sie in den Ergebnisdetails im Feld Haupt-E-Mail-Adresse notiert haben.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Sehen Sie sich den Eintrag des MITRE ATT&CK-Frameworks für diesen Ergebnistyp an: Umgehung von Abwehrmaßnahmen: Bereitstellung von Break-Glass-Arbeitslasten.
2. Sie können verwandte Ergebnisse prüfen, indem Sie auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Zugehörige Ergebnisse auf den Link für Ähnliche Ergebnisse klicken.
3. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Defense Evasion: Breakglass Workload Deployment Updated

Vorschau

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Breakglass Workload Deployment Updated wird durch Prüfen von Cloud-Audit-Logs erkannt, ob Aktualisierungen für Arbeitslasten vorliegen, die mit dem Break-Glass-Flag die Einstellungen der Binärautorisierung überschreiben.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Defense Evasion: Breakglass Workload Deployment Updated, wie unter Ergebnisse prüfen beschrieben. Der Bereich für die Ergebnisdetails wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: das Konto, über das die Änderung vorgenommen wurde.
     • Methodenname: Die aufgerufene Methode.
     • Kubernetes-Pods: Pod-Name und Namespace.
   • Betroffene Ressource, insbesondere das folgende Feld:
     • Anzeigename der Ressource: der GKE-Namespace, in dem das Update aufgetreten ist.
   • Weitere Informationen:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

Schritt 2: Protokolle prüfen

1. Rufen Sie in der Google Cloud Console auf dem Tab Zusammenfassung der Ergebnisdetails den Log-Explorer auf, indem Sie auf den Link im Feld Cloud Logging-URI klicken.
2. Prüfen Sie den Wert im Feld protoPayload.resourceName, um die jeweilige Anfrage zur Zertifikatsignierung zu identifizieren.

3. Prüfen Sie mithilfe der folgenden Filter auf andere Aktionen, die vom Hauptkonto ausgeführt wurden:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Ersetzen Sie Folgendes:

   • CLUSTER_NAME: der Wert, den Sie in den Ergebnisdetails im Feld Anzeigename der Ressource notiert haben.

   • PRINCIPAL_EMAIL: der Wert, den Sie in den Ergebnisdetails im Feld Haupt-E-Mail-Adresse notiert haben.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Sehen Sie sich den Eintrag des MITRE ATT&CK-Frameworks für diesen Ergebnistyp an: Umgehung von Abwehrmaßnahmen: Bereitstellung von Break-Glass-Arbeitslasten.
2. Sie können verwandte Ergebnisse prüfen, indem Sie auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Zugehörige Ergebnisse auf den Link für Ähnliche Ergebnisse klicken.
3. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Defense Evasion: Modify VPC Service Control

Dieses Ergebnis ist für Aktivierungen auf Projektebene nicht verfügbar.

Audit-Logs werden untersucht, um Änderungen an VPC Service Controls-Perimetern zu erkennen, die zu einem geringeren Schutz in diesem Perimeter führen würden. Hier einige Beispiele:

• Ein Projekt wird aus einem Perimeter entfernt.
• Einem Perimeter wird eine Zugriffsebenen-Richtlinie hinzugefügt
• Ein oder mehrere Dienste werden der Liste der zugänglichen Dienste hinzugefügt.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Defense Evasion: Modify VPC Service Control wie unter Ergebnisse prüfen beschrieben. Der Bereich mit den Details des Ergebnisses wird mit dem Tab Zusammenfassung geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere das folgende Feld:
     • Haupt-E-Mail-Adresse: das Konto, über das die Änderung vorgenommen wurde.
   • Betroffene Ressource, insbesondere das folgende Feld:
     • Vollständiger Name der Ressource: Der Name des VPC Service Controls-Perimeters, der geändert wurde.
   • Weitere Informationen:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

3. Klicken Sie auf den Tab JSON.

4. Beachten Sie in der JSON-Datei die folgenden Felder.

   • sourceProperties
     • properties
       • name: der Name des geänderten VPC Service Controls-Perimeters
       • policyLink: der Link zur Zugriffsrichtlinie, die den Perimeter steuert
       • delta: die Änderungen, entweder REMOVE oder ADD, an einem Perimeter, der den Schutz reduziert hat
       • restricted_resources: die Projekte, die den Einschränkungen dieses Perimeters folgen Der Schutz wird verringert, wenn Sie ein Projekt entfernen.
       • restricted_services: die Dienste, für die die Ausführung durch die Einschränkungen dieses Perimeters unzulässig ist Der Schutz wird reduziert, wenn Sie einen eingeschränkten Dienst entfernen.
       • allowed_services: die Dienste, die gemäß den Einschränkungen dieses Perimeters ausgeführt werden dürfen Der Schutz wird reduziert, wenn Sie einen zulässigen Dienst hinzufügen.
       • access_levels: Die Zugriffsebenen, die so konfiguriert sind, dass sie Zugriff auf Ressourcen unter dem Perimeter zulassen. Der Schutz wird reduziert, wenn Sie weitere Zugriffsebenen hinzufügen

Schritt 2: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.
2. Verwenden Sie die folgenden Filter, um Logs zu Administratoraktivitäten im Zusammenhang mit VPC Service Controls-Änderungen zu finden:
   • protoPayload.methodName:"AccessContextManager.UpdateServicePerimeter"
   • protoPayload.methodName:"AccessContextManager.ReplaceServicePerimeters"

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Defense Evasion: Modify Authentication Process.
2. Sie können verwandte Ergebnisse prüfen, indem Sie auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Zugehörige Ergebnisse auf den Link für Ähnliche Ergebnisse klicken.
3. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 4: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber der VPC Service Controls-Richtlinie und des Perimeters.
• Sie sollten die Änderungen für den Perimeter rückgängig machen, bis die Untersuchung abgeschlossen ist.
• Vielleicht sollten Sie Access Context Manager-Rollen für das Hauptkonto widerrufen, das den Perimeter geändert hat, bis die Untersuchung abgeschlossen ist.
• Untersuchen Sie, wie die reduzierten Schutzmaßnahmen verwendet wurden. Prüfen Sie, wer diesen Dienst verwendet und was übertragen wird, wenn beispielsweise die "BigQuery Data Transfer Service API" aktiviert oder als zulässiger Dienst hinzugefügt wurde.

Discovery: Can get sensitive Kubernetes object check

Ein potenziell böswilliger Akteur hat mit dem Befehl kubectl auth can-i get versucht, herauszufinden, welche vertraulichen Objekte in GKE abfragen können. Konkret führte der Schauspieler einen der folgenden Befehle aus:

• kubectl auth can-i get '*'
• kubectl auth can-i get secrets
• kubectl auth can-i get clusterroles/cluster-admin

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Discovery: Can get sensitive Kubernetes object check wie unter Ergebnisse prüfen beschrieben.

2. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Felder:

   • Gehen Sie unter Was erkannt wurde so vor:
     • Kubernetes-Zugriffsprüfungen: Die angeforderten Informationen zur Zugriffsprüfung, basierend auf der k8s-Ressource SelfSubjectAccessReview.
     • Haupt-E-Mail-Adresse: das Konto, über das der Anruf getätigt wurde.
   • Unter Betroffene Ressource:
     • Anzeigename der Ressource: der Kubernetes-Cluster, in dem die Aktion aufgetreten ist
   • Unter Weitere Informationen:
     • Cloud Logging-URI: Link zu Logging-Einträgen.

Schritt 2: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.

2. Prüfen Sie auf der Seite, die geladen wird, mithilfe der folgenden Filter nach anderen Aktionen, die vom Hauptkonto ausgeführt wurden:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Ersetzen Sie Folgendes:

   • CLUSTER_NAME: der Wert, den Sie in den Ergebnisdetails im Feld Anzeigename der Ressource notiert haben.

   • PRINCIPAL_EMAIL: der Wert, den Sie in den Ergebnisdetails im Feld Haupt-E-Mail-Adresse notiert haben.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Sehen Sie sich die MITRE ATT&CK-Framework-Einträge für diesen Ergebnistyp an: Discovery.
2. Prüfen Sie die Vertraulichkeit des abgefragten Objekts und ermitteln Sie, ob es in den Logs andere Anzeichen für schädliche Aktivitäten des Hauptkontos gibt.

3. Wenn das Konto, das Sie in den Ergebnisdetails in der Zeile Haupt-E-Mail-Adresse angegeben haben, kein Dienstkonto ist, fragen Sie den Inhaber des Kontos, ob der legitime Inhaber die Aktion durchgeführt hat.

   Wenn die Haupt-E-Mail-Adresse ein Dienstkonto (IAM oder Kubernetes) ist, ermitteln Sie die Quelle der Zugriffsprüfung, um deren Legitimität zu ermitteln.

4. Kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung, um einen Reaktionsplan zu entwickeln.

Exfiltration: BigQuery Data Exfiltration

Ergebnisse, die von Exfiltration: BigQuery Data Exfiltration zurückgegeben werden, enthalten eine von zwei möglichen Unterregeln. Jede untergeordnete Regel hat einen anderen Schweregrad:

• Untergeordnete Regel exfil_to_external_table mit Schweregrad = HIGH:
  • Eine Ressource wurde außerhalb Ihrer Organisation oder Ihres Projekts gespeichert.
• Untergeordnete Regel vpc_perimeter_violation mit Schweregrad = LOW:
  • VPC Service Controls hat einen Kopiervorgang oder einen Versuch, auf BigQuery-Ressourcen zuzugreifen, blockiert.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Exfiltration: BigQuery Data Exfiltration wie unter Ergebnisse prüfen beschrieben.

2. Sehen Sie sich auf dem Tab Zusammenfassung des Felds mit den Ergebnisdetails die Werte in den folgenden Abschnitten an:

   • Erkannt:
     • Schweregrad: Der Schweregrad ist entweder HIGH für die untergeordnete Regel exfil_to_external_table oder LOW für die untergeordnete Regel vpc_perimeter_violation.
     • Haupt-E-Mail-Adresse: Das Konto, über das die Daten exfiltriert wurden.
     • Exfiltrationsquellen: Details zu den Tabellen, aus denen Daten exfiltriert wurden.
     • Exfiltrationsziele: Details zu den Tabellen, in denen die exfiltrierten Daten gespeichert wurden.
   • Betroffene Ressource:
     • Vollständiger Name der Ressource: Der vollständige Ressourcenname des Projekts, des Ordners oder der Organisation, aus der Daten ausgeschleust wurden.
   • Weitere Informationen:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
     • Chronicle: Link zu Google SecOps.

3. Klicken Sie auf den Tab Quellattribute und prüfen Sie die angezeigten Felder.

   • detectionCategory:
     • subRuleName: entweder exfil_to_external_table oder vpc_perimeter_violation.
   • evidence:
     • sourceLogId:
       • projectId: Das Google Cloud-Projekt, das das BigQuery-Quell-Dataset enthält.
   • properties
     • dataExfiltrationAttempt
       • jobLink: der Link zum BigQuery-Job, der Daten ausgeschleust hat.
       • query: die für das BigQuery-Dataset ausgeführte SQL-Abfrage.

4. Klicken Sie optional auf den Tab JSON, um eine vollständige Liste der JSON-Attribute des Ergebnisses aufzurufen.

Schritt 2: Sicherheitsvorgänge von Google untersuchen

Sie können dies mit Google Security Operations untersuchen. Google SecOps ist ein Google Cloud-Dienst, mit dem Sie Bedrohungen in einer einheitlichen Zeitachse untersuchen und durch zugehörige Entitäten pivotieren können. Google SecOps reichert die Ergebnisdaten an, sodass Sie relevante Indikatoren identifizieren und Untersuchungen vereinfachen können.

Sie können Google SecOps nur verwenden, wenn Sie Security Command Center auf Organisationsebene aktivieren.

1. Wechseln Sie in der Google Cloud Console zur Seite Ergebnisse des Security Command Center.

   Zu Ergebnissen

2. Scrollen Sie im Bereich Schnellfilter nach unten zu Anzeigename der Quelle.

3. Wählen Sie im Abschnitt Anzeigename der Quelle die Option Event Threat Detection aus.

   Die Tabelle wird mit Ergebnissen von Event Threat Detection gefüllt.

4. Klicken Sie in der Tabelle unter Kategorie auf ein Exfiltration: BigQuery Data Exfiltration-Ergebnis. Der Detailbereich für das Ergebnis wird geöffnet.

5. Klicken Sie im Bereich Weitere Informationen des Bereichs mit den Ergebnisdetails auf In Chronicle untersuchen.

6. Folgen Sie der Anleitung in der geführten Benutzeroberfläche von Google SecOps.

Orientieren Sie sich an den folgenden Leitfäden, um Prüfungen in Google SecOps durchzuführen:

• Nutzer untersuchen
• Asset untersuchen

Schritt 3: Berechtigungen und Einstellungen prüfen

1. Öffnen Sie in der Google Cloud Console die Seite IAM.

   IAM aufrufen

2. Wählen Sie bei Bedarf das Projekt aus, das im Feld projectId der Ergebnis-JSON-Datei aufgeführt ist.

3. Geben Sie auf der angezeigten Seite im Feld Filter die unter Haupt-E-Mail aufgeführte E-Mail-Adresse ein und überprüfen Sie, welche Berechtigungen dem Konto zugewiesen sind.

Schritt 4: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.

2. Verwenden Sie die folgenden Filter, um Logs zur Administratoraktivität im Zusammenhang mit BigQuery-Jobs zu finden:

   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Schritt 5: Angriffs- und Reaktionsmethoden untersuchen

1. Prüfen Sie den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp: Exfiltration over Web Service: Exfiltration to Cloud Storage.
2. Sie können verwandte Ergebnisse prüfen, indem Sie auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Zugehörige Ergebnisse auf den Link für Ähnliche Ergebnisse klicken. Ähnliche Ergebnisse sind für dieselbe Instanz und dasselbe Netzwerk identisch.
3. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 6: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Den Inhaber des Projekts mit exfiltrierten Daten kontaktieren
• Ziehen Sie in Betracht, Berechtigungen für userEmail zu widerrufen, bis die Untersuchung abgeschlossen ist.
• Wenn Sie die weitere Exfiltration verhindern möchten, fügen Sie den betroffenen BigQuery-Datasets restriktive IAM-Richtlinien hinzu (exfiltration.sources und exfiltration.targets).
• Um betroffene Datasets auf vertrauliche Informationen zu scannen, verwenden Sie den Schutz sensibler Daten. Sie können auch Schutzdaten sensibler Daten an Security Command Center senden. Je nach Umfang der Informationen können die Kosten für den Schutz sensibler Daten beträchtlich sein. Befolgen Sie die Best Practices, um die Kosten für den Schutz sensibler Daten unter Kontrolle zu halten.
• Zugriff auf die BigQuery API beschränken
• Um IAM-Rollen mit zu vielen Berechtigungen zu identifizieren und zu beheben, verwenden Sie IAM Recommender.

Exfiltration: BigQuery Data Extraction

Die Daten-Exfiltration aus BigQuery wird anhand von Audit-Logs für zwei Szenarien erkannt:

• Eine Ressource wird in einem Cloud Storage-Bucket außerhalb Ihrer Organisation gespeichert.
• Eine Ressource wird in einem öffentlich zugänglichen Cloud Storage-Bucket Ihrer Organisation gespeichert.

Bei Aktivierungen der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Exfiltration: BigQuery Data Extraction-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet.

2. Sehen Sie sich auf dem Tab Zusammenfassung des Felds mit den Ergebnisdetails die Werte in den folgenden Abschnitten an:

   • Erkannt:
     • Haupt-E-Mail-Adresse: Das Konto, über das die Daten exfiltriert wurden.
     • Exfiltrationsquellen: Details zu den Tabellen, aus denen Daten exfiltriert wurden.
     • Exfiltrationsziele: Details zu den Tabellen, in denen die exfiltrierten Daten gespeichert wurden.
   • Betroffene Ressource:
     • Vollständiger Name der Ressource: Der Name der BigQuery-Ressource, deren Daten exfiltriert wurden.
     • Vollständiger Name des Projekts: Das Google Cloud-Projekt, das das BigQuery-Quell-Dataset enthält.
   • Weitere Informationen:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

3. Klicken Sie im Bereich mit den Ergebnisdetails auf den Tab JSON.

4. Beachten Sie in der JSON-Datei die folgenden Felder.

   • sourceProperties:
     • evidence:
       • sourceLogId:
       • projectId: Das Google Cloud-Projekt, das das BigQuery-Quell-Dataset enthält.
     • properties:
       • extractionAttempt:
       • jobLink: der Link zum BigQuery-Job, der Daten ausgeschleust hat

Schritt 2: Berechtigungen und Einstellungen prüfen

1. Öffnen Sie in der Google Cloud Console die Seite IAM.

   IAM aufrufen

2. Wählen Sie bei Bedarf das Projekt aus, das im Feld projectId der Ergebnis-JSON-Datei aufgeführt ist (aus Schritt 1).

3. Geben Sie auf der angezeigten Seite im Feld Filter die E-Mail-Adresse ein, die unter Haupt-E-Mail (aus Schritt 1) aufgeführt ist, und prüfen Sie, welche Berechtigungen dem Konto zugewiesen sind.

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.
2. Suchen Sie mit den folgenden Filtern nach Administratoraktivitätslogs, die sich auf BigQuery-Jobs beziehen:
   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Prüfen Sie den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp: Exfiltration over Web Service: Exfiltration to Cloud Storage.
2. Sie können verwandte Ergebnisse prüfen, indem Sie in den Ergebnisdetails auf dem Tab Zusammenfassung in der Zeile Ähnliche Ergebnisse auf den Link klicken. Ähnliche Ergebnisse sind für dieselbe Instanz und dasselbe Netzwerk identisch.
3. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 5: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Den Inhaber des Projekts mit exfiltrierten Daten kontaktieren
• Sie können die Berechtigungen für das Hauptkonto widerrufen, das auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Hauptkonto-E-Mail aufgeführt ist, bis die Prüfung abgeschlossen ist.
• Wenn Sie die weitere Daten-Exfiltration stoppen möchten, fügen Sie den betroffenen BigQuery-Datasets, die im Feld Exfiltrationsquellen auf dem Tab Zusammenfassung der Ergebnisdetails angegeben sind, reduzierende IAM-Richtlinien hinzu.
• Um betroffene Datasets auf vertrauliche Informationen zu scannen, verwenden Sie den Schutz sensibler Daten. Sie können auch Schutzdaten sensibler Daten an Security Command Center senden. Je nach Umfang der Informationen können die Kosten für den Schutz sensibler Daten beträchtlich sein. Befolgen Sie die Best Practices, um die Kosten für den Schutz sensibler Daten unter Kontrolle zu halten.
• Zugriff auf die BigQuery API beschränken
• Wenn Sie der Inhaber des Buckets sind, sollten Sie Berechtigungen für den öffentlichen Zugriff widerrufen.
• Um IAM-Rollen mit zu vielen Berechtigungen zu identifizieren und zu beheben, verwenden Sie IAM Recommender.

Exfiltration: BigQuery Data to Google Drive

Eine Daten-Exfiltration in BigQuery wird anhand von Audit-Logs für das folgende Szenario erkannt:

• Eine Ressource wird in einem Google Drive-Ordner gespeichert.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Exfiltration: BigQuery Data to Google Drive-Ergebnis, wie unter Ergebnisse prüfen beschrieben.

2. Prüfen Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, z. B.:
     • Haupt-E-Mail-Adresse: Das Konto, über das die Daten exfiltriert wurden.
     • Quellen zur Datenausschleusung: Details zur BigQuery-Tabelle, aus der Daten exfiltriert wurden.
     • Exfiltrationsziele: Details zum Ziel in Google Drive.
   • Betroffene Ressource, einschließlich:
     • Vollständiger Name der Ressource: Der Name der BigQuery-Ressource, deren Daten exfiltriert wurden.
     • Vollständiger Name des Projekts: Das Google Cloud-Projekt, das das BigQuery-Quell-Dataset enthält.
   • Weitere Informationen, darunter:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

3. Weitere Informationen erhalten Sie, wenn Sie auf den Tab JSON klicken.

4. Beachten Sie in der JSON-Datei die folgenden Felder.

   • sourceProperties:
     • evidence:
       • sourceLogId:
       • projectId: Das Google Cloud-Projekt, das das BigQuery-Quell-Dataset enthält.
     • properties:
       • extractionAttempt:
       • jobLink: der Link zum BigQuery-Job, der Daten exfiltriert hat

Schritt 2: Berechtigungen und Einstellungen prüfen

1. Öffnen Sie in der Google Cloud Console die Seite IAM.

   IAM aufrufen

2. Wählen Sie bei Bedarf das Projekt aus, das im Feld projectId der Ergebnis-JSON-Datei aufgeführt ist (aus Schritt 1).

3. Geben Sie auf der angezeigten Seite im Feld Filter die E-Mail-Adresse ein, die in access.principalEmail (aus Schritt 1) aufgeführt ist, und prüfen Sie, welche Berechtigungen dem Konto zugewiesen sind.

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.
2. Suchen Sie mit den folgenden Filtern nach Administratoraktivitätslogs, die sich auf BigQuery-Jobs beziehen:
   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Prüfen Sie den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp: Exfiltration over Web Service: Exfiltration to Cloud Storage.
2. Sie können verwandte Ergebnisse prüfen, indem Sie auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Zugehörige Ergebnisse auf den Link für Ähnliche Ergebnisse klicken. Ähnliche Ergebnisse sind für dieselbe Instanz und dasselbe Netzwerk identisch.
3. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 5: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Den Inhaber des Projekts mit exfiltrierten Daten kontaktieren
• Ziehen Sie in Betracht, für das Hauptkonto im Feld access.principalEmail Berechtigungen zu widerrufen, bis die Untersuchung abgeschlossen ist.
• Wenn Sie die weitere Exfiltration verhindern möchten, fügen Sie den betroffenen BigQuery-Datasets restriktive IAM-Richtlinien hinzu (exfiltration.sources).
• Um betroffene Datasets auf vertrauliche Informationen zu scannen, verwenden Sie den Schutz sensibler Daten. Sie können auch Schutzdaten sensibler Daten an Security Command Center senden. Je nach Umfang der Informationen können die Kosten für den Schutz sensibler Daten beträchtlich sein. Befolgen Sie die Best Practices, um die Kosten für den Schutz sensibler Daten unter Kontrolle zu halten.
• Zugriff auf die BigQuery API beschränken
• Um IAM-Rollen mit zu vielen Berechtigungen zu identifizieren und zu beheben, verwenden Sie IAM Recommender.

Exfiltration: Cloud SQL Data Exfiltration

Eine Daten-Exfiltration aus Cloud SQL wird durch die Untersuchung von Audit-Logs für zwei Szenarien erkannt:

• Live-Instanzdaten, die in einen Cloud Storage-Bucket außerhalb der Organisation exportiert wurden
• Live-Instanzdaten, die in einen Cloud Storage-Bucket exportiert wurden, der der Organisation gehört und öffentlich zugänglich

Alle Cloud SQL-Instanztypen werden unterstützt.

Bei Aktivierungen der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Exfiltration: Cloud SQL Data Exfiltration-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse : das Konto, das zur Exfiltrierung der Daten verwendet wird.
     • Exfiltrationsquellen: Details zur Cloud SQL-Instanz, deren Daten ausgeschleust wurden.
     • Exfiltrationsziele: Details zum Cloud Storage-Bucket, in den die Daten exportiert wurden.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der Ressourcenname von Cloud SQL, dessen Daten exfiltriert wurden.
     • Vollständiger Name des Projekts: Das Google Cloud-Projekt, das die Cloud SQL-Quelldaten enthält.
   • Weitere Informationen, darunter:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

3. Klicken Sie auf den Tab JSON.

4. Beachten Sie in der JSON-Datei für das Ergebnis die folgenden Felder:

   • sourceProperties:
     • evidence:
     • sourceLogId:
       • projectId: das Google Cloud-Projekt, das die Cloud SQL-Quellinstanz enthält.
     • properties
     • bucketAccess: gibt an, ob der Cloud Storage-Bucket öffentlich zugänglich oder außerhalb der Organisation befindet
     • exportScope: gibt an, wie viele Daten exportiert wurden, z. B. die gesamte Instanz, eine oder mehrere Datenbanken, eine oder mehrere Tabellen oder eine durch eine Abfrage angegebene Teilmenge.

Schritt 2: Berechtigungen und Einstellungen prüfen

1. Öffnen Sie in der Google Cloud Console die Seite IAM.

   IAM aufrufen

2. Wählen Sie bei Bedarf das Projekt der Instanz aus, das im Feld projectId der Ergebnis-JSON-Datei aufgeführt ist (aus Schritt 1).

3. Geben Sie auf der angezeigten Seite im Feld Filter die E-Mail-Adresse ein, die auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Haupt-E-Mail aufgeführt ist (aus Schritt 1). Prüfen Sie, welche Berechtigungen dem Konto zugewiesen sind.

Schritt 3: Protokolle prüfen

1. Rufen Sie in der Google Cloud Console den Log-Explorer auf. Klicken Sie dazu auf den Link in Cloud Logging-URI (aus Schritt 1). Die Seite Log-Explorer enthält alle Logs für die entsprechende Cloud SQL-Instanz.

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Prüfen Sie den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp: Exfiltration over Web Service: Exfiltration to Cloud Storage.
2. Prüfen Sie die zugehörigen Ergebnisse, indem Sie auf den Link in der Zeile Ähnliche Ergebnisse klicken, der in Schritt 1 beschrieben wurde. Ähnliche Ergebnisse haben in derselben Cloud SQL-Instanz denselben Ergebnistyp.
3. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 5: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Den Inhaber des Projekts mit exfiltrierten Daten kontaktieren
• Ziehen Sie in Betracht, Berechtigungen für access.principalEmail zu widerrufen, bis die Untersuchung abgeschlossen ist.
• Um eine weitere Daten-Exfiltration zu stoppen, fügen Sie den betroffenen Cloud SQL-Instanzen restriktive Richtlinien hinzu.
  • MySQL
  • PostgreSQL
  • SQL Server
• Beschränken Sie den Zugriff auf die Cloud SQL Admin API und den Export aus der Cloud SQL Admin API mit VPC Service Controls.
• Um IAM-Rollen mit zu vielen Berechtigungen zu identifizieren und zu beheben, verwenden Sie IAM Recommender.

Exfiltration: Cloud SQL Restore Backup to External Organization

Die Daten-Exfiltration aus einer Cloud SQL-Sicherung wird mithilfe von Audit-Logs erkannt, um festzustellen, ob Daten aus der Sicherung in einer Cloud SQL-Instanz außerhalb der Organisation oder des Projekts wiederhergestellt wurden. Alle Cloud SQL-Instanz- und Sicherungstypen werden unterstützt.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Exfiltration: Cloud SQL Restore Backup to External Organization-Ergebnis, wie unter Ergebnisse prüfen beschrieben.

2. Prüfen Sie auf dem Tab Zusammenfassung des Felds mit den Ergebnisdetails die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: Das Konto, über das die Daten exfiltriert wurden.
     • Exfiltrationsquellen: Details zur Cloud SQL-Instanz, aus der die Sicherung erstellt wurde.
     • Exfiltrationsziele: Details zur Cloud SQL-Instanz, auf der die Sicherungsdaten wiederhergestellt wurden.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der Ressourcenname der wiederhergestellten Sicherung.
     • Vollständiger Name des Projekts: Das Google Cloud-Projekt, das die Cloud SQL-Instanz enthält, aus der die Sicherung erstellt wurde.

3. Weitere Informationen, insbesondere die folgenden Felder:

   • Cloud Logging-URI: Link zu Logging-Einträgen.
   • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
   • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

4. Klicken Sie auf den Tab JSON.

5. Beachten Sie in der JSON-Datei die folgenden Felder.

   • resource:
     • parent_name: der Ressourcenname der Cloud SQL-Instanz, aus der die Sicherung erstellt wurde.
   • evidence:
     • sourceLogId:
       • projectId: Das Google Cloud-Projekt, das das BigQuery-Quell-Dataset enthält.
   • properties:
     • restoreToExternalInstance:
       • backupId: die ID des wiederhergestellten Sicherungslaufs

Schritt 2: Berechtigungen und Einstellungen prüfen

1. Öffnen Sie in der Google Cloud Console die Seite IAM.

   IAM aufrufen

2. Wählen Sie bei Bedarf das Projekt der Instanz aus, das im Feld projectId der Ergebnis-JSON-Datei aufgeführt ist (aus Schritt 1).

3. Geben Sie auf der angezeigten Seite im Feld Filter die E-Mail-Adresse ein, die unter Haupt-E-Mail-Adresse (aus Schritt 1) aufgeführt ist, und prüfen Sie, welche Berechtigungen dem Konto zugewiesen sind.

Schritt 3: Protokolle prüfen

1. Rufen Sie in der Google Cloud Console den Log-Explorer auf. Klicken Sie dazu auf den Link in Cloud Logging-URI (aus Schritt 1). Die Seite Log-Explorer enthält alle Logs, die sich auf die relevante Cloud SQL-Instanz beziehen.

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Prüfen Sie den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp: Exfiltration over Web Service: Exfiltration to Cloud Storage.
2. Überprüfen Sie die zugehörigen Ergebnisse, indem Sie auf den Link in der Zeile Ähnliche Ergebnisse klicken. (ab Schritt 1). Ähnliche Ergebnisse haben denselben Ergebnistyp auf derselben Cloud SQL-Instanz.
3. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 5: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Den Inhaber des Projekts mit exfiltrierten Daten kontaktieren
• Sie können die Berechtigungen für das Hauptkonto widerrufen, das auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Hauptkonto-E-Mail aufgeführt ist, bis die Prüfung abgeschlossen ist.
• Um eine weitere Daten-Exfiltration zu stoppen, fügen Sie den betroffenen Cloud SQL-Instanzen restriktive Richtlinien hinzu.
  • MySQL
  • PostgreSQL
  • SQL Server
• Beschränken Sie den Zugriff auf die Cloud SQL Admin API mithilfe von VPC Service Controls.
• Um IAM-Rollen mit zu vielen Berechtigungen zu identifizieren und zu beheben, verwenden Sie IAM Recommender.

Exfiltration: Cloud SQL Over-Privileged Grant

Erkennt, wenn alle Berechtigungen für eine PostgreSQL-Datenbank (oder alle Funktionen oder Prozeduren in einer Datenbank) einem oder mehreren Datenbanknutzern gewährt werden.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Exfiltration: Cloud SQL Over-Privileged Grant wie unter Ergebnisse prüfen beschrieben.

2. Prüfen Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Anzeigename der Datenbank: der Name der Datenbank in der betroffenen PostgreSQL-Instanz von Cloud SQL
     • Name des Datenbanknutzers: der PostgreSQL-Nutzer, der nicht erforderliche Berechtigungen gewährt hat.
     • Datenbankabfrage: Die ausgeführte PostgreSQL-Abfrage, mit der die Berechtigungen gewährt wurden.
     • Datenbankempfänger: die Empfänger der über umfassenden Berechtigungen
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der Ressourcenname der betroffenen PostgreSQL-Instanz von Cloud SQL.
     • Vollständiger Name des übergeordneten Elements: Der Ressourcenname der PostgreSQL-Instanz von Cloud SQL.
     • Vollständiger Name des Projekts: Das Google Cloud-Projekt, das die PostgreSQL-Instanz von Cloud SQL enthält.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

3. Klicken Sie auf den Tab JSON, um die vollständige JSON-Datei für das Ergebnis anzusehen.

Schritt 2: Datenbankberechtigungen prüfen

1. Stellen Sie eine Verbindung zur PostgreSQL-Datenbank her.
2. Zugriffsberechtigungen für die folgenden Elemente auflisten und anzeigen:
   • Datenbanken. Verwenden Sie den Metabefehl \l oder \list und prüfen Sie, welche Berechtigungen für die Datenbank zugewiesen sind, die unter Anzeigename der Datenbank (aus Schritt 1) aufgeführt ist.
   • Funktionen oder Verfahren. Verwenden Sie den Metabefehl \df und prüfen Sie, welche Berechtigungen für Funktionen oder Prozeduren in der Datenbank zugewiesen sind, die unter Anzeigename der Datenbank (aus Schritt 1) aufgeführt ist.

Schritt 3: Protokolle prüfen

1. Rufen Sie in der Google Cloud Console den Log-Explorer auf. Klicken Sie dazu auf den Link in Cloud Logging-URI (aus Schritt 1). Die Seite Log-Explorer enthält alle Logs, die sich auf die relevante Cloud SQL-Instanz beziehen.
2. Prüfen Sie im Log-Explorer die PostgreSQL-pgaudit-Logs, in denen ausgeführte Abfragen an die Datenbank aufgezeichnet werden. Verwenden Sie dazu die folgenden Filter:
   • protoPayload.request.database="var class="edit">database"

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Sehen Sie sich den Eintrag zum MITRE ATT&CK-Framework für diesen Ergebnistyp an: Exfiltration über Webdienst.
2. Sie können feststellen, ob zusätzliche Abhilfemaßnahmen erforderlich sind, indem Sie Ihre Untersuchungsergebnisse mit MITRE-Studien kombinieren.

Schritt 5: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber der Instanz mit übermäßigen Berechtigungen.
• Sie können bis zum Abschluss der Prüfung alle Berechtigungen für die Empfänger, die unter Datenbankempfänger aufgeführt sind, entziehen.
• Zum Beschränken des Zugriffs auf die Datenbank (aus Anzeigename der Datenbank in Schritt 1) revoke von den Empfängern auf (von Teilnehmern der Datenbank in Schritt 1).

Initial Access: Database Superuser Writes to User Tables

Erkennt, wenn das Superuser-Konto der Cloud SQL-Datenbank (postgres für PostgreSQL und root für MySQL) in Nutzertabellen schreibt. Der Superuser (eine Rolle mit sehr großem Zugriff) sollte im Allgemeinen nicht zum Schreiben in Nutzertabellen verwendet werden. Für normale tägliche Aktivitäten sollte ein Nutzerkonto mit stärker eingeschränktem Zugriff verwendet werden. Wenn ein Superuser in eine Nutzertabelle schreibt, kann dies darauf hindeuten, dass ein Angreifer Berechtigungen ausgeweitet oder den Standarddatenbanknutzer manipuliert hat und Daten ändert. Er könnte auch auf normale, unsichere Praktiken hinweisen.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Initial Access: Database Superuser Writes to User Tables-Ergebnis, wie unter Ergebnisse prüfen beschrieben.

2. Prüfen Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Anzeigename der Datenbank: der Name der Datenbank in der betroffenen PostgreSQL- oder MySQL-Instanz von Cloud SQL
     • Datenbanknutzername: der Superuser
     • Datenbankabfrage: Die SQL-Abfrage, die beim Schreiben in Nutzertabellen ausgeführt wird.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der Ressourcenname der betroffenen Cloud SQL-Instanz.
     • Vollständiger Name des übergeordneten Elements: Der Ressourcenname der Cloud SQL-Instanz.
     • Vollständiger Name des Projekts: Das Google Cloud-Projekt, das die Cloud SQL-Instanz enthält.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

3. Klicken Sie auf den Tab JSON, um die vollständige JSON-Datei für das Ergebnis anzusehen.

Schritt 2: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console Log-Explorer. Klicken Sie dazu auf den Link in cloudLoggingQueryURI (aus Schritt 1). Die Seite Log-Explorer enthält alle Logs, die sich auf die relevante Cloud SQL-Instanz beziehen.
2. Prüfen Sie mithilfe der folgenden Filter die Logs für PostgreSQL pgaudit-Logs oder Cloud SQL for MySQL-Audit-Logs, die die vom Superuser ausgeführten Abfragen enthalten:
   • protoPayload.request.user="SUPERUSER"

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Sehen Sie sich den Eintrag zum MITRE ATT&CK-Framework für diesen Ergebnistyp an: Exfiltration über Webdienst.
2. Sie können feststellen, ob zusätzliche Abhilfemaßnahmen erforderlich sind, indem Sie Ihre Untersuchungsergebnisse mit MITRE-Studien kombinieren.

Schritt 4: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Prüfen Sie die Nutzer, die eine Verbindung zur Datenbank herstellen dürfen.

  • Informationen zu PostgreSQL finden Sie unter Nutzer erstellen und verwalten.
  • Für MySQL siehe Nutzer mit integrierter Authentifizierung verwalten

• Ändern Sie gegebenenfalls das Passwort für den Superuser.

  • Informationen zu PostgreSQL finden Sie unter Passwort für den Standardnutzer festlegen.
  • Für MySQL siehe Passwort für den Standardnutzer festlegen

• Erwägen Sie, einen neuen Nutzer mit eingeschränktem Zugriff für die verschiedenen Abfragetypen zu erstellen, die auf der Instanz verwendet werden.

  • Gewähren Sie dem neuen Nutzer nur die Berechtigungen, die zum Ausführen seiner Abfragen erforderlich sind.

    • Für PostgreSQL siehe Grant (Befehl)
    • Für MySQL siehe Zugriffssteuerung und Kontoverwaltung

  • Anmeldedaten für die Clients aktualisieren, die eine Verbindung zur Cloud SQL-Instanz herstellen

Initial Access: Anonymous GKE resource created from the internet

Vorschau

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Erkennt, wenn ein potenziell böswilliger Akteur einen der folgenden Kubernetes-Standardnutzer oder ‐Nutzergruppen zum Erstellen einer neuen Kubernetes-Ressource im Cluster verwendet hat:

• system:anonymous
• system:authenticated
• system:unauthenticated

Diese Nutzer und Gruppen sind praktisch anonym. Eine Bindung für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) in Ihrem Cluster hat diesem Nutzer die Berechtigung zum Erstellen dieser Ressourcen im Cluster gewährt.

Prüfen Sie die erstellte Ressource und die zugehörige RBAC-Bindung, um sicherzustellen, dass die Bindung erforderlich ist. Wenn die Bindung nicht erforderlich ist, entfernen Sie sie. Weitere Informationen finden Sie in der Lognachricht zu diesem Ergebnis.

Informationen zur Behebung dieses Problems finden Sie unter Standardrollen und ‐gruppen vermeiden.

Initial Access: GKE resource modified anonymously from the internet

Vorschau

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Erkennt, wenn ein potenziell böswilliger Akteur einen der folgenden Kubernetes-Standardnutzer oder ‐Nutzergruppen zum Ändern einer Kubernetes-Ressource im Cluster verwendet hat:

• system:anonymous
• system:authenticated
• system:unauthenticated

Diese Nutzer und Gruppen sind praktisch anonym. Eine Bindung für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) in Ihrem Cluster hat diesem Nutzer die Berechtigung zum Ändern dieser Ressourcen im Cluster gewährt.

Prüfen Sie die geänderte Ressource und die zugehörige RBAC-Bindung, um sicherzustellen, dass die Bindung erforderlich ist. Wenn die Bindung nicht erforderlich ist, entfernen Sie sie. Weitere Informationen finden Sie in der Lognachricht zu diesem Ergebnis.

Informationen zur Behebung dieses Problems finden Sie unter Standardrollen und ‐gruppen vermeiden.

Initial Access: Dormant Service Account Action

Erkennt Ereignisse, bei denen ein inaktives vom Nutzer verwaltetes Dienstkonto eine Aktion ausgelöst hat. Ein Dienstkonto gilt in diesem Zusammenhang als inaktiv, wenn es länger als 180 Tage inaktiv war.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Initial Access: Dormant Service Account Action wie unter Ergebnisse prüfen beschrieben.

2. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Felder.

   Gehen Sie unter Was erkannt wurde so vor:

   • Haupt-E-Mail-Adresse: das inaktive Dienstkonto, das die Aktion ausgeführt hat
   • Dienstname: Der API-Name des Google Cloud-Dienstes, auf den das Dienstkonto zugegriffen hat.
   • Method name: die aufgerufene Methode

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Verwenden Sie Dienstkonto-Tools wie Activity Analyzer, um die Aktivität des inaktiven Dienstkontos zu untersuchen.
2. Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts, in dem die Aktion ausgeführt wurde.
• Löschen Sie gegebenenfalls das potenziell manipulierte Dienstkonto und rotieren und löschen Sie alle Dienstkonto-Zugriffsschlüssel für das potenziell manipulierte Projekt. Nach dem Löschen verlieren Anwendungen, die das Dienstkonto zur Authentifizierung verwenden, den Zugriff. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Anwendungen identifizieren und mit den Anwendungsinhabern zusammenarbeiten, um für die Geschäftskontinuität zu sorgen.
• Ermitteln Sie gemeinsam mit Ihrem Sicherheitsteam unbekannte Ressourcen, einschließlich Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer. Ressourcen löschen, die nicht mit autorisierten Konten erstellt wurden.
• Reagieren Sie auf alle Benachrichtigungen vom Google Cloud-Support.
• Mit dem Organisationsrichtliniendienst können Sie einschränken, wer Dienstkonten erstellen kann.
• Um IAM-Rollen mit zu vielen Berechtigungen zu identifizieren und zu beheben, verwenden Sie IAM Recommender.

Initial Access: Dormant Service Account Key Created

Erkennt Ereignisse, bei denen ein inaktiver vom Nutzer verwalteter Dienstkontoschlüssel erstellt wird. Ein Dienstkonto gilt in diesem Zusammenhang als inaktiv, wenn es länger als 180 Tage inaktiv war.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Initial Access: Dormant Service Account Key Created wie unter Ergebnisse prüfen beschrieben.

2. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Felder.

   Gehen Sie unter Was erkannt wurde so vor:

   • Haupt-E-Mail-Adresse: der Nutzer, der den Dienstkontoschlüssel erstellt hat

   Unter Betroffene Ressource gehen Sie so vor:

   • Anzeigename der Ressource: der neu erstellte inaktive Dienstkontoschlüssel
   • Vollständiger Name des Projekts: das Projekt, in dem sich das inaktive Dienstkonto befindet

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Verwenden Sie Dienstkonto-Tools wie Activity Analyzer, um die Aktivität des inaktiven Dienstkontos zu untersuchen.
2. Wenden Sie sich an den Inhaber des Felds Haupt-E-Mail-Adresse. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts, in dem die Aktion ausgeführt wurde.
• Entfernen Sie den Zugriff des Inhabers der Haupt-E-Mail-Adresse, wenn diese manipuliert wurde.
• Entwerten Sie den neu erstellten Dienstkontoschlüssel auf der Seite „Dienstkonten“.
• Löschen Sie gegebenenfalls das potenziell manipulierte Dienstkonto und rotieren und löschen Sie alle Dienstkonto-Zugriffsschlüssel für das potenziell manipulierte Projekt. Nach dem Löschen verlieren Anwendungen, die das Dienstkonto zur Authentifizierung verwenden, den Zugriff. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Anwendungen identifizieren und mit den Anwendungsinhabern zusammenarbeiten, um für die Geschäftskontinuität zu sorgen.
• Ermitteln Sie gemeinsam mit Ihrem Sicherheitsteam unbekannte Ressourcen, einschließlich Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer. Ressourcen löschen, die nicht mit autorisierten Konten erstellt wurden.
• Auf Benachrichtigungen von Cloud Customer Care reagieren.
• Mit dem Organisationsrichtliniendienst können Sie einschränken, wer Dienstkonten erstellen kann.
• Verwenden Sie IAM Recommender, um zu moderate Rollen zu ermitteln und zu korrigieren.

Initial Access: Leaked Service Account Key Used

Erkennt Ereignisse, bei denen ein gehackter Dienstkontoschlüssel zur Authentifizierung der Aktion verwendet wird. Ein gehackter Dienstkontoschlüssel wurde in diesem Zusammenhang im öffentlichen Internet veröffentlicht. Dienstkontoschlüssel werden beispielsweise häufig fälschlicherweise in einem öffentlichen GitHub-Repository veröffentlicht.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Initial Access: Leaked Service Account Key Used wie unter Ergebnisse prüfen beschrieben.

2. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Felder.

   Gehen Sie unter Was erkannt wurde so vor:

   • Haupt-E-Mail-Adresse: das in dieser Aktion verwendete Dienstkonto
   • Dienstname: Der API-Name des Google Cloud-Dienstes, auf den das Dienstkonto zugegriffen hat.
   • Method name: der Methodenname der Aktion
   • Name des Dienstkontoschlüssels: der gehackte Dienstkontoschlüssel, der zur Authentifizierung dieser Aktion verwendet wurde
   • Beschreibung: die Beschreibung dessen, was erkannt wurde, einschließlich des Standorts im öffentlichen Internet, an dem der Dienstkontoschlüssel zu finden ist

   Unter Betroffene Ressource gehen Sie so vor:

   • Anzeigename der Ressource: die an der Aktion beteiligte Ressource

Schritt 2: Protokolle prüfen

1. Rufen Sie in der Google Cloud Console den Log-Explorer auf. Klicken Sie dazu auf den Link in Cloud Logging-URI.
2. Wählen Sie in der Symbolleiste der Google Cloud Console Ihr Projekt oder Ihre Organisation aus.

3. Suchen Sie auf der Seite, die geladen wird, nach zugehörigen Logs, indem Sie den folgenden Filter verwenden:

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
   • protoPayload.authenticationInfo.serviceAccountKeyName="SERVICE_ACCOUNT_KEY_NAME"

   Ersetzen Sie PRINCIPAL_EMAIL durch den Wert, den Sie in den Ergebnisdetails im Feld Haupt-E-Mail-Adresse notiert haben. Ersetzen Sie SERVICE_ACCOUNT_KEY_NAME durch den Wert, den Sie sich in den Ergebnisdetails im Feld Name des Dienstkontoschlüssels notiert haben.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Widerrufen Sie den Dienstkontoschlüssel sofort auf der Seite Dienstkonten.
• Deaktivieren Sie die Webseite oder das GitHub-Repository, auf der bzw. dem der Dienstkontoschlüssel veröffentlicht wurde.
• Löschen Sie gegebenenfalls das manipulierte Dienstkonto.
• Rotieren und löschen Sie alle Dienstkonto-Zugriffsschlüssel für das potenziell manipulierte Projekt. Nach dem Löschen verlieren Anwendungen, die das Dienstkonto zur Authentifizierung verwenden, den Zugriff. Vor dem Löschen sollte Ihr Sicherheitsteam alle betroffenen Anwendungen identifizieren und mit den Anwendungsinhabern zusammenarbeiten, um für die Geschäftskontinuität zu sorgen.
• Ermitteln Sie gemeinsam mit Ihrem Sicherheitsteam unbekannte Ressourcen, einschließlich Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer. Ressourcen löschen, die nicht mit autorisierten Konten erstellt wurden.
• Auf Benachrichtigungen von Cloud Customer Care reagieren.

Initial Access: Excessive Permission Denied Actions

Erkennt Ereignisse, bei denen ein Hauptkonto wiederholt den Fehler Berechtigung verweigert für mehrere Methoden und Dienste auslöst.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Initial Access: Excessive Permission Denied Actions wie unter Ergebnisse prüfen beschrieben.

2. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Felder.

   Gehen Sie unter Was erkannt wurde so vor:

   • Haupt-E-Mail-Adresse: Das Hauptkonto, das mehrere Fehler aufgrund von mehreren abgelehnten Berechtigungen ausgelöst hat
   • Dienstname: Der API-Name des Google Cloud-Dienstes, bei dem der letzte Fehler aufgrund einer abgelehnten Berechtigung aufgetreten ist.
   • Methodenname: Die Methode, die aufgerufen wurde, als der letzte Fehler aufgrund einer abgelehnten Berechtigung aufgetreten ist.

3. Notieren Sie sich in den Ergebnisdetails auf dem Tab Quelleigenschaften die Werte der folgenden Felder in der JSON-Datei:

   • properties.failedActions: Die aufgetretenen Fehler aufgrund von abgelehnten Berechtigungen. Zu jedem Eintrag gehören der Dienstname, der Methodenname, die Anzahl der Fehlversuche und der Zeitpunkt, zu dem der Fehler zuletzt aufgetreten ist. Es werden maximal 10 Einträge angezeigt.

Schritt 2: Protokolle prüfen

1. Rufen Sie in der Google Cloud Console den Log-Explorer auf. Klicken Sie dazu auf den Link in Cloud Logging-URI.
2. Wählen Sie in der Symbolleiste der Cloud Console Ihr Projekt aus.

3. Suchen Sie auf der Seite, die geladen wird, nach zugehörigen Logs, indem Sie den folgenden Filter verwenden:

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
   • protoPayload.status.code=7

   Ersetzen Sie PRINCIPAL_EMAIL durch den Wert, den Sie in den Ergebnisdetails im Feld Haupt-E-Mail-Adresse notiert haben.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten: Cloudkonten.
2. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 4: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Kontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
• Löschen Sie Projektressourcen, die von diesem Konto erstellt wurden, z. B. unbekannte Compute Engine-Instanzen, Snapshots, Dienstkonten, IAM-Nutzer usw.
• Wenden Sie sich an den Inhaber des Projekts mit dem Konto. Möglicherweise löschen oder deaktivieren Sie das Konto.

Brute Force: SSH

Erkennung erfolgreicher SSH-Brute Force auf einem Host. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Brute Force: SSH-Ergebnis, wie unter Ergebnisse prüfen beschrieben.

2. Prüfen Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:

     • Caller IP: Die IP-Adresse, die den Angriff gestartet hat.
     • Nutzername: das Konto, in dem Sie angemeldet sind

   • Betroffene Ressource

   • Weitere Informationen, insbesondere die folgenden Felder:

     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
     • Chronicle: Link zu Google SecOps.

3. Klicken Sie auf den Tab JSON.

4. Beachten Sie in der JSON-Datei die folgenden Felder.

   • sourceProperties:
     • evidence:
       • sourceLogId: die Projekt-ID und der Zeitstempel zur Identifizierung des Logeintrags
       • projectId: das Projekt, das das Ergebnis enthält
     • properties:
       • attempts:
       • Attempts: Die Anzahl der Anmeldeversuche
         • username: das Konto, mit dem Sie sich angemeldet haben
         • vmName: der Name der VM
         • authResult: das Ergebnis der SSH-Authentifizierung

Schritt 2: Sicherheitsvorgänge von Google untersuchen

Sie können dies mit Google Security Operations untersuchen. Google SecOps ist ein Google Cloud-Dienst, mit dem Sie Bedrohungen in einer benutzerfreundlichen Zeitachse prüfen und durch zugehörige Entitäten pivotieren können. Google SecOps reichert die Ergebnisdaten an, sodass Sie relevante Indikatoren identifizieren und Untersuchungen vereinfachen können.

Sie können Google SecOps nur verwenden, wenn Sie Security Command Center auf Organisationsebene aktivieren.

1. Wechseln Sie in der Google Cloud Console zur Seite Ergebnisse des Security Command Center.

   Zu Ergebnissen

2. Scrollen Sie im Bereich Schnellfilter nach unten zu Anzeigename der Quelle.

3. Wählen Sie im Abschnitt Anzeigename der Quelle die Option Event Threat Detection aus.

   Die Tabelle enthält die Ergebnisse für den ausgewählten Quelltyp.

4. Klicken Sie in der Tabelle unter Kategorie auf ein Brute Force: SSH-Ergebnis. Der Detailbereich für das Ergebnis wird geöffnet.

5. Klicken Sie im Bereich Weitere Informationen des Bereichs mit den Ergebnisdetails auf In Chronicle untersuchen.

6. Folgen Sie der Anleitung in der geführten Benutzeroberfläche von Google SecOps.

Orientieren Sie sich an den folgenden Leitfäden, um Prüfungen in Google SecOps durchzuführen:

• Nutzer untersuchen
• IP-Adresse untersuchen
• Asset untersuchen

Schritt 3: Berechtigungen und Einstellungen prüfen

1. Rufen Sie in der Google Cloud Console das Dashboard auf.

   Zum Dashboard

2. Wählen Sie das Projekt aus, das in projectId angegeben ist.

3. Rufen Sie die Karte Ressourcen auf und klicken Sie auf Compute Engine.

4. Klicken Sie auf die VM-Instanz, die dem Namen und der Zone in vmName entspricht. Prüfen Sie die Instanzdetails einschließlich der Netzwerk- und Zugriffseinstellungen.

5. Klicken Sie im Navigationsbereich auf VPC-Netzwerk und dann auf Firewall. Entfernen oder deaktivieren Sie zu freizügige Firewallregeln für Port 22.

Schritt 4: Protokolle prüfen

1. Rufen Sie in der Google Cloud Console den Log-Explorer auf. Klicken Sie dazu auf den Link in Cloud Logging-URI.
2. Suchen Sie auf der Seite, die geladen wird, nach VPC-Flusslogs, die sich auf die IP-Adresse beziehen, die auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Haupt-E-Mail aufgeführt ist. Verwenden Sie dazu den folgenden Filter:
   • logName="projects/projectId/logs/syslog"
   • labels."compute.googleapis.com/resource_name"="vmName"

Schritt 5: Angriffs- und Reaktionsmethoden untersuchen

1. Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten: Lokale Konten.
2. Sie können zusammengehörige Ergebnisse überprüfen, indem Sie auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Zugehörige Ergebnisse auf den Link für Ähnliche Ergebnisse klicken. Ähnliche Ergebnisse haben denselben Ergebnistyp und dieselbe Instanz und dasselbe Netzwerk.
3. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 6: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich mit dem erfolgreichen Versuch der Brute-Force an den Inhaber des Projekts.
• Untersuchen Sie die potenziell manipulierte Instanz und entfernen Sie erkannte Malware. Verwenden Sie eine Lösung zur Endpunkterkennung und -antwort, um Unterstützung bei der Erkennung und Entfernung zu erhalten.
• Deaktivieren Sie den SSH-Zugriff auf die VM. Informationen zum Deaktivieren von SSH-Schlüsseln finden Sie unter SSH-Schlüssel von VMs einschränken. Dieser Schritt könnte den autorisierten Zugriff auf die VM unterbrechen. Berücksichtigen Sie daher die Anforderungen Ihrer Organisation, bevor Sie fortfahren.
• Verwenden Sie die SSH-Authentifizierung nur mit autorisierten Schlüsseln.
• Blockieren Sie die schädlichen IP-Adressen, indem Sie Firewallregeln aktualisieren oder Google Cloud Armor verwenden. Sie können Google Cloud Armor auf der Seite Integrierte Dienste des Security Command Center aktivieren. Abhängig von der Menge der Informationen können Google Cloud Armor-Kosten beträchtlich sein. Weitere Informationen finden Sie in der Preisübersicht für Google Cloud Armor.

Credential Access: External Member Added To Privileged Group

Dieses Ergebnis ist für Aktivierungen auf Projektebene nicht verfügbar.

Erkennt, wenn ein externes Mitglied einer privilegierten Google-Gruppe hinzugefügt wird (einer Gruppe, die vertrauliche Rollen oder Berechtigungen gewährt). Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Credential Access: External Member Added To Privileged Group-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: das Konto, über das die Änderungen vorgenommen wurden.
   • Betroffene Ressource
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

3. Klicken Sie im Detailbereich auf den Tab JSON.

4. Beachten Sie in der JSON-Datei die folgenden Felder.

   • groupName: die Google-Gruppe, in der die Änderungen vorgenommen wurden
   • externalMember: das neu hinzugefügte externe Mitglied
   • sensitiveRoles: die mit dieser Gruppe verknüpften vertraulichen Rollen

Schritt 2: Gruppenmitglieder prüfen

1. Öffnen Sie Google Groups.

   Öffnen Sie Google Groups.

2. Klicken Sie auf den Namen der Gruppe, die Sie prüfen möchten.

3. Klicken Sie im Navigationsmenü auf Mitglieder.

4. Wenn das neu hinzugefügte externe Mitglied nicht in dieser Gruppe sein soll, klicken Sie auf das Kästchen neben dem Mitgliedsnamen und wählen Sie dann Mitglied entfernen oder Mitglied sperren aus.

   Zum Entfernen von Mitgliedern müssen Sie Google Workspace-Administrator sein oder die Rolle Inhaber oder Manager in der Google-Gruppe haben. Weitere Informationen finden Sie unter Mitgliedern einer Gruppe Rollen zuweisen.

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.

2. Wählen Sie bei Bedarf Ihr Projekt aus.

   

3. Prüfen Sie auf der Seite, die geladen wird, die Logs auf Google Groups-Mitgliedschaftsänderungen mithilfe der folgenden Filter:

   • protoPayload.methodName="google.apps.cloudidentity.groups.v1.MembershipsService.UpdateMembership"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Sehen Sie sich den MITRE ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten.
2. Um festzustellen, ob zusätzliche Schritte zur Abhilfe erforderlich sind, kombinieren Sie Ihre Untersuchungsergebnisse mit dem MITRE-Forschung.

Credential Access: Privileged Group Opened To Public

Dieses Ergebnis ist für Aktivierungen auf Projektebene nicht verfügbar.

Erkennt, wenn eine privilegierte Google-Gruppe (eine Gruppe mit vertraulichen Rollen oder Berechtigungen) so geändert wird, dass sie öffentlich zugänglich ist. So reagieren Sie auf dieses Ergebnis:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Credential Access: Privileged Group Opened To Public-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: Das Konto, über das die Änderungen vorgenommen wurden und das möglicherweise manipuliert wurde.
   • Betroffene Ressource
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
   1. Klicken Sie auf den Tab JSON.
   2. Beachten Sie in der JSON-Datei die folgenden Felder.
   • groupName: die Google-Gruppe, in der die Änderungen vorgenommen wurden
   • sensitiveRoles: die mit dieser Gruppe verknüpften vertraulichen Rollen
   • whoCanJoin: die Einstellung für die Teilnahmemöglichkeiten der Gruppe

Schritt 2: Einstellungen für den Gruppenzugriff prüfen

1. Rufen Sie die Admin-Konsole für Google Groups auf. Sie müssen ein Google Workspace-Administrator sein, um sich in der Konsole anzumelden.

   Zur Admin-Konsole

2. Klicken Sie im Navigationsbereich auf Verzeichnis und wählen Sie dann Gruppen aus.

3. Klicken Sie auf den Namen der Gruppe, die Sie prüfen möchten.

4. Klicken Sie auf Zugriffseinstellungen und prüfen Sie dann unter Wer kann der Gruppe beitreten die Beitreten-Einstellung für die Gruppe.

5. Ändern Sie bei Bedarf im Drop-down-Menü die Einstellung für die Beitretenmöglichkeiten.

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.

2. Wählen Sie bei Bedarf Ihr Projekt aus.

   

3. Prüfen Sie auf der Seite, die geladen wird, die Google Groups-Einstellungsänderungen mithilfe der folgenden Filter:

   • protoPayload.methodName="google.admin.AdminService.changeGroupSetting"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Sehen Sie sich den MITRE ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten.
2. Um festzustellen, ob zusätzliche Schritte zur Abhilfe erforderlich sind, kombinieren Sie Ihre Untersuchungsergebnisse mit dem MITRE-Forschung.

Credential Access: Secrets Accessed in Kubernetes Namespace

Vorschau

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Erkennt, wenn das Kubernetes-Dienstkonto default eines Pods für den Zugriff auf Secret-Objekte im Cluster verwendet wurde. Das Kubernetes-Dienstkonto default sollte keinen Zugriff auf Secret-Objekte haben, sofern Sie diesen Zugriff nicht explizit mit einem Role- oder ClusterRole-Objekt gewährt haben.

Credential Access: Sensitive Role Granted To Hybrid Group

Erkennt, wenn sensible Rollen oder Berechtigungen einer Google-Gruppe mit externen Mitgliedern zugewiesen werden. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Credential Access: Sensitive Role Granted To Hybrid Group-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: Das Konto, über das die Änderungen vorgenommen wurden und das möglicherweise manipuliert wurde.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Die Ressource, der die neue Rolle gewährt wurde.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
   1. Klicken Sie auf den Tab JSON.
   2. Beachten Sie in der JSON-Datei die folgenden Felder.
   • groupName: die Google-Gruppe, in der die Änderungen vorgenommen wurden
   • bindingDeltas: die sensiblen Rollen, die dieser Gruppe neu gewährt werden.

Schritt 2: Gruppenberechtigungen prüfen

1. Rufen Sie in der Google Cloud Console die Seite IAM auf.

   IAM aufrufen

2. Geben Sie im Feld Filter den in groupName aufgeführten Kontonamen ein.

3. Prüfen Sie die sensiblen Rollen, die der Gruppe zugewiesen wurden.

4. Wenn die neu hinzugefügte sensible Rolle nicht benötigt wird, entziehen Sie die Rolle.

   Sie benötigen bestimmte Berechtigungen, um Rollen in Ihrer Organisation oder Ihrem Projekt zu verwalten. Weitere Informationen finden Sie unter Erforderliche Berechtigungen.

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.

2. Wählen Sie bei Bedarf Ihr Projekt aus.

   

3. Prüfen Sie auf der Seite, die geladen wird, die Google Groups-Einstellungsänderungen mithilfe der folgenden Filter:

   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Sehen Sie sich den MITRE ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten.
2. Um festzustellen, ob zusätzliche Schritte zur Abhilfe erforderlich sind, kombinieren Sie Ihre Untersuchungsergebnisse mit dem MITRE-Forschung.

Malware: Cryptomining Bad IP

Malware wird durch Untersuchung der VPC-Flusslogs und Cloud DNS-Logs auf Verbindungen zu bekannten Befehls- und Kontrolldomains und IP-Adressen erkannt. Gehen Sie so vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Malware: Cryptomining Bad IP-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Quell-IP: die mutmaßliche Kryptomining-IP-Adresse.
     • Quellport: Der Quellport der Verbindung, falls verfügbar.
     • Ziel-IP: die Ziel-IP-Adresse
     • Zielport: Der Zielport der Verbindung, falls verfügbar.
     • Protokoll: Das IANA-Protokoll, das der Verbindung zugeordnet ist.
   • Betroffene Ressource
   • Weitere Informationen, darunter die folgenden Felder:
     • Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

3. Klicken Sie in der Detailansicht des Ergebnisses auf den Tab Quell-Properties.

4. Maximieren Sie properties und notieren Sie Projekt- und Instanzwerte im folgenden Feld:

   • instanceDetails: Notieren Sie sich sowohl die Projekt-ID als auch den Namen der Compute Engine-Instanz. Die Projekt-ID und der Instanzname werden wie im folgenden Beispiel dargestellt:

     /projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME

5. Klicken Sie auf den Tab JSON, um die vollständige JSON-Datei für das Ergebnis anzusehen.

Schritt 2: Berechtigungen und Einstellungen prüfen

1. Öffnen Sie in der Google Cloud Console die Seite Dashboard.

   Zum Dashboard

2. Wählen Sie das Projekt aus, das in properties_project_id angegeben ist.

3. Rufen Sie die Karte Ressourcen auf und klicken Sie auf Compute Engine.

4. Klicken Sie auf die VM-Instanz, die mit properties_sourceInstance übereinstimmt. Untersuchen Sie die potenziell manipulierte Instanz auf Malware.

5. Klicken Sie im Navigationsbereich auf VPC-Netzwerk und dann auf Firewall. Firewallregeln mit zu vielen Berechtigungen entfernen oder deaktivieren

Schritt 3: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console den Log-Explorer.

   Zum Log-Explorer

2. Wählen Sie in der Symbolleiste der Cloud Console Ihr Projekt aus.

3. Suchen Sie auf der Seite, die geladen wird, mit dem folgenden Filter nach VPC-Flusslogs für Properties_ip_0:

   • logName="projects/properties_project_id/logs/compute.googleapis.com%2Fvpc_flows"
   • (jsonPayload.connection.src_ip="Properties_ip_0" OR jsonPayload.connection.dest_ip="Properties_ip_0")

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ressourcendiebstahl.
2. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 5: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts, das Malware enthält.
• Untersuchen Sie die potenziell manipulierte Instanz und entfernen Sie erkannte Malware. Verwenden Sie eine Lösung zur Endpunkterkennung und -antwort, um Unterstützung bei der Erkennung und Entfernung zu erhalten.
• Beenden Sie bei Bedarf die manipulierte Instanz und ersetzen Sie sie durch eine neue Instanz.
• Blockieren Sie die schädlichen IP-Adressen, indem Sie Firewallregeln aktualisieren oder Google Cloud Armor verwenden. Sie können Google Cloud Armor auf der Seite Integrierte Dienste des Security Command Center aktivieren. Abhängig vom Datenvolumen können die Google Cloud Armor-Kosten beträchtlich sein. Weitere Informationen finden Sie in der Preisübersicht für Google Cloud Armor.

Initial Access: Log4j Compromise Attempt

Dieses Ergebnis wird generiert, wenn lookups (Java Naming and Directory Interface) in Headern oder URL-Parametern erkannt werden. Diese Lookups können auf Versuche der Ausnutzung von Log4Shell-Exploits hinweisen. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Initial Access: Log4j Compromise Attempt-Ergebnis, wie unter Ergebnisdetails prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde
   • Betroffene Ressource
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
   • Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON.

   • Beachten Sie in der JSON-Datei die folgenden Felder.

   • properties

     • loadBalancerName: der Name des Load-Balancers, der die JNDI-Suche empfangen hat
     • requestUrl: Die Anfrage-URL der HTTP-Anfrage. Falls vorhanden, enthält dies einen JNDI-Lookup.
     • requestUserAgent: Der User-Agent, der die HTTP-Anfrage gesendet hat. Falls vorhanden, enthält dies ein JNDI-Lookup.
     • refererUrl: Die URL der Seite, die die HTTP-Anfrage gesendet hat. Falls vorhanden, enthält dies einen JNDI-Lookup.

Schritt 2: Protokolle prüfen

1. Rufen Sie in der Google Cloud Console den Log-Explorer auf. Klicken Sie dazu auf den Link im Feld Cloud Logging-URI aus Schritt 1.

2. Prüfen Sie auf der Seite, die geladen wird, die Felder httpRequest auf String-Tokens wie ${jndi:ldap://, die mögliche Angriffsversuche anzeigen können.

   Unter CVE-2021-44228: Log4Shell-Exploit erkennen in der Logging-Dokumentation finden Sie Beispielstrings, nach denen gesucht werden soll, und eine Beispielabfrage.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Prüfen Sie den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp: Exploit Public-Facing Application.
2. Sie können verwandte Ergebnisse prüfen, indem Sie auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Zugehörige Ergebnisse auf den Link für Ähnliche Ergebnisse klicken. Ähnliche Ergebnisse sind der gleiche Ergebnistyp sowie dieselbe Instanz und dasselbe Netzwerk.
3. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Schritt 4: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Führen Sie ein Upgrade auf die neueste Version von Log4j2 durch.
• Folgen Sie den Empfehlungen von Google Cloud zur Untersuchung und Behebung der Sicherheitslücke „Apache Log4j 2“ {: target="blog" track-type="tasks" track-name="blogLink"}
• Empfohlene Schutzmaßnahmen in Apache Log4j-Sicherheitslücken implementieren
• Wenn Sie Google Cloud Armor verwenden, stellen Sie cve-canary rule in einer neuen oder vorhandenen Google Cloud Armor-Sicherheitsrichtlinie bereit. Weitere Informationen finden Sie unter Google Cloud Armor-WAF-Regel zur Bewahrung vor der Apache Log4j-Sicherheitslücke.

Active Scan: Log4j Vulnerable to RCE

Unterstützte Log4j-Sicherheitslücken-Scanner fügen verschleierte JNDI-Lookups in HTTP-Parametern, URLs und Textfeldern mit Callbacks zu Domains ein, die von den Scannern gesteuert werden. Dieses Ergebnis wird generiert, wenn DNS-Abfragen für die nicht verschleierten Domains gefunden werden. Solche Abfragen treten nur auf, wenn eine JNDI-Suche erfolgreich war und eine aktive Log4j-Sicherheitslücke anzeigt. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Active Scan: Log4j Vulnerable to RCE-Ergebnis, wie unter Ergebnisdetails prüfen beschrieben. Im Detailbereich für das Ergebnis wird der Tab Zusammenfassung geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde
   • Betroffene Ressource, insbesondere das folgende Feld:
     • Vollständiger Name der Ressource: Der vollständige Ressourcenname der Compute Engine-Instanz, die für Log4j RCE anfällig ist.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

3. Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON.

4. Beachten Sie in der JSON-Datei die folgenden Felder.

   • properties
     • scannerDomain: Die Domain, die vom Scanner als Teil der JNDI-Suche verwendet wird. So wissen Sie, welcher Scanner die Sicherheitslücke identifiziert hat.
     • sourceIp: Die IP-Adresse, die zum Erstellen der DNS-Abfrage verwendet wird.
     • vpcName: der Name des Netzwerks auf der Instanz, auf der die DNS-Abfrage durchgeführt wurde.

Schritt 2: Protokolle prüfen

1. Rufen Sie in der Google Cloud Console den Log-Explorer auf. Klicken Sie dazu auf den Link im Feld Cloud Logging-URI aus Schritt 1.

2. Prüfen Sie auf der Seite, die geladen wird, die Felder httpRequest auf String-Tokens wie ${jndi:ldap://, die mögliche Angriffsversuche anzeigen können.

   Unter CVE-2021-44228: Log4Shell-Exploit erkennen in der Logging-Dokumentation finden Sie Beispielstrings, nach denen gesucht werden soll, und eine Beispielabfrage.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Exploitation of Remote Services.
2. Sie können verwandte Ergebnisse prüfen, indem Sie auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Zugehörige Ergebnisse auf den Link für Ähnliche Ergebnisse klicken. Ähnliche Ergebnisse haben denselben Ergebnistyp und dieselbe Instanz und dasselbe Netzwerk.
3. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Schritt 4: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Führen Sie ein Upgrade auf die neueste Version von Log4j2 durch.
• Folgen Sie den Empfehlungen von Google Cloud zur Untersuchung und Behebung der Sicherheitslücke „Apache Log4j 2“ {: target="blog" track-type="tasks" track-name="blogLink"}
• Empfohlene Schutzmaßnahmen in Apache Log4j-Sicherheitslücken implementieren
• Wenn Sie Google Cloud Armor verwenden, stellen Sie cve-canary rule in einer neuen oder vorhandenen Google Cloud Armor-Sicherheitsrichtlinie bereit. Weitere Informationen finden Sie unter Google Cloud Armor-WAF-Regel zur Bewahrung vor der Apache Log4j-Sicherheitslücke.

Leaked credentials

Dieses Ergebnis ist für Aktivierungen auf Projektebene nicht verfügbar.

Dieses Ergebnis wird generiert, wenn die Anmeldedaten des Google Cloud-Dienstkontos versehentlich online gehackt oder manipuliert wurden. So reagieren Sie auf dieses Ergebnis:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein account_has_leaked_credentials-Ergebnis, wie unter Ergebnisdetails prüfen beschrieben. Der Detailbereich für das Ergebnis wird auf dem Tab Zusammenfassung geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

• Was erkannt wurde
• Betroffene Ressource

1. Klicken Sie auf den Tab Quelleigenschaften und beachten Sie die folgenden Felder:

   • Compromised_account: das potenziell manipulierte Dienstkonto
   • Project_identifier: das Projekt, das die potenziell gehackten Kontoanmeldedaten enthält
   • URL: der Link zum GitHub-Repository

2. Klicken Sie auf den Tab JSON, um die vollständige JSON-Datei für das Ergebnis anzusehen.

Schritt 2: Projekt- und Dienstkontoberechtigungen prüfen

1. Öffnen Sie in der Google Cloud Console die Seite IAM.

   IAM aufrufen

2. Wählen Sie bei Bedarf das in Project_identifier aufgeführte Projekt aus.

3. Geben Sie auf der angezeigten Seite im Feld Filter den in Compromised_account aufgeführten Kontonamen ein und prüfen Sie die zugewiesenen Berechtigungen.

4. Rufen Sie in der Google Cloud Console die Seite Dienstkonten auf.

   Zur Seite „Dienstkonten“

5. Geben Sie auf der angezeigten Seite im Feld Filter den Namen des manipulierten Dienstkontos ein und prüfen Sie die Schlüssel und das Datum der Erstellung des Dienstkontos.

Schritt 3: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console den Log-Explorer.

   Zum Log-Explorer

2. Wählen Sie in der Symbolleiste der Cloud Console Ihr Projekt aus.

3. Prüfen Sie auf der geladenen Seite die Logs der Aktivitäten neuer oder aktualisierter IAM-Ressourcen mithilfe der folgenden Filter:

   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • resource.type="gce_instance" AND log_name="projects/Project_identifier/logs/cloudaudit.googleapis.com%2Factivity"
   • protoPayload.methodName="InsertProjectOwnershipInvite"
   • protoPayload.authenticationInfo.principalEmail="Compromised_account"

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten: Cloudkonten.
2. Klicken Sie auf den Link in relatedFindingURI, um ähnliche Ergebnisse abzurufen. Ähnliche Ergebnisse haben denselben Ergebnistyp und dieselbe Instanz und dasselbe Netzwerk.
3. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 5: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich mit gehackten Anmeldedaten an den Inhaber des Projekts.
• Erwägen Sie, das manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das manipulierte Projekt zu rotieren und zu löschen. Nach dem Löschen verlieren Ressourcen, die das Dienstkonto für die Authentifizierung verwenden, den Zugriff. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Ressourcen identifizieren und mit Ressourceninhabern zusammenarbeiten, um die Geschäftskontinuität zu gewährleisten.
• Ermitteln Sie gemeinsam mit Ihrem Sicherheitsteam unbekannte Ressourcen, einschließlich Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer. Ressourcen löschen, die nicht mit autorisierten Konten erstellt wurden.
• Auf Benachrichtigungen des Google Cloud-Supports antworten
• Mit dem Organisationsrichtliniendienst können Sie einschränken, wer Dienstkonten erstellen kann.
• Um IAM-Rollen mit zu vielen Berechtigungen zu identifizieren und zu beheben, verwenden Sie IAM Recommender.
• Öffnen Sie den Link URL und löschen Sie die gehackten Anmeldedaten. Sammeln Sie weitere Informationen zum manipulierten Konto und wenden Sie sich an den Inhaber.

Malware

Malware wird durch Untersuchung der VPC-Flusslogs und Cloud DNS-Logs auf Verbindungen zu bekannten Befehls- und Kontrolldomains und IP-Adressen erkannt. Derzeit bietet Event Threat Detection allgemeine Malware-Erkennung (Malware: Bad IP und Malware: Bad Domain) und Detektoren, insbesondere für Log4j-bezogene Malware (Log4j Malware: Bad IP und Log4j Malware: Bad Domain).

In den folgenden Schritten wird beschrieben, wie Sie IP-basierte Ergebnisse untersuchen und darauf reagieren können. Die Schritte zur Fehlerbehebung sind für domainbasierte Ergebnisse ähnlich.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das entsprechende Malware-Ergebnis. In den folgenden Schritten wird das Ergebnis Malware: Bad IP verwendet, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Indikatordomain: Bei Bad domain Ergebnissen die Domain, die das Ergebnis ausgelöst hat.
     • Indikator-IP: Bei Bad IP Ergebnissen die IP-Adresse, die das Ergebnis ausgelöst hat.
     • Quell-IP: für Bad IP-Ergebnisse ein bekannter Malwarebefehl und eine Kontroll-IP-Adresse.
     • Quellport: bei Bad IP Ergebnissen der Quellport der Verbindung.
     • Ziel-IP: Bei Bad IP Ergebnissen die Ziel-IP-Adresse der Malware.
     • Zielport: bei Bad IP Ergebnissen der Zielport der Verbindung.
     • Protokoll: Bei Bad IP-Ergebnissen die mit der Verbindung verknüpfte IANA-Protokollnummer.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der vollständige Ressourcenname der betroffenen Compute Engine-Instanz.
     • Vollständiger Name des Projekts: Der vollständige Ressourcenname des Projekts, das das Ergebnis enthält.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
     • Chronicle: Link zu Google SecOps.
     • VirusTotal-Indikator: Link zur Analyseseite von VirusTotal.

   1. Klicken Sie auf den Tab JSON und notieren Sie sich das folgende Feld:

      • evidence:
      • sourceLogId:
        • projectID: die ID des Projekts, in dem das Problem festgestellt wurde.
      • properties:
      • InstanceDetails: die Ressourcenadresse für die Compute Engine-Instanz.

Schritt 2: Sicherheitsvorgänge von Google untersuchen

Sie können dies mit Google Security Operations untersuchen. Google SecOps ist ein Google Cloud-Dienst, mit dem Sie Bedrohungen in einer benutzerfreundlichen Zeitachse prüfen und durch zugehörige Entitäten pivotieren können. Google SecOps reichert die Ergebnisdaten an, sodass Sie relevante Indikatoren identifizieren und Untersuchungen vereinfachen können.

Sie können Google SecOps nur verwenden, wenn Sie Security Command Center auf Organisationsebene aktivieren.

1. Wechseln Sie in der Google Cloud Console zur Seite Ergebnisse des Security Command Center.

   Zu Ergebnissen

2. Scrollen Sie im Bereich Schnellfilter nach unten zu Anzeigename der Quelle.

3. Wählen Sie im Abschnitt Anzeigename der Quelle die Option Event Threat Detection aus.

   Die Tabelle enthält die Ergebnisse für den ausgewählten Quelltyp.

4. Klicken Sie in der Tabelle unter category auf das Ergebnis Malware: Bad IP. Der Detailbereich für das Ergebnis wird geöffnet.

5. Klicken Sie im Bereich Weitere Informationen des Bereichs mit den Ergebnisdetails auf In Chronicle untersuchen.

6. Folgen Sie der Anleitung in der geführten Benutzeroberfläche von Google SecOps.

Orientieren Sie sich an den folgenden Leitfäden, um Prüfungen in Google SecOps durchzuführen:

• IP-Adresse untersuchen
• Asset untersuchen

Schritt 3: Berechtigungen und Einstellungen prüfen

1. Öffnen Sie in der Google Cloud Console die Seite Dashboard.

   Zum Dashboard

2. Wählen Sie das Projekt aus, das in der Zeile Vollständiger Name des Projekts auf dem Tab Zusammenfassung angegeben ist.

3. Rufen Sie die Karte Ressourcen auf und klicken Sie auf Compute Engine.

4. Klicken Sie auf die VM-Instanz, die dem Namen und der Zone in Vollständiger Name der Ressource entspricht. Prüfen Sie die Instanzdetails einschließlich der Netzwerk- und Zugriffseinstellungen.

5. Klicken Sie im Navigationsbereich auf VPC-Netzwerk und dann auf Firewall. Firewallregeln mit zu vielen Berechtigungen entfernen oder deaktivieren

Schritt 4: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.

2. Suchen Sie auf der Seite, die geladen wird, nach VPC-Flusslogs, die sich auf die IP-Adresse in Quell-IP beziehen, mithilfe des folgenden Filters:

   • logName="projects/projectId/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="SOURCE_IP" OR jsonPayload.connection.dest_ip="destIP")

     Ersetzen Sie Folgendes:

     • PROJECT_ID durch Auswahl des in projectId aufgeführten Projekts.
     • SOURCE_IP durch die IP-Adresse, die auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Quell-IP aufgeführt ist.

Schritt 5: Angriffs- und Reaktionsmethoden untersuchen

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Dynamische Lösung und Befehl und Kontrolle.
2. Sie können verwandte Ergebnisse prüfen, indem Sie auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Zugehörige Ergebnisse auf den Link für Ähnliche Ergebnisse klicken. Ähnliche Ergebnisse haben denselben Ergebnistyp und dieselbe Instanz und dasselbe Netzwerk.
3. Prüfen Sie die markierten URLs und Domains in VirusTotal. Klicken Sie dazu auf den Link im VirusTotal-Indikator. VirusTotal, ein Alphabet-eigener Dienst, der Kontext zu potenziell schädlichen Dateien, URLs, Domains und IP-Adressen bereitstellt.
4. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 6: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts, das Malware enthält.
• Untersuchen Sie die potenziell manipulierte Instanz und entfernen Sie erkannte Malware. Verwenden Sie eine Lösung zur Endpunkterkennung und -antwort, um Unterstützung bei der Erkennung und Entfernung zu erhalten.
• Prüfen Sie Audit-Logs und Syslogs, die mit der manipulierten Instanz verknüpft sind, um Aktivitäten und Sicherheitslücken zu verfolgen, die das Einfügen von Malware ermöglichen.
• Beenden Sie bei Bedarf die manipulierte Instanz und ersetzen Sie sie durch eine neue Instanz.
• Blockieren Sie die schädlichen IP-Adressen, indem Sie Firewallregeln aktualisieren oder Google Cloud Armor verwenden. Sie können Google Cloud Armor auf der Seite Integrierte Dienste des Security Command Center aktivieren. Abhängig vom Datenvolumen können die Google Cloud Armor-Kosten beträchtlich sein. Weitere Informationen finden Sie in der Preisübersicht für Google Cloud Armor.
• Verwenden Sie die IAM-Richtlinie Shielded VM und Trusted Images, um den Zugriff und die Verwendung von VM-Images zu steuern.

Malware: Outgoing DoS

Event Threat Detection erkennt die mögliche Verwendung einer Instanz, um einen Denial-of-Service-Angriff (DoS) zu starten. Dazu werden VPC-Flusslogs analysiert. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Malware: Outgoing DoS, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde
     • Quell-IP: Die Quell-IP-Adresse der DoS-Aktivität.
     • Quellport: Der Quellport der Verbindung.
     • Ziel-IP: Die Ziel-IP-Adresse der DoS-Aktivität.
     • Zielport: Der Zielport der Verbindung.
   • Betroffene Ressource
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
   1. Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON.
   2. Beachten Sie in der JSON-Datei die folgenden Felder.
   • sourceInstanceDetails: die betroffene Compute Engine-VM-Instanz

Schritt 2: Berechtigungen und Einstellungen prüfen

1. Öffnen Sie in der Google Cloud Console die Seite Dashboard.

   Zum Dashboard

2. Wählen Sie das Projekt aus, das in sourceInstanceDetails angegeben ist.

3. Rufen Sie die Karte Ressourcen auf und klicken Sie auf Compute Engine.

4. Klicken Sie auf die VM-Instanz, die mit dem Instanznamen und der Zone in sourceInstanceDetails übereinstimmt. Prüfen Sie die Instanzdetails, einschließlich der Netzwerk- und Zugriffseinstellungen.

5. Klicken Sie im Navigationsbereich auf VPC-Netzwerk und dann auf Firewall. Firewallregeln mit zu vielen Berechtigungen entfernen oder deaktivieren

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.

2. Suchen Sie auf der Seite, die geladen wird, nach VPC-Flusslogs, die sich auf die IP-Adresse in srcIP beziehen. Verwenden Sie dazu den folgenden Filter:

   • logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="srcIP" OR jsonPayload.connection.dest_ip="destIP")

     Ersetzen Sie Folgendes:

     • PROJECT_ID durch die ID des Projekts, in dem das Problem festgestellt wurde.
     • SOURCE_IP durch die IP-Adresse, die im Feld srcIP der Ergebnis-JSON-Datei aufgeführt ist.
     • DESTINATION_IP durch die IP-Adresse, die im Feld destIp der Ergebnis-JSON-Datei aufgeführt ist.

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Network Denial of Service.
2. Sie können verwandte Ergebnisse prüfen, indem Sie auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Zugehörige Ergebnisse auf den Link für Ähnliche Ergebnisse klicken. Ähnliche Ergebnisse haben denselben Ergebnistyp und dieselbe Instanz und dasselbe Netzwerk.
3. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 5: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts, bei dem der ausgehende DoS-Traffic auftritt.
• Untersuchen Sie die potenziell manipulierte Instanz und entfernen Sie erkannte Malware. Verwenden Sie eine Lösung zur Endpunkterkennung und -antwort, um Unterstützung bei der Erkennung und Entfernung zu erhalten.
• Prüfen Sie Audit-Logs und Syslogs, die mit der manipulierten Instanz verknüpft sind, um Aktivitäten und Sicherheitslücken zu verfolgen, die das Einfügen von Malware ermöglichen.
• Beenden Sie bei Bedarf die manipulierte Instanz und ersetzen Sie sie durch eine neue Instanz.
• Blockieren Sie die schädlichen IP-Adressen, indem Sie Firewallregeln aktualisieren oder Google Cloud Armor verwenden. Sie können Google Cloud Armor auf der Seite Integrierte Dienste des Security Command Center aktivieren. Abhängig vom Datenvolumen können die Google Cloud Armor-Kosten beträchtlich sein. Weitere Informationen finden Sie in der Preisübersicht für Google Cloud Armor.
• Verwenden Sie die IAM-Richtlinie Shielded VM und Trusted Images, um den Zugriff und die Verwendung von VM-Images zu steuern.

Persistence: IAM Anomalous Grant

Audit-Logs werden untersucht, um das Hinzufügen von IAM-Rollenzuweisungen zu erkennen, die als verdächtig eingestuft werden können.

Im Folgenden finden Sie Beispiele für anomale Erteilungen:

• Externen Nutzer wie gmail.com über die Google Cloud Console als Projektinhaber einladen
• Ein Dienstkonto, das vertrauliche Berechtigungen erteilt
• Eine benutzerdefinierte Rolle, die vertrauliche Berechtigungen erteilt
• Ein Dienstkonto, das von außerhalb Ihrer Organisation oder Ihres Projekts hinzugefügt wurde

Das Ergebnis IAM Anomalous Grant ist einzigartig, da es untergeordnete Regeln enthält, die spezifischere Informationen zu jeder Instanz dieses Ergebnisses liefern. Der Schweregrad dieses Ergebnisses hängt von der untergeordneten Regel ab. Für jede untergeordnete Regel kann eine andere Antwort erforderlich sein.

In der folgenden Liste sind alle möglichen Unterregeln und ihre Schweregrade aufgeführt:

• external_service_account_added_to_policy:
  • HIGH, wenn eine hochsensible Rolle oder eine Rolle mit mittlerer Vertraulichkeit auf Organisationsebene gewährt wurde. Weitere Informationen finden Sie unter Besonders sensible Rollen.
  • MEDIUM, wenn eine Rolle mit mittlerer Vertraulichkeit gewährt wurde. Weitere Informationen finden Sie unter Rollen mit mittlerer Vertraulichkeit.
• external_member_invited_to_policy: HIGH
• external_member_added_to_policy:
  • HIGH, wenn eine hochsensible Rolle oder eine Rolle mit mittlerer Vertraulichkeit auf Organisationsebene gewährt wurde. Weitere Informationen finden Sie unter Besonders sensible Rollen.
  • MEDIUM, wenn eine Rolle mit mittlerer Vertraulichkeit gewährt wurde. Weitere Informationen finden Sie unter Rollen mit mittlerer Vertraulichkeit.
• custom_role_given_sensitive_permissions: MEDIUM
• service_account_granted_sensitive_role_to_member: HIGH
• policy_modified_by_default_compute_service_account: HIGH

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Persistence: IAM Anomalous Grant, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: E-Mail-Adresse des Nutzers oder Dienstkontos, dem die Rolle zugewiesen wurde.

   • Betroffene Ressource

   • Weitere Informationen, insbesondere die folgenden Felder:

     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
     • VirusTotal-Indikator: Link zur Analyseseite von VirusTotal.
     • Chronicle: Link zu Google SecOps.

3. Klicken Sie auf den Tab JSON. Der vollständige JSON-Code des Ergebnisses wird angezeigt.

4. Beachten Sie in der JSON-Datei für das Ergebnis die folgenden Felder:

   • detectionCategory:
     • subRuleName: genauere Informationen zur Art der aufgetretenen anormalen Gewährung. Die untergeordnete Regel bestimmt den Schweregrad dieses Ergebnisses.
   • evidence:
     • sourceLogId:
     • projectId: die ID des Projekts, das das Ergebnis enthält.
   • properties:
     • sensitiveRoleGrant:
       • bindingDeltas:
       • Action: die vom Nutzer ausgeführte Aktion.
       • Role: die Rolle, die dem Nutzer zugewiesen ist.
       • member: die E-Mail-Adresse des Nutzers, dem die Rolle zugewiesen wurde

Schritt 2: Sicherheitsvorgänge von Google untersuchen

Sie können dies mit Google Security Operations untersuchen. Google SecOps ist ein Google Cloud-Dienst, mit dem Sie Bedrohungen in einer benutzerfreundlichen Zeitachse prüfen und durch zugehörige Entitäten pivotieren können. Google SecOps reichert die Ergebnisdaten an, sodass Sie relevante Indikatoren identifizieren und Untersuchungen vereinfachen können.

Sie können Security Command Center-Ergebnisse in Chronicle nicht untersuchen, wenn Sie Security Command Center auf Projektebene aktivieren.

1. Wechseln Sie in der Google Cloud Console zur Seite Ergebnisse des Security Command Center.

   Zu Ergebnissen

2. Scrollen Sie im Bereich Schnellfilter nach unten zu Anzeigename der Quelle.

3. Wählen Sie im Abschnitt Anzeigename der Quelle die Option Event Threat Detection aus.

   Die Tabelle enthält die Ergebnisse für den ausgewählten Quelltyp.

4. Klicken Sie in der Tabelle unter Kategorie auf ein Persistence: IAM Anomalous Grant-Ergebnis. Der Detailbereich für die Suche wird geöffnet.

5. Klicken Sie im Bereich Weitere Informationen des Bereichs mit den Ergebnisdetails auf In Chronicle untersuchen.

6. Folgen Sie der Anleitung in der geführten Benutzeroberfläche von Google SecOps.

Orientieren Sie sich an den folgenden Leitfäden, um Prüfungen in Google SecOps durchzuführen:

• Nutzer untersuchen
• Asset untersuchen

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.
2. Suchen Sie auf der Seite, die geladen wird, mithilfe der folgenden Filter nach neuen oder aktualisierten IAM-Ressourcen:
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Prüfen Sie die MITRE ATT&CK-Framework-Einträge für diesen Ergebnistyp: Gültige Konten: Cloud-Konten.
2. Prüfen Sie verwandte Ergebnisse, indem Sie auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Ähnliche Ergebnisse auf den Link klicken. Ähnliche Ergebnisse sind der gleiche Ergebnistyp sowie dieselbe Instanz und dasselbe Netzwerk.
3. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Schritt 5: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Konto.
• Löschen Sie das manipulierte Dienstkonto und rotieren und löschen Sie alle Zugriffsschlüssel des Dienstkontos für das manipulierte Projekt. Nach dem Löschen verlieren Ressourcen, die das Dienstkonto für die Authentifizierung verwenden, den Zugriff.
• Projektressourcen löschen, die von nicht autorisierten Konten erstellt wurden, z. B. unbekannte Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer.
• Verwenden Sie die Organisationsrichtlinie, um das Hinzufügen von gmail.com-Nutzern einzuschränken.
• Um IAM-Rollen mit zu vielen Berechtigungen zu identifizieren und zu beheben, verwenden Sie IAM Recommender.

Persistence: Impersonation Role Granted for Dormant Service Account

Erkennt Ereignisse, bei denen einem Hauptkonto eine Rolle zur Identitätsübernahme gewährt wird, mit der dieses Hauptkonto die Identität eines inaktiven nutzerverwalteten Dienstkontos übernehmen kann. In diesem Ergebnis ist das inaktive Dienstkonto die betroffene Ressource. Ein Dienstkonto gilt als inaktiv, wenn es länger als 180 Tage inaktiv war.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Persistence: Impersonation Role Granted for Dormant Service Account wie unter Ergebnisse prüfen beschrieben.

2. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Felder.

   Gehen Sie unter Was erkannt wurde so vor:

   • Haupt-E-Mail-Adresse: der Nutzer, der die Gewährungsaktion durchgeführt hat
   • Verstoßende Zugriffsberechtigungen.Hauptkontoname: das Hauptkonto, dem die Rolle zur Identitätsübernahme gewährt wurde

   Unter Betroffene Ressource gehen Sie so vor:

   • Anzeigename der Ressource: das inaktive Dienstkonto als Ressource
   • Vollständiger Name des Projekts: das Projekt, in dem sich das inaktive Dienstkonto befindet

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Verwenden Sie Dienstkonto-Tools wie Activity Analyzer, um die Aktivität des inaktiven Dienstkontos zu untersuchen.
2. Wenden Sie sich an den Inhaber des Felds Haupt-E-Mail-Adresse. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung unter Weitere Informationen auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.

Schritt 4: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts, in dem die Aktion ausgeführt wurde.
• Entfernen Sie den Zugriff des Inhabers der Haupt-E-Mail-Adresse, wenn diese manipuliert wurde.
• Entfernen Sie die neu gewährte Rolle zur Identitätsübernahme für das Zielmitglied.
• Löschen Sie gegebenenfalls das potenziell manipulierte Dienstkonto und rotieren und löschen Sie alle Dienstkonto-Zugriffsschlüssel für das potenziell manipulierte Projekt. Nach dem Löschen verlieren Anwendungen, die das Dienstkonto zur Authentifizierung verwenden, den Zugriff. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Anwendungen identifizieren und mit den Anwendungsinhabern zusammenarbeiten, um für die Geschäftskontinuität zu sorgen.
• Ermitteln Sie gemeinsam mit Ihrem Sicherheitsteam unbekannte Ressourcen, einschließlich Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer. Ressourcen löschen, die nicht mit autorisierten Konten erstellt wurden.
• Auf Benachrichtigungen von Cloud Customer Care reagieren.
• Mit dem Organisationsrichtliniendienst können Sie einschränken, wer Dienstkonten erstellen kann.
• Verwenden Sie IAM Recommender, um zu moderate Rollen zu ermitteln und zu korrigieren.

Persistence: Unmanaged Account Granted Sensitive Role

Vorschau

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Erkennt Ereignisse, bei denen einem nicht verwalteten Konto eine vertrauliche Rolle gewährt wird Nicht verwaltete Konten können von Systemadministratoren nicht gesteuert werden. Wenn der entsprechende Mitarbeiter beispielsweise das Unternehmen verlassen hat, kann der Administrator das Konto nicht löschen. Das Gewähren von vertraulichen Rollen nicht verwalteten Konten stellt daher ein potenzielles Sicherheitsrisiko für die Organisation dar.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Persistence: Unmanaged Account Granted Sensitive Role wie unter Ergebnisse prüfen beschrieben.

2. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Felder.

   Gehen Sie unter Was erkannt wurde so vor:

   • Haupt-E-Mail-Adresse: der Nutzer, der die Gewährungsaktion durchgeführt hat
   • Verstoßende Zugriffsberechtigungen.Hauptkontoname: das nicht verwaltete Konto, das die Erteilung erhält
   • Offending access Grants.Role Grants: die gewährte sensible Rolle

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Wenden Sie sich an den Inhaber des Felds Haupt-E-Mail-Adresse. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
2. Wenden Sie sich an den Inhaber des Felds Offending access Grants.Principal name, um mehr über den Ursprung des nicht verwalteten Kontos zu erfahren.

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung unter Weitere Informationen auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.

Schritt 4: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts, in dem die Aktion ausgeführt wurde.
• Entfernen Sie den Zugriff des Inhabers der Haupt-E-Mail-Adresse, wenn diese manipuliert wurde.
• Entfernen Sie die neu gewährte sensible Rolle aus dem nicht verwalteten Konto.
• Sie können das nicht verwaltete Konto mit dem Übertragungstool in ein verwaltetes Konto umwandeln und dieses Konto dann unter die Kontrolle von Systemadministratoren verschieben.

Persistence: New API Method

In einer Organisation, einem Ordner oder einem Projekt wurden ungewöhnliche Administratoraktivitäten eines potenziell böswilligen Akteurs erkannt. Folgende anomale Aktivitäten sind möglich:

• Neue Aktivität von einem Hauptkonto in einer Organisation, einem Ordner oder einem Projekt
• Aktivität, die von einem Hauptkonto seit einiger Zeit nicht mehr in einer Organisation, einem Ordner oder einem Projekt erkannt wurde

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Persistence: New API Method wie unter Ergebnisse prüfen beschrieben.

2. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Felder:

   • Gehen Sie unter Was erkannt wurde so vor:
     • Haupt-E-Mail-Adresse: das Konto, über das der Anruf getätigt wurde
     • Dienstname: Der API-Name des Google Cloud-Dienstes, der in der Aktion verwendet wird.
     • Method name: die aufgerufene Methode
   • Unter Betroffene Ressource:
     • Anzeigename der Ressource: der Name der betroffenen Ressource. Dieser kann mit dem Namen der Organisation, des Ordners oder des Projekts übereinstimmen.
     • Ressourcenpfad: der Ort in der Ressourcenhierarchie, an dem die Aktivität stattfand

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Sehen Sie sich die Einträge des MITRE ATT&CK-Frameworks für den Ergebnistyp Persistenz an.
2. Prüfen Sie, ob die Aktion in der Organisation, im Ordner oder im Projekt gerechtfertigt war und ob sie vom rechtmäßigen Inhaber des Kontos ausgeführt wurde. Die Organisation, der Ordner oder das Projekt wird in der Zeile Ressourcenpfad und das Konto in der Zeile Haupt-E-Mail-Adresse angezeigt.
3. Kombinieren Sie Ihre Untersuchungsergebnisse mit MITRE-Studien, um einen Reaktionsplan zu entwickeln.

Persistence: New Geography

Dieses Ergebnis ist für Aktivierungen auf Projektebene nicht verfügbar.

Ein IAM-Nutzer oder ein Dienstkonto greift von einem ungewöhnlichen Standort aus auf die Google Cloud zu, basierend auf der Standortbestimmung der anfragenden IP-Adresse.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Persistence: New Geography-Ergebnis wie unter Ergebnisdetails prüfen weiter oben auf dieser Seite beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

• Was erkannt wurde, insbesondere die folgenden Felder:
  • Haupt-E-Mail-Adresse: Das möglicherweise manipulierte Nutzerkonto.
• Betroffene Ressource, insbesondere die folgenden Felder:
  • Vollständiger Name des Projekts: Das Projekt, das das potenziell manipulierte Nutzerkonto enthält.
• Weitere Informationen, insbesondere die folgenden Felder:
  • Cloud Logging-URI: Link zu Logging-Einträgen.
  • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
  • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

1. Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON.

2. Beachten Sie in der JSON-Datei die folgenden sourceProperties-Felder:

   • affectedResources:
     • gcpResourceName: betroffene Ressource
   • evidence:
     • sourceLogId:
     • projectId: Die ID des Projekts, das das Ergebnis enthält.
   • properties:
     • anomalousLocation:
     • anomalousLocation: der ungefähre aktuelle Standort des Nutzers.
     • callerIp ist die externe IP-Adresse.
     • notSeenInLast: der Zeitraum, der als Basis für das normale Verhalten herangezogen wird.
     • typicalGeolocations: die Standorte, an denen der Nutzer normalerweise auf Google Cloud-Ressourcen zugreift.

Schritt 2: Projekt- und Kontoberechtigungen prüfen

1. Öffnen Sie in der Google Cloud Console die Seite IAM.

   IAM aufrufen

2. Wählen Sie bei Bedarf das Projekt aus, das im Feld projectID der Ergebnis-JSON-Datei aufgeführt ist.

3. Geben Sie auf der angezeigten Seite im Feld Filter den Kontonamen ein, der unter Haupt-E-Mail-Adresse aufgeführt ist, und prüfen Sie die gewährten Rollen.

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.
2. Wählen Sie bei Bedarf Ihr Projekt aus.
3. Prüfen Sie auf der Seite, die geladen wird, die Logs von Aktivitäten aus neuen oder aktualisierten IAM-Ressourcen mithilfe der folgenden Filter:
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Sehen Sie sich den Eintrag des MITRE ATT&CK-Frameworks für diesen Ergebnistyp an: Gültige Konten: Cloud-Konten.
2. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Schritt 5: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Konto.
• Prüfen Sie die Felder anomalousLocation, typicalGeolocations und notSeenInLast, um festzustellen, ob der Zugriff abnormal ist und ob das Konto manipuliert wurde.
• Projektressourcen löschen, die von nicht autorisierten Konten erstellt wurden, z. B. unbekannte Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer.
• Informationen zum Einschränken der Erstellung neuer Ressourcen auf bestimmte Regionen finden Sie unter Ressourcenstandorte einschränken.
• Um IAM-Rollen mit zu vielen Berechtigungen zu identifizieren und zu beheben, verwenden Sie IAM Recommender.

Persistence: New User Agent

Dieses Ergebnis ist für Aktivierungen auf Projektebene nicht verfügbar.

Ein IAM-Dienstkonto greift über verdächtige Software auf Google Cloud zu, wie durch einen anomalen User-Agent angegeben.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Persistence: New User Agent-Ergebnis wie unter Ergebnisdetails prüfen weiter oben auf dieser Seite beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: Das möglicherweise manipulierte Dienstkonto.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name des Projekts: Das Projekt, das das potenziell manipulierte Dienstkonto enthält.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
   1. Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON.
   2. Beachten Sie in der JSON-Datei die folgenden Felder.
   • projectId: das Projekt, das das potenziell manipulierte Dienstkonto enthält
   • callerUserAgent: der anomale User-Agent.
   • anomalousSoftwareClassification: der Typ der Software.
   • notSeenInLast: der Zeitraum, der als Basis für ein normales Verhalten dient.

Schritt 2: Projekt- und Kontoberechtigungen prüfen

1. Öffnen Sie in der Google Cloud Console die Seite IAM.

   IAM aufrufen

2. Wählen Sie bei Bedarf das in projectId aufgeführte Projekt aus.

3. Geben Sie auf der angezeigten Seite im Feld Filter den Kontonamen ein, der auf dem Tab Zusammenfassung in der Zeile Haupt-E-Mail der Ergebnisdetails aufgeführt ist, und prüfen Sie die gewährten Rollen.

4. Rufen Sie in der Google Cloud Console die Seite Dienstkonten auf.

   Zur Seite „Dienstkonten“

5. Geben Sie auf der angezeigten Seite im Feld Filter den Kontonamen ein, der auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Haupt-E-Mail-Adresse aufgeführt ist.

6. Prüfen Sie die Schlüssel und das Datum der Schlüsselerstellung des Dienstkontos.

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.
2. Wählen Sie bei Bedarf Ihr Projekt aus.
3. Prüfen Sie auf der Seite, die geladen wird, die Logs von Aktivitäten aus neuen oder aktualisierten IAM-Ressourcen mithilfe der folgenden Filter:
   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten: Cloudkonten.
2. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 5: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Konto.
• Prüfen Sie die Felder anomalousSoftwareClassification, callerUserAgent und behaviorPeriod, um festzustellen, ob der Zugriff abnormal ist und ob das Konto manipuliert wurde.
• Projektressourcen löschen, die von nicht autorisierten Konten erstellt wurden, z. B. unbekannte Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer.
• Informationen zum Einschränken der Erstellung neuer Ressourcen auf bestimmte Regionen finden Sie unter Ressourcenstandorte einschränken.
• Um IAM-Rollen mit zu vielen Berechtigungen zu identifizieren und zu beheben, verwenden Sie IAM Recommender.

Privilege Escalation: Changes to sensitive Kubernetes RBAC objects

Zum Eskalieren der Berechtigung hat ein potenziell böswilliger Akteur versucht, ein Objekt der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) der sensiblen cluster-admin-Rolle mit einer PUT- oder PATCH-Anfrage zu ändern.ClusterRoleRoleBindingClusterRoleBinding

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Privilege Escalation: Changes to sensitive Kubernetes RBAC objects wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: das Konto, über das der Anruf getätigt wurde.
     • Methodenname: Die aufgerufene Methode.
     • Kubernetes-Bindungen: Die vertrauliche Kubernetes-Bindung oder ClusterRoleBinding, die geändert wurde.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Anzeigename der Ressource: der Kubernetes-Cluster, in dem die Aktion aufgetreten ist
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

3. Klicken Sie im Abschnitt Was erkannt wurde in der Zeile Kubernetes-Bindungen auf den Namen der Bindung. Die Bindungsdetails werden angezeigt.

4. Notieren Sie sich die Bindungsdetails in der angezeigten Bindung.

Schritt 2: Protokolle prüfen

1. Rufen Sie in der Google Cloud Console auf dem Tab Zusammenfassung der Ergebnisdetails den Log-Explorer auf, indem Sie auf den Link im Feld Cloud Logging-URI klicken.

2. Wenn der Wert in Methodenname eine PATCH-Methode war, sehen Sie im Anfragetext nach, welche Attribute geändert wurden.

   Bei update-Aufrufen (PUT) wird das gesamte Objekt in der Anfrage gesendet, sodass die Änderungen nicht so eindeutig sind.

3. Prüfen Sie mithilfe der folgenden Filter auf andere Aktionen, die vom Hauptkonto ausgeführt wurden:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Ersetzen Sie Folgendes:

   • CLUSTER_NAME: der Wert, den Sie in den Ergebnisdetails im Feld Anzeigename der Ressource notiert haben.

   • PRINCIPAL_EMAIL: der Wert, den Sie in den Ergebnisdetails im Feld Haupt-E-Mail-Adresse notiert haben.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Prüfen Sie die MITRE ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ausweitung von Berechtigungen.
2. Prüfen Sie die Empfindlichkeit des Objekts und finden Sie heraus, ob die Änderung gerechtfertigt ist.
3. Bei Bindungen können Sie das Subjekt überprüfen und untersuchen, ob es die Rolle benötigt, an die es gebunden ist.
4. Prüfen Sie, ob die Logs weitere Anzeichen für schädliche Aktivitäten des Hauptkontos enthalten.

5. Wenn die E-Mail-Adresse des Hauptkontos kein Dienstkonto ist, fragen Sie den Inhaber des Kontos, ob der legitime Inhaber die Aktion durchgeführt hat.

   Wenn die Haupt-E-Mail-Adresse ein Dienstkonto (IAM oder Kubernetes) ist, ermitteln Sie die Quelle der Änderung, um deren Legitimität zu ermitteln.

6. Kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung, um einen Reaktionsplan zu entwickeln.

Privilege Escalation: Create Kubernetes CSR for master cert

Um die Berechtigung auszuweiten, erstellte ein potenziell böswilliger Akteur eine Anfrage zur Zertifikatssignierung (CSR), die ihm cluster-admin Zugriff gewährt.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Privilege Escalation: Create Kubernetes CSR for master cert wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: das Konto, über das der Anruf getätigt wurde.
     • Methodenname: Die aufgerufene Methode.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Anzeigename der Ressource: der Kubernetes-Cluster, in dem die Aktion aufgetreten ist
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

Schritt 2: Protokolle prüfen

1. Rufen Sie in der Google Cloud Console auf dem Tab Zusammenfassung der Ergebnisdetails den Log-Explorer auf, indem Sie auf den Link im Feld Cloud Logging-URI klicken.
2. Prüfen Sie den Wert im Feld protoPayload.resourceName, um die jeweilige Anfrage zur Zertifikatsignierung zu identifizieren.

3. Prüfen Sie mithilfe der folgenden Filter auf andere Aktionen, die vom Hauptkonto ausgeführt wurden:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Ersetzen Sie Folgendes:

   • CLUSTER_NAME: der Wert, den Sie in den Ergebnisdetails im Feld Anzeigename der Ressource notiert haben.

   • PRINCIPAL_EMAIL: der Wert, den Sie in den Ergebnisdetails im Feld Haupt-E-Mail-Adresse notiert haben.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Prüfen Sie die MITRE ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ausweitung von Berechtigungen.
2. Prüfen Sie, ob die Gewährung des Zugriffs für cluster-admin gerechtfertigt war.

3. Wenn die E-Mail-Adresse des Hauptkontos kein Dienstkonto ist, fragen Sie den Inhaber des Kontos, ob der legitime Inhaber die Aktion durchgeführt hat.

   Wenn die Haupt-E-Mail-Adresse ein Dienstkonto (IAM oder Kubernetes) ist, ermitteln Sie die Quelle der Aktion, um ihre Legitimität zu ermitteln.

4. Kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung, um einen Reaktionsplan zu entwickeln.

Privilege Escalation: Creation of sensitive Kubernetes bindings

Zum Ausweiten der Berechtigung hat ein potenziell böswilliger Akteur versucht, ein neues RoleBinding- oder ClusterRoleBinding-Objekt für die Rolle cluster-admin zu erstellen.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Privilege Escalation: Creation of sensitive Kubernetes bindings wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: das Konto, über das der Anruf getätigt wurde.
     • Kubernetes-Bindungen: Die erstellte vertrauliche Kubernetes-Bindung oder ClusterRoleBinding.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Anzeigename der Ressource: der Kubernetes-Cluster, in dem die Aktion aufgetreten ist
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

Schritt 2: Protokolle prüfen

1. Rufen Sie in der Google Cloud Console auf dem Tab Zusammenfassung der Ergebnisdetails den Log-Explorer auf, indem Sie auf den Link im Feld Cloud Logging-URI klicken.

2. Prüfen Sie mithilfe der folgenden Filter auf andere Aktionen, die vom Hauptkonto ausgeführt wurden:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Ersetzen Sie Folgendes:

   • CLUSTER_NAME: der Wert, den Sie in den Ergebnisdetails im Feld Anzeigename der Ressource notiert haben.

   • PRINCIPAL_EMAIL: der Wert, den Sie in den Ergebnisdetails im Feld Haupt-E-Mail-Adresse notiert haben.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Prüfen Sie die MITRE ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ausweitung von Berechtigungen.
2. Prüfen Sie die Vertraulichkeit der erstellten Bindung und ob die Rollen für die Subjekte erforderlich sind.
3. Bei Bindungen können Sie das Subjekt überprüfen und untersuchen, ob es die Rolle benötigt, an die es gebunden ist.
4. Prüfen Sie, ob die Logs weitere Anzeichen für schädliche Aktivitäten des Hauptkontos enthalten.

5. Wenn die E-Mail-Adresse des Hauptkontos kein Dienstkonto ist, fragen Sie den Inhaber des Kontos, ob der legitime Inhaber die Aktion durchgeführt hat.

   Wenn die Haupt-E-Mail-Adresse ein Dienstkonto (IAM oder Kubernetes) ist, ermitteln Sie die Quelle der Aktion, um ihre Legitimität zu ermitteln.

6. Kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung, um einen Reaktionsplan zu entwickeln.

Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials

Zum Ausweiten der Berechtigungen fragte ein potenziell böswilliger Akteur mit dem Befehl kubectl eine Zertifikatsignierungsanfrage (Certificate Signing Request, CSR) ab. Dabei wurden manipulierte Bootstrap-Anmeldedaten verwendet.

Im Folgenden finden Sie ein Beispiel für einen Befehl, der von dieser Regel erkannt wird:

kubectl --client-certificate kubelet.crt --client-key kubelet.key --server YOUR_SERVER get csr CSR_NAME

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: das Konto, über das der Anruf getätigt wurde.
     • Methodenname: Die aufgerufene Methode.
   • Unter Betroffene Ressource:
     • Anzeigename der Ressource: der Kubernetes-Cluster, in dem die Aktion aufgetreten ist
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

Schritt 2: Protokolle prüfen

Wenn der Methodenname, den Sie in den Ergebnisdetails im Feld Methodenname notiert haben, eine Methode vom Typ GET ist, gehen Sie so vor:

1. Rufen Sie in der Google Cloud Console auf dem Tab Zusammenfassung der Ergebnisdetails den Log-Explorer auf, indem Sie auf den Link im Feld Cloud Logging-URI klicken.
2. Prüfen Sie den Wert im Feld protoPayload.resourceName, um die jeweilige Anfrage zur Zertifikatsignierung zu identifizieren.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Prüfen Sie die MITRE ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ausweitung von Berechtigungen.
2. Wenn die spezifische CSR im Logeintrag verfügbar ist, prüfen Sie die Vertraulichkeit des Zertifikats und ob die Aktion gerechtfertigt war.
3. Kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung, um einen Reaktionsplan zu entwickeln.

Privilege Escalation: Launch of privileged Kubernetes container

Ein potenziell böswilliger Akteur hat einen Pod erstellt, der privilegierte Container oder Container mit Funktionen zur Rechteausweitung enthält.

Bei einem privilegierten Container ist das Feld privileged auf true festgelegt. Bei einem Container mit Berechtigungen zur Rechteausweitung ist das Feld allowPrivilegeEscalation auf true gesetzt. Weitere Informationen finden Sie in der Kubernetes-Dokumentation in der API-Referenz für SecurityContext v1 Core.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Privilege Escalation: Launch of privileged Kubernetes container wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: das Konto, über das der Anruf getätigt wurde.
     • Kubernetes-Pods: der neu erstellte Pod mit privilegierten Containern.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Anzeigename der Ressource: der Kubernetes-Cluster, in dem die Aktion aufgetreten ist
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

3. Notieren Sie sich auf dem Tab JSON die Werte der Ergebnisfelder:

   • findings.kubernetes.pods[].containers: Der privilegierte Container, der im Pod aktiviert ist.

Schritt 2: Protokolle prüfen

1. Rufen Sie in der Google Cloud Console auf dem Tab Zusammenfassung der Ergebnisdetails den Log-Explorer auf, indem Sie auf den Link im Feld Cloud Logging-URI klicken.

2. Prüfen Sie mithilfe der folgenden Filter auf andere Aktionen, die vom Hauptkonto ausgeführt wurden:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Ersetzen Sie Folgendes:

   • CLUSTER_NAME: der Wert, den Sie in den Ergebnisdetails im Feld Anzeigename der Ressource notiert haben.

   • PRINCIPAL_EMAIL: der Wert, den Sie in den Ergebnisdetails im Feld Haupt-E-Mail-Adresse notiert haben.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Prüfen Sie die MITRE ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ausweitung von Berechtigungen.
2. Prüfen Sie, ob der erstellte Container Zugriff auf Hostressourcen und Kernelfunktionen benötigt.
3. Prüfen Sie, ob die Logs weitere Anzeichen für schädliche Aktivitäten des Hauptkontos enthalten.

4. Wenn die E-Mail-Adresse des Hauptkontos kein Dienstkonto ist, fragen Sie den Inhaber des Kontos, ob die Aktion vom legitimen Inhaber durchgeführt wurde.

   Wenn die Haupt-E-Mail-Adresse ein Dienstkonto (IAM oder Kubernetes) ist, ermitteln Sie die Quelle der Aktion, um ihre Legitimität zu ermitteln.

5. Kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung, um einen Reaktionsplan zu entwickeln.

Privilege Escalation: Dormant Service Account Granted Sensitive Role

Erkennt Ereignisse, bei denen einem inaktiven nutzerverwalteten Dienstkonto eine vertrauliche IAM-Rolle gewährt wird. Ein Dienstkonto gilt in diesem Zusammenhang als inaktiv, wenn es länger als 180 Tage inaktiv war.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Privilege Escalation: Dormant Service Account Granted Sensitive Role wie unter Ergebnisse prüfen beschrieben.

2. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Felder.

   Gehen Sie unter Was erkannt wurde so vor:

   • Haupt-E-Mail-Adresse: der Nutzer, der die Gewährungsaktion durchgeführt hat
   • Verstörende Zugriffsberechtigungen.Hauptkontoname: das inaktive Dienstkonto, das die vertrauliche Rolle erhalten hat
   • Verstöße gegen Zugriffsberechtigungen.Rolle gewährt: die vertrauliche IAM-Rolle, die zugewiesen wird

   Unter Betroffene Ressource gehen Sie so vor:

   • Anzeigename der Ressource: die Organisation, der Ordner oder das Projekt, in dem die vertrauliche IAM-Rolle dem inaktiven Dienstkonto gewährt wurde.

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Verwenden Sie Dienstkonto-Tools wie Activity Analyzer, um die Aktivität des inaktiven Dienstkontos zu untersuchen.
2. Wenden Sie sich an den Inhaber des Felds Haupt-E-Mail-Adresse. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung unter Weitere Informationen auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.

Schritt 4: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts, in dem die Aktion ausgeführt wurde.
• Entfernen Sie den Zugriff des Inhabers der Haupt-E-Mail-Adresse, wenn diese manipuliert wurde.
• Entfernen Sie die neu zugewiesene vertrauliche IAM-Rolle aus dem inaktiven Dienstkonto.
• Löschen Sie gegebenenfalls das potenziell manipulierte Dienstkonto und rotieren und löschen Sie alle Dienstkonto-Zugriffsschlüssel für das potenziell manipulierte Projekt. Nach dem Löschen verlieren Ressourcen, die das Dienstkonto zur Authentifizierung verwenden, den Zugriff. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Ressourcen identifizieren und mit den Ressourceninhabern zusammenarbeiten, um für die Geschäftskontinuität zu sorgen.
• Ermitteln Sie gemeinsam mit Ihrem Sicherheitsteam unbekannte Ressourcen, einschließlich Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer. Ressourcen löschen, die nicht mit autorisierten Konten erstellt wurden.
• Auf Benachrichtigungen von Cloud Customer Care reagieren.
• Mit dem Organisationsrichtliniendienst können Sie einschränken, wer Dienstkonten erstellen kann.
• Verwenden Sie IAM Recommender, um zu moderate Rollen zu ermitteln und zu korrigieren.

Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity

Um eine ungewöhnliche Identität eines Dienstkontos zu erkennen, wird in den Audit-Logs zur Administratoraktivität geprüft, ob bei einer Anfrage zur Identitätsübernahme eines Dienstkontos eine Anomalie aufgetreten ist.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: das letzte Dienstkonto in der Anfrage zur Identitätsübernahme, die für den Zugriff auf Google Cloud verwendet wurde.
     • Dienstname: der API-Name des Google Cloud-Dienstes, der an der Anfrage zur Identitätsübernahme beteiligt ist.
     • Methodenname: Die aufgerufene Methode.
     • Informationen zur Dienstkontodelegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto am Ende der Liste ist der Aufrufer der Anfrage zur Identitätsübernahme.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der Name des Clusters.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
2. Prüfen Sie die Hauptkonten in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
3. Wenden Sie sich in der Liste Informationen zur Dienstkontodelegierung an den Inhaber des Aufrufers zur Identitätsübernahme. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts, in dem die Aktion ausgeführt wurde.
• Löschen Sie gegebenenfalls das potenziell manipulierte Dienstkonto und rotieren und löschen Sie alle Dienstkonto-Zugriffsschlüssel für das potenziell manipulierte Projekt. Nach dem Löschen verlieren Ressourcen, die das Dienstkonto zur Authentifizierung verwenden, den Zugriff. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Ressourcen identifizieren und mit den Ressourceninhabern zusammenarbeiten, um für die Geschäftskontinuität zu sorgen.
• Ermitteln Sie gemeinsam mit Ihrem Sicherheitsteam unbekannte Ressourcen, einschließlich Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer. Ressourcen löschen, die nicht mit autorisierten Konten erstellt wurden.
• Reagieren Sie auf alle Benachrichtigungen vom Google Cloud-Support.
• Mit dem Organisationsrichtliniendienst können Sie einschränken, wer Dienstkonten erstellen kann.
• Verwenden Sie IAM Recommender, um zu moderate Rollen zu ermitteln und zu korrigieren.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity

Anomalous Multistep Service Account Delegation wird durch Prüfen der Audit-Logs zur Administratoraktivität darauf erkannt, ob bei einer Anfrage zur Identitätsübernahme eines Dienstkontos eine Anomalie aufgetreten ist.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: das letzte Dienstkonto in der Anfrage zur Identitätsübernahme, die für den Zugriff auf Google Cloud verwendet wurde.
     • Dienstname: der API-Name des Google Cloud-Dienstes, der an der Anfrage zur Identitätsübernahme beteiligt ist.
     • Methodenname: Die aufgerufene Methode.
     • Informationen zur Dienstkontodelegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto am Ende der Liste ist der Aufrufer der Anfrage zur Identitätsübernahme.
   • Betroffene Ressource
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
2. Prüfen Sie die Hauptkonten in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
3. Wenden Sie sich in der Liste Informationen zur Dienstkontodelegierung an den Inhaber des Aufrufers zur Identitätsübernahme. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts, in dem die Aktion ausgeführt wurde.
• Löschen Sie gegebenenfalls das potenziell manipulierte Dienstkonto und rotieren und löschen Sie alle Dienstkonto-Zugriffsschlüssel für das potenziell manipulierte Projekt. Nach dem Löschen verlieren Ressourcen, die das Dienstkonto zur Authentifizierung verwenden, den Zugriff. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Ressourcen identifizieren und mit den Ressourceninhabern zusammenarbeiten, um für die Geschäftskontinuität zu sorgen.
• Ermitteln Sie gemeinsam mit Ihrem Sicherheitsteam unbekannte Ressourcen, einschließlich Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer. Ressourcen löschen, die nicht mit autorisierten Konten erstellt wurden.
• Reagieren Sie auf alle Benachrichtigungen vom Google Cloud-Support.
• Mit dem Organisationsrichtliniendienst können Sie einschränken, wer Dienstkonten erstellen kann.
• Verwenden Sie IAM Recommender, um zu moderate Rollen zu ermitteln und zu korrigieren.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access

Anomalous Multistep Service Account Delegation wird durch Prüfen der Audit-Logs zum Datenzugriff auf Anomalien bei einer Anfrage zur Identitätsübernahme eines Dienstkontos erkannt.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: das letzte Dienstkonto in der Anfrage zur Identitätsübernahme, die für den Zugriff auf Google Cloud verwendet wurde
     • Dienstname: der API-Name des Google Cloud-Dienstes, der an der Anfrage zur Identitätsübernahme beteiligt ist.
     • Method name: die aufgerufene Methode
     • Informationen zur Dienstkontodelegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto am Ende der Liste ist der Aufrufer der Anfrage zur Identitätsübernahme.
   • Betroffene Ressource
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
2. Prüfen Sie die Hauptkonten in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
3. Wenden Sie sich in der Liste Informationen zur Dienstkontodelegierung an den Inhaber des Aufrufers zur Identitätsübernahme. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts, in dem die Aktion ausgeführt wurde.
• Löschen Sie gegebenenfalls das potenziell manipulierte Dienstkonto und rotieren und löschen Sie alle Dienstkonto-Zugriffsschlüssel für das potenziell manipulierte Projekt. Nach dem Löschen verlieren Ressourcen, die das Dienstkonto zur Authentifizierung verwenden, den Zugriff. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Ressourcen identifizieren und mit den Ressourceninhabern zusammenarbeiten, um für die Geschäftskontinuität zu sorgen.
• Ermitteln Sie gemeinsam mit Ihrem Sicherheitsteam unbekannte Ressourcen, einschließlich Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer. Ressourcen löschen, die nicht mit autorisierten Konten erstellt wurden.
• Reagieren Sie auf alle Benachrichtigungen vom Google Cloud-Support.
• Mit dem Organisationsrichtliniendienst können Sie einschränken, wer Dienstkonten erstellen kann.
• Verwenden Sie IAM Recommender, um zu moderate Rollen zu ermitteln und zu korrigieren.

Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity

Anomalous Service Account Impersonator wird durch Prüfen der Audit-Logs zur Administratoraktivität darauf erkannt, ob bei einer Anfrage zur Identitätsübernahme eines Dienstkontos eine Anomalie aufgetreten ist.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:

     • Haupt-E-Mail-Adresse: das letzte Dienstkonto in der Anfrage zur Identitätsübernahme, die für den Zugriff auf Google Cloud verwendet wurde
     • Dienstname: der API-Name des Google Cloud-Dienstes, der an der Anfrage zur Identitätsübernahme beteiligt ist.
     • Method name: die aufgerufene Methode
     • Informationen zur Dienstkontodelegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto am Ende der Liste ist der Aufrufer der Anfrage zur Identitätsübernahme.

   • Betroffene Ressource

   • Weitere Informationen, insbesondere die folgenden Felder:

     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
2. Prüfen Sie die Hauptkonten in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
3. Wenden Sie sich in der Liste Informationen zur Dienstkontodelegierung an den Inhaber des Aufrufers zur Identitätsübernahme. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts, in dem die Aktion ausgeführt wurde.
• Löschen Sie gegebenenfalls das potenziell manipulierte Dienstkonto und rotieren und löschen Sie alle Dienstkonto-Zugriffsschlüssel für das potenziell manipulierte Projekt. Nach dem Löschen verlieren Ressourcen, die das Dienstkonto zur Authentifizierung verwenden, den Zugriff. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Ressourcen identifizieren und mit den Ressourceninhabern zusammenarbeiten, um für die Geschäftskontinuität zu sorgen.
• Ermitteln Sie gemeinsam mit Ihrem Sicherheitsteam unbekannte Ressourcen, einschließlich Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer. Ressourcen löschen, die nicht mit autorisierten Konten erstellt wurden.
• Reagieren Sie auf alle Benachrichtigungen vom Google Cloud-Support.
• Mit dem Organisationsrichtliniendienst können Sie einschränken, wer Dienstkonten erstellen kann.
• Verwenden Sie IAM Recommender, um zu moderate Rollen zu ermitteln und zu korrigieren.

Privilege Escalation: Anomalous Service Account Impersonator for Data Access

Anomale Dienstkonto-Identitätsübernahmen werden erkannt, indem die Audit-Logs zum Datenzugriff auf Anomalien bei einer Anfrage zur Identitätsübernahme für ein Dienstkonto untersucht werden.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Privilege Escalation: Anomalous Service Account Impersonator for Data Access wie unter Ergebnisse prüfen beschrieben.

2. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Felder.

   Gehen Sie unter Was erkannt wurde so vor:

   • Haupt-E-Mail-Adresse: das letzte Dienstkonto in der Anfrage zur Identitätsübernahme, die für den Zugriff auf Google Cloud verwendet wurde
   • Dienstname: der API-Name des Google Cloud-Dienstes, der an der Anfrage zur Identitätsübernahme beteiligt ist.
   • Method name: die aufgerufene Methode
   • Informationen zur Dienstkontodelegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto am Ende der Liste ist der Aufrufer der Anfrage zur Identitätsübernahme.

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
2. Prüfen Sie die Hauptkonten in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
3. Wenden Sie sich in der Liste Informationen zur Dienstkontodelegierung an den Inhaber des Aufrufers zur Identitätsübernahme. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts, in dem die Aktion ausgeführt wurde.
• Löschen Sie gegebenenfalls das potenziell manipulierte Dienstkonto und rotieren und löschen Sie alle Dienstkonto-Zugriffsschlüssel für das potenziell manipulierte Projekt. Nach dem Löschen verlieren Ressourcen, die das Dienstkonto zur Authentifizierung verwenden, den Zugriff. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Ressourcen identifizieren und mit den Ressourceninhabern zusammenarbeiten, um für die Geschäftskontinuität zu sorgen.
• Ermitteln Sie gemeinsam mit Ihrem Sicherheitsteam unbekannte Ressourcen, einschließlich Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer. Ressourcen löschen, die nicht mit autorisierten Konten erstellt wurden.
• Reagieren Sie auf alle Benachrichtigungen vom Google Cloud-Support.
• Mit dem Organisationsrichtliniendienst können Sie einschränken, wer Dienstkonten erstellen kann.
• Verwenden Sie IAM Recommender, um zu moderate Rollen zu ermitteln und zu korrigieren.

Service account self-investigation

Die Anmeldedaten eines Dienstkontos werden verwendet, um die Rollen und Berechtigungen zu untersuchen, die mit diesem Dienstkonto verknüpft sind. Dieses Ergebnis deutet darauf hin, dass die Anmeldedaten des Dienstkontos gehackt wurden und sofort Maßnahmen ergriffen werden sollten.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Discovery: Service Account Self-Investigation-Ergebnis wie unter Ergebnisdetails prüfen weiter oben auf dieser Seite beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Schweregrad: Die dem Ergebnis zugewiesene Risikostufe. Der Schweregrad lautet HIGH, wenn der API-Aufruf, der dieses Ergebnis ausgelöst hat, nicht autorisiert war. Das Dienstkonto ist nicht berechtigt, seine eigenen IAM-Berechtigungen mit der projects.getIamPolicy API abzufragen.
     • Haupt-E-Mail-Adresse: Das möglicherweise manipulierte Dienstkonto.
     • Caller IP: die interne oder externe IP-Adresse
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource:
     • Vollständiger Name des Projekts: Das Projekt, das die potenziell gehackten Kontoanmeldedaten enthält.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
   1. Klicken Sie auf den Tab JSON, um die vollständige JSON-Datei für das Ergebnis anzusehen.

Schritt 2: Projekt- und Dienstkontoberechtigungen prüfen

1. Öffnen Sie in der Google Cloud Console die Seite IAM.

   IAM aufrufen

2. Wählen Sie bei Bedarf das Projekt aus, das im Feld projectID der Ergebnis-JSON-Datei aufgeführt ist.

3. Geben Sie auf der angezeigten Seite im Feld Filter den Kontonamen ein, der unter Haupt-E-Mail-Adresse aufgeführt ist, und überprüfen Sie die zugewiesenen Berechtigungen.

4. Rufen Sie in der Google Cloud Console die Seite Dienstkonten auf.

   Zur Seite „Dienstkonten“

5. Geben Sie auf der angezeigten Seite im Feld Filter den Namen des manipulierten Dienstkontos ein und prüfen Sie die Schlüssel und das Datum der Erstellung des Dienstkontos.

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.
2. Wählen Sie bei Bedarf Ihr Projekt aus.
3. Prüfen Sie auf der Seite, die geladen wird, die Logs von Aktivitäten aus neuen oder aktualisierten IAM-Ressourcen mithilfe der folgenden Filter:
   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Permission Groups Discovery: Cloud Groups.
2. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 5: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Konto.
• Löschen Sie das manipulierte Dienstkonto und rotieren und löschen Sie alle Zugriffsschlüssel des Dienstkontos für das manipulierte Projekt. Nach dem Löschen verlieren Ressourcen, die das Dienstkonto für die Authentifizierung verwenden, den Zugriff.
• Löschen Sie Projektressourcen, die vom manipulierten Konto erstellt wurden, z. B. unbekannte Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer.

Inhibit System Recovery: Deleted Google Cloud Backup and DR host

Event Threat Detection prüft Audit-Logs, um das Löschen von Hosts zu erkennen, auf denen Anwendungen ausgeführt werden, die durch den Sicherungs‐ und Notfallwiederherstellungsdienst geschützt sind. Nachdem ein Host gelöscht wurde, können mit dem Host verknüpfte Anwendungen nicht mehr gesichert werden.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Inhibit System Recovery: Deleted Google Cloud Backup and DR host, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.
2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:
   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Anwendungsname: der Name einer Datenbank oder VM, die mit Sicherung und Notfallwiederherstellung verbunden ist
     • Hostname: der Name eines Hosts, der mit der Sicherung und Notfallwiederherstellung verbunden ist
     • Hauptthema: Ein Nutzer, der eine Aktion erfolgreich ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: das Projekt, in dem der Host gelöscht wurde
   • Weitere Informationen, insbesondere die folgenden Felder:
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Logging-URI: Link zum Öffnen des Log-Explorers

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein. Werten Sie die Informationen aus Ihrer Untersuchung sorgfältig aus, um den besten Weg zur Lösung der Ergebnisse zu ermitteln.

1. Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf.
2. Prüfen Sie, ob der gelöschte Host nicht mehr in der Liste der Hosts für Sicherung und Notfallwiederherstellung enthalten ist.
3. Wählen Sie die Option Host hinzufügen aus, um den gelöschten Host wieder hinzuzufügen.

Inhibit System Recovery: Google Cloud Backup and DR remove plan

Security Command Center prüft Audit-Logs, um das anomale Löschen eines Sicherungsplans für den Sicherungs- und Notfallwiederherstellungsdienst zu erkennen, der zur Anwendung von Sicherungsrichtlinien auf eine Anwendung verwendet wird.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Inhibit System Recovery: Google Cloud Backup and DR remove plan, wie unter Ergebnisse prüfen beschrieben. Im Detailbereich für das Ergebnis wird der Tab Zusammenfassung geöffnet.
2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:
   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Anwendungsname: der Name einer Datenbank oder VM, die mit Sicherung und Notfallwiederherstellung verbunden ist
     • Profilname: Gibt das Speicherziel für Sicherungen von Anwendungs- und VM-Daten an.
     • Vorlagenname: Der Name für eine Reihe von Richtlinien, mit denen die Häufigkeit, der Zeitplan und die Aufbewahrungsdauer für die Sicherung definiert werden
   • Betroffene Ressource
     • Anzeigename der Ressource: das Projekt, in dem der Plan gelöscht wurde
   • Weitere Informationen, insbesondere die folgenden Felder:
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Logging-URI: Link zum Öffnen des Log-Explorers

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein. Werten Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erhalten haben, sorgfältig aus, um die beste Möglichkeit zur Lösung von Ergebnissen zu ermitteln.

1. Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf.
2. Suchen Sie auf dem Tab App Manager nach den betroffenen Anwendungen, die nicht mehr geschützt sind, und prüfen Sie die Sicherungsrichtlinien für jede Anwendung.

Inhibit System Recovery: Google Cloud Backup and DR delete template

Security Command Center prüft Audit-Logs, um das ungewöhnliche Löschen einer Vorlage zu erkennen. Eine Vorlage ist eine Basiskonfiguration für Sicherungen, die auf mehrere Anwendungen angewendet werden können.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Inhibit System Recovery: Google Cloud Backup and DR delete template, wie unter Ergebnisse prüfen beschrieben. Im Detailbereich für das Ergebnis wird der Tab Zusammenfassung geöffnet.
2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:
   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Vorlagenname: Der Name für eine Reihe von Richtlinien, mit denen die Häufigkeit, der Zeitplan und die Aufbewahrungsdauer für die Sicherung definiert werden
     • Hauptthema: Ein Nutzer, der eine Aktion erfolgreich ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: das Projekt, in dem die Vorlage gelöscht wurde
   • Weitere Informationen, insbesondere die folgenden Felder:
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Logging-URI: Link zum Öffnen des Log-Explorers

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein. Werten Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erhalten haben, sorgfältig aus, um die beste Möglichkeit zur Lösung von Ergebnissen zu ermitteln.

1. Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf.
2. Suchen Sie auf dem Tab App Manager nach den betroffenen Anwendungen, die nicht mehr geschützt sind, und prüfen Sie die Sicherungsrichtlinien für jede Anwendung.
3. Wenn Sie eine Vorlage wieder hinzufügen möchten, gehen Sie zum Tab Sicherungspläne, wählen Sie Vorlagen und dann die Option Vorlage erstellen aus.

Inhibit System Recovery: Google Cloud Backup and DR delete policy

Audit-Logs werden darauf geprüft, ob eine Richtlinie gelöscht wurde. Eine Richtlinie definiert, wie eine Sicherung erstellt und wo sie gespeichert wird.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Inhibit System Recovery: Google Cloud Backup and DR delete policy, wie unter Ergebnisse prüfen beschrieben. Im Detailbereich für das Ergebnis wird der Tab Zusammenfassung geöffnet.
2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:
   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Richtlinienname: Der Name für eine einzelne Richtlinie, der die Sicherungshäufigkeit, den Zeitplan und die Aufbewahrungsdauer definiert
     • Hauptthema: Ein Nutzer, der eine Aktion erfolgreich ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: Das Projekt, in dem die Richtlinie gelöscht wurde
   • Weitere Informationen, insbesondere die folgenden Felder:
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Logging-URI: Link zum Öffnen des Log-Explorers

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein. Werten Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erhalten haben, sorgfältig aus, um den besten Weg zur Lösung der Ergebnisse zu ermitteln. 1. Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf. 2. Wählen Sie auf dem Tab App Manager die betroffene App aus und überprüfen Sie die entsprechenden Richtlinieneinstellungen.

Inhibit System Recovery: Google Cloud Backup and DR delete profile

Audit-Logs werden auf das Löschen eines Profils geprüft. Ein Profil definiert, welche Speicherpools zum Speichern von Sicherungen verwendet werden.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Inhibit System Recovery: Google Cloud Backup and DR delete profile, wie unter Ergebnisse überprüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.
2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:
   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Profilname: Gibt das Speicherziel für Sicherungen von Anwendungs- und VM-Daten an.
     • Hauptthema: Ein Nutzer, der eine Aktion erfolgreich ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: das Projekt, in dem das Profil gelöscht wurde
   • Weitere Informationen, insbesondere die folgenden Felder:
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Logging-URI: Link zum Öffnen des Log-Explorers

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein. Werten Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erhalten haben, sorgfältig aus, um den besten Weg zur Lösung der Ergebnisse zu ermitteln. 1. Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf. 2. Wählen Sie auf dem Tab Sicherungspläne die Option Profile aus, um eine Liste aller Profile zu erhalten. 3. Prüfen Sie die Profile, um sicherzustellen, dass alle erforderlichen Profile vorhanden sind. 4. Falls das gelöschte Profil fälschlicherweise entfernt wurde, wählen Sie Profil erstellen aus, um Speicherziele für Ihre Sicherungs‐ und Notfallwiederherstellungs-Appliances zu definieren.

Inhibit System Recovery: Google Cloud Backup and DR delete storage pool

Audit-Logs werden untersucht, um das Löschen eines Speicherpools zu erkennen. Ein Speicherpool verknüpft einen Cloud Storage-Bucket mit Sicherung und Notfallwiederherstellung.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Inhibit System Recovery: Google Cloud Backup and DR delete storage pool, wie unter Ergebnisse überprüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.
2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:
   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Speicherpoolname: der Name für Storage-Buckets, in denen Sicherungen gespeichert werden
     • Hauptthema: Ein Nutzer, der eine Aktion erfolgreich ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: das Projekt, in dem der Speicherpool gelöscht wurde
   • Weitere Informationen, insbesondere die folgenden Felder:
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Logging-URI: Link zum Öffnen des Log-Explorers

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein. Werten Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erhalten haben, sorgfältig aus, um den besten Weg zur Lösung der Ergebnisse zu ermitteln. 1. Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf. 2. Wählen Sie auf dem Tab „Verwalten“ die Option Speicherpools aus, um eine Liste aller Speicherpools aufzurufen. 3. Prüfen Sie die Speicherpoolverknüpfungen mit Sicherungs-Appliances. 4. Wenn einer aktiven Appliance kein Speicherpool zugeordnet ist, wählen Sie OnVault-Pool hinzufügen aus, um diesen wieder hinzuzufügen.

Data Destruction: Google Cloud Backup and DR expire image

Ein potenziell böswilliger Akteur hat das Löschen eines Reservebilds angefordert.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Inhibit System Recovery: Google Cloud Backup and DR expire image, wie unter Ergebnisse überprüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.
2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:
   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Richtlinienname: Der Name für eine einzelne Richtlinie, der die Häufigkeit, den Zeitplan und die Aufbewahrungsdauer für die Sicherung definiert
     • Vorlagenname: Der Name für eine Reihe von Richtlinien, mit denen die Häufigkeit, der Zeitplan und die Aufbewahrungsdauer für die Sicherung definiert werden
     • Profilname: Gibt das Speicherziel für Sicherungen von Anwendungs- und VM-Daten an.
     • Hauptthema: Ein Nutzer, der eine Aktion erfolgreich ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: Projekt, in dem das Reservebild gelöscht wurde
   • Weitere Informationen, insbesondere die folgenden Felder:
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Logging-URI: Link zum Öffnen des Log-Explorers

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein. Werten Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erhalten haben, sorgfältig aus, um den besten Weg zur Lösung der Ergebnisse zu ermitteln. 1. Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf. 2. Wechseln Sie zum Tab „Überwachen“ und wählen Sie Jobs aus, um den Status des zu löschenden Sicherungsjobs zu prüfen. 3. Wenn ein Löschjob nicht autorisiert ist, rufen Sie die IAM-Berechtigungen auf, um Nutzer mit Zugriff auf Sicherungsdaten zu prüfen.

Data Destruction: Google Cloud Backup and DR expire all images

Ein potenziell böswilliger Akteur hat die Löschung aller Backup-Images einer Anwendung angefordert.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Inhibit System Recovery: Google Cloud Backup and DR expire all images, wie unter Ergebnisse überprüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.
2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:
   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Richtlinienname: Der Name für eine einzelne Richtlinie, der die Häufigkeit, den Zeitplan und die Aufbewahrungsdauer für die Sicherung definiert
     • Vorlagenname: Der Name für eine Reihe von Richtlinien, mit denen die Häufigkeit, der Zeitplan und die Aufbewahrungsdauer für die Sicherung definiert werden
     • Profilname: Gibt das Speicherziel für Sicherungen von Anwendungs- und VM-Daten an.
     • Hauptthema: Ein Nutzer, der eine Aktion erfolgreich ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: Projekt, in dem die Reservebilder gelöscht wurden
   • Weitere Informationen, insbesondere die folgenden Felder:
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Logging-URI: Link zum Öffnen des Log-Explorers

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein. Werten Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erhalten haben, sorgfältig aus, um den besten Weg zur Lösung der Ergebnisse zu ermitteln. 1. Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf. 2. Wechseln Sie zum Tab „Überwachen“ und wählen Sie Jobs aus, um den Status des zu löschenden Sicherungsjobs zu prüfen. 3. Wenn ein Löschjob nicht autorisiert ist, rufen Sie die IAM-Berechtigungen auf, um Nutzer mit Zugriff auf Sicherungsdaten zu prüfen.

Data Destruction: Google Cloud Backup and DR remove appliance

Audit-Logs werden untersucht, um das Entfernen einer Sicherungs- und Wiederherstellungs-Appliance zu erkennen. Eine Sicherungs- und Wiederherstellungs-Appliance ist eine wichtige Komponente für Sicherungsvorgänge.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Inhibit System Recovery: Google Cloud Backup and DR remove appliance, wie unter Ergebnisse überprüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.
2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:
   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Appliance-Name: der Name einer Datenbank oder VM, die mit Sicherung und Notfallwiederherstellung verbunden ist
     • Hauptthema: Ein Nutzer, der eine Aktion erfolgreich ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: das Projekt, in dem die Appliance gelöscht wurde
   • Weitere Informationen, insbesondere die folgenden Felder:
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Logging-URI: Link zum Öffnen des Log-Explorers

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein. Werten Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erhalten haben, sorgfältig aus, um den besten Weg zur Lösung der Ergebnisse zu ermitteln. 1. Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf. 2. Suchen Sie auf dem Tab App-Manager nach den betroffenen Anwendungen, die nicht mehr geschützt sind, und prüfen Sie die Sicherungsrichtlinien für jede Anwendung. 3. Wenn Sie eine neue Appliance erstellen und Schutzmaßnahmen auf ungeschützte Anwendungen anwenden möchten, rufen Sie in der Google Cloud Console „Sicherung und Notfallwiederherstellung“ auf und wählen Sie die Option „Weitere Sicherungs- oder Wiederherstellungs-Appliance bereitstellen“ aus. 4. Konfigurieren Sie im Menü Speicher jede neue Appliance mit einem Speicherziel. Nachdem Sie eine Appliance konfiguriert haben, wird sie beim Erstellen eines Profils für Ihre Anwendungen als Option angezeigt.

Impact: Google Cloud Backup and DR reduced backup expiration

Event Threat Detection prüft Audit-Logs darauf, ob das Ablaufdatum für eine Sicherung auf einer Sicherungs- und Notfallwiederherstellungsdienst-Appliance verkürzt wurde.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Impact: Google Cloud Backup and DR reduced backup expiration, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.
2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:
   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Beschreibung: Informationen zur Erkennung
     • Hauptsubjekt: ein Nutzer oder Dienstkonto, das erfolgreich eine Aktion ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: Das Projekt, in dem der Ablauf der Sicherung verkürzt wurde.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation.
     • Logging-URI: Link zum Öffnen des Log-Explorers

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

Wenden Sie sich im Feld Inhaber des Hauptkontos an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein. Werten Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erhalten haben, sorgfältig aus, um die beste Möglichkeit zur Lösung von Ergebnissen zu ermitteln.

1. Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf.
2. Suchen Sie auf dem Tab App Manager nach der betroffenen Anwendung, für die der Ablauf von Sicherungen verkürzt wurde, und prüfen Sie, ob der Ablauf vom Hauptkonto beabsichtigt war.
3. Um eine neue Sicherung der Anwendung zu starten, wählen Sie Sicherungskonfigurationen verwalten aus, um eine On-Demand-Sicherung zu erstellen oder eine neue Sicherung zu planen.

Impact: Google Cloud Backup and DR reduced backup frequency

Event Threat Detection prüft Audit-Logs darauf, ob der Sicherungsplan geändert wurde, um die Sicherungshäufigkeit zu reduzieren.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Impact: Google Cloud Backup and DR reduced backup frequency, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.
2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:
   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Beschreibung: Informationen zur Erkennung
     • Hauptsubjekt: ein Nutzer oder Dienstkonto, das erfolgreich eine Aktion ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: Das Projekt, in dem die Sicherungshäufigkeit reduziert wurde.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation.
     • Logging-URI: Link zum Öffnen des Log-Explorers

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

Wenden Sie sich im Feld Inhaber des Hauptkontos an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein. Werten Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erhalten haben, sorgfältig aus, um die beste Möglichkeit zur Lösung von Ergebnissen zu ermitteln.

1. Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf.
2. Suchen Sie auf dem Tab App Manager nach der betroffenen Anwendung, für die die Sicherungshäufigkeit reduziert wurde, und prüfen Sie, ob die Änderung vom Hauptkonto beabsichtigt war.
3. Um eine neue Sicherung der Anwendung zu starten, wählen Sie Sicherungskonfigurationen verwalten aus, um eine On-Demand-Sicherung zu erstellen oder eine neue Sicherung zu planen.

Lateral Movement: Modified Boot Disk Attached to Instance

Audit-Logs werden auf verdächtige Laufwerkbewegungen zwischen Compute Engine-Instanzressourcen geprüft. Ein potenziell geändertes Bootlaufwerk wurde an Ihre Compute Engine angehängt.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Lateral Movement: Modify Boot Disk Attaching to Instance, wie unter Ergebnisse überprüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Auf dem Tab Zusammenfassung sehen Sie die Werte in den folgenden Feldern.

   Gehen Sie unter Was erkannt wurde so vor:

   • Haupt-E-Mail-Adresse: das Dienstkonto, das die Aktion ausgeführt hat
   • Dienstname: Der API-Name des Google Cloud-Dienstes, auf den das Dienstkonto zugegriffen hat.
   • Method name: die aufgerufene Methode

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Verwenden Sie Dienstkonto-Tools wie Activity Analyzer, um die Aktivität des verknüpften Dienstkontos zu untersuchen.
2. Wenden Sie sich im Feld Haupt-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts, in dem die Aktion ausgeführt wurde.
• Secure Boot für Compute Engine verwenden
• Löschen Sie gegebenenfalls das potenziell manipulierte Dienstkonto und rotieren und löschen Sie alle Dienstkonto-Zugriffsschlüssel für das potenziell manipulierte Projekt. Nach dem Löschen verlieren Anwendungen, die das Dienstkonto zur Authentifizierung verwenden, den Zugriff. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Anwendungen identifizieren und mit den Anwendungsinhabern zusammenarbeiten, um für die Geschäftskontinuität zu sorgen.
• Ermitteln Sie gemeinsam mit Ihrem Sicherheitsteam unbekannte Ressourcen, einschließlich Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer. Ressourcen löschen, die nicht mit autorisierten Konten erstellt wurden.
• Reagieren Sie auf alle Benachrichtigungen vom Google Cloud-Support.

Privilege Escalation: AlloyDB Over-Privileged Grant

Erkennt, wenn alle Berechtigungen für eine AlloyDB for PostgreSQL-Datenbank (oder alle Funktionen oder Prozeduren in einer Datenbank) einem oder mehreren Datenbanknutzern gewährt werden.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Privilege Escalation: AlloyDB Over-Privileged Grant wie unter Ergebnisse prüfen beschrieben.

2. Prüfen Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Anzeigename der Datenbank: Der Name der betroffenen Datenbank in der AlloyDB for PostgreSQL-Instanz.
     • Name des Datenbanknutzers: der PostgreSQL-Nutzer, der nicht erforderliche Berechtigungen gewährt hat.
     • Datenbankabfrage: Die ausgeführte PostgreSQL-Abfrage, mit der die Berechtigungen gewährt wurden.
     • Datenbankempfänger: die Empfänger der über umfassenden Berechtigungen
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der Ressourcenname der betroffenen AlloyDB for PostgreSQL-Instanz.
     • Vollständiger Name des übergeordneten Elements: Der Ressourcenname der AlloyDB for PostgreSQL-Instanz.
     • Vollständiger Name des Projekts: Das Google Cloud-Projekt, das die AlloyDB for PostgreSQL-Instanz enthält.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation

3. Klicken Sie auf den Tab JSON, um die vollständige JSON-Datei für das Ergebnis anzusehen.

Schritt 2: Datenbankberechtigungen prüfen

1. Stellen Sie eine Verbindung zur AlloyDB for PostgreSQL-Instanz her.
2. Zugriffsberechtigungen für die folgenden Elemente auflisten und anzeigen:
   • Datenbanken. Verwenden Sie den Metabefehl \l oder \list und prüfen Sie, welche Berechtigungen für die Datenbank zugewiesen sind, die unter Anzeigename der Datenbank (aus Schritt 1) aufgeführt ist.
   • Funktionen oder Verfahren. Verwenden Sie den Metabefehl \df und prüfen Sie, welche Berechtigungen für Funktionen oder Prozeduren in der Datenbank zugewiesen sind, die unter Anzeigename der Datenbank (aus Schritt 1) aufgeführt ist.

Schritt 3: Protokolle prüfen

1. Rufen Sie in der Google Cloud Console den Log-Explorer auf. Klicken Sie dazu auf den Link in Cloud Logging-URI (aus Schritt 1). Die Seite Log-Explorer enthält alle Logs, die sich auf die relevante Cloud SQL-Instanz beziehen.
2. Prüfen Sie im Log-Explorer die PostgreSQL-pgaudit-Logs, in denen ausgeführte Abfragen an die Datenbank aufgezeichnet werden. Verwenden Sie dazu die folgenden Filter:
   • protoPayload.request.database="var class="edit">database"

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Sehen Sie sich den Eintrag zum MITRE ATT&CK-Framework für diesen Ergebnistyp an: Exfiltration über Webdienst.
2. Sie können feststellen, ob zusätzliche Abhilfemaßnahmen erforderlich sind, indem Sie Ihre Untersuchungsergebnisse mit MITRE-Studien kombinieren.

Schritt 5: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber der Instanz mit übermäßigen Berechtigungen.
• Sie können bis zum Abschluss der Prüfung alle Berechtigungen für die Empfänger, die unter Datenbankempfänger aufgeführt sind, entziehen.
• Zum Beschränken des Zugriffs auf die Datenbank (aus Anzeigename der Datenbank in Schritt 1) revoke von den Empfängern auf (von Teilnehmern der Datenbank in Schritt 1).

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

Erkennt, wenn das AlloyDB for PostgreSQL-Datenbank-Superuser-Konto (postgres) in Nutzertabellen schreibt. Der Superuser (eine Rolle mit sehr großem Zugriff) sollte im Allgemeinen nicht zum Schreiben in Nutzertabellen verwendet werden. Für normale tägliche Aktivitäten sollte ein Nutzerkonto mit eingeschränktem Zugriff verwendet werden. Wenn ein Superuser in eine Nutzertabelle schreibt, kann dies darauf hindeuten, dass ein Angreifer Berechtigungen ausgeweitet oder den Standarddatenbanknutzer manipuliert hat und Daten ändert. Es könnte auch auf normale, aber unsichere Praktiken hindeuten.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Privilege Escalation: AlloyDB Database Superuser Writes to User Tables-Ergebnis, wie unter Ergebnisse prüfen beschrieben.

2. Prüfen Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Anzeigename der Datenbank: Der Name der betroffenen Datenbank in der AlloyDB for PostgreSQL-Instanz.
     • Datenbanknutzername: der Superuser
     • Datenbankabfrage: Die SQL-Abfrage, die beim Schreiben in Nutzertabellen ausgeführt wird.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der Ressourcenname der betroffenen AlloyDB for PostgreSQL-Instanz.
     • Vollständiger Name des übergeordneten Elements: Der Ressourcenname der AlloyDB for PostgreSQL-Instanz.
     • Vollständiger Name des Projekts: Das Google Cloud-Projekt, das die AlloyDB for PostgreSQL-Instanz enthält.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation

3. Klicken Sie auf den Tab JSON, um die vollständige JSON-Datei für das Ergebnis anzusehen.

Schritt 2: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console Log-Explorer. Klicken Sie dazu auf den Link in cloudLoggingQueryURI (aus Schritt 1). Die Seite Log-Explorer enthält alle Logs, die sich auf die entsprechende AlloyDB for PostgreSQL-Instanz beziehen.
2. Prüfen Sie mithilfe der folgenden Filter die PostgreSQL-pgaudit-Logs, die die vom Superuser ausgeführten Abfragen enthalten:
   • protoPayload.request.user="postgres"

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Sehen Sie sich den Eintrag zum MITRE ATT&CK-Framework für diesen Ergebnistyp an: Exfiltration über Webdienst.
2. Sie können feststellen, ob zusätzliche Abhilfemaßnahmen erforderlich sind, indem Sie Ihre Untersuchungsergebnisse mit MITRE-Studien kombinieren.

Schritt 4: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Prüfen Sie die Nutzer, die eine Verbindung zur Datenbank herstellen dürfen.
• Ändern Sie gegebenenfalls das Passwort für den Superuser.
• Erwägen Sie das Erstellen eines neuen Nutzers mit eingeschränktem Zugriff für die verschiedenen Abfragetypen, die auf der Instanz verwendet werden.
  • Gewähren Sie dem neuen Nutzer nur die Berechtigungen, die zum Ausführen seiner Abfragen erforderlich sind.
  • Aktualisieren Sie die Anmeldedaten für die Clients, die eine Verbindung zur AlloyDB for PostgreSQL-Instanz herstellen

Metadaten-Erkennung für Compute Engine Administrator

Persistence: GCE Admin Added SSH Key

Beschreibung	Aktionen
Der Metadatenschlüssel ssh-keys der Compute Engine-Instanz wurde auf einer vorhandenen Instanz geändert.	Der Metadatenschlüssel ssh-keys der Compute Engine-Instanz wurde auf einer Instanz geändert, die vor mehr als sieben Tagen erstellt wurde. Prüfen Sie, ob die Änderung absichtlich von einem Mitglied vorgenommen oder von einem Angreifer implementiert wurde, um neuen Zugriff auf Ihre Organisation einzuführen.	Prüfen Sie Logs mit den folgenden Filtern: protopayload.resource.labels.instance_id=INSTANCE_ID protoPayload.serviceName="compute.googleapis.com" (protoPayload.metadata.instanceMetaData.addedMetadataKey : "ssh-keys" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "ssh-keys" ) logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Ersetzen Sie Folgendes: INSTANCE_ID: der im Ergebnis aufgeführte gceInstanceId ORGANIZATION_ID: Ihre Organisations-ID.
		Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: MITRE: https://attack.mitre.org/techniques/T1098/004/

Persistence: GCE Admin Added Startup Script

Beschreibung	Aktionen
Der Metadatenschlüssel startup-script oder startup-script-url der Compute Engine-Instanz wurde auf einer vorhandenen Instanz geändert.	Einer der Metadatenschlüssel startup-script oder startup-script-url der Compute Engine-Instanz wurde auf einer Instanz geändert, die vor mehr als sieben Tagen erstellt wurde. Prüfen Sie, ob die Änderung absichtlich von einem Mitglied vorgenommen oder von einem Angreifer implementiert wurde, um neuen Zugriff auf Ihre Organisation einzuführen.	Prüfen Sie Logs mit den folgenden Filtern: protopayload.resource.labels.instance_id=INSTANCE_ID protoPayload.serviceName="compute.googleapis.com" ((protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script" ) OR (protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script-url" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script-url" )) logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Ersetzen Sie Folgendes: INSTANCE_ID: der im Ergebnis aufgeführte gceInstanceId ORGANIZATION_ID: Ihre Organisations-ID.
		Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: MITRE: https://attack.mitre.org/techniques/T1098/004/

Google Workspace-Logerkennung

Wenn Sie Ihre Google Workspace-Logs für Cloud Logging freigeben, generiert Event Threat Detection Ergebnisse für mehrere Google Workspace-Bedrohungen. Da sich Google Workspace-Logs auf Organisationsebene befinden, kann Event Threat Detection sie nur scannen, wenn Sie Security Command Center auf Organisationsebene aktivieren.

Event Threat Detection reichert Logereignisse an und schreibt Ergebnisse in Security Command Center. Die folgende Tabelle enthält Google Workspace-Bedrohungen, relevante MITRE ATT&CK-Framework-Einträge und Details zu den Ereignissen, die Ergebnisse auslösen. Sie können Logs auch mit bestimmten Filtern prüfen und alle Informationen kombinieren, um auf Google Workspace-Bedrohungen zu reagieren.

Initial Access: Disabled Password Leak

Dieses Ergebnis ist nicht verfügbar, wenn Sie Security Command Center auf Projektebene aktivieren.

Beschreibung	Aktionen
Das Konto eines Mitglieds ist deaktiviert, weil ein Passwortleck erkannt wurde.	Setzen Sie die Passwörter für die betroffenen Konten zurück und raten Sie Mitgliedern, starke, eindeutige Passwörter für Unternehmenskonten zu verwenden.	Prüfen Sie Logs mit den folgenden Filtern: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Ersetzen Sie ORGANIZATION_ID durch Ihre Organisations-ID.
		Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: MITRE: https://attack.mitre.org/techniques/T1078/ Workspace-Ereignisdetails: https://developers.google.com/admin-sdk/reports/v1/attachment/activity/login#account_disabled_password_leak

Initial Access: Suspicious Login Blocked

Dieses Ergebnis ist nicht verfügbar, wenn Sie Security Command Center auf Projektebene aktivieren.

Beschreibung	Aktionen
Es wurde eine verdächtige Anmeldung im Konto eines Mitglieds erkannt und blockiert.	Auf dieses Konto kann ein Ziel von Angreifern sein. Das Nutzerkonto muss den Sicherheitsrichtlinien Ihrer Organisation für starke Passwörter und Multi-Faktor-Authentifizierung entsprechen.	Prüfen Sie Logs mit den folgenden Filtern: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Ersetzen Sie ORGANIZATION_ID durch Ihre Organisations-ID.
		Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: MITRE: https://attack.mitre.org/techniques/T1078/ Workspace-Ereignisdetails: https://developers.google.com/admin-sdk/reports/v1/attachment/activity/login#suspicious_login

Initial Access: Account Disabled Hijacked

Dieses Ergebnis ist nicht verfügbar, wenn Sie Security Command Center auf Projektebene aktivieren.

Beschreibung	Aktionen
Das Konto eines Mitglieds wurde aufgrund verdächtiger Aktivitäten gesperrt.	Dieses Konto wurde gehackt. Setzen Sie das Kontopasswort zurück und fordern Sie Nutzer auf, starke, eindeutige Passwörter für Unternehmenskonten zu erstellen.	Prüfen Sie Logs mit den folgenden Filtern: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Ersetzen Sie ORGANIZATION_ID durch Ihre Organisations-ID.
		Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: MITRE: https://attack.mitre.org/techniques/T1078/ Workspace-Ereignisdetails: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_hijacked

Impair Defenses: Two Step Verification Disabled

Dieses Ergebnis ist nicht verfügbar, wenn Sie Security Command Center auf Projektebene aktivieren.

Beschreibung	Aktionen
Ein Mitglied hat die Bestätigung in zwei Schritten deaktiviert.	Prüfen Sie, ob der Nutzer die Bestätigung in zwei Schritten deaktivieren wollte. Wenn Ihre Organisation die Bestätigung in zwei Schritten erfordert, sorgen Sie dafür, dass der Nutzer sie sofort aktiviert.	Prüfen Sie Logs mit den folgenden Filtern: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Ersetzen Sie ORGANIZATION_ID durch Ihre Organisations-ID.
		Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: MITRE: https://attack.mitre.org/techniques/T1562/ Workspace-Ereignisdetails: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#2sv_disable

Initial Access: Government Based Attack

Dieses Ergebnis ist nicht verfügbar, wenn Sie Security Command Center auf Projektebene aktivieren.

Beschreibung	Aktionen
Angreifer, die von staatlichen Stellen unterstützt werden, haben möglicherweise versucht, ein Mitgliedskonto oder einen Computer zu manipulieren.	Auf dieses Konto kann ein Ziel von Angreifern sein. Das Nutzerkonto muss den Sicherheitsrichtlinien Ihrer Organisation für starke Passwörter und Multi-Faktor-Authentifizierung entsprechen.	Prüfen Sie Logs mit den folgenden Filtern: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Ersetzen Sie ORGANIZATION_ID durch Ihre Organisations-ID.
		Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: MITRE: https://attack.mitre.org/techniques/T1078/ Workspace-Ereignisdetails: https://developers.google.com/admin-sdk/reports/v1/attachment/activity/login#gov_attack_warning

Persistence: SSO Enablement Toggle

Dieses Ergebnis ist nicht verfügbar, wenn Sie Security Command Center auf Projektebene aktivieren.

Beschreibung	Aktionen
Die Einstellung "SSO (Einmalanmeldung) aktivieren" für das Administratorkonto wurde deaktiviert.	Die SSO-Einstellungen für Ihre Organisation wurden geändert. Prüfen Sie, ob die Änderung absichtlich von einem Mitglied vorgenommen oder von einem Angreifer implementiert wurde, um neuen Zugriff auf Ihre Organisation einzuführen.	Prüfen Sie Logs mit den folgenden Filtern: protopayload.resource.labels.service="admin.googleapis.com" protopayload.metadata.event.parameter.value=DOMAIN_NAME logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Ersetzen Sie Folgendes: DOMAIN_NAME: der im Ergebnis aufgeführte domainName ORGANIZATION_ID: Ihre Organisations-ID.
		Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: MITRE: https://attack.mitre.org/techniques/T1098/ Workspace-Ereignisdetails: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#TOGGLE_SSO_ENABLED

Persistence: SSO Settings Changed

Dieses Ergebnis ist nicht verfügbar, wenn Sie Security Command Center auf Projektebene aktivieren.

Beschreibung	Aktionen
Die SSO-Einstellungen für das Administratorkonto wurden geändert.	Die SSO-Einstellungen für Ihre Organisation wurden geändert. Prüfen Sie, ob die Änderung absichtlich von einem Mitglied vorgenommen oder von einem Angreifer implementiert wurde, um neuen Zugriff auf Ihre Organisation einzuführen.	Prüfen Sie Logs mit den folgenden Filtern: protopayload.resource.labels.service="admin.googleapis.com" protopayload.metadata.event.parameter.value=DOMAIN_NAME logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Ersetzen Sie Folgendes: DOMAIN_NAME: der im Ergebnis aufgeführte domainName ORGANIZATION_ID: Ihre Organisations-ID.
		Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: MITRE: https://attack.mitre.org/techniques/T1098/ Workspace-Ereignisdetails: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#CHANGE_SSO_SETTINGS

Impair Defenses: Strong Authentication Disabled

Dieses Ergebnis ist nicht verfügbar, wenn Sie Security Command Center auf Projektebene aktivieren.

Beschreibung	Aktionen
Die Bestätigung in zwei Schritten wurde für die Organisation deaktiviert.	Die Bestätigung in zwei Schritten ist für Ihre Organisation nicht mehr erforderlich. Prüfen Sie, ob dies eine beabsichtigte Richtlinienänderung durch einen Administrator war oder ob es sich um einen Versuch durch einen Angreifer handelt, um den Kontodiebstahl zu vereinfachen.	Prüfen Sie Logs mit den folgenden Filtern: protopayload.resource.labels.service="admin.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Ersetzen Sie ORGANIZATION_ID durch Ihre Organisations-ID.
		Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: MITRE: https://attack.mitre.org/techniques/T1562/ Workspace-Ereignisdetails: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-security-settings#ENFORCE_STRONG_AUTHENTICATION

Auf Google Workspace-Bedrohungen reagieren

Ergebnisse für Google Workspace sind nur für Aktivierungen von Security Command Center auf Organisationsebene verfügbar. Google Workspace-Logs können nicht nach Aktivierungen auf Projektebene gescannt werden.

Als Google Workspace-Administrator können Sie die Sicherheitstools des Dienstes verwenden, um diese Bedrohungen zu beheben:

• Google Workspace-Benachrichtigungszentrale
• Google Workspace-Sicherheitscenter

Die Tools umfassen Benachrichtigungen, ein Sicherheits-Dashboard und Sicherheitsempfehlungen und helfen Ihnen, Bedrohungen zu untersuchen und zu beheben.

Wenn Sie kein Google Workspace-Administrator sind, gehen Sie so vor:

• Wenn Sie noch Zugriff auf Ihr Konto haben, ändern Sie Ihr Passwort oder setzen Sie es zurück und aktivieren Sie die Bestätigung in zwei Schritten.
• Wenden Sie sich an Ihren Google Workspace-Administrator oder an das Team in Ihrem Unternehmen, das Ihr Google Workspace-Konto verwaltet. Verwenden Sie diese Ergebnisse als Hinweis darauf, dass ein Konto möglicherweise manipuliert wurde.

Cloud IDS-Bedrohungserkennung

Cloud IDS: THREAT_ID

Vorschau

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Cloud IDS-Ergebnisse werden von Cloud IDS generiert. Cloud IDS ist ein Sicherheitsdienst, der den Traffic zu und von Ihren Google Cloud-Ressourcen auf Bedrohungen überwacht. Wenn Cloud IDS eine Bedrohung erkennt, sendet es Informationen zur Bedrohung wie Quell-IP-Adresse, Zieladresse und Portnummer an Event Threat Detection, die dann ein Bedrohungsergebnis generiert.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Cloud IDS: THREAT_ID wie unter Ergebnisse prüfen beschrieben.

2. Prüfen Sie in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Protokoll: Das verwendete Netzwerkprotokoll.
     • Ereigniszeit: Zeitpunkt, an dem das Ereignis aufgetreten ist
     • Beschreibung: Weitere Informationen zum Ergebnis.
     • Schweregrad: Der Schweregrad der Benachrichtigung
     • Ziel-IP: Die Ziel-IP-Adresse des Netzwerkverkehrs.
     • Zielport: Der Zielport des Netzwerkverkehrs
     • Quell-IP: Die Quell-IP-Adresse des Netzwerkverkehrs.
     • Quellport: Der Quellport des Netzwerkverkehrs.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Das Projekt, das das Netzwerk mit der Bedrohung enthält
   • Weitere Informationen, insbesondere die folgenden Felder:
     • Cloud Logging-URI: Link zu Cloud IDS-Logging-Einträgen. Diese Einträge enthalten die erforderlichen Informationen, um nach Threat Vault von Palo Alto Networks zu suchen.
   • Erkennungsdienst
     • Ergebniskategorie: Name der Cloud IDS-Bedrohung

3. Klicken Sie auf den Tab JSON, um die vollständige JSON-Datei für das Ergebnis anzusehen.

Schritt 2: Angriffs- und Reaktionsmethoden suchen

Nachdem Sie die Details des Ergebnisses geprüft haben, können Sie in der Cloud IDS-Dokumentation zur Untersuchung von Bedrohungswarnungen eine geeignete Antwort finden.

Weitere Informationen zum erkannten Ereignis im ursprünglichen Logeintrag erhalten Sie durch Klicken auf den Link im Feld Cloud Logging-URI in den Ergebnisdetails.

Container Threat Detection-Antworten

Weitere Informationen zu Container Threat Detection finden Sie unter Funktionsweise von Container Threat Detection.

Added Binary Executed

Eine Binärdatei, die nicht Teil des ursprünglichen Container-Image war, wurde ausgeführt. Angreifer installieren oft Exploit-Tools und Malware, nachdem sie das erste Mal kompromittiert wurden. Es ist eine wichtige Best Practice, dafür zu sorgen, dass Ihre Container unveränderlich sind. Dies ist ein Ergebnis mit geringem Schweregrad, da Ihre Organisation diese Best Practice möglicherweise nicht befolgt. Es gibt entsprechende Execution: Added Malicious Binary Executed-Ergebnisse, wenn der Hash des Binärprogramms ein bekannter Gefahrenindikator ist. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Added Binary Executed-Ergebnis wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Programmbinärprogramm: Der absolute Pfad der hinzugefügten Binärdatei.
     • Argumente: Die Argumente, die beim Aufrufen der hinzugefügten Binärdatei angegeben werden.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der vollständige Ressourcenname des Clusters, einschließlich Projektnummer, Standort und Clustername.

3. Klicken Sie auf JSON und notieren Sie sich die folgenden Felder:

   • resource:
     • project_display_name: der Name des Projekts, das den Cluster enthält.
   • sourceProperties:
     • Pod_Namespace: der Name des Kubernetes-Namespace des Pods.
     • Pod_Name: der Name des GKE-Pods.
     • Container_Name: der Name des betroffenen Containers.
     • Container_Image_Uri ist der Name des Container-Images, das bereitgestellt wird.
     • VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.

4. Ermitteln Sie andere Ergebnisse, die zu einem ähnlichen Zeitpunkt für diesen Container aufgetreten sind. Entsprechende Ergebnisse können darauf hindeuten, dass diese Aktivität schädlich war und nicht die Best Practices nicht eingehalten haben.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

   Zur Seite Kubernetes Clusters

2. Wählen Sie bei Bedarf in der Symbolleiste der Google Cloud Console das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie den Cluster aus, der auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Vollständiger Name der Ressource aufgeführt ist. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.

4. Klicken Sie auf den Tab Knoten. Wählen Sie den in VM_Instance_Name aufgeführten Knoten aus.

5. Klicken Sie auf den Tab Details und notieren Sie sich die Annotation container.googleapis.com/instance_id.

Schritt 3: Pod überprüfen

1. Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.

   Zur Seite "Kubernetes-Arbeitslasten"

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Filtern Sie nach dem Cluster, der auf dem Tab Zusammenfassung in der Zeile Vollständiger Name der Ressource der Ergebnisdetails und bei Bedarf nach dem in Pod_Namespace aufgeführten Pod-Namespace aufgeführt ist.

4. Wählen Sie den in Pod_Name aufgeführten Pod aus. Notieren Sie sich alle Metadaten zum Pod und zu seinem Inhaber.

Schritt 4: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console den Log-Explorer.

   Zum Log-Explorer

2. Wählen Sie bei Bedarf in der Symbolleiste der Google Cloud Console das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.

4. Gehen Sie auf der Seite, die geladen wird, so vor:

   1. Suchen Sie mit dem folgenden Filter Pod-Logs für Pod_Name:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Suchen Sie mit dem folgenden Filter Cluster-Audit-Logs:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Schritt 5: Laufenden Container prüfen

Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.

1. Öffnen Sie die Google Cloud Console.

   Google Cloud Console öffnen

2. Wählen Sie bei Bedarf in der Symbolleiste der Google Cloud Console das in resource.project_display_name aufgeführte Projekt aus.

3. Klicken Sie auf Cloud Shell aktivieren .

4. Rufen Sie GKE-Anmeldedaten für Ihren Cluster ab, indem Sie die folgenden Befehle ausführen.

   Für zonale Cluster:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   Für regionale Cluster:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   Ersetzen Sie Folgendes:

   • cluster_name: der in resource.labels.cluster_name aufgeführte Cluster
   • location: der in resource.labels.location aufgeführte Standort
   • project_name: der in resource.project_display_name aufgeführte Projektname

5. Rufen Sie die hinzugefügte Binärdatei mit folgendem Befehl ab:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Ersetzen Sie local_file durch einen lokalen Dateipfad zum Speichern der hinzugefügten Binärdatei.

6. Stellen Sie eine Verbindung zur Containerumgebung her, indem Sie Folgendes ausführen:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Bei diesem Befehl muss für den Container eine Shell unter /bin/sh installiert sein.

Schritt 6: Forschungsangriffs- und Reaktionsmethoden

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ingress-Tool-Übertragung, Native API.
2. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Schritt 7: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenn die Binärdatei im Container enthalten sein sollte, erstellen Sie das Container-Image mit der Binärdatei neu. Auf diese Weise kann der Container unveränderlich sein.
• Andernfalls wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Container.
• Beenden oder löschen Sie den manipulierten Container und ersetzen Sie ihn durch einen neuen Container.

Added Library Loaded

Eine Bibliothek, die nicht Teil des ursprünglichen Container-Image war, wurde geladen. Angreifer könnten schädliche Bibliotheken in vorhandene Programme laden, um den Schutz vor Codeausführungen zu umgehen und schädlichen Code zu verbergen. Es ist eine wichtige Best Practice, dafür zu sorgen, dass Ihre Container unveränderlich sind. Dies ist ein Ergebnis mit geringem Schweregrad, da Ihre Organisation diese Best Practice möglicherweise nicht befolgt. Es gibt entsprechende Execution: Added Malicious Library Loaded-Ergebnisse, wenn der Hash des Binärprogramms ein bekannter Gefahrenindikator ist. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Added Library Loaded-Ergebnis wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird auf dem Tab Zusammenfassung geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Programmbinärdatei: Der vollständige Pfad der Prozessbinärdatei, mit der die Bibliothek geladen wurde.
     • Bibliotheken: Details zur hinzugefügten Bibliothek.
     • Argumente: Die Argumente, die beim Aufrufen der Prozessbinärdatei angegeben wurden.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der vollständige Ressourcenname des Clusters.

3. Klicken Sie auf den Tab JSON und notieren Sie sich die folgenden Felder:

   • resource:
     • project_display_name: der Name des Projekts, das das Asset enthält.
   • sourceProperties:
     • Pod_Namespace: der Name des Kubernetes-Namespace des Pods.
     • Pod_Name: der Name des GKE-Pods.
     • Container_Name: der Name des betroffenen Containers.
     • Container_Image_Uri: der Name des ausgeführten Container-Images.
     • VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.

4. Ermitteln Sie andere Ergebnisse, die zu einem ähnlichen Zeitpunkt für diesen Container aufgetreten sind. Entsprechende Ergebnisse können darauf hindeuten, dass diese Aktivität schädlich war und nicht die Best Practices nicht eingehalten haben.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

   Zur Seite Kubernetes Clusters

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie den in resource.name aufgeführten Cluster aus. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.

4. Klicken Sie auf den Tab Knoten. Wählen Sie den in VM_Instance_Name aufgeführten Knoten aus.

5. Klicken Sie auf den Tab Details und notieren Sie sich die Annotation container.googleapis.com/instance_id.

Schritt 3: Pod überprüfen

1. Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.

   Zur Seite "Kubernetes-Arbeitslasten"

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Filtern Sie nach dem Cluster, der auf dem Tab Zusammenfassung in der Zeile Vollständiger Name der Ressource der Ergebnisdetails und bei Bedarf nach dem in Pod_Namespace aufgeführten Pod-Namespace aufgeführt ist.

4. Wählen Sie den in Pod_Name aufgeführten Pod aus. Notieren Sie sich alle Metadaten zum Pod und zu seinem Inhaber.

Schritt 4: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console den Log-Explorer.

   Zum Log-Explorer

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.

4. Gehen Sie auf der Seite, die geladen wird, so vor:

   1. Suchen Sie mit dem folgenden Filter Pod-Logs für Pod_Name:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Suchen Sie mit dem folgenden Filter Cluster-Audit-Logs:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Schritt 5: Laufenden Container prüfen

Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.

1. Öffnen Sie die Google Cloud Console.

   Google Cloud Console öffnen

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Klicken Sie auf Cloud Shell aktivieren .

4. Rufen Sie die GKE-Anmeldedaten für Ihren Cluster ab, indem Sie die folgenden Befehle ausführen.

   Für zonale Cluster:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Für regionale Cluster:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Rufen Sie die hinzugefügte Bibliothek ab, indem Sie folgenden Befehl ausführen:

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Ersetzen Sie local_file durch einen lokalen Dateipfad, um die hinzugefügte Bibliothek zu speichern.

6. Stellen Sie eine Verbindung zur Containerumgebung her, indem Sie Folgendes ausführen:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Bei diesem Befehl muss für den Container eine Shell unter /bin/sh installiert sein.

Schritt 6: Forschungsangriffs- und Reaktionsmethoden

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ingress-Tool-Übertragung, Freigegebene Module.
2. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Schritt 7: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenn die Bibliothek im Container enthalten sein soll, erstellen Sie das Container-Image mit der enthaltenen Bibliothek neu. Auf diese Weise kann der Container unveränderlich sein.
• Andernfalls wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Container.
• Beenden oder löschen Sie den manipulierten Container und ersetzen Sie ihn durch einen neuen Container.

Execution: Added Malicious Binary Executed

Es wurde eine schädliche Binärdatei ausgeführt, die nicht Teil des ursprünglichen Container-Images war. Angreifer installieren häufig Ausbeutungstools und Malware nach dem anfänglichen Manipulationsprozess. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Execution: Added Malicious Binary Executed-Ergebnis wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Programmbinärprogramm: Der absolute Pfad der hinzugefügten Binärdatei.
     • Argumente: Die Argumente, die beim Aufrufen der hinzugefügten Binärdatei angegeben werden.
     • Container: der Name des betroffenen Containers
     • Container-URI: Der Name des Container-Images, das bereitgestellt wird.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der vollständige Ressourcenname des Clusters, einschließlich Projektnummer, Standort und Clustername.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • VirusTotal-Indikator: Link zur Analyseseite von VirusTotal.

3. Klicken Sie auf den Tab JSON und notieren Sie sich die folgenden Felder:

   • sourceProperties:
     • VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

   Zur Seite Kubernetes Clusters

2. Wählen Sie bei Bedarf in der Symbolleiste der Google Cloud Console das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie den Cluster aus, der auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Vollständiger Name der Ressource aufgeführt ist. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.

4. Klicken Sie auf den Tab Knoten. Wählen Sie den in VM_Instance_Name aufgeführten Knoten aus.

5. Klicken Sie auf den Tab Details und notieren Sie sich die Annotation container.googleapis.com/instance_id.

Schritt 3: Pod überprüfen

1. Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.

   Zur Seite "Kubernetes-Arbeitslasten"

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Filtern Sie nach dem Cluster, der auf dem Tab Zusammenfassung in der Zeile Vollständiger Name der Ressource der Ergebnisdetails und bei Bedarf nach dem in Pod_Namespace aufgeführten Pod-Namespace aufgeführt ist.

4. Wählen Sie den in Pod_Name aufgeführten Pod aus. Notieren Sie sich alle Metadaten zum Pod und zu seinem Inhaber.

Schritt 4: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console den Log-Explorer.

   Zum Log-Explorer

2. Wählen Sie bei Bedarf in der Symbolleiste der Google Cloud Console das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.

4. Gehen Sie auf der Seite, die geladen wird, so vor:

   1. Suchen Sie mit dem folgenden Filter Pod-Logs für Pod_Name:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Suchen Sie mit dem folgenden Filter Cluster-Audit-Logs:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Schritt 5: Laufenden Container prüfen

Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.

1. Öffnen Sie die Google Cloud Console.

   Google Cloud Console öffnen

2. Wählen Sie bei Bedarf in der Symbolleiste der Google Cloud Console das in resource.project_display_name aufgeführte Projekt aus.

3. Klicken Sie auf Cloud Shell aktivieren .

4. Rufen Sie GKE-Anmeldedaten für Ihren Cluster ab, indem Sie die folgenden Befehle ausführen.

   Für zonale Cluster:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   Für regionale Cluster:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   Ersetzen Sie Folgendes:

   • cluster_name: der in resource.labels.cluster_name aufgeführte Cluster
   • location: der in resource.labels.location aufgeführte Standort
   • project_name: der in resource.project_display_name aufgeführte Projektname

5. Rufen Sie das hinzugefügte schädliche Binärprogramm ab:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Ersetzen Sie local_file durch einen lokalen Pfad zum Speichern der hinzugefügten schädlichen Binärdatei.

6. Stellen Sie eine Verbindung zur Containerumgebung her:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Bei diesem Befehl muss für den Container eine Shell unter /bin/sh installiert sein.

Schritt 6: Forschungsangriffs- und Reaktionsmethoden

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ingress-Tool-Übertragung, Native API.
2. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
3. Prüfen Sie den SHA-256-Hashwert des Binärprogramms, das in VirusTotal als schädlich gekennzeichnet ist. Klicken Sie dazu auf den Link im VirusTotal-Indikator. VirusTotal, ein Alphabet-eigener Dienst, der Kontext zu potenziell schädlichen Dateien, URLs, Domains und IP-Adressen bereitstellt.

Schritt 7: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Container.
• Beenden oder löschen Sie den manipulierten Container und ersetzen Sie ihn durch einen neuen Container.

Execution: Added Malicious Library Loaded

Eine schädliche Bibliothek, die nicht Teil des ursprünglichen Container-Images war, wurde geladen. Angreifer könnten schädliche Bibliotheken in vorhandene Programme laden, um den Schutz vor Codeausführungen zu umgehen und schädlichen Code zu verbergen. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Execution: Added Malicious Library Loaded-Ergebnis wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird auf dem Tab Zusammenfassung geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Programmbinärdatei: Der vollständige Pfad der Prozessbinärdatei, mit der die Bibliothek geladen wurde.
     • Bibliotheken: Details zur hinzugefügten Bibliothek.
     • Argumente: Die Argumente, die beim Aufrufen der Prozessbinärdatei angegeben wurden.
     • Container: der Name des betroffenen Containers
     • Container-URI: Der Name des Container-Images, das bereitgestellt wird.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der vollständige Ressourcenname des Clusters.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • VirusTotal-Indikator: Link zur Analyseseite von VirusTotal.

3. Klicken Sie auf den Tab JSON und notieren Sie sich die folgenden Felder:

   • sourceProperties:
     • VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

   Zur Seite Kubernetes Clusters

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie den Cluster aus, der auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Vollständiger Name der Ressource aufgeführt ist. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.

4. Klicken Sie auf den Tab Knoten. Wählen Sie den in VM_Instance_Name aufgeführten Knoten aus.

5. Klicken Sie auf den Tab Details und notieren Sie sich die Annotation container.googleapis.com/instance_id.

Schritt 3: Pod überprüfen

1. Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.

   Zur Seite "Kubernetes-Arbeitslasten"

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Filtern Sie nach dem Cluster, der auf dem Tab Zusammenfassung in der Zeile Vollständiger Name der Ressource der Ergebnisdetails und bei Bedarf nach dem in Pod_Namespace aufgeführten Pod-Namespace aufgeführt ist.

4. Wählen Sie den in Pod_Name aufgeführten Pod aus. Notieren Sie sich alle Metadaten zum Pod und zu seinem Inhaber.

Schritt 4: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console den Log-Explorer.

   Zum Log-Explorer

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.

4. Gehen Sie auf der Seite, die geladen wird, so vor:

   1. Suchen Sie mit dem folgenden Filter Pod-Logs für Pod_Name:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Suchen Sie mit dem folgenden Filter Cluster-Audit-Logs:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Schritt 5: Laufenden Container prüfen

Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.

1. Öffnen Sie die Google Cloud Console.

   Google Cloud Console öffnen

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Klicken Sie auf Cloud Shell aktivieren .

4. Rufen Sie die GKE-Anmeldedaten für Ihren Cluster ab, indem Sie die folgenden Befehle ausführen.

   Für zonale Cluster:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Für regionale Cluster:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Rufen Sie die hinzugefügte schädliche Bibliothek ab:

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Ersetzen Sie local_file durch einen lokalen Pfad zum Speichern der hinzugefügten schädlichen Bibliothek.

6. Stellen Sie eine Verbindung zur Containerumgebung her:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Bei diesem Befehl muss für den Container eine Shell unter /bin/sh installiert sein.

Schritt 6: Forschungsangriffs- und Reaktionsmethoden

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ingress-Tool-Übertragung, Freigegebene Module.
2. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
3. Prüfen Sie den SHA-256-Hashwert der Bibliothek, die in VirusTotal als schädlich gekennzeichnet ist. Klicken Sie dazu auf den Link im VirusTotal-Indikator. VirusTotal, ein Alphabet-eigener Dienst, der Kontext zu potenziell schädlichen Dateien, URLs, Domains und IP-Adressen bereitstellt.

Schritt 7: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Container.
• Beenden oder löschen Sie den manipulierten Container und ersetzen Sie ihn durch einen neuen Container.

Execution: Built in Malicious Binary Executed

Eine ausgeführte Binärdatei mit der folgenden Binärdatei:

• Im ursprünglichen Container-Image enthalten.
• Laut Bedrohungsdaten als schädlich eingestuft

Der Angreifer hat die Kontrolle über das Container-Image-Repository oder die Erstellungspipeline, wo die schädliche Binärdatei in das Container-Image eingeschleust wird. Gehen Sie so vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Execution: Built in Malicious Binary Executed-Ergebnis wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Programmbinärprogramm: der absolute Pfad des integrierten Binärprogramms.
     • Argumente: Die Argumente, die beim Aufrufen des integrierten Binärprogramms angegeben werden.
     • Container: der Name des betroffenen Containers
     • Container-URI: Der Name des Container-Images, das bereitgestellt wird.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der vollständige Ressourcenname des Clusters, einschließlich Projektnummer, Standort und Clustername.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • VirusTotal-Indikator: Link zur Analyseseite von VirusTotal.

3. Klicken Sie auf JSON und notieren Sie sich die folgenden Felder:

   • sourceProperties:
     • VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

   Zur Seite Kubernetes Clusters

2. Wählen Sie bei Bedarf in der Symbolleiste der Google Cloud Console das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie den Cluster aus, der auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Vollständiger Name der Ressource aufgeführt ist. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.

4. Klicken Sie auf den Tab Knoten. Wählen Sie den in VM_Instance_Name aufgeführten Knoten aus.

5. Klicken Sie auf den Tab Details und notieren Sie sich die Annotation container.googleapis.com/instance_id.

Schritt 3: Pod überprüfen

1. Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.

   Zur Seite "Kubernetes-Arbeitslasten"

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Filtern Sie nach dem Cluster, der auf dem Tab Zusammenfassung in der Zeile Vollständiger Name der Ressource der Ergebnisdetails und bei Bedarf nach dem in Pod_Namespace aufgeführten Pod-Namespace aufgeführt ist.

4. Wählen Sie den in Pod_Name aufgeführten Pod aus. Notieren Sie sich alle Metadaten zum Pod und zu seinem Inhaber.

Schritt 4: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console den Log-Explorer.

   Zum Log-Explorer

2. Wählen Sie bei Bedarf in der Symbolleiste der Google Cloud Console das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.

4. Gehen Sie auf der Seite, die geladen wird, so vor:

   1. Suchen Sie mit dem folgenden Filter Pod-Logs für Pod_Name:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Suchen Sie mit dem folgenden Filter Cluster-Audit-Logs:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Schritt 5: Laufenden Container prüfen

Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.

1. Öffnen Sie die Google Cloud Console.

   Google Cloud Console öffnen

2. Wählen Sie bei Bedarf in der Symbolleiste der Google Cloud Console das in resource.project_display_name aufgeführte Projekt aus.

3. Klicken Sie auf Cloud Shell aktivieren .

4. Rufen Sie GKE-Anmeldedaten für Ihren Cluster ab, indem Sie die folgenden Befehle ausführen.

   Für zonale Cluster:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   Für regionale Cluster:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   Ersetzen Sie Folgendes:

   • cluster_name: der in resource.labels.cluster_name aufgeführte Cluster
   • location: der in resource.labels.location aufgeführte Standort
   • project_name: der in resource.project_display_name aufgeführte Projektname

5. Rufen Sie die integrierte schädliche Binärdatei ab:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Ersetzen Sie local_file durch einen lokalen Pfad zum Speichern der erstellten schädlichen Zinn-Binärdatei.

6. Stellen Sie eine Verbindung zur Containerumgebung her:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Bei diesem Befehl muss für den Container eine Shell unter /bin/sh installiert sein.

Schritt 6: Forschungsangriffs- und Reaktionsmethoden

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ingress-Tool-Übertragung, Native API.
2. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
3. Prüfen Sie den SHA-256-Hashwert des Binärprogramms, das in VirusTotal als schädlich gekennzeichnet ist. Klicken Sie dazu auf den Link im VirusTotal-Indikator. VirusTotal, ein Alphabet-eigener Dienst, der Kontext zu potenziell schädlichen Dateien, URLs, Domains und IP-Adressen bereitstellt.

Schritt 7: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Container.
• Beenden oder löschen Sie den manipulierten Container und ersetzen Sie ihn durch einen neuen Container.

Execution: Modified Malicious Binary Executed

Eine ausgeführte Binärdatei mit der folgenden Binärdatei:

• Im ursprünglichen Container-Image enthalten.
• Während der Containerlaufzeit geändert
• Laut Bedrohungsdaten als schädlich eingestuft

Angreifer installieren häufig Ausbeutungstools und Malware nach dem anfänglichen Manipulationsprozess. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Execution: Modified Malicious Binary Executed-Ergebnis wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Programmbinärprogramm: der absolute Pfad der geänderten Binärdatei.
     • Argumente: Die Argumente, die beim Aufrufen der geänderten Binärdatei angegeben wurden.
     • Container: der Name des betroffenen Containers
     • Container-URI: Der Name des Container-Images, das bereitgestellt wird.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der vollständige Ressourcenname des Clusters, einschließlich Projektnummer, Standort und Clustername.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • VirusTotal-Indikator: Link zur Analyseseite von VirusTotal.

3. Klicken Sie auf JSON und notieren Sie sich die folgenden Felder:

   • sourceProperties:
     • VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

   Zur Seite Kubernetes Clusters

2. Wählen Sie bei Bedarf in der Symbolleiste der Google Cloud Console das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie den Cluster aus, der auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Vollständiger Name der Ressource aufgeführt ist. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.

4. Klicken Sie auf den Tab Knoten. Wählen Sie den in VM_Instance_Name aufgeführten Knoten aus.

5. Klicken Sie auf den Tab Details und notieren Sie sich die Annotation container.googleapis.com/instance_id.

Schritt 3: Pod überprüfen

1. Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.

   Zur Seite "Kubernetes-Arbeitslasten"

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Filtern Sie nach dem Cluster, der auf dem Tab Zusammenfassung in der Zeile Vollständiger Name der Ressource der Ergebnisdetails und bei Bedarf nach dem in Pod_Namespace aufgeführten Pod-Namespace aufgeführt ist.

4. Wählen Sie den in Pod_Name aufgeführten Pod aus. Notieren Sie sich alle Metadaten zum Pod und zu seinem Inhaber.

Schritt 4: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console den Log-Explorer.

   Zum Log-Explorer

2. Wählen Sie bei Bedarf in der Symbolleiste der Google Cloud Console das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.

4. Gehen Sie auf der Seite, die geladen wird, so vor:

   1. Suchen Sie mit dem folgenden Filter Pod-Logs für Pod_Name:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Suchen Sie mit dem folgenden Filter Cluster-Audit-Logs:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Schritt 5: Laufenden Container prüfen

Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.

1. Öffnen Sie die Google Cloud Console.

   Google Cloud Console öffnen

2. Wählen Sie bei Bedarf in der Symbolleiste der Google Cloud Console das in resource.project_display_name aufgeführte Projekt aus.

3. Klicken Sie auf Cloud Shell aktivieren .

4. Rufen Sie GKE-Anmeldedaten für Ihren Cluster ab, indem Sie die folgenden Befehle ausführen.

   Für zonale Cluster:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   Für regionale Cluster:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   Ersetzen Sie Folgendes:

   • cluster_name: der in resource.labels.cluster_name aufgeführte Cluster
   • location: der in resource.labels.location aufgeführte Standort
   • project_name: der in resource.project_display_name aufgeführte Projektname

5. Rufen Sie die geänderte schädliche Binärdatei ab:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Ersetzen Sie local_file durch einen lokalen Pfad zum Speichern der geänderten schädlichen Binärdatei.

6. Stellen Sie eine Verbindung zur Containerumgebung her:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Bei diesem Befehl muss für den Container eine Shell unter /bin/sh installiert sein.

Schritt 6: Forschungsangriffs- und Reaktionsmethoden

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ingress-Tool-Übertragung, Native API.
2. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
3. Prüfen Sie den SHA-256-Hashwert des Binärprogramms, das in VirusTotal als schädlich gekennzeichnet ist. Klicken Sie dazu auf den Link im VirusTotal-Indikator. VirusTotal, ein Alphabet-eigener Dienst, der Kontext zu potenziell schädlichen Dateien, URLs, Domains und IP-Adressen bereitstellt.

Schritt 7: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Container.
• Beenden oder löschen Sie den manipulierten Container und ersetzen Sie ihn durch einen neuen Container.

Execution: Modified Malicious Library Loaded

Eine Bibliothek, die mit der folgenden Bibliothek geladen wurde:

• Im ursprünglichen Container-Image enthalten.
• Während der Containerlaufzeit geändert
• Laut Bedrohungsdaten als schädlich eingestuft

Angreifer könnten schädliche Bibliotheken in vorhandene Programme laden, um den Schutz vor Codeausführungen zu umgehen und schädlichen Code zu verbergen. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Execution: Modified Malicious Library Loaded-Ergebnis wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird auf dem Tab Zusammenfassung geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Programmbinärdatei: Der vollständige Pfad der Prozessbinärdatei, mit der die Bibliothek geladen wurde.
     • Bibliotheken: Details zur geänderten Bibliothek.
     • Argumente: Die Argumente, die beim Aufrufen der Prozessbinärdatei angegeben wurden.
     • Container: der Name des betroffenen Containers
     • Container-URI: Der Name des Container-Images, das bereitgestellt wird.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der vollständige Ressourcenname des Clusters.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • VirusTotal-Indikator: Link zur Analyseseite von VirusTotal.

3. Klicken Sie auf den Tab JSON und notieren Sie sich die folgenden Felder:

   • sourceProperties:
     • VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

   Zur Seite Kubernetes Clusters

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie den in resource.name aufgeführten Cluster aus. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.

4. Klicken Sie auf den Tab Knoten. Wählen Sie den in VM_Instance_Name aufgeführten Knoten aus.

5. Klicken Sie auf den Tab Details und notieren Sie sich die Annotation container.googleapis.com/instance_id.

Schritt 3: Pod überprüfen

1. Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.

   Zur Seite "Kubernetes-Arbeitslasten"

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Filtern Sie nach dem Cluster, der auf dem Tab Zusammenfassung in der Zeile Vollständiger Name der Ressource der Ergebnisdetails und bei Bedarf nach dem in Pod_Namespace aufgeführten Pod-Namespace aufgeführt ist.

4. Wählen Sie den in Pod_Name aufgeführten Pod aus. Notieren Sie sich alle Metadaten zum Pod und zu seinem Inhaber.

Schritt 4: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console den Log-Explorer.

   Zum Log-Explorer

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.

4. Gehen Sie auf der Seite, die geladen wird, so vor:

   1. Suchen Sie mit dem folgenden Filter Pod-Logs für Pod_Name:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Suchen Sie mit dem folgenden Filter Cluster-Audit-Logs:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Schritt 5: Laufenden Container prüfen

Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.

1. Öffnen Sie die Google Cloud Console.

   Google Cloud Console öffnen

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Klicken Sie auf Cloud Shell aktivieren .

4. Rufen Sie die GKE-Anmeldedaten für Ihren Cluster ab, indem Sie die folgenden Befehle ausführen.

   Für zonale Cluster:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Für regionale Cluster:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Rufen Sie die geänderte schädliche Bibliothek ab:

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Ersetzen Sie local_file durch einen lokalen Pfad zum Speichern der geänderten schädlichen Bibliothek.

6. Stellen Sie eine Verbindung zur Containerumgebung her:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Bei diesem Befehl muss für den Container eine Shell unter /bin/sh installiert sein.

Schritt 6: Forschungsangriffs- und Reaktionsmethoden

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ingress-Tool-Übertragung, Freigegebene Module.
2. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
3. Prüfen Sie den SHA-256-Hashwert der Bibliothek, die in VirusTotal als schädlich gekennzeichnet ist. Klicken Sie dazu auf den Link im VirusTotal-Indikator. VirusTotal, ein Alphabet-eigener Dienst, der Kontext zu potenziell schädlichen Dateien, URLs, Domains und IP-Adressen bereitstellt.

Schritt 7: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Container.
• Beenden oder löschen Sie den manipulierten Container und ersetzen Sie ihn durch einen neuen Container.

Malicious Script Executed

Ein Modell für maschinelles Lernen hat den ausgeführten Bash-Code als schädlich erkannt. Angreifer können Bash verwenden, um Tools zu übertragen und Befehle ohne Binärdateien auszuführen. Es ist eine wichtige Best Practice, dafür zu sorgen, dass Ihre Container unveränderlich sind. Die Verwendung von Skripts zur Übertragung von Tools kann die Angreifertechnik der Übertragung von Ingress-Tools nachahmen und zur unerwünschten Erkennung führen.

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Malicious Script Executed, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Programmbinärprogramm: Details zum Interpreter, der das Skript aufgerufen hat.
     • Script: absoluter Pfad des Skriptnamens auf der Festplatte; dieses Attribut wird nur für Skripts angezeigt, die auf das Laufwerk geschrieben wurden, nicht für die literale Skriptausführung (z. B. bash -c).
     • Argumente: die Argumente, die beim Aufrufen des Skripts angegeben wurden
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der vollständige Ressourcenname des Clusters, einschließlich Projektnummer, Standort und Clustername

3. Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON.

4. Beachten Sie in der JSON-Datei die folgenden Felder.

   • finding:
     • processes:
     • script:
       • contents: Inhalt des ausgeführten Skripts, der aus Leistungsgründen möglicherweise abgeschnitten wird; kann bei Ihrer Untersuchung helfen
       • sha256: SHA-256-Hash von script.contents
   • resource:
     • project_display_name: der Name des Projekts, das das Asset enthält.
   • sourceProperties:
     • Pod_Namespace: der Name des Kubernetes-Namespace des Pods.
     • Pod_Name: der Name des GKE-Pods.
     • Container_Name: der Name des betroffenen Containers.
     • Container_Image_Uri: der Name des ausgeführten Container-Images.
     • VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.

5. Ermitteln Sie andere Ergebnisse, die zu einem ähnlichen Zeitpunkt für diesen Container aufgetreten sind. Wenn das Skript beispielsweise ein Binärprogramm löscht, suchen Sie nach Ergebnissen im Zusammenhang mit der Binärdatei.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

   Zur Seite Kubernetes Clusters

2. Wählen Sie bei Bedarf in der Symbolleiste der Google Cloud Console das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie den Cluster aus, der auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Vollständiger Name der Ressource aufgeführt ist. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.

4. Klicken Sie auf den Tab Knoten. Wählen Sie den in VM_Instance_Name aufgeführten Knoten aus.

5. Klicken Sie auf den Tab Details und notieren Sie sich die Annotation container.googleapis.com/instance_id.

Schritt 3: Pod überprüfen

1. Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.

   Zur Seite "Kubernetes-Arbeitslasten"

2. Wählen Sie bei Bedarf in der Symbolleiste der Google Cloud Console das in resource.project_display_name aufgeführte Projekt aus.

3. Filtern Sie bei Bedarf nach dem in resource.name aufgeführten Cluster und dem in Pod_Namespace aufgeführten Pod-Namespace.

4. Wählen Sie den in Pod_Name aufgeführten Pod aus. Notieren Sie sich alle Metadaten zum Pod und zu seinem Inhaber.

Schritt 4: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console den Log-Explorer.

   Zum Log-Explorer

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.

4. Gehen Sie auf der Seite, die geladen wird, so vor:

   1. Suchen Sie mit dem folgenden Filter Pod-Logs für Pod_Name:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Suchen Sie mit dem folgenden Filter Cluster-Audit-Logs:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Schritt 5: Laufenden Container prüfen

Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.

1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

   Zur Seite Kubernetes Clusters

2. Klicken Sie auf den Namen des Clusters in resource.labels.cluster_name.

3. Klicken Sie auf der Seite Cluster auf Verbinden und dann auf In Cloud Shell ausführen.

   Cloud Shell startet Befehle für den Cluster im Terminal und fügt sie hinzu.

4. Drücken Sie die Eingabetaste. Wenn das Dialogfeld Cloud Shell autorisieren angezeigt wird, klicken Sie auf Autorisieren.

5. Stellen Sie eine Verbindung zur Containerumgebung her, indem Sie den folgenden Befehl ausführen:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Bei diesem Befehl muss für den Container eine Shell unter /bin/sh installiert sein.

Schritt 6: Forschungsangriffs- und Reaktionsmethoden

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Befehls- und Skriptinterpreter, Ingress-Tool Transfer.
2. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Schritt 7: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenn das Skript die vorgesehenen Änderungen am Container vorgenommen hat, erstellen Sie das Container-Image neu, sodass keine Änderungen erforderlich sind. Auf diese Weise kann der Container unveränderlich sein.
• Andernfalls wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Container.
• Beenden oder löschen Sie den manipulierten Container und ersetzen Sie ihn durch einen neuen Container.

Malicious URL Observed

Vorschau

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Container Threat Detection hat eine schädliche URL in der Argumentliste eines ausführbaren Prozesses festgestellt. Angreifer können Malware oder schädliche Bibliotheken über schädliche URLs laden.

Führen Sie die folgenden Schritte aus, um auf dieses Ergebnis zu reagieren.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Malicious URL Observed, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • URI: Der beobachtete schädliche URI.
     • Hinzugefügte Binärdatei: Der vollständige Pfad der Prozessbinärdatei, die die Argumente mit der schädlichen URL empfangen hat.
     • Argumente: Die Argumente, die beim Aufrufen des Prozessbinärs angegeben wurden.
     • Umgebungsvariablen: die Umgebungsvariablen, die beim Aufrufen der Prozessbinärdatei aktiv waren.
     • Container: der Name des Containers
     • Kubernetes-Pods: Pod-Name und Namespace.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Anzeigename der Ressource: der Name der betroffenen Ressource.
     • Vollständiger Name der Ressource: Der vollständige Ressourcenname des Clusters. Der vollständige Ressourcenname enthält folgende Informationen:
       • Das Projekt, das den Cluster enthält: projects/PROJECT_ID
       • Der Standort, an dem sich der Cluster befindet: entweder zone/ZONE oder locations/LOCATION
       • Der Name des Clusters: projects/CLUSTER_NAME

3. Notieren Sie sich auf dem Tab JSON im Attribut sourceProperties den Wert des Attributs VM_Instance_Name.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

   Zur Seite Kubernetes Clusters

2. Wählen Sie gegebenenfalls in der Symbolleiste der Google Cloud Console das Projekt aus, das unter Vollständiger Name der Ressource (resource.name) angezeigt wird. Der Projektname wird im vollständigen Ressourcennamen nach /projects/ angezeigt.

3. Klicken Sie auf den Clusternamen, den Sie in der Ergebniszusammenfassung unter Anzeigename der Ressource (resource.display_name) notiert haben. Die Seite Cluster wird geöffnet.

4. Notieren Sie sich im Abschnitt „Metadaten“ auf der Seite **Clusterdetails> benutzerdefinierte Informationen, die bei der Behebung der Bedrohung hilfreich sein können, z. B. Informationen zur Identifizierung des Clusterinhabers.

5. Klicken Sie auf den Tab „Knoten“.

6. Wählen Sie aus den aufgeführten Knoten den Knoten aus, der dem Wert von VM_Instance_Name entspricht, den Sie zuvor in der Ergebnis-JSON-Datei notiert haben.

7. Notieren Sie sich auf dem Tab Details der Seite Knotendetails im Abschnitt Annotationen den Wert der Annotation container.googleapis.com/instance_id.

Schritt 3: Pod überprüfen

1. Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.

   Zur Seite "Kubernetes-Arbeitslasten"

2. Wählen Sie bei Bedarf in der Symbolleiste der Google Cloud Console das Projekt aus, das Sie in der Ergebniszusammenfassung unter Vollständiger Name der Ressource (resource.name) des Clusters notiert haben.

3. Klicken Sie auf Systemarbeitslasten anzeigen.

4. Filtern Sie die Liste der Arbeitslasten nach dem Clusternamen, den Sie unter Vollständiger Name der Ressource (resource.name) der Ergebniszusammenfassung angegeben haben, und gegebenenfalls nach dem von Ihnen notierten Pod-Namespace (kubernetes.pods.ns).

5. Klicken Sie auf den Arbeitslastnamen, der dem Wert des Attributs VM_Instance_Name entspricht, das Sie zuvor in der Ergebnis-JSON-Datei notiert haben. Die Seite Pod-Details wird geöffnet.

6. Notieren Sie sich auf der Seite Pod-Details alle Informationen zum Pod, mit denen Sie die Bedrohung beheben können.

Schritt 4: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console den Log-Explorer.

   Zum Log-Explorer

2. Wählen Sie gegebenenfalls in der Symbolleiste der Google Cloud Console das Projekt aus, das unter Vollständiger Name der Ressource (resource.name) angezeigt wird.

3. Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.

4. Gehen Sie auf der Seite, die geladen wird, so vor:

   1. Mithilfe des folgenden Filters können Sie nach Pod-Logs für Ihren Pod (kubernetes.pods.name) suchen:
      • resource.type="k8s_container"
      • resource.labels.project_id="PROJECT_ID"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • resource.labels.namespace_name="NAMESPACE_NAME"
      • resource.labels.pod_name="POD_NAME"
   2. Suchen Sie mit dem folgenden Filter Cluster-Audit-Logs:
      • logName="projects/PROJECT_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="PROJECT_ID"
      • resource.labels.location="LOCATION_OR_ZONE"
      • resource.labels.cluster_name="CLUSTER_NAME/var>"
      • POD_NAME
   3. Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Schritt 5: Den ausgeführten Container prüfen

Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.

1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

   Zur Seite Kubernetes Clusters

2. Klicken Sie auf den Namen des Clusters in resource.labels.cluster_name.

3. Klicken Sie auf der Seite Cluster auf Verbinden und dann auf In Cloud Shell ausführen.

   Cloud Shell startet Befehle für den Cluster im Terminal und fügt sie hinzu.

4. Drücken Sie die Eingabetaste. Wenn das Dialogfeld Cloud Shell autorisieren angezeigt wird, klicken Sie auf Autorisieren.

5. Stellen Sie eine Verbindung zur Containerumgebung her, indem Sie den folgenden Befehl ausführen:

     kubectl exec --namespace=POD_NAMESPACE -ti POD_NAME -c CONTAINER_NAME -- /bin/sh
   

   Ersetzen Sie CONTAINER_NAME durch den Namen des Containers, den Sie zuvor in der Ergebniszusammenfassung notiert haben.

   Bei diesem Befehl muss für den Container eine Shell unter /bin/sh installiert sein.

Schritt 6: Forschungsangriffs- und Reaktionsmethoden

1. Im Safe Browsing-Websitestatus erfahren Sie, warum die URL als schädlich eingestuft ist.
2. Überprüfen Sie die MITRE ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ingress Tool Transfer.
3. Kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung, um einen Reaktionsplan zu entwickeln.

Schritt 7: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Container.
• Beenden oder löschen Sie den manipulierten Container und ersetzen Sie ihn durch einen neuen Container.

Reverse Shell

Ein Prozess, bei dem die Stream-Weiterleitung an einen Remote-Socket gestartet wurde. Das Erstellen einer mit dem Netzwerk verbundenen Shell kann es einem Angreifer ermöglichen, nach einem begrenzten anfänglichen Kompromiss beliebige Aktionen auszuführen. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Reverse Shell-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Programmbinärprogramm: Der absolute Pfad des Prozesses, der mit der Streamumleitung zu einem Remote-Socket gestartet wurde.
     • Argumente: Die Argumente, die beim Aufrufen des Prozessbinärs angegeben wurden.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der vollständige Ressourcenname des Clusters.
     • Vollständiger Name des Projekts:
   • Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON.
   • Beachten Sie in der JSON-Datei die folgenden Felder.
   • resource:
     • project_display_name: der Name des Projekts, das das Asset enthält.
   • sourceProperties:
     • Pod_Namespace: der Name des Kubernetes-Namespace des Pods.
     • Pod_Name: der Name des GKE-Pods.
     • Container_Name: der Name des betroffenen Containers.
     • VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.
     • Reverse_Shell_Stdin_Redirection_Dst_Ip: die Remote-IP-Adresse der Verbindung
     • Reverse_Shell_Stdin_Redirection_Dst_Port: der Remote-Port
     • Reverse_Shell_Stdin_Redirection_Src_Ip: die lokale IP-Adresse der Verbindung
     • Reverse_Shell_Stdin_Redirection_Src_Port: der lokale Port
     • Container_Image_Uri: der Name des ausgeführten Container-Images.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

   Zur Seite Kubernetes Clusters

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie den in resource.name aufgeführten Cluster aus. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.

4. Klicken Sie auf den Tab Knoten. Wählen Sie den in VM_Instance_Name aufgeführten Knoten aus.

5. Klicken Sie auf den Tab Details und notieren Sie sich die Annotation container.googleapis.com/instance_id.

Schritt 3: Pod überprüfen

1. Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.

   Zur Seite "Kubernetes-Arbeitslasten"

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Filtern Sie bei Bedarf nach dem in resource.name aufgeführten Cluster und dem in Pod_Namespace aufgeführten Pod-Namespace.

4. Wählen Sie den in Pod_Name aufgeführten Pod aus. Notieren Sie sich alle Metadaten zum Pod und zu seinem Inhaber.

Schritt 4: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console den Log-Explorer.

   Zum Log-Explorer

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.

4. Gehen Sie auf der Seite, die geladen wird, so vor:

   1. Suchen Sie mit dem folgenden Filter Pod-Logs für Pod_Name:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Suchen Sie mit dem folgenden Filter Cluster-Audit-Logs:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Schritt 5: Laufenden Container prüfen

Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.

1. Öffnen Sie die Google Cloud Console.

   Google Cloud Console öffnen

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Klicken Sie auf Cloud Shell aktivieren .

4. Rufen Sie die GKE-Anmeldedaten für Ihren Cluster ab, indem Sie die folgenden Befehle ausführen.

   Für zonale Cluster:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Für regionale Cluster:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Starten Sie eine Shell in der Containerumgebung, indem Sie Folgendes ausführen:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Bei diesem Befehl muss für den Container eine Shell unter /bin/sh installiert sein.

   Führen Sie den folgenden Befehl in der Container-Shell aus, um alle im Container ausgeführten Prozesse aufzurufen:

     ps axjf
   

   Bei diesem Befehl muss für den Container /bin/ps installiert sein.

Schritt 6: Forschungsangriffs- und Reaktionsmethoden

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Befehls- und Skriptinterpreter, Ingress-Tool Transfer.
2. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Schritt 7: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Container.
• Beenden oder löschen Sie den manipulierten Container und ersetzen Sie ihn durch einen neuen Container.

Unexpected Child Shell

Container Threat Detection hat einen Prozess festgestellt, durch den unerwartet ein untergeordneter Shell-Prozess ausgelöst wurde. Dieses Ereignis kann darauf hindeuten, dass ein Angreifer versucht, Shell-Befehle und -Skripte zu missbrauchen.

Führen Sie die folgenden Schritte aus, um auf dieses Ergebnis zu reagieren.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Unexpected Child Shell-Ergebnis wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • Übergeordneter Prozess: Der Prozess, bei dem unerwartet der untergeordnete Shell-Prozess erstellt wurde.
     • Untergeordneter Prozess: der untergeordnete Shell-Prozess.
     • Argumente: Die Argumente, die an das Binärprogramm des untergeordneten Shell-Prozesses übergeben werden.
     • Umgebungsvariablen: die Umgebungsvariablen der Binärdatei des untergeordneten Shell-Prozesses.
     • Container: der Name des Containers
     • Container-URI: der Image-URI des Containers.
     • Kubernetes-Pods: Pod-Name und Namespace.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Anzeigename der Ressource: der Name der betroffenen Ressource.
     • Vollständiger Name der Ressource: Der vollständige Ressourcenname des Clusters. Der vollständige Ressourcenname enthält folgende Informationen:
       • Das Projekt, das den Cluster enthält: projects/PROJECT_ID
       • Der Standort, an dem sich der Cluster befindet: entweder zone/ZONE oder locations/LOCATION
       • Der Name des Clusters: projects/CLUSTER_NAME

3. Klicken Sie auf den Tab JSON und notieren Sie sich die folgenden Felder:

+processes: ein Array, das alle Prozesse im Zusammenhang mit dem Ergebnis enthält. Dieses Array enthält den untergeordneten und den übergeordneten Prozess. +resource: +project_display_name: Der Name des Projekts, das die Assets enthält. +sourceProperties: +VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.

   Zur Seite Kubernetes Clusters

2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie den in resource.name aufgeführten Cluster aus. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.

4. Klicken Sie auf den Tab Knoten. Wählen Sie den in VM_Instance_Name aufgeführten Knoten aus.

5. Klicken Sie auf den Tab Details und notieren Sie sich die Annotation container.googleapis.com/instance_id.

Schritt 3: Pod überprüfen

1. Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.

   Zur Seite "Kubernetes-Arbeitslasten"

2. Wählen Sie bei Bedarf in der Symbolleiste der Google Cloud Console das Projekt aus, das Sie in der Ergebniszusammenfassung unter Vollständiger Name der Ressource (resource.name) des Clusters notiert haben.

3. Klicken Sie auf Systemarbeitslasten anzeigen.

4. Filtern Sie die Liste der Arbeitslasten nach dem Clusternamen, den Sie unter Vollständiger Name der Ressource (resource.name) der Ergebniszusammenfassung angegeben haben, und gegebenenfalls nach dem von Ihnen notierten Pod-Namespace (kubernetes.pods.ns).

5. Klicken Sie auf den Arbeitslastnamen, der dem Wert des Attributs VM_Instance_Name entspricht, das Sie zuvor in der JSON-Datei für das Ergebnis notiert haben. Die Seite Pod-Details wird geöffnet.

6. Notieren Sie sich auf der Seite Pod-Details alle Informationen zum Pod, mit denen Sie die Bedrohung beheben können.

Schritt 4: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console den Log-Explorer.

   Zum Log-Explorer

2. Wählen Sie in der Symbolleiste der Google Cloud Console das in resource.project_display_name aufgeführte Projekt aus.

3. Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.

4. Gehen Sie auf der Seite, die geladen wird, so vor:

   1. Suchen Sie mit dem folgenden Filter Pod-Logs für Pod_Name:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Suchen Sie mit dem folgenden Filter Cluster-Audit-Logs:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Schritt 5: Den ausgeführten Container prüfen

Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.

1. Öffnen Sie die Google Cloud Console.

   Google Cloud Console öffnen

2. Wählen Sie in der Symbolleiste der Google Cloud Console das in resource.project_display_name aufgeführte Projekt aus.

3. Klicken Sie auf Cloud Shell aktivieren .

4. Rufen Sie die GKE-Anmeldedaten für Ihren Cluster ab, indem Sie die folgenden Befehle ausführen.

   Führen Sie für zonale Cluster folgenden Befehl aus:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Führen Sie für regionale Cluster folgenden Befehl aus:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Führen Sie folgenden Befehl aus, um eine Shell in der Containerumgebung zu starten:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Bei diesem Befehl muss für den Container eine Shell unter /bin/sh installiert sein.

   Führen Sie den folgenden Befehl in der Container-Shell aus, um alle im Container ausgeführten Prozesse aufzurufen:

     ps axjf
   

   Bei diesem Befehl muss für den Container /bin/ps installiert sein.

Schritt 6: Forschungsangriffs- und Reaktionsmethoden

1. Sehen Sie sich die MITRE ATT&CK-Framework-Einträge für den Ergebnistyp Befehls- und Skriptinterpreter: Unix-Shell an.
2. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Schritt 7: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

• Wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Container.
• Beenden oder löschen Sie den manipulierten Container und ersetzen Sie ihn durch einen neuen Container.

VM Threat Detection-Antwort

Weitere Informationen zu VM Threat Detection finden Sie unter Übersicht: VM Threat Detection.

Execution: Cryptocurrency Mining Hash Match

VM Threat Detection erkannte Krypto-Mining-Aktivitäten, indem die Hashes laufender Programme mit den Speicher-Hashes bekannter Krypto-Mining-Software abgeglichen wurden.

So reagieren Sie auf diese Ergebnisse:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Execution: Cryptocurrency Mining Hash Match-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:

     • Binärfamilie: die erkannte Kryptowährungsanwendung
     • Programmbinärdatei: absoluter Pfad des Prozesses
     • Argumente: Die Argumente, die beim Aufrufen des Prozessbinärs angegeben wurden.
     • Prozessnamen: Der Name des in der VM-Instanz ausgeführten Prozesses, der den erkannten Signaturübereinstimmungen zugeordnet ist.

     VM Threat Detection kann Kernel-Builds aus wichtigen Linux-Distributionen erkennen. Wenn der Kernel-Build der betroffenen VM erkannt wird, lassen sich die Prozessdetails der Anwendung identifizieren und das Feld processes des Ergebnisses ausfüllen. Wenn VM Threat Detection den Kernel nicht neu erkennen kann, z. B. weil der Kernel benutzerdefiniert erstellt wurde, ist das Feld processes des Ergebnisses nicht ausgefüllt.

   • Betroffene Ressource, insbesondere die folgenden Felder:

     • Vollständiger Name der Ressource: Der vollständige Ressourcenname der betroffenen VM-Instanz, einschließlich der ID des Projekts, in dem sie enthalten ist.

3. Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON, um sich die vollständige JSON-Datei für dieses Ergebnis anzusehen.

   • indicator
     • signatures:
       • memory_hash_signature: eine Signatur, die den Hashes der Speicherseite entspricht.
       • detections
         • binary: der Name des Binärprogramms der Kryptowährungsanwendung, z. B. linux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0.
         • percent_pages_matched: der Prozentsatz der Seiten im Arbeitsspeicher, die mit Seiten in bekannten Kryptowährungsanwendungen in der Seiten-Hash-Datenbank übereinstimmen.

Schritt 2: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console den Log-Explorer.

   Zum Log-Explorer

2. Wählen Sie in der Symbolleiste der Google Cloud Console das Projekt aus, das die VM-Instanz enthält, wie in der Zeile Vollständiger Name der Ressource auf dem Tab Zusammenfassung der Ergebnisdetails angegeben.

3. Prüfen Sie, ob in den Logs Zeichen für Angriffe auf die betroffene VM-Instanz enthalten sind. Beispielsweise können Sie nach verdächtigen oder unbekannten Aktivitäten und Zeichen von kompromittierten Anmeldedaten suchen.

Schritt 3: Berechtigungen und Einstellungen prüfen

1. Öffnen Sie in der Google Cloud Console die Seite Dashboard.

   Zum Dashboard

2. Wählen Sie das Projekt aus, das auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Vollständiger Name der Ressource angegeben ist.

3. Rufen Sie die Karte Ressourcen auf und klicken Sie auf Compute Engine.

4. Klicken Sie auf die VM-Instanz, die mit dem Projekt übereinstimmt, das unter Vollständiger Name der Ressource angegeben ist. Prüfen Sie die Instanzdetails einschließlich der Netzwerk- und Zugriffseinstellungen.

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für Ausführung.
2. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Schritt 5: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

Verwenden Sie eine Lösung zur Endpunkterkennung und -antwort, um Unterstützung bei der Erkennung und Entfernung zu erhalten.

1. Wenden Sie sich an den Inhaber der VM.

2. Prüfen Sie, ob die Anwendung eine Mining-Anwendung ist:

   • Wenn der Prozessname und der Binärpfad der erkannten Anwendung verfügbar sind, prüfen Sie die Werte in den Zeilen Binärprogramm, Argumente und Prozessnamen auf dem Tab Zusammenfassung der Ergebnisdetails in Ihrer Untersuchung.

   • Wenn die Prozessdetails nicht verfügbar sind, prüfen Sie, ob der Binärname aus der Speicher-Hash-Signatur Hinweise enthalten kann. Betrachten Sie eine Binärdatei mit dem Namen linux-x86-64_xmrig_2.14.1. Mit dem Befehl grep können Sie im Speicher nach wichtigen Dateien suchen. Verwenden Sie einen aussagekräftigen Teil des Binärnamens in Ihrem Suchmuster, in diesem Fall xmrig. Sehen Sie sich die Suchergebnisse an.

   • Untersuchen Sie die laufenden Prozesse, insbesondere die Prozesse mit hoher CPU-Auslastung, um festzustellen, ob es Prozesse gibt, die Sie nicht erkennen. Bestimmen Sie, ob die zugehörigen Anwendungen Mining-Anwendungen sind.

   • Suchen Sie im Speicher nach gängigen Strings, die von Mining-Anwendungen verwendet werden, z. B. btc.com, ethminer, xmrig, cpuminer und randomx. Weitere Beispiele für Strings, nach denen Sie suchen können, finden Sie unter Softwarenamen und YARA-Regeln und in der zugehörigen Dokumentation für die einzelnen aufgeführten Softwares.

3. Wenn Sie feststellen, dass es sich bei der Anwendung um eine Mining-Anwendung handelt und ihr Prozess noch ausgeführt wird, beenden Sie den Prozess. Suchen Sie die ausführbare Binärdatei der Anwendung im Speicher der VM und löschen Sie sie.

4. Beenden Sie bei Bedarf die manipulierte Instanz und ersetzen Sie sie durch eine neue Instanz.

Execution: Cryptocurrency Mining YARA Rule

Die VM Threat Detection hat das Mining von Kryptowährungen erkannt. Dazu wurden Speichermuster wie Proof of Work-Konstanten abgeglichen, die bekanntermaßen von Kryptowährung-Mining-Software verwendet werden.

So reagieren Sie auf diese Ergebnisse:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Execution: Cryptocurrency Mining YARA Rule-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:

     • YARA-Regelname: Die Regel, die für YARA-Detektoren ausgelöst wurde.
     • Programmbinärdatei: absoluter Pfad des Prozesses
     • Argumente: Die Argumente, die beim Aufrufen des Prozessbinärs angegeben wurden.
     • Prozessnamen: der Name der Prozesse, die in der VM-Instanz ausgeführt werden und den erkannten Signaturübereinstimmungen zugeordnet ist.

     VM Threat Detection kann Kernel-Builds aus wichtigen Linux-Distributionen erkennen. Wenn der Kernel-Build der betroffenen VM erkannt wird, lassen sich die Prozessdetails der Anwendung identifizieren und das Feld processes des Ergebnisses ausfüllen. Wenn VM Threat Detection den Kernel nicht neu erkennen kann, z. B. weil der Kernel benutzerdefiniert erstellt wurde, ist das Feld processes des Ergebnisses nicht ausgefüllt.

   • Betroffene Ressource, insbesondere die folgenden Felder:

     • Vollständiger Name der Ressource: Der vollständige Ressourcenname der betroffenen VM-Instanz, einschließlich der ID des Projekts, in dem sie enthalten ist.

   • Weitere Informationen, insbesondere die folgenden Felder:

     • Cloud Logging-URI: Link zu Logging-Einträgen.
     • MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
     • VirusTotal-Indikator: Link zur Analyseseite von VirusTotal.
     • Chronicle: Link zu Google SecOps.

3. Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON, um sich die vollständige JSON-Datei für dieses Ergebnis anzusehen.

Schritt 2: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console den Log-Explorer.

   Zum Log-Explorer

2. Wählen Sie in der Symbolleiste der Google Cloud Console das Projekt aus, das die VM-Instanz enthält, wie in der Zeile Vollständiger Name der Ressource auf dem Tab Zusammenfassung der Ergebnisdetails angegeben.

3. Prüfen Sie, ob in den Logs Zeichen für Angriffe auf die betroffene VM-Instanz enthalten sind. Beispielsweise können Sie nach verdächtigen oder unbekannten Aktivitäten und Zeichen von kompromittierten Anmeldedaten suchen.

Schritt 3: Berechtigungen und Einstellungen prüfen

1. Öffnen Sie in der Google Cloud Console die Seite Dashboard.

   Zum Dashboard

2. Wählen Sie das Projekt aus, das im Ressourcennamen angegeben ist, der auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Vollständiger Name der Ressource aufgeführt ist.

3. Rufen Sie die Karte Ressourcen auf und klicken Sie auf Compute Engine.

4. Klicken Sie auf die VM-Instanz, die mit resourceName übereinstimmt. Prüfen Sie die Instanzdetails einschließlich der Netzwerk- und Zugriffseinstellungen.

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für Ausführung.
2. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Schritt 5: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

Verwenden Sie eine Lösung zur Endpunkterkennung und -antwort, um Unterstützung bei der Erkennung und Entfernung zu erhalten.

1. Wenden Sie sich an den Inhaber der VM.

2. Prüfen Sie, ob die Anwendung eine Mining-Anwendung ist:

   • Wenn der Prozessname und der Binärpfad der erkannten Anwendung verfügbar sind, prüfen Sie die Werte in den Zeilen Binärprogramm, Argumente und Prozessnamen auf dem Tab Zusammenfassung der Ergebnisdetails in Ihrer Untersuchung.

   • Untersuchen Sie die laufenden Prozesse, insbesondere die Prozesse mit hoher CPU-Auslastung, um festzustellen, ob es Prozesse gibt, die Sie nicht erkennen. Bestimmen Sie, ob die zugehörigen Anwendungen Mining-Anwendungen sind.

   • Suchen Sie im Speicher nach gängigen Strings, die von Mining-Anwendungen verwendet werden, z. B. btc.com, ethminer, xmrig, cpuminer und randomx. Weitere Beispiele für Strings, nach denen Sie suchen können, finden Sie unter Softwarenamen und YARA-Regeln und in der zugehörigen Dokumentation für die einzelnen aufgeführten Softwares.

3. Wenn Sie feststellen, dass es sich bei der Anwendung um eine Mining-Anwendung handelt und ihr Prozess noch ausgeführt wird, beenden Sie den Prozess. Suchen Sie die ausführbare Binärdatei der Anwendung im Speicher der VM und löschen Sie sie.

4. Beenden Sie bei Bedarf die manipulierte Instanz und ersetzen Sie sie durch eine neue Instanz.

Execution: cryptocurrency mining combined detection

VM Threat Detection hat innerhalb eines Tages mehrere Kategorien von Ergebnissen aus einer einzigen Quelle erkannt. Eine einzelne Anwendung kann gleichzeitig Execution: Cryptocurrency Mining YARA Rule und Execution: Cryptocurrency Mining Hash Match findings auslösen.

Wenn Sie auf ein kombiniertes Ergebnis reagieren möchten, folgen Sie der Antwortanleitung für Execution: Cryptocurrency Mining YARA Rule und Execution: Cryptocurrency Mining Hash Match findings.

Malware: Malicious file on disk (YARA)

VM Threat Detection hat eine potenziell schädliche Datei erkannt, indem die nichtflüchtigen Speicher einer VM auf bekannte Malwaresignaturen gescannt wurden.

So reagieren Sie auf diese Ergebnisse:

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Ergebnis Malware: Malicious file on disk (YARA) wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird geöffnet.

2. Prüfen Sie auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten:

   • Was erkannt wurde, insbesondere die folgenden Felder:
     • YARA-Regelname: die YARA-Regel, für die eine Übereinstimmung gefunden wurde
     • Files (Dateien): Die UUID der Partition und der relative Pfad der potenziell schädlichen Datei, die erkannt wurde.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Der vollständige Ressourcenname der betroffenen VM-Instanz, einschließlich der ID des Projekts, in dem sie enthalten ist.

3. Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON, um sich die vollständige JSON-Datei für dieses Ergebnis anzusehen.

4. Beachten Sie in der JSON-Datei die folgenden Felder:

   • indicator
     • signatures:
       • yaraRuleSignature: eine Signatur, die der abgeglichenen YARA-Regel entspricht.

Schritt 2: Protokolle prüfen

1. Öffnen Sie in der Google Cloud Console den Log-Explorer.

   Zum Log-Explorer

2. Wählen Sie in der Symbolleiste der Google Cloud Console das Projekt aus, das die VM-Instanz enthält, wie in der Zeile Vollständiger Name der Ressource auf dem Tab Zusammenfassung der Ergebnisdetails angegeben.

3. Prüfen Sie, ob in den Logs Zeichen für Angriffe auf die betroffene VM-Instanz enthalten sind. Beispielsweise können Sie nach verdächtigen oder unbekannten Aktivitäten und Zeichen von kompromittierten Anmeldedaten suchen.

Schritt 3: Berechtigungen und Einstellungen prüfen

1. Öffnen Sie in der Google Cloud Console die Seite Dashboard.

   Zum Dashboard

2. Wählen Sie das Projekt aus, das im Ressourcennamen angegeben ist, der auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Vollständiger Name der Ressource aufgeführt ist.

3. Rufen Sie die Karte Ressourcen auf und klicken Sie auf Compute Engine.

4. Klicken Sie auf die VM-Instanz, die mit resourceName übereinstimmt. Prüfen Sie die Instanzdetails einschließlich der Netzwerk- und Zugriffseinstellungen.

Schritt 4: Angriffs- und Reaktionsmethoden untersuchen

Prüfen Sie den SHA-256-Hashwert der Datei, die in VirusTotal als schädlich gekennzeichnet ist. VirusTotal ist ein Dienst von Alphabet, der Kontext zu potenziell schädlichen Dateien, URLs, Domains und IP-Adressen bietet.

Hinweis :VirusTotal enthält möglicherweise nicht für alle Malware-Varianten Hashes.

Schritt 5: Antwort implementieren

Der folgende Antwortplan könnte für dieses Ergebnis geeignet sein, aber auch den Betrieb beeinträchtigen. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

1. Wenden Sie sich an den Inhaber der VM.

2. Suchen und löschen Sie die potenziell schädliche Datei, falls erforderlich. Die UUID der Partition und den relativen Pfad der Datei finden Sie auf dem Tab Zusammenfassung der Ergebnisdetails im Feld Dateien. Verwenden Sie eine Lösung zur Erkennung und Entfernung von Endpunkten.

3. Beenden Sie bei Bedarf die manipulierte Instanz und ersetzen Sie sie durch eine neue Instanz.

   Hinweis: Mit der Enterprise-Stufe von Security Command Center können Sie diese Aktion auch über ein Playbook für die Bedrohungsabwehr ausführen.

4. Für forensische Analysen sollten Sie die virtuellen Maschinen und nichtflüchtigen Speicher sichern. Weitere Informationen finden Sie unter Datenschutzoptionen in der Compute Engine-Dokumentation.

5. Zur weiteren Untersuchung können Sie Incident-Response-Services wie Mandiant in Betracht ziehen.

Sicherheitslücken schließen

Damit sich Bedrohungen nicht wiederholen, sollten Sie die zugehörigen Ergebnisse zu Sicherheitslücken und Fehlkonfigurationen prüfen und beheben.

So finden Sie zugehörige Ergebnisse:

1. Rufen Sie in der Google Cloud Console die Seite Ergebnisse von Security Command Center auf.

   Zu Ergebnissen

2. Prüfen Sie das Bedrohungsergebnis und kopieren Sie den Wert eines Attributs, das wahrscheinlich in einem zugehörigen Ergebnis zu Sicherheitslücken oder Fehlkonfigurationen auftritt, z. B. die Haupt-E-Mail-Adresse oder den Namen der betroffenen Ressource.

3. Öffnen Sie auf der Seite Ergebnisse den Abfrageeditor, indem Sie auf Abfrage bearbeiten klicken.

4. Klicken Sie auf Filter hinzufügen. Das Menü Filter auswählen wird geöffnet.

5. Wählen Sie in der Liste der Filterkategorien auf der linken Seite des Menüs die Kategorie aus, die das Attribut enthält, das Sie in der Bedrohungssuche notiert haben.

   Wenn Sie sich beispielsweise den vollständigen Namen der betroffenen Ressource notiert haben, wählen Sie Ressource aus. Die Attributtypen der Kategorie Ressource werden in der Spalte rechts angezeigt, einschließlich des Attributs Vollständiger Name.

6. Wählen Sie aus den angezeigten Attributen den Attributtyp aus, den Sie sich im Bedrohungsergebnis notiert haben. Auf der rechten Seite wird ein Suchbereich für Attributwerte geöffnet, in dem alle gefundenen Werte des ausgewählten Attributtyps angezeigt werden.

7. Fügen Sie in das Feld Filter den Attributwert ein, den Sie aus dem Bedrohungsergebnis kopiert haben. Die angezeigte Werteliste wird aktualisiert, sodass nur die Werte angezeigt werden, die mit dem eingefügten Wert übereinstimmen.

8. Wählen Sie aus der Liste der angezeigten Werte einen oder mehrere Werte aus und klicken Sie auf Übernehmen. Der Bereich Ergebnisse der Abfrageergebnisse wird aktualisiert, sodass nur die übereinstimmenden Ergebnisse angezeigt werden.

9. Wenn die Ergebnisse viele Ergebnisse enthalten, filtern Sie die Ergebnisse, indem Sie zusätzliche Filter im Bereich Schnellfilter auswählen.

   Wenn Sie beispielsweise nur die Klassenergebnisse Vulnerability und Misconfiguration anzeigen möchten, die die ausgewählten Attributwerte enthalten, scrollen Sie im Bereich Schnellfilter nach unten zum Abschnitt Ergebnisklasse und wählen Sie Sicherheitslücke und Fehlkonfiguration aus.

Zusätzlich zu den von Google bereitgestellten Indikatoren für Manipulation können Nutzer, die Kunden von Palo Alto Networks sind, die AutoFocus Threat Intelligence von Palo Alto Networks in die Event Threat Detection integrieren. AutoFocus ist ein Bedrohungserkennungsdienst, der Informationen über Netzwerkbedrohungen bereitstellt. Weitere Informationen finden Sie in der Google Cloud Console auf der Seite AutoFocus (Autofokus).

Bedrohungen beheben

Die Behebung von Event Threat Detection- und Container Threat Detection-Ergebnissen ist nicht so einfach wie das Beheben von Fehlkonfigurationen und Sicherheitslücken, die von Security Command Center identifiziert wurden.

Konfigurationsfehler und Compliance-Verstöße identifizieren Schwachstellen in Ressourcen, die ausgenutzt werden könnten. Normalerweise haben Fehlkonfigurationen bekannte, einfach zu implementierende Fehlerbehebungen, wie das Aktivieren einer Firewall oder das Rotieren eines Verschlüsselungsschlüssels.

Bedrohungen unterscheiden sich von Sicherheitslücken dadurch, dass sie dynamisch sind und darauf hindeuten, dass eine oder mehrere Ressourcen aktiv genutzt werden können. Eine Korrekturempfehlung ist möglicherweise nicht effektiv beim Sichern Ihrer Ressourcen, da die genauen Methoden, mit denen der Exploit erreicht wurde, möglicherweise nicht bekannt sind.

Beispiel: Ein Added Binary Executed-Ergebnis gibt an, dass eine nicht autorisierte Binärdatei in einem Container gestartet wurde. Eine grundlegende Korrekturempfehlung bietet möglicherweise an, den Container unter Quarantäne zu stellen und die Binärdatei zu löschen, ohne die zugrunde liegende Ursache zu beheben, die dem Angreifer Zugriff auf die Binärdatei ermöglicht. Sie müssen herausfinden, wie das Container-Image beschädigt wurde, um den Exploit zu beheben. Um festzustellen, ob die Datei über einen falsch konfigurierten Port oder auf andere Weise hinzugefügt wurde, ist eine gründliche Untersuchung erforderlich. Ein Analyst mit entsprechenden Kenntnissen über Ihr System muss Ihr System unter Umständen auf Schwachstellen prüfen.

Böswillige Akteure greifen Ressourcen mithilfe verschiedener Techniken an. Deshalb ist die Anwendung einer Korrektur für einen bestimmten Exploit möglicherweise nicht auf Varianten dieses Angriffs wirksam. Als Reaktion auf ein Brute Force: SSH-Ergebnis können Sie beispielsweise die Berechtigungsstufen einiger Nutzerkonten verringern, um den Zugriff auf Ressourcen einzuschränken. Schwache Passwörter können jedoch immer noch einen Angriffspfad darstellen.

Die Breite der Angriffsvektoren erschwert die Behebung von Maßnahmen, die in allen Situationen funktionieren. Die Rolle von Security Command Center in Ihrem Cloud-Sicherheitsplan besteht darin, betroffene Ressourcen nahezu in Echtzeit zu identifizieren, Ihnen mitteilen, welche Bedrohungen Sie haben, und Nachweise und Kontext für Ihre Untersuchungen bereitzustellen. Das Sicherheitspersonal muss jedoch die umfassenden Informationen in den Ergebnissen von Security Command Center verwenden, um die besten Möglichkeiten zur Behebung von Problemen und zum Schutz von Ressourcen vor zukünftigen Angriffen zu ermitteln.

Nächste Schritte

• In der Event Threat Detection-Übersicht finden Sie weitere Informationen über den Dienst und die erkannten Bedrohungen.

• Informationen zur Funktionsweise des Dienstes finden Sie unter Container Threat Detection – Übersicht.

• In der VM Threat Detection-Übersicht finden Sie weitere Informationen über den Dienst und die erkannten Bedrohungen.