Bedrohungen untersuchen und darauf reagieren

Dieses Dokument enthält informelle Anleitungen, mit denen Sie verdächtige Aktivitäten in Ihrer Google Cloud -Umgebung untersuchen können, die möglicherweise von böswilligen Akteuren verursacht wurden. Dieses Dokument enthält auch zusätzliche Ressourcen, um den Security Command Center-Ergebnissen Kontext hinzuzufügen. Mit den folgenden Schritten können Sie nachvollziehen, was bei einem potenziellen Angriff passiert ist, und mögliche Reaktionen 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 zur Behebung von Ressourcenfehlern finden Sie in der Dokumentation zu betroffenen Produkten.

Ergebnisse zu Bedrohungen

Event Threat Detection liefert Sicherheitsergebnisse, indem Ereignisse in Ihren Cloud Logging-Logstreams mit bekannten Indikatoren für Manipulation (IoC) abgeglichen werden. IoCs, die von internen Google-Sicherheitsquellen entwickelt wurden, identifizieren potenzielle Sicherheitslücken und Angriffe. Event Threat Detection erkennt auch Bedrohungen, indem es bekannte schädliche Taktiken, Techniken und Verfahren in Ihrem Logging-Stream identifiziert und Abweichungen vom bisherigen Verhalten Ihrer Organisation oder Ihres Projekts erkennt. 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 Security Command Center Premium-Stufe auf Organisationsebene aktivieren, können Sie auch konfigurieren, dass Ergebnisse in Cloud Logging geschrieben werden.

Ergebnisse prüfen

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

1. Rufen Sie in der Google Cloud Console die Seite Ergebnisse des 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 entsprechenden Filter, um das benötigte Ergebnis in der Tabelle Ergebnisse der Ergebnisabfrage aufzurufen. Wenn Sie beispielsweise im Unterabschnitt Anzeigename der Quelle die Option Event Threat Detection oder Container Threat Detection auswählen, werden in den Ergebnissen nur Ergebnisse des ausgewählten Dienstes 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 maximiert und zeigt eine Zusammenfassung der Ergebnisdetails 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äge 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. Falls verfügbar, enthält das Feld VirusTotal-Indikator einen Link zu VirusTotal, damit Sie potenzielle Sicherheitsprobleme weiter untersuchen können.

  VirusTotal ist ein separat berechnetes Angebot mit anderen Nutzungslimits und Funktionen. Sie sind dafür verantwortlich, die Richtlinien zur API-Nutzung von VirusTotal und alle damit verbundenen Kosten zu verstehen und einzuhalten. Weitere Informationen finden Sie in der VirusTotal-Dokumentation.

In den folgenden Abschnitten werden potenzielle Antworten auf Bedrohungsergebnisse beschrieben.

Deaktivierung von Ergebnissen zu Bedrohungen

Nachdem Sie ein Problem behoben haben, das ein Ergebnis für eine Bedrohung ausgelöst hat, wird der Status des Ergebnisses in Security Command Center nicht automatisch auf INACTIVE festgelegt. Der Status eines Threat-Ergebnisses bleibt ACTIVE, sofern Sie die Property state nicht manuell auf INACTIVE festlegen.

Bei einem falsch-positiven Ergebnis sollten Sie den Status des Ergebnisses auf ACTIVE belassen und das Ergebnis stattdessen stummschalten.

Bei dauerhaften oder wiederkehrenden Falschmeldungen können Sie eine Ausblendungsregel erstellen. Durch das Festlegen einer Stummschaltungsregel können Sie die Anzahl der Ergebnisse reduzieren, die Sie verwalten müssen. So lässt sich eine tatsächliche Bedrohung leichter erkennen.

Wenn es sich um eine tatsächliche Bedrohung handelt, müssen Sie die Bedrohung beseitigen und eine gründliche Untersuchung der erkannten Bedrohung, des Ausmaßes des Eindringens und aller anderen zugehörigen Ergebnisse und Probleme durchführen, bevor Sie den Status des Ergebnisses auf INACTIVE setzen.

Informationen zum Stummschalten eines Ergebnisses oder zum Ändern des 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 für Ergebnisse, die von benutzerdefinierten Modulen für Event Threat Detection generiert wurden, da Ihre Organisation die empfohlenen Maßnahmen für diese Detektoren definiert.

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. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?
   • Betroffene Ressource, insbesondere das folgende Feld:
     • Vollständiger Ressourcenname: 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. Achten Sie in der JSON-Datei auf 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, in der die DNS-Abfrage ausgefü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. Klicken Sie auf den Tab Zusammenfassung in den Ergebnisdetails in der Zeile Ähnliche Ergebnisse auf den Link unter Ähnliche Ergebnisse, um ähnliche Ergebnisse aufzurufen. Ä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 ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 vonGoogle Cloudzur Untersuchung und Reaktion auf die Sicherheitslücke „Apache Log4j 2“.
• 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.

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. Sehen Sie sich im Bereich „Ergebnisdetails“ auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt, insbesondere die folgenden Felder:

     • IP-Adresse des Anrufers: Die IP-Adresse, von der der Angriff gestartet wurde.
     • Nutzername: Das Konto, mit dem sich angemeldet wurde.

   • Betroffene Ressource

   • Zugehörige Links, 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.

4. Achten Sie in der JSON-Datei auf 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: 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 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.
2. Suchen Sie auf der Seite, die geladen wird, mit dem folgenden Filter nach VPC-Flusslogs, die sich auf die IP-Adresse beziehen, die im Tab Zusammenfassung der Ergebnisdetails in der Zeile Haupt-E-Mail-Adresse aufgeführt ist:
   • logName="projects/projectId/logs/syslog"
   • labels."compute.googleapis.com/resource_name"="vmName"

Schritt 4: 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. Klicken Sie auf den Link unter Ähnliche Ergebnisse auf dem Tab Zusammenfassung der Ergebnisdetails, um ähnliche Ergebnisse aufzurufen. Ä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 ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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: CloudDB Failed login from Anonymizing Proxy IP

Erkennt eine fehlgeschlagene Anmeldung in Ihrer Datenbankinstanz über eine bekannte anonymisierende IP-Adresse. Diese Anonymisierungsadressen sind Tor-Knoten. Dies könnte darauf hindeuten, dass ein Angreifer versucht, unbefugt auf Ihre Instanz zuzugreifen.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Credential Access: CloudDB Failed login from Anonymizing Proxy IP-Ergebnis, wie unter Ergebnisse prüfen beschrieben.

2. Sehen Sie sich im Bereich „Ergebnisdetails“ auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
   • Indikator-IP-Adresse: Die anonymisierende IP-Adresse.
   • Anzeigename der Datenbank: Der Name der Datenbank in der betroffenen Cloud SQL PostgreSQL-, MySQL- oder AlloyDB-Instanz.
   • Nutzername der Datenbank: der Nutzer.
   • Vollständiger Projektname: Das Google Cloud Projekt, das die Cloud SQL-Instanz enthält.

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

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

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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, welche Nutzer sich mit der Datenbank verbinden dürfen.

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

• Ändern Sie das Passwort des Nutzers.

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

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

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

• Netzwerkzugriff auf Ihre Instanz prüfen

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

Credential Access: Failed Attempt to Approve Kubernetes Certificate Signing Request (CSR)

Jemand hat versucht, eine Anfrage zur Zertifikatssignierung (Certificate Signing Request, CSR) manuell zu genehmigen, aber die Aktion ist fehlgeschlagen. Das Erstellen eines Zertifikats für die Clusterauthentifizierung ist eine gängige Methode für Angreifer, um dauerhaften Zugriff auf einen kompromittierten Cluster zu erhalten. Die mit dem Zertifikat verknüpften Berechtigungen variieren je nach den darin enthaltenen Themen, können aber sehr umfassend sein. Weitere Informationen finden Sie in der Log-Meldung für diese Benachrichtigung.

1. Überprüfen Sie die Audit-Logs in Cloud Logging und zusätzliche Benachrichtigungen auf andere CSR-bezogene Ereignisse, um festzustellen, ob eine CSR approved und ausgestellt wurde und ob CSR-bezogene Aktionen vom Hauptkonto erwartet werden.
2. Stellen Sie fest, ob die Audit-Logs in Cloud Logging weitere Anzeichen für schädliche Aktivitäten des Hauptkontos enthalten. Beispiel:
   • Hat sich das Hauptkonto, das die CSR genehmigen wollte, vom Hauptkonto unterschieden, das sie erstellt hat?
   • Hat das Hauptkonto versucht, andere CSRs anzufordern, zu erstellen, zu genehmigen oder zu löschen?
3. Wenn eine CSR-Genehmigung nicht erwartet wurde oder als schädlich eingestuft wird, ist für den Cluster eine Rotation von Anmeldedaten erforderlich, um das Zertifikat ungültig zu machen. Lesen Sie die Anleitung zum Rotieren der Clusteranmeldedaten.

Credential Access: Manually Approved Kubernetes Certificate Signing Request (CSR)

Jemand hat eine Anfrage zur Zertifikatssignierung (Certificate Signing Request, CSR) manuell genehmigt. Das Erstellen eines Zertifikats für die Clusterauthentifizierung ist eine gängige Methode für Angreifer, um dauerhaften Zugriff auf einen kompromittierten Cluster zu erhalten. Die mit dem Zertifikat verknüpften Berechtigungen variieren je nach den darin enthaltenen Themen, können aber sehr privilegiert sein. Weitere Informationen finden Sie in der Log-Meldung für diese Benachrichtigung.

1. Überprüfen Sie die Audit-Logs in Cloud Logging und zusätzliche Benachrichtigungen auf andere CSR-bezogene Ereignisse, um festzustellen, ob CSR-bezogene Aktionen vom Hauptkonto erwartet werden.
2. Stellen Sie fest, ob die Audit-Logs in Cloud Logging weitere Anzeichen für schädliche Aktivitäten des Hauptkontos enthalten. Beispiel:
   • Hat sich das Hauptkonto, das die CSR genehmigt hat, vom Hauptkonto unterschieden, das sie erstellt hat?
   • Wurde in der CSR ein integrierter Signer angegeben und musste sie letztendlich doch manuell genehmigt werden, da sie nicht den Kriterien des Signers entsprach?
   • Hat das Hauptkonto versucht, andere CSRs anzufordern, zu erstellen, zu genehmigen oder zu löschen?
3. Wenn eine CSR-Genehmigung nicht erwartet wurde oder als schädlich eingestuft wird, ist für den Cluster eine Rotation von Anmeldedaten erforderlich, um das Zertifikat ungültig zu machen. Lesen Sie die Anleitung zum Rotieren der Clusteranmeldedaten.

Credential Access: Secrets Accessed in Kubernetes Namespace

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

Defense Evasion: Breakglass Workload Deployment Created

Breakglass Workload Deployment Created wird erkannt, indem Cloud-Audit-Logs daraufhin untersucht werden, ob es Bereitstellungen für Arbeitslasten gibt, bei denen das Break-Glass-Flag verwendet wird, um Einstellungen für die Binärautorisierung zu überschreiben.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Defense Evasion: Breakglass Workload Deployment Created-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Bereich mit den Details zum Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: das Konto, von dem die Änderung vorgenommen wurde.
     • Methodenname: Die aufgerufene Methode.
     • Kubernetes-Pods: Der Pod-Name und der Namespace.
   • Betroffene Ressource, insbesondere das folgende Feld:
     • Anzeigename der Ressource: Der GKE-Namespace, in dem die Bereitstellung erfolgt 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 auf dem Tab Zusammenfassung der Details zum Ergebnis in der Google Cloud -Konsole den Log-Explorer auf. Klicken Sie dazu auf den Link im Feld Cloud Logging-URI.
2. Prüfen Sie den Wert im Feld protoPayload.resourceName, um die spezifische Anfrage zur Zertifikatsignierung zu ermitteln.

3. Prüfen Sie mit den folgenden Filtern, ob das Hauptkonto andere Aktionen ausgeführt hat:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Ersetzen Sie Folgendes:

   • CLUSTER_NAME: Der Wert, den Sie in den Funddetails im Feld Resource display name (Anzeigename der Ressource) notiert haben.

   • PRINCIPAL_EMAIL: Der Wert, den Sie in den Details des Ergebnisses im Feld E-Mail-Adresse des Hauptkontos notiert haben.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Defense Evasion: Breakglass Workload Deployment.
2. Klicken Sie auf den Tab Zusammenfassung in den Ergebnisdetails in der Zeile Ähnliche Ergebnisse auf den Link unter Ähnliche Ergebnisse, um ähnliche Ergebnisse aufzurufen.
3. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Defense Evasion: Breakglass Workload Deployment Updated

Breakglass Workload Deployment Updated wird erkannt, indem Cloud-Audit-Logs untersucht werden, um festzustellen, ob es Aktualisierungen von Arbeitslasten gibt, bei denen das Break-Glass-Flag verwendet wird, um Einstellungen für die Binärautorisierung zu überschreiben.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Defense Evasion: Breakglass Workload Deployment Updated-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Bereich mit den Details zum Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: das Konto, von dem die Änderung vorgenommen wurde.
     • Methodenname: Die aufgerufene Methode.
     • Kubernetes-Pods: Der Pod-Name und der Namespace.
   • Betroffene Ressource, insbesondere das folgende Feld:
     • Anzeigename der Ressource: Der GKE-Namespace, in dem das Update 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 auf dem Tab Zusammenfassung der Details zum Ergebnis in der Google Cloud -Konsole den Log-Explorer auf. Klicken Sie dazu auf den Link im Feld Cloud Logging-URI.
2. Prüfen Sie den Wert im Feld protoPayload.resourceName, um die spezifische Anfrage zur Zertifikatsignierung zu ermitteln.

3. Prüfen Sie mit den folgenden Filtern, ob das Hauptkonto andere Aktionen ausgeführt hat:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Ersetzen Sie Folgendes:

   • CLUSTER_NAME: Der Wert, den Sie in den Funddetails im Feld Resource display name (Anzeigename der Ressource) notiert haben.

   • PRINCIPAL_EMAIL: Der Wert, den Sie in den Details des Ergebnisses im Feld E-Mail-Adresse des Hauptkontos notiert haben.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Defense Evasion: Breakglass Workload Deployment.
2. Klicken Sie auf den Tab Zusammenfassung in den Ergebnisdetails in der Zeile Ähnliche Ergebnisse auf den Link unter Ähnliche Ergebnisse, um ähnliche Ergebnisse aufzurufen.
3. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Defense Evasion: GCS Bucket IP Filtering Modified

Event Threat Detection untersucht Audit-Logs, um zu erkennen, ob die IP-Filterkonfiguration für einen Cloud Storage-Bucket aktualisiert wurde.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Defense Evasion: GCS Bucket IP Filtering Modified-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 die Informationen in den folgenden Abschnitten an:
   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Beschreibung: Informationen zur Erkennung
     • Inhaber des Hauptkontos: Ein Nutzer oder Dienstkonto, der bzw. das eine Aktion erfolgreich ausgeführt hat.
   • Betroffene Ressource
     • Anzeigename der Ressource: Der Bucket, in dem die Konfiguration aktualisiert 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 Hauptkonto-Subjekt an den Inhaber des Dienstkontos oder Nutzerkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Defense Evasion: Manually Deleted Certificate Signing Request (CSR)

Eine Anfrage zur Zertifikatssignierung (Certificate Signing Request, CSR) wurde manuell gelöscht. CSRs werden automatisch von einem Garbage Collection-Controller entfernt, aber böswillige Akteure können sie manuell löschen, um einer Erkennung zu entgehen. Wenn die gelöschte CSR für ein genehmigtes und ausgestelltes Zertifikat war, hat der potenziell böswillige Akteur nun eine zusätzliche Authentifizierungsmethode für den Zugriff auf den Cluster. Die mit dem Zertifikat verknüpften Berechtigungen variieren je nach enthaltenem Betreff, können aber sehr umfangreich sein. Kubernetes unterstützt den Zertifikatsperrung nicht. Weitere Informationen finden Sie in der Log-Meldung für diese Benachrichtigung.

1. Überprüfen Sie die Audit-Logs in Cloud Logging und zusätzliche Benachrichtigungen auf weitere Ereignisse im Zusammenhang mit dieser CSR, um festzustellen, ob die CSR approved wurde und ob die CSR-Erstellung eine vom Hauptkonto erwartete Aktivität war.
2. Stellen Sie fest, ob die Audit-Logs in Cloud Logging weitere Anzeichen für schädliche Aktivitäten des Hauptkontos enthalten. Beispiel:
   • Unterscheidet sich das Hauptkonto, das die CSR gelöscht hat, von dem Hauptkonto, das sie erstellt oder genehmigt hat?
   • Hat das Hauptkonto versucht, andere CSRs anzufordern, zu erstellen, zu genehmigen oder zu löschen?
3. Wenn eine CSR-Genehmigung nicht erwartet wurde oder als schädlich eingestuft wird, ist für den Cluster eine Rotation von Anmeldedaten erforderlich, um das Zertifikat ungültig zu machen. Lesen Sie die Anleitung zum Rotieren der Clusteranmeldedaten.

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 einer Reduzierung des Schutzes dieses Perimeters 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 Defense Evasion: Modify VPC Service Control-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Bereich mit den Details zum Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere das folgende Feld:
     • Haupt-E-Mail-Adresse: das Konto, von dem die Änderung vorgenommen wurde.
   • Betroffene Ressource, insbesondere das folgende Feld:
     • Vollständiger Ressourcenname: der Name des geänderten VPC Service Controls-Perimeters.
   • 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. Achten Sie in der JSON-Datei auf 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 „Details zu Ergebnissen“ 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 Änderungen in VPC Service Controls beziehen:
   • 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. Klicken Sie auf den Tab Zusammenfassung in den Ergebnisdetails in der Zeile Ähnliche Ergebnisse auf den Link unter Ähnliche Ergebnisse, um ähnliche Ergebnisse aufzurufen.
3. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 4: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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.

Defense Evasion: Potential Kubernetes Pod Masquerading

Jemand hat einen Pod mit einer Namenskonvention bereitgestellt, die den Standardarbeitslasten ähnelt, die GKE für den regulären Clusterbetrieb erstellt. Diese Technik wird als Masquerading bezeichnet. Weitere Informationen finden Sie in der Log-Meldung für diese Benachrichtigung.

1. Bestätigen Sie, dass der Pod rechtmäßig ist.
2. Stellen Sie fest, ob die Audit-Logs in Cloud Logging weitere Anzeichen für schädliche Aktivitäten des Pods oder Hauptkontos enthalten.
3. Wenn das Hauptkonto kein IAM- oder Kubernetes-Dienstkonto ist, lassen Sie sich vom rechtmäßigen Inhaber des Kontos bestätigen, dass er die Aktion ausgeführt hat.
4. Wenn das Hauptkonto ein IAM- oder Kubernetes-Dienstkonto ist, identifizieren Sie die Quelle der Aktion, um deren Rechtmäßigkeit festzustellen.
5. Wenn der Pod nicht rechtmäßig ist, entfernen Sie ihn zusammen mit allen zugehörigen RBAC-Bindungen und Dienstkonten, die von der Arbeitslast verwendet wurden und die seine Erstellung zugelassen haben.

Defense Evasion: Project HTTP Policy Block Disabled

Event Threat Detection untersucht Audit-Logs, um festzustellen, ob die Richtlinie constraints/storage.secureHttpTransport aktualisiert wurde, um die Blockierung von HTTP-Richtlinien zu deaktivieren.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Defense Evasion: Project HTTP Policy Block Disabled-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 die Informationen in den folgenden Abschnitten an:
   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Beschreibung: Informationen zur Erkennung
     • Inhaber des Hauptkontos: Ein Nutzer oder Dienstkonto, der bzw. das eine Aktion erfolgreich ausgeführt hat.
   • Betroffene Ressource
     • Anzeigename der Ressource: Das Projekt, der Ordner oder die Organisation, in dem/der die Richtlinie aktualisiert 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 Hauptkonto-Subjekt an den Inhaber des Dienstkontos oder Nutzerkontos. Bestätigen Sie, ob der legitime Inhaber die Aktion zum Deaktivieren der Richtlinie „constraints/storage.secureHttpTransport“ ausgeführt hat.

Defensive Evasion: Static Pod Created

Jemand hat einen statischen Pod in Ihrem GKE-Cluster erstellt. Statische Pods werden direkt auf dem Knoten ausgeführt und umgehen den Kubernetes API-Server. Daher sind sie schwieriger zu überwachen und zu steuern. Dies könnte von Angreifern verwendet werden, um die Erkennung zu umgehen oder die Persistenz aufrechtzuerhalten.

1. Sehen Sie sich die Manifestdatei des statischen Pods und ihren Zweck an. Prüfen Sie, ob die Anfrage legitim und notwendig ist.
2. Prüfen Sie, ob die Funktionalität des statischen Pods durch einen regulären Pod erreicht werden kann, der vom Kubernetes API-Server verwaltet wird.
3. Wenn der statische Pod erforderlich ist, muss er den Best Practices für die Sicherheit entsprechen und nur minimale Berechtigungen haben.
4. Aktivität des statischen Pods und seine Auswirkungen auf Ihren Cluster überwachen

Discovery: Can get sensitive Kubernetes object check

Ein potenziell böswilliger Akteur hat mithilfe des Befehls kubectl auth can-i get ermittelt, welche vertraulichen Objekte in GKE abgefragt werden können. Konkret hat der Akteur einen der folgenden Befehle ausgeführt:

• 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:

   • Unter Was wurde erkannt?:
     • Kubernetes-Zugriffsüberprüfungen: Die angeforderten Informationen zur Zugriffsüberprüfung basierend auf der SelfSubjectAccessReview-Kubernetes-Ressource.
     • Hauptkonto-E-Mail-Adresse: Das Konto, mit dem der Anruf getätigt wurde.
   • Unter Betroffene Ressource:
     • Anzeigename der Ressource: Der Kubernetes-Cluster, in dem die Aktion ausgeführt wurde.
   • Unter Weitere Informationen:
     • Cloud Logging-URI: Link zu Logging-Einträgen.

Schritt 2: Protokolle prüfen

1. Klicken Sie im Bereich „Details zu Ergebnissen“ 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, mit den folgenden Filtern, ob das Hauptkonto weitere Aktionen ausgeführt hat:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Ersetzen Sie Folgendes:

   • CLUSTER_NAME: Der Wert, den Sie in den Funddetails im Feld Resource display name (Anzeigename der Ressource) notiert haben.

   • PRINCIPAL_EMAIL: Der Wert, den Sie in den Details des Ergebnisses im Feld E-Mail-Adresse des Hauptkontos notiert haben.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

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

3. Wenn das Konto, das Sie in der Zeile E‑Mail-Adresse des Hauptkontos der Ergebnisdetails gefunden haben, kein Dienstkonto ist, wenden Sie sich an den Inhaber, um herauszufinden, ob der rechtmäßige Kontoinhaber die Aktion ausgeführt hat.

   Wenn die E‑Mail-Adresse des Hauptkontos ein Dienstkonto ist (IAM oder Kubernetes), identifizieren Sie die Quelle der Zugriffsüberprüfung, um deren Rechtmäßigkeit zu ermitteln.

4. Wenn Sie einen Reaktionsplan entwickeln möchten, kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung.

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 einer IP-Adresse stammen, die mit dem Tor-Netzwerk verknüpft ist.

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 mit den Details zum Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich im Bereich „Ergebnisdetails“ auf dem Tab Zusammenfassung die aufgeführten Werte in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Hauptkonto-E-Mail-Adresse: Das Konto, das die Änderungen vorgenommen hat (ein potenziell gehacktes 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. Optional: Klicken Sie auf den Tab JSON, um zusätzliche Ergebnis-Felder aufzurufen.

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.

Execution: Cryptomining Docker Image

Erkennt, wenn ein Cloud Run-Dienst oder -Job erstellt oder überarbeitet wird, indem ein bekanntes schädliches Docker-Image hinzugefügt wird, das für das Kryptomining verwendet werden kann.

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

1. Prüfen Sie das Container-Image, um festzustellen, ob dies erwartet wurde.
2. Löschen Sie den manipulierten Container und ersetzen Sie ihn durch einen neuen Container.

Execution: GKE launch excessively capable container

Jemand hat einen Container mit einer oder mehreren der folgenden Funktionen in einem GKE-Cluster mit einem erhöhten Sicherheitskontext bereitgestellt:

• CAP_SYS_MODULE
• CAP_SYS_RAWIO
• CAP_SYS_PTRACE
• CAP_SYS_BOOT
• CAP_DAC_READ_SEARCH
• CAP_NET_ADMIN
• CAP_BPF

Diese Funktionen wurden bereits verwendet, um aus Containern auszubrechen, und sollten daher mit Vorsicht bereitgestellt werden.

1. Sehen Sie sich den Sicherheitskontext des Containers in der Pod-Definition an. Ermitteln Sie alle Funktionen, die für die Funktion nicht unbedingt erforderlich sind.
2. Entfernen oder reduzieren Sie übermäßige Berechtigungen, wann immer möglich. Prinzip der geringsten Berechtigung anwenden

Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments

Jemand hat einen Pod erstellt, der Befehle oder Argumente enthält, die häufig mit einer Reverse Shell in Verbindung gebracht werden. Angreifer verwenden Reverse Shells, um ihren anfänglichen Zugriff auf einen Cluster zu erweitern oder aufrechtzuerhalten und beliebige Befehle auszuführen. Weitere Informationen finden Sie in der Log-Meldung für diese Benachrichtigung.

1. Bestätigen Sie, dass der Pod einen rechtmäßigen Grund hat, diese Befehle und Argumente anzugeben.
2. Stellen Sie fest, ob die Audit-Logs in Cloud Logging weitere Anzeichen für schädliche Aktivitäten des Pods oder Hauptkontos enthalten.
3. Wenn das Hauptkonto kein IAM- oder Kubernetes-Dienstkonto ist, lassen Sie sich vom rechtmäßigen Inhaber des Kontos bestätigen, dass er die Aktion ausgeführt hat.
4. Wenn das Hauptkonto ein IAM- oder Kubernetes-Dienstkonto ist, stellen Sie fest, ob der Grund für die Ausführung dieser Aktion durch das Dienstkonto rechtmäßig ist.
5. Wenn der Pod nicht rechtmäßig ist, entfernen Sie ihn zusammen mit allen zugehörigen RBAC-Bindungen und Dienstkonten, die von der Arbeitslast verwendet wurden und die seine Erstellung zugelassen haben.

Execution: Suspicious Exec or Attach to a System Pod

Jemand hat die Befehle exec oder attach verwendet, um eine Shell zu erhalten oder einen Befehl in einem Container auszuführen, der im Namespace kube-system ausgeführt wird. Diese Methoden werden manchmal für legitime Debugging-Zwecke verwendet. kube-system namespace ist jedoch für Systemobjekte vorgesehen, die von Kubernetes erstellt wurden. Unerwartete Befehlsausführung oder Shell-Erstellung sollten überprüft werden. Weitere Informationen finden Sie in der Log-Meldung für diese Benachrichtigung.

1. Überprüfen Sie die Audit-Logs in Cloud Logging, um festzustellen, ob dies eine vom Hauptkonto erwartete Aktivität war.
2. Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten des Hauptkontos in den Logs gibt.

Lesen Sie die Anleitung zum Verwenden des Prinzips der geringsten Berechtigung für die RBAC-Rollen und Clusterrollen, die diesen Zugriff zugelassen haben.

Execution: Workload triggered in sensitive namespace

Jemand hat eine Arbeitslast (z. B. einen Pod oder ein Deployment) in den Namespaces kube-system oder kube-public bereitgestellt. Diese Namespaces sind für den Betrieb von GKE-Cluster von entscheidender Bedeutung. Unautorisierte Arbeitslasten können die Stabilität oder Sicherheit des Clusters beeinträchtigen.

1. Ermitteln Sie die bereitgestellte Arbeitslast und ihren Zweck.
2. Wenn die Arbeitslast nicht autorisiert ist, löschen Sie sie und untersuchen Sie die Quelle der Bereitstellung.

Exfiltration: BigQuery Data Exfiltration

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

• Unterregel exfil_to_external_table mit Schweregrad = HIGH:
  • Eine Ressource wurde außerhalb Ihrer Organisation oder Ihres Projekts gespeichert.
• Unterregel 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 Exfiltration: BigQuery Data Exfiltration-Ergebnis, wie unter Ergebnisse prüfen beschrieben.

2. Sehen Sie sich im Detailbereich des Ergebnisses auf dem Tab Zusammenfassung die aufgeführten Werte in den folgenden Abschnitten an:

   • Was wurde erkannt?:
     • Schweregrad: Der Schweregrad ist entweder HIGH für die Unterregel exfil_to_external_table oder LOW für die Unterregel vpc_perimeter_violation.
     • Haupt-E-Mail-Adresse: Das Konto, das zum Exfiltrieren der Daten verwendet wird.
     • Exfiltrationsquellen: Details zu den Tabellen, aus denen Daten exfiltriert wurden.
     • Exfiltrationsziele: Details zu den Tabellen, in denen exfiltrierte Daten gespeichert wurden.
   • Betroffene Ressource:
     • Vollständiger Ressourcenname: Der vollständige Ressourcenname des Projekts, Ordners oder der Organisation, aus dem Daten exfiltriert 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.

3. Klicken Sie auf den Tab Quellattribute und sehen Sie sich die angezeigten Felder an, insbesondere:

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

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

Schritt 2: Berechtigungen und Einstellungen prüfen

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

   IAM aufrufen

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

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

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich „Details zu Ergebnissen“ 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. Klicken Sie auf den Tab Zusammenfassung in den Ergebnisdetails in der Zeile Ähnliche Ergebnisse auf den Link unter Ähnliche Ergebnisse, um ähnliche Ergebnisse aufzurufen. Ä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 ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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).
• Verwenden Sie Sensitive Data Protection, um betroffene Datasets auf vertrauliche Informationen zu scannen. Sie können auch Daten zum Schutz sensibler Daten an Security Command Center senden. Je nach Menge der Informationen können die Kosten für Sensitive Data Protection erheblich sein. Halten Sie sich an Best Practices, um die Kosten für den Schutz sensibler Daten zu kontrollieren.
• 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 der Aktivierung der Security Command Center Premium-Stufe auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standard-Stufe 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 geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich im Detailbereich des Ergebnisses auf dem Tab Zusammenfassung die aufgeführten Werte in den folgenden Abschnitten an:

   • Was wurde erkannt?:
     • Haupt-E-Mail-Adresse: Das Konto, das zum Exfiltrieren der Daten verwendet wird.
     • Exfiltrationsquellen: Details zu den Tabellen, aus denen Daten exfiltriert wurden.
     • Exfiltrationsziele: Details zu den Tabellen, in denen exfiltrierte Daten gespeichert wurden.
   • Betroffene Ressource:
     • Vollständiger Ressourcenname: Der Name der BigQuery-Ressource, deren Daten exfiltriert wurden.
     • Vollständiger Projektname: Das Google Cloud Projekt, das das BigQuery-Quelldataset 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. Achten Sie in der JSON-Datei auf die folgenden Felder.

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

Schritt 2: Berechtigungen und Einstellungen prüfen

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

   IAM aufrufen

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

3. Geben Sie auf der angezeigten Seite im Feld Filter die E-Mail-Adresse ein, die in Principal email (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 „Details zu Ergebnissen“ 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. Klicken Sie auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Ähnliche Ergebnisse auf den Link, um ähnliche Ergebnisse aufzurufen. Ä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 ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 das Hauptkonto zu widerrufen, das in der Zeile Haupt-E-Mail-Adresse auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist, bis die Untersuchung abgeschlossen ist.
• Wenn Sie die weitere Exfiltration verhindern möchten, fügen Sie den betroffenen BigQuery-Datasets restriktive IAM-Richtlinien hinzu, die auf dem Tab Zusammenfassung der Detailansicht des Findings im Feld Exfiltrationsquellen angegeben sind.
• Verwenden Sie Sensitive Data Protection, um betroffene Datasets auf vertrauliche Informationen zu scannen. Sie können auch Daten zum Schutz sensibler Daten an Security Command Center senden. Je nach Menge der Informationen können die Kosten für Sensitive Data Protection erheblich sein. Halten Sie sich an Best Practices, um die Kosten für den Schutz sensibler Daten zu kontrollieren.
• 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. Sehen Sie sich im Bereich „Ergebnisdetails“ auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?
     • Haupt-E-Mail-Adresse: Das Konto, das zum Exfiltrieren der Daten verwendet wird.
     • Exfiltrationsquellen: Details zur BigQuery-Tabelle, aus der Daten exfiltriert wurden.
     • Exfiltrationsziele: Details zum Ziel in Google Drive.
   • Betroffene Ressource, einschließlich:
     • Vollständiger Ressourcenname: Der Name der BigQuery-Ressource, deren Daten exfiltriert wurden.
     • Vollständiger Projektname: Das Google Cloud Projekt, das das BigQuery-Quelldataset 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, um weitere Informationen zu erhalten.

4. Achten Sie in der JSON-Datei auf die folgenden Felder.

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

Schritt 2: Berechtigungen und Einstellungen prüfen

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

   IAM aufrufen

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

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 „Details zu Ergebnissen“ 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. Klicken Sie auf den Tab Zusammenfassung in den Ergebnisdetails in der Zeile Ähnliche Ergebnisse auf den Link unter Ähnliche Ergebnisse, um ähnliche Ergebnisse aufzurufen. Ä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 ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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).
• Verwenden Sie Sensitive Data Protection, um betroffene Datasets auf vertrauliche Informationen zu scannen. Sie können auch Daten zum Schutz sensibler Daten an Security Command Center senden. Je nach Menge der Informationen können die Kosten für Sensitive Data Protection erheblich sein. Halten Sie sich an Best Practices, um die Kosten für den Schutz sensibler Daten zu kontrollieren.
• 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 der Aktivierung der Security Command Center Premium-Stufe auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standard-Stufe 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 angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse : Das Konto, das zum Exfiltrieren der Daten verwendet wird.
     • Exfiltrationsquellen: Details zur Cloud SQL-Instanz, deren Daten exfiltriert wurden.
     • Exfiltrationsziele: Details zum Cloud Storage-Bucket, in den die Daten exportiert wurden.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Ressourcenname: der Ressourcenname der Cloud SQL-Instanz, deren Daten exfiltriert wurden.
     • Vollständiger Projektname: 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 im JSON-Code 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: der Umfang der exportierten Daten, 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. Rufen Sie in der Google Cloud Console die Seite IAM auf.

   IAM aufrufen

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

3. Geben Sie auf der angezeigten Seite im Feld Filter die E-Mail-Adresse ein, die in den Ergebnisdetails auf dem Tab Zusammenfassung in der Zeile Haupt-E-Mail-Adresse 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, 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. Prüfen Sie die ähnlichen Ergebnisse. Klicken Sie dazu auf den Link in der Zeile Ähnliche Ergebnisse, die in Schritt 1 beschrieben wurde. Ä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 ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Over-Privileged Grant

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

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

Schritt 1: Ergebnisdetails prüfen

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

2. Sehen Sie sich im Bereich „Ergebnisdetails“ auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Anzeigename der Datenbank: Der Name der Datenbank in der betroffenen Cloud SQL for PostgreSQL-Instanz.
     • Datenbanknutzername: Der PostgreSQL-Nutzer, der übermäßige Berechtigungen gewährt hat.
     • Datenbankabfrage: Die ausgeführte PostgreSQL-Abfrage, mit der die Berechtigungen erteilt wurden.
     • Empfänger von Datenbanken: Die Empfänger der zu weit gefassten Berechtigungen.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Ressourcenname: Der Ressourcenname der betroffenen Cloud SQL for PostgreSQL-Instanz.
     • Vollständiger Name des übergeordneten Elements: Der Ressourcenname der Cloud SQL for PostgreSQL-Instanz.
     • Vollständiger Projektname: das Google Cloud Projekt, das die Cloud SQL 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.
     • Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.

3. Klicken Sie auf den Tab JSON, um das vollständige JSON für das Ergebnis aufzurufen.

Schritt 2: Datenbankberechtigungen prüfen

1. Verbindung zur PostgreSQL-Datenbank herstellen
2. Zugriffsberechtigungen auflisten und anzeigen für Folgendes:
   • Datenbanken. Verwenden Sie den Metacommand \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 Prozeduren. Verwenden Sie den Metacommand \df und prüfen Sie, welche Berechtigungen für Funktionen oder Prozeduren in der Datenbank zugewiesen sind, die in 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 im 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 MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Exfiltration Over Web Service.
2. Um festzustellen, ob zusätzliche Schritte zur Abhilfe erforderlich sind, kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung.

Schritt 5: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 überprivilegierten Berechtigungen.
• Ziehen Sie in Betracht, alle Berechtigungen für die Empfänger, die unter Datenbankempfänger aufgeführt sind, zu widerrufen, bis die Untersuchung abgeschlossen ist.
• Um den Zugriff auf die Datenbank einzuschränken (Database display name aus Schritt 1), entziehen Sie den Berechtigten (Database grantees aus Schritt 1) unnötige Berechtigungen.

Exfiltration: Cloud SQL Restore Backup to External Organization

Die Daten-Exfiltration aus einer Cloud SQL-Sicherung wird durch Prüfen der Audit-Logs erkannt, wobei festgestellt wird, 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. Sehen Sie sich im Bereich „Ergebnisdetails“ auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: Das Konto, das zum Exfiltrieren der Daten verwendet wird.
     • 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 Ressourcenname: Der Ressourcenname der wiederhergestellten Sicherung.
     • Vollständiger Projektname: Das Google Cloud Projekt, das die Cloud SQL-Instanz enthält, aus der die Sicherung erstellt wurde.

3. Zugehörige Links, 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. Achten Sie in der JSON-Datei auf 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-Quelldataset enthält.
   • properties:
     • restoreToExternalInstance:
       • backupId: die ID des wiederhergestellten Sicherungslaufs

Schritt 2: Berechtigungen und Einstellungen prüfen

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

   IAM aufrufen

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

3. Geben Sie auf der angezeigten Seite im Feld Filter die E-Mail-Adresse ein, die in E-Mail-Adresse des Hauptkontos (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 im 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. Klicken Sie in der Zeile Ähnliche Ergebnisse auf den Link, um ähnliche Ergebnisse aufzurufen. (aus 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 ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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, das in der Zeile Haupt-E-Mail-Adresse auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist, Berechtigungen 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 mithilfe von VPC Service Controls.
• Um IAM-Rollen mit zu vielen Berechtigungen zu identifizieren und zu beheben, verwenden Sie IAM Recommender.

Impact: Cryptomining Commands

Erkennt, wenn bekannte Cryptomining-Befehle als Einstiegspunkte an Cloud Run-Jobs übergeben werden, die bei der Ausführung des Jobs ausgeführt werden.

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

1. Prüfen Sie den Job, den Befehl und den Container, um festzustellen, ob dies erwartet wurde.
2. Löschen Sie den manipulierten Job und Container.

Impact: Deleted Google Cloud Backup and DR Backup

Event Threat Detection untersucht Audit-Logs, um festzustellen, ob eine in einem Backup-Vault gespeicherte Sicherung gelöscht wurde.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Impact: Deleted Google Cloud Backup and DR Backup-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 die Informationen in den folgenden Abschnitten an:
   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Beschreibung: Informationen zur Erkennung.
     • Inhaber des Hauptkontos: Ein Nutzer oder Dienstkonto, das eine Aktion erfolgreich 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 an den Inhaber des Dienstkontos im Feld Hauptkonto-Betreff und fragen Sie nach, ob er die Aktion ausgeführt hat.

Impact: Deleted Google Cloud Backup and DR host

Event Threat Detection untersucht Audit-Logs, um das Löschen von Hosts zu erkennen, auf denen Anwendungen ausgeführt werden, die durch den Backup and DR Service geschützt sind. Nachdem ein Host gelöscht wurde, können mit ihm 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 Impact: Deleted Google Cloud Backup and DR host-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.
2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Anwendungsname: Der Name einer Datenbank oder VM, die mit Backup and DR verbunden ist.
     • Hostname: Der Name eines Hosts, der mit Backup and DR verbunden ist.
     • Hauptsubjekt: 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 ATTACK-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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung sammeln, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

1. Rufen Sie im Projekt, in dem die Maßnahme ergriffen wurde, die Verwaltungskonsole auf.
2. Prüfen Sie, ob der gelöschte Host nicht mehr in der Liste der Backup & DR-Hosts enthalten ist.
3. Wählen Sie die Option Host hinzufügen aus, um den gelöschten Host wieder hinzuzufügen.

Impact: Deleted Google Cloud Backup and DR plan association

Event Threat Detection untersucht Audit-Logs, um festzustellen, ob eine Planzuordnung gelöscht wurde.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Impact: Deleted Google Cloud Backup and DR plan association-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 die Informationen in den folgenden Abschnitten an:
   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Beschreibung: Informationen zur Erkennung.
     • Inhaber des Hauptkontos: Ein Nutzer oder Dienstkonto, das eine Aktion erfolgreich 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 an den Inhaber des Dienstkontos im Feld Hauptkonto-Betreff und fragen Sie nach, ob er die Aktion ausgeführt hat.

Impact: Deleted Google Cloud Backup and DR Vault

Event Threat Detection untersucht Audit-Logs, um festzustellen, ob der Sicherungstresor gelöscht wurde.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Impact: Google Cloud Backup and DR reduced backup frequency-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 die Informationen in den folgenden Abschnitten an:
   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Beschreibung: Informationen zur Erkennung.
     • Inhaber des Hauptkontos: Ein Nutzer oder Dienstkonto, das eine Aktion erfolgreich 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 Hauptkonto-Betreff an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Impact: GKE kube-dns modification detected

Jemand hat die kube-dns-Konfiguration in Ihrem GKE-Cluster geändert. kube-dns in GKE ist eine kritische Komponente des Netzwerks Ihres Clusters. Eine falsche Konfiguration kann zu einem Sicherheitsrisiko führen.

1. Prüfen Sie die kube-dns-Konfiguration des Clusters auf verdächtige Änderungen.

Impact: Google Cloud Backup and DR delete policy

Audit-Logs werden geprüft, um das Löschen einer Richtlinie zu erkennen. Eine Richtlinie definiert, wie eine Sicherung erstellt und wo sie gespeichert wird.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Impact: Google Cloud Backup and DR delete policy-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.
2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Richtlinienname: Der Name einer einzelnen Richtlinie, in der die Sicherungshäufigkeit, der Zeitplan und die Aufbewahrungsdauer definiert werden.
     • Hauptsubjekt: ein Nutzer, der eine Aktion erfolgreich ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: Das Projekt, in dem die Richtlinie gelöscht wurde
   • Verknüpfte Links, insbesondere die folgenden Felder:
     • MITRE ATTACK-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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung sammeln, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln. 1. Rufen Sie im Projekt, in dem die Maßnahme ergriffen wurde, die Verwaltungskonsole auf. 2. Wählen Sie auf dem Tab App Manager (App-Verwaltung) die betreffende Anwendung aus und prüfen Sie die für diese Anwendung angewendeten Policy-Einstellungen (Richtlinie).

Impact: Google Cloud Backup and DR delete profile

Audit-Logs werden untersucht, um das Löschen eines Profils zu erkennen. In einem Profil wird festgelegt, welche Speicherpools zum Speichern von Sicherungen verwendet werden.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Impact: Google Cloud Backup and DR delete profile-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.
2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Profilname: Gibt das Speicherziel für Sicherungen von Anwendungs- und VM-Daten an.
     • Hauptsubjekt: ein Nutzer, der eine Aktion erfolgreich ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: Das Projekt, in dem das Profil gelöscht wurde
   • Verknüpfte Links, insbesondere die folgenden Felder:
     • MITRE ATTACK-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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung sammeln, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln. 1. Rufen Sie im Projekt, in dem die Maßnahme ergriffen wurde, die Verwaltungskonsole auf. 2. Wählen Sie auf dem Tab Sicherungspläne die Option Profile aus, um eine Liste aller Profile aufzurufen. 3. Prüfen Sie die Profile, um sicherzustellen, dass alle erforderlichen Profile vorhanden sind. 4. Wenn das gelöschte Profil versehentlich entfernt wurde, wählen Sie Profil erstellen aus, um Speicherziele für Ihre Backup & DR-Appliances zu definieren.

Impact: Google Cloud Backup and DR delete template

Security Command Center untersucht Audit-Logs, um das anomale Löschen einer Vorlage zu erkennen. Eine Vorlage ist eine Basiskonfiguration für Sicherungen, die auf mehrere Anwendungen angewendet werden kann.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Impact: Google Cloud Backup and DR delete template-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.
2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Vorlagenname: Der Name für eine Reihe von Richtlinien, die die Sicherungshäufigkeit, den Zeitplan und die Aufbewahrungsdauer definieren.
     • Hauptsubjekt: ein Nutzer, der eine Aktion erfolgreich ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: Das Projekt, in dem die Vorlage gelöscht wurde.
   • Verknüpfte Links, insbesondere die folgenden Felder:
     • MITRE ATTACK-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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung sammeln, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

1. Rufen Sie im Projekt, in dem die Maßnahme ergriffen wurde, die Verwaltungskonsole auf.
2. Suchen Sie auf dem Tab App Manager (App-Verwaltung) 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, rufen Sie den Tab Sicherungspläne auf, wählen Sie Vorlagen aus und klicken Sie dann auf Vorlage erstellen.

Impact: 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 Backup and DR.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Impact: Google Cloud Backup and DR delete storage pool-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.
2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Name des Speicherpools: Der Name für Speicher-Buckets, in denen Sicherungen gespeichert werden.
     • Hauptsubjekt: ein Nutzer, der eine Aktion erfolgreich ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: Das Projekt, in dem der Speicherpool gelöscht wurde
   • Verknüpfte Links, insbesondere die folgenden Felder:
     • MITRE ATTACK-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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung sammeln, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln. 1. Rufen Sie im Projekt, in dem die Maßnahme ergriffen 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 Zuordnungen von Speicherpools zu Backup-Appliances. 4. Wenn einer aktiven Appliance kein Speicherpool zugeordnet ist, wählen Sie OnVault-Pool hinzufügen aus, um ihn wieder hinzuzufügen.

Impact: Google Cloud Backup and DR expire all images

Ein potenziell böswilliger Akteur hat das Löschen aller Sicherungsbilder angefordert, die mit einer Anwendung verknüpft sind.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Impact: Google Cloud Backup and DR expire all images-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.
2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Richtlinienname: Der Name einer einzelnen Richtlinie, die die Sicherungshäufigkeit, den Zeitplan und die Aufbewahrungsdauer definiert.
     • Vorlagenname: Der Name für eine Reihe von Richtlinien, die die Sicherungshäufigkeit, den Zeitplan und die Aufbewahrungsdauer definieren.
     • Profilname: Gibt das Speicherziel für Sicherungen von Anwendungs- und VM-Daten an.
     • Hauptsubjekt: ein Nutzer, der eine Aktion erfolgreich ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: Das Projekt, in dem die Sicherungsbilder gelöscht wurden
   • Verknüpfte Links, insbesondere die folgenden Felder:
     • MITRE ATTACK-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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung sammeln, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln. 1. Rufen Sie im Projekt, in dem die Maßnahme ergriffen wurde, die Verwaltungskonsole auf. 2. Rufen Sie den Tab „Monitor“ auf und wählen Sie „Jobs“ aus, um den Status des Löschjobs für Back-ups zu prüfen. 3. Wenn ein Löschvorgang nicht autorisiert ist, rufen Sie die IAM-Berechtigungen auf, um Nutzer mit Zugriff auf Sicherungsdaten zu prüfen.

Impact: Google Cloud Backup and DR expire image

Ein potentiell böswilliger Nutzer hat die Löschung eines Sicherungsbilds beantragt.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Inhibit System Recovery: Google Cloud Backup and DR expire image-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.
2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Richtlinienname: Der Name einer einzelnen Richtlinie, die die Sicherungshäufigkeit, den Zeitplan und die Aufbewahrungsdauer definiert.
     • Vorlagenname: Der Name für eine Reihe von Richtlinien, die die Sicherungshäufigkeit, den Zeitplan und die Aufbewahrungsdauer definieren.
     • Profilname: Gibt das Speicherziel für Sicherungen von Anwendungs- und VM-Daten an.
     • Hauptsubjekt: ein Nutzer, der eine Aktion erfolgreich ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: Das Projekt, in dem das Sicherungsbild gelöscht wurde
   • Verknüpfte Links, insbesondere die folgenden Felder:
     • MITRE ATTACK-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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung sammeln, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln. 1. Rufen Sie im Projekt, in dem die Maßnahme ergriffen wurde, die Verwaltungskonsole auf. 2. Rufen Sie den Tab „Monitor“ auf und wählen Sie „Jobs“ aus, um den Status des Löschjobs für Back-ups zu prüfen. 3. Wenn ein Löschvorgang nicht autorisiert ist, rufen Sie die IAM-Berechtigungen auf, um Nutzer mit Zugriff auf Sicherungsdaten zu prüfen.

Impact: Google Cloud Backup and DR reduced backup expiration

Event Threat Detection untersucht Audit-Logs, um festzustellen, ob das Ablaufdatum für eine Sicherung auf einer Backup and DR Service-Appliance verkürzt wurde.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Impact: Google Cloud Backup and DR reduced backup expiration-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 die Informationen in den folgenden Abschnitten an:
   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Beschreibung: Informationen zur Erkennung
     • Inhaber des Hauptkontos: Ein Nutzer oder Dienstkonto, der bzw. das eine Aktion erfolgreich ausgeführt hat.
   • Betroffene Ressource
     • Anzeigename der Ressource: Das Projekt, in dem die Ablaufzeit des Back-ups 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 Hauptkonto-Betreff an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung sammeln, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

1. Rufen Sie im Projekt, in dem die Maßnahme ergriffen wurde, die Verwaltungskonsole auf.
2. Suchen Sie auf dem Tab App Manager nach der betroffenen Anwendung, für die die Sicherung abgelaufen ist, und prüfen Sie, ob das Ablaufdatum vom Hauptkonto festgelegt wurde.
3. Wenn Sie eine neue Sicherung der Anwendung starten möchten, 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 untersucht Audit-Logs, um festzustellen, ob der Sicherungsplan so geändert wurde, dass die Sicherungshäufigkeit reduziert wird.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Impact: Google Cloud Backup and DR reduced backup frequency-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 die Informationen in den folgenden Abschnitten an:
   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Beschreibung: Informationen zur Erkennung
     • Inhaber des Hauptkontos: Ein Nutzer oder Dienstkonto, der bzw. das eine Aktion erfolgreich 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 Hauptkonto-Betreff an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung sammeln, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

1. Rufen Sie im Projekt, in dem die Maßnahme ergriffen wurde, die Verwaltungskonsole auf.
2. Suchen Sie auf dem Tab App Manager (App-Verwaltung) nach der betroffenen Anwendung, für die die Sicherungshäufigkeit reduziert wurde, und prüfen Sie, ob die Änderung vom Hauptkonto beabsichtigt war.
3. Wenn Sie eine neue Sicherung der Anwendung starten möchten, 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 remove appliance

Audit-Logs werden geprüft, um das Entfernen eines Geräts für Sicherung und Wiederherstellung zu erkennen. Eine Sicherungs- und Wiederherstellungs-Appliance ist eine wichtige Komponente für Sicherungsvorgänge.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Inhibit System Recovery: Google Cloud Backup and DR remove appliance-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.
2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Appliance-Name: Der Name einer Datenbank oder VM, die mit Backup and DR verbunden ist.
     • Hauptsubjekt: ein Nutzer, der eine Aktion erfolgreich ausgeführt hat
   • Betroffene Ressource
     • Anzeigename der Ressource: Das Projekt, in dem das Gerät gelöscht wurde
   • Verknüpfte Links, insbesondere die folgenden Felder:
     • MITRE ATTACK-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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung sammeln, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln. 1. Rufen Sie im Projekt, in dem die Maßnahme ergriffen wurde, die Verwaltungskonsole auf. 2. Suchen Sie auf dem Tab App Manager (App-Verwaltung) 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 den Schutz auf nicht geschützte Apps anwenden möchten, rufen Sie Backup and DR in der Google Cloud -Konsole auf und wählen Sie die Option „Weitere Sicherungs- oder Wiederherstellungs-Appliance bereitstellen“ aus. 4. Konfigurieren Sie im Menü Storage (Speicher) für jedes neue Gerät ein Speicherziel. Nachdem Sie eine Appliance konfiguriert haben, wird sie als Option angezeigt, wenn Sie ein Profil für Ihre Anwendungen erstellen.

Impact: Google Cloud Backup and DR remove plan

Security Command Center untersucht Audit-Logs, um das anomale Löschen eines Backup- und DR-Dienst-Sicherungsplans zu erkennen, der zum Anwenden von Sicherungsrichtlinien auf eine Anwendung verwendet wird.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Impact: Google Cloud Backup and DR remove plan-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.
2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Anwendungsname: Der Name einer Datenbank oder VM, die mit Backup and DR verbunden ist.
     • Profilname: Gibt das Speicherziel für Sicherungen von Anwendungs- und VM-Daten an.
     • Vorlagenname: Der Name für eine Reihe von Richtlinien, die die Sicherungshäufigkeit, den Zeitplan und die Aufbewahrungsdauer definieren.
   • Betroffene Ressource
     • Anzeigename der Ressource: Das Projekt, in dem der Plan gelöscht wurde.
   • Verknüpfte Links, insbesondere die folgenden Felder:
     • MITRE ATTACK-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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung sammeln, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

1. Rufen Sie im Projekt, in dem die Maßnahme ergriffen wurde, die Verwaltungskonsole auf.
2. Suchen Sie auf dem Tab App Manager (App-Verwaltung) nach den betroffenen Anwendungen, die nicht mehr geschützt sind, und prüfen Sie die Sicherungsrichtlinien für jede Anwendung.

Impact: Suspicious Kubernetes Container Names - Cryptocurrency Mining

Jemand hat einen Pod mit einer Namenskonvention bereitgestellt, die der von gängigen Kryptowährungs-Coinminern ähnelt. Dies kann ein Versuch eines Angreifers sein, der sich bereits Zugriff auf den Cluster verschafft hat, die Ressourcen des Clusters für das Mining von Kryptowährungen zu nutzen. Weitere Informationen finden Sie in der Log-Meldung für diese Benachrichtigung.

1. Bestätigen Sie, dass der Pod rechtmäßig ist.
2. Stellen Sie fest, ob die Audit-Logs in Cloud Logging weitere Anzeichen für schädliche Aktivitäten des Pods oder Hauptkontos enthalten.
3. Wenn das Hauptkonto kein IAM- oder Kubernetes-Dienstkonto ist, lassen Sie sich vom rechtmäßigen Inhaber des Kontos bestätigen, dass er die Aktion ausgeführt hat.
4. Wenn das Hauptkonto ein IAM- oder Kubernetes-Dienstkonto ist, identifizieren Sie die Quelle der Aktion, um deren Rechtmäßigkeit festzustellen.
5. Wenn der Pod nicht rechtmäßig ist, entfernen Sie ihn zusammen mit allen zugehörigen RBAC-Bindungen und Dienstkonten, die von der Arbeitslast verwendet wurden und die seine Erstellung zugelassen haben.

Initial Access: Anonymous GKE resource created from the internet

Erkennt, wenn ein potenziell böswilliger Akteur einen der folgenden Kubernetes-Standardnutzer oder eine der folgenden Kubernetes-Standardnutzergruppen verwendet hat, um eine neue Kubernetes-Ressource im Cluster zu erstellen:

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

Diese Nutzer und Gruppen sind effektiv anonym. Eine RBAC-Bindung (Role-based Access Control, rollenbasierte Zugriffssteuerung) 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 Log-Meldung für diesen Befund.

Informationen dazu, wie Sie dieses Problem beheben können, finden Sie unter Standardrollen und -gruppen vermeiden.

Initial Access: CloudDB Successful login from Anonymizing Proxy IP

Erkennt eine erfolgreiche Anmeldung in Ihrer Datenbankinstanz über eine bekannte IP-Adresse des Anonymisierungs-Proxys. Diese Anonymisierungsadressen sind Tor-Knoten. Dies könnte darauf hindeuten, dass ein Angreifer sich zum ersten Mal Zugriff auf Ihre Instanz verschafft hat.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Initial Access: CloudDB Successful login from Anonymizing Proxy IP-Ergebnis, wie unter Ergebnisse prüfen beschrieben.

2. Sehen Sie sich im Bereich „Ergebnisdetails“ auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
   • Indikator-IP-Adresse: Die anonymisierende IP-Adresse.
   • Anzeigename der Datenbank: Der Name der Datenbank in der betroffenen Cloud SQL PostgreSQL-, MySQL- oder AlloyDB-Instanz.
   • Nutzername der Datenbank: der Nutzer.
   • Vollständiger Projektname: Das Google Cloud Projekt, das die Cloud SQL-Instanz enthält.

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

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

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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, welche Nutzer sich mit der Datenbank verbinden dürfen.

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

• Ändern Sie das Passwort des Nutzers.

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

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

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

Initial Access: Database Superuser Writes to User Tables

Erkennt, wenn das Cloud SQL-Datenbank-Superuserkonto (postgres für PostgreSQL und root für MySQL) in Nutzertabellen schreibt. Der Superuser (eine Rolle mit sehr weitreichendem Zugriff) sollte im Allgemeinen nicht zum Schreiben in Nutzertabellen verwendet werden. Für normale tägliche Aktivitäten sollte ein Nutzerkonto mit eingeschränkterem Zugriff verwendet werden. Wenn ein Superuser in eine Nutzertabelle schreibt, könnte das darauf hindeuten, dass ein Angreifer seine Rechte erweitert oder den Standardnutzer der Datenbank kompromittiert hat und Daten ändert. Es könnte auch auf normale, aber 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. Sehen Sie sich im Bereich „Ergebnisdetails“ auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Anzeigename der Datenbank: Der Name der Datenbank in der betroffenen Cloud SQL PostgreSQL- oder MySQL-Instanz.
     • Nutzername der Datenbank: Der Superuser.
     • Datenbankabfrage: Die SQL-Abfrage, die beim Schreiben in Nutzertabellen ausgeführt wird.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Ressourcenname: Der Ressourcenname der betroffenen Cloud SQL-Instanz.
     • Vollständiger Name des übergeordneten Elements: Der Ressourcenname der Cloud SQL-Instanz.
     • Vollständiger Projektname: 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 das vollständige JSON für das Ergebnis aufzurufen.

Schritt 2: Protokolle prüfen

1. Rufen Sie in der Google Cloud Console den Log-Explorer auf. 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 die Logs auf PostgreSQL-pgaudit-Logs oder Cloud SQL for MySQL-Audit-Logs, die die vom Superuser ausgeführten Abfragen enthalten. Verwenden Sie dazu die folgenden Filter:
   • protoPayload.request.user="SUPERUSER"

Schritt 3: Forschungsangriffe und Reaktionsmethoden

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

Schritt 4: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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, welche Nutzer sich mit der Datenbank verbinden dürfen.

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

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

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

• Erstellen Sie einen neuen Nutzer mit eingeschränktem Zugriff für die verschiedenen Arten von Abfragen, die in der Instanz verwendet werden.

  • Gewähren Sie dem neuen Nutzer nur die Berechtigungen, die er zum Ausführen seiner Abfragen benötigt.

    • Informationen zu PostgreSQL finden Sie unter GRANT (Befehl).
    • Informationen zu MySQL finden Sie unter Access Control and Account Management.

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

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 seit mehr als 180 Tagen nicht verwendet wurde.

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

Schritt 1: Ergebnisdetails prüfen

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

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

   Unter Was wurde erkannt?:

   • E-Mail-Adresse des Hauptkontos: Das inaktive Dienstkonto, mit dem die Aktion ausgeführt wurde
   • Dienstname: Der API-Name des Google Cloud-Dienstes, auf den über das Dienstkonto zugegriffen wurde.
   • Methodenname: die aufgerufene Methode

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Verwenden Sie Dienstkontotools wie die Aktivitätsanalyse, um die Aktivitäten des inaktiven Dienstkontos zu untersuchen.
2. Wenden Sie sich im Feld E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Erwägen Sie, das möglicherweise manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das möglicherweise manipulierte Projekt zu rotieren und zu löschen. Nach dem Löschen verlieren Anwendungen, die das Dienstkonto für die Authentifizierung verwenden, den Zugriff. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Anwendungen identifizieren und mit den Anwendungsbesitzern 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.

Initial Access: Dormant Service Account Activity in AI Service

Erkennt Ereignisse, bei denen ein inaktives vom Nutzer verwaltetes Dienstkonto eine Aktion in einem KI-Dienst ausgelöst hat. In diesem Zusammenhang gilt ein Dienstkonto als inaktiv, wenn es seit mehr als 180 Tagen nicht verwendet wurde.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie das Initial Access: Dormant Service Account Activity in AI Service-Ergebnis, wie unter Ergebnisse prüfen beschrieben.

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

   Unter Was wurde erkannt?:

   • E-Mail-Adresse des Hauptkontos: Das inaktive Dienstkonto, mit dem die Aktion ausgeführt wurde
   • Methodenname: die aufgerufene Methode
   • KI-Ressourcen: Die potenziell betroffenen KI-Ressourcen, z. B. die Vertex AI-Ressourcen und das KI-Modell.

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Verwenden Sie Dienstkontotools wie die Aktivitätsanalyse, um die Aktivitäten des inaktiven Dienstkontos zu untersuchen.
2. Wenden Sie sich im Feld E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Erwägen Sie, das möglicherweise manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das möglicherweise manipulierte Projekt zu rotieren und zu löschen. Nach dem Löschen verlieren Anwendungen, die das Dienstkonto für die Authentifizierung verwenden, den Zugriff. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Anwendungen identifizieren und mit den Anwendungsbesitzern 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 von Cloud Customer Care reagieren
• 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 Schlüssel für ein inaktives vom Nutzer verwaltetes Dienstkonto erstellt wird. Ein Dienstkonto gilt in diesem Zusammenhang als inaktiv, wenn es seit mehr als 180 Tagen nicht verwendet wurde.

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

Schritt 1: Ergebnisdetails prüfen

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

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

   Unter Was wurde erkannt?:

   • Hauptkonto-E-Mail-Adresse: Der Nutzer, der den Dienstkontoschlüssel erstellt hat.

   Unter Betroffene Ressource:

   • Ressourcen-Anzeigename: Der neu erstellte inaktive Dienstkontoschlüssel
   • Vollständiger Projektname: Das Projekt, in dem sich das inaktive Dienstkonto befindet

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Verwenden Sie Dienstkontotools wie die Aktivitätsanalyse, um die Aktivitäten des inaktiven Dienstkontos zu untersuchen.
2. Wenden Sie sich an den Inhaber des Felds Haupt-E-Mail-Adresse. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Entfernen Sie den Zugriff des Inhabers der Haupt-E-Mail-Adresse, wenn das Konto gehackt wurde.
• Ungültigmachen des neu erstellten Dienstkontoschlüssels auf der Seite „Dienstkonten“
• Erwägen Sie, das möglicherweise manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das möglicherweise manipulierte Projekt zu rotieren und zu löschen. Nach dem Löschen verlieren Anwendungen, die das Dienstkonto für die Authentifizierung verwenden, den Zugriff. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Anwendungen identifizieren und mit den Anwendungsbesitzern 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 von Cloud Customer Care reagieren
• 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: Excessive Permission Denied Actions

Erkennt Ereignisse, bei denen ein Prinzipal wiederholt permission denied-Fehler in mehreren Methoden und Diensten auslöst.

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

Schritt 1: Ergebnisdetails prüfen

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

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

   Unter Was wurde erkannt?:

   • E-Mail-Adresse des Hauptkontos: Das Hauptkonto, das mehrere Fehler „Berechtigung verweigert“ ausgelöst hat.
   • Dienstname: Der API-Name des Google Cloud-Dienstes, bei dem der letzte Fehler „Berechtigung verweigert“ aufgetreten ist.
   • Methodenname: Die Methode, die aufgerufen wurde, als der letzte Fehler „Zugriff verweigert“ aufgetreten ist.

3. Notieren Sie sich in den Ergebnisdetails auf dem Tab Quellattribute die Werte der folgenden Felder im JSON-Code:

   • properties.failedActions: Die aufgetretenen Fehler „Berechtigung verweigert“. Jeder Eintrag enthält Details wie den Servicenamen, den Methodennamen, die Anzahl der fehlgeschlagenen Versuche und den Zeitpunkt, zu dem der Fehler zuletzt aufgetreten ist. Es werden maximal zehn 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 Google Cloud -Console Ihr Projekt aus.

3. Suchen Sie auf der Seite, die geladen wird, mit dem folgenden Filter nach zugehörigen Logs:

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

   Ersetzen Sie PRINCIPAL_EMAIL durch den Wert, den Sie in den Details des Ergebnisses im Feld E-Mail-Adresse des Hauptkontos 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 ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Kontos, der im Feld E-Mail-Adresse des Hauptkontos aufgeführt ist. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
• Löschen Sie Projektressourcen, die von diesem Konto erstellt wurden, z. B. unbekannte Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer.
• Wenden Sie sich an den Inhaber des Projekts mit dem Konto und löschen oder deaktivieren Sie das Konto gegebenenfalls.

Initial Access: GKE NodePort service created

Jemand hat einen NodePort-Dienst erstellt. NodePort-Dienste machen Pods direkt über die IP-Adresse und den statischen Port eines Knotens verfügbar, sodass die Pods von außerhalb des Clusters aus erreichbar sind. Dies kann ein erhebliches Sicherheitsrisiko darstellen, da ein Angreifer Sicherheitslücken im bereitgestellten Dienst ausnutzen könnte, um Zugriff auf den Cluster oder sensible Daten zu erhalten.

1. Sehen Sie sich die Konfiguration des Dienstes an, um seinen Zweck zu ermitteln.
2. Erwägen Sie, Netzwerkrichtlinien einzuschränken, um den Dienst zu schützen.

Initial Access: GKE resource modified anonymously from the internet

Erkennt, wenn ein potenziell böswilliger Akteur einen der folgenden Kubernetes-Standardnutzer oder eine der folgenden Nutzergruppen verwendet hat, um eine Kubernetes-Ressource im Cluster zu ändern:

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

Diese Nutzer und Gruppen sind effektiv anonym. Eine RBAC-Bindung (Role-Based Access Control) 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 Log-Meldung für diesen Befund.

Informationen dazu, wie Sie dieses Problem beheben können, finden Sie unter Standardrollen und -gruppen vermeiden.

Initial Access: Leaked Service Account Key Used

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

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

Schritt 1: Ergebnisdetails prüfen

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

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

   Unter Was wurde erkannt?:

   • Hauptkonto-E-Mail-Adresse: Das in dieser Aktion verwendete Dienstkonto
   • Dienstname: Der API-Name des Google Cloud-Dienstes, auf den über das Dienstkonto zugegriffen wurde.
   • Method name (Methodenname): Der Methodenname der Aktion.
   • Name des Dienstkontoschlüssels: Der gehackte Dienstkontoschlüssel, der zur Authentifizierung dieser Aktion verwendet wurde
   • Beschreibung: Die Beschreibung des erkannten Problems, einschließlich des Speicherorts im öffentlichen Internet, an dem der Dienstkontoschlüssel gefunden werden kann.

   Unter Betroffene Ressource:

   • Anzeigename der Ressource: Die Ressource, die an der Aktion beteiligt ist

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, mit dem folgenden Filter nach zugehörigen Logs:

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

   Ersetzen Sie PRINCIPAL_EMAIL durch den Wert, den Sie in den Details des Ergebnisses im Feld E-Mail-Adresse des Hauptkontos notiert haben. Ersetzen Sie SERVICE_ACCOUNT_KEY_NAME durch den Wert, den Sie in den Funddetails im Feld Name des Dienstkontoschlüssels notiert haben.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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“.
• Entfernen Sie die Webseite oder das GitHub-Repository, auf der bzw. in dem der Dienstkontoschlüssel veröffentlicht wurde.
• Erwägen Sie, das manipulierte Dienstkonto zu löschen.
• Rotieren und löschen Sie alle Zugriffsschlüssel des Dienstkontos für das potenziell manipulierte Projekt. Nach dem Löschen verlieren Anwendungen, die das Dienstkonto für die Authentifizierung verwenden, den Zugriff. Bevor Sie sie löschen, sollte Ihr Sicherheitsteam alle betroffenen Anwendungen identifizieren und mit den Anwendungsbesitzern 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 von Cloud Customer Care reagieren

Initial Access: Log4j Compromise Attempt

Dieses Ergebnis wird generiert, wenn JNDI-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 mit dem Tab Zusammenfassung geöffnet.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?
   • 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.

   • Achten Sie in der JSON-Datei auf die folgenden Felder.

   • properties

     • loadBalancerName: Der Name des Load-Balancers, der die JNDI-Suche erhalten hat.
     • requestUrl: Die Anfrage-URL der HTTP-Anfrage. Falls vorhanden, enthält dies ein 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 ein 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. Klicken Sie auf den Tab Zusammenfassung in den Ergebnisdetails in der Zeile Ähnliche Ergebnisse auf den Link unter Ähnliche Ergebnisse, um ähnliche Ergebnisse aufzurufen. Ä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 ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 vonGoogle Cloudzur Untersuchung und Reaktion auf die Sicherheitslücke „Apache Log4j 2“.
• 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.

Initial Access: Successful API call made from a TOR proxy IP

Es wurde ein erfolgreicher API-Aufruf an Ihren GKE-Cluster von einer IP-Adresse aus durchgeführt, die mit dem Tor-Netzwerk verknüpft ist. Tor bietet Anonymität, die Angreifer oft nutzen, um ihre Identität zu verbergen.

1. Untersuchen Sie die Art des API-Aufrufs und die aufgerufenen Ressourcen.
2. Prüfen Sie Ihre Netzwerkrichtlinien und Firewallregeln, um den Zugriff über Tor-Proxy-IP-Adressen zu blockieren.

Lateral Movement: Modified Boot Disk Attached to Instance

Audit-Logs werden untersucht, um verdächtige Festplattenbewegungen zwischen Compute Engine-Instanzressourcen zu erkennen. An Ihre Compute Engine-Instanz wurde ein möglicherweise manipuliertes Bootlaufwerk angehängt.

Schritt 1: Ergebnisdetails prüfen

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

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

   Unter Was wurde erkannt?:

   • E-Mail-Adresse des Hauptkontos: Das Dienstkonto, mit dem die Aktion ausgeführt wurde
   • Dienstname: Der API-Name des Google Cloud Dienstes, auf den über das Dienstkonto zugegriffen wurde
   • Methodenname: die aufgerufene Methode

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Verwenden Sie Dienstkontotools wie die Aktivitätsanalyse, um die Aktivitäten des zugehörigen Dienstkontos zu untersuchen.
2. Wenden Sie sich im Feld E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Erwägen Sie die Verwendung von Secure Boot für Ihre Compute Engine-VM-Instanzen.
• Erwägen Sie, das möglicherweise manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das möglicherweise manipulierte Projekt zu rotieren und zu löschen. Nach dem Löschen verlieren Anwendungen, die das Dienstkonto für die Authentifizierung verwenden, den Zugriff. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Anwendungen identifizieren und mit den Anwendungsbesitzern 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

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 geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

• Was wurde erkannt?
• Betroffene Ressource

1. Klicken Sie auf den Tab Quellattribute und notieren Sie sich 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 das vollständige JSON für das Ergebnis aufzurufen.

Schritt 2: Projekt- und Dienstkontoberechtigungen prüfen

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

   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. Rufen Sie in der Google Cloud Console den Log-Explorer auf.

   Zum Log-Explorer

2. Wählen Sie in der Symbolleiste der Google 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 ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Malwareerkennung (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. Die Schritte zur Fehlerbehebung sind für domainbasierte Ergebnisse ähnlich.

Schritt 1: Ergebnisdetails prüfen

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

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, 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: Bei Bad IP-Ergebnissen eine bekannte Malware-Befehls- und 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 IANA-Protokollnummer, die der Verbindung zugeordnet ist.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Ressourcenname: Der vollständige Ressourcenname der betroffenen Compute Engine-Instanz.
     • Vollständiger Projektname: Der vollständige Ressourcenname des Projekts, das den Befund 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.
     • VirusTotal-Indikator: Link zur VirusTotal-Analyseseite.
     • Flow Analyzer: Link zur Flow Analyzer-Funktion von Network Intelligence Center. Dieses Feld wird nur angezeigt, wenn VPC-Flusslogs aktiviert sind.

   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 erkannt wurde.
      • properties:
      • InstanceDetails: die Ressourcenadresse für die Compute Engine-Instanz.

Schritt 2: Berechtigungen und Einstellungen prüfen

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

   Zum Dashboard

2. Wählen Sie das Projekt aus, das in der Zeile Project full name (Vollständiger Projektname) auf dem Tab Summary (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 Ressourcenname 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 3: Protokolle prüfen

1. Klicken Sie im Bereich „Details zu Ergebnissen“ 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, mit dem folgenden Filter nach VPC-Flusslogs, die sich auf die IP-Adresse in Quell-IP beziehen:

   • 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 das in projectId aufgeführte Projekt.
     • SOURCE_IP durch die IP-Adresse, die in den Ergebnisdetails auf dem Tab Zusammenfassung in der Zeile Quell-IP aufgeführt ist.

Schritt 4: Flow Analyzer prüfen

Sie müssen VPC-Flusslogs aktivieren, um den folgenden Prozess auszuführen.

1. Prüfen Sie, ob Sie ein Upgrade für Ihren Log-Bucket zur Verwendung von Log Analytics durchgeführt haben. Eine Anleitung dazu finden Sie unter Bucket für Log Analytics aktualisieren. Für das Upgrade fallen keine zusätzlichen Kosten an.

2. Rufen Sie in der Google Cloud Console die Seite Flow Analyzer auf:

   Flow Analyzer aufrufen

   Sie können auch über den Link Flow Analyzer-URL im Bereich Zugehörige Links auf dem Tab Zusammenfassung des Bereichs Details zu Funden auf Flow Analyzer zugreifen.

3. Wenn Sie weitere Informationen zum Ergebnis der Event Threat Detection untersuchen möchten, verwenden Sie die Zeitbereichsauswahl in der Aktionsleiste, um den Zeitraum zu ändern. Der Zeitraum sollte den Zeitpunkt widerspiegeln, zu dem das Ergebnis zum ersten Mal gemeldet wurde. Wenn der Befund beispielsweise in den letzten zwei Stunden gemeldet wurde, können Sie den Zeitraum auf Letzte 6 Stunden festlegen. So wird sichergestellt, dass der Zeitraum im Flow Analyzer die Zeit umfasst, in der der Befund gemeldet wurde.

4. Filtern Sie Flow Analyzer, um die entsprechenden Ergebnisse für die IP-Adresse anzuzeigen, die mit dem Ergebnis für die schädliche IP-Adresse verknüpft ist:

   1. Wählen Sie im Menü Filter in der Zeile Quelle des Abschnitts Abfrage die Option IP aus.

   2. Geben Sie im Feld Wert die IP-Adresse ein, die mit dem Ergebnis verknüpft ist, und klicken Sie auf Neue Abfrage ausführen.

      Wenn im Flow Analyzer keine Ergebnisse für die IP-Adresse angezeigt werden, entfernen Sie den Filter aus der Zeile Quelle und führen Sie die Abfrage noch einmal mit demselben Filter in der Zeile Ziel aus.

5. Analysieren Sie die Ergebnisse. Wenn Sie weitere Informationen zu einem bestimmten Ablauf aufrufen möchten, klicken Sie in der Tabelle Alle Datenflüsse auf Details, um den Bereich Ablaufdetails zu öffnen.

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. Klicken Sie auf den Tab Zusammenfassung in den Ergebnisdetails in der Zeile Ähnliche Ergebnisse auf den Link unter Ähnliche Ergebnisse, um ähnliche Ergebnisse aufzurufen. Ähnliche Ergebnisse haben denselben Ergebnistyp und dieselbe Instanz und dasselbe Netzwerk.
3. Prüfen Sie die markierten URLs und Domains auf VirusTotal, indem Sie auf den Link im VirusTotal-Indikator klicken. 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 ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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: 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 angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Quell-IP: Die vermutete IP-Adresse für Kryptomining.
     • Quellport: Der Quellport der Verbindung, falls verfügbar.
     • Ziel-IP: die Ziel-IP-Adresse.
     • Zielport: Der Zielport der Verbindung, sofern verfügbar.
     • Protokoll: Das IANA-Protokoll, das der Verbindung zugeordnet ist.
   • Betroffene Ressource
   • Weitere Informationen, einschließlich der 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.
     • Flow Analyzer: Link zur Flow Analyzer-Funktion von Network Intelligence Center. Dieses Feld wird nur angezeigt, wenn VPC-Flusslogs aktiviert sind.

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

4. Maximieren Sie properties und notieren Sie die 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 angezeigt:

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

5. Klicken Sie auf den Tab JSON, um das vollständige JSON für das Ergebnis aufzurufen.

Schritt 2: Berechtigungen und Einstellungen prüfen

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

   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. Rufen Sie in der Google Cloud Console den Log-Explorer auf.

   Zum Log-Explorer

2. Wählen Sie in der Symbolleiste der Google 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 ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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.

Persistence: GKE Webhook Configuration Detected

In Ihrem GKE-Cluster wurde eine Webhook-Konfiguration erkannt. Webhooks können Kubernetes API-Anfragen abfangen und ändern. Dadurch können Angreifer möglicherweise in Ihrem Cluster bleiben oder Ressourcen manipulieren.

1. Zweck und Ursprung der Webhook-Konfiguration ermitteln Prüfen Sie, ob sie aus einer vertrauenswürdigen Quelle stammt und einem legitimen Zweck dient.
2. Prüfen Sie die Webhook-Konfiguration, um den Umfang und die Arten von Anfragen zu verstehen, die abgefangen werden.
3. Überwachen Sie die Webhook-Aktivitäten auf verdächtige oder nicht autorisierte Aktionen.
4. Wenn der Webhook nicht erforderlich ist oder sein Verhalten bedenklich ist, sollten Sie ihn entfernen oder deaktivieren.

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 Berechtigungen:

• Einladen eines externen Nutzers, z. B. eines gmail.com-Nutzers, als Projektinhaber über die Google Cloud Console
• Ein Dienstkonto, das vertrauliche Berechtigungen erteilt
• Eine benutzerdefinierte Rolle, die vertrauliche Berechtigungen erteilt
• Dienstkonto, das von außerhalb Ihrer Organisation oder Ihres Projekts hinzugefügt wurde

Die IAM Anomalous Grant-Erkenntnis ist insofern einzigartig, als sie Unterregeln enthält, die genauere Informationen zu jeder Instanz dieser Erkenntnis liefern. Die Schweregradklassifizierung dieses Ergebnisses hängt von der untergeordneten Regel ab. Für jede untergeordnete Regel ist möglicherweise eine andere Antwort erforderlich.

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

• external_service_account_added_to_policy:
  • HIGH, wenn eine Rolle mit hoher Vertraulichkeit oder eine Rolle mit mittlerer Vertraulichkeit auf Organisationsebene gewährt wurde. Weitere Informationen finden Sie unter Rollen mit hoher Sensibilität.
  • MEDIUM, wenn eine Rolle mit mittlerer Vertraulichkeit zugewiesen wurde. Weitere Informationen finden Sie unter Rollen mit mittlerer Sensibilität.
• external_member_invited_to_policy: HIGH
• external_member_added_to_policy:
  • HIGH, wenn eine Rolle mit hoher Vertraulichkeit oder eine Rolle mit mittlerer Vertraulichkeit auf Organisationsebene gewährt wurde. Weitere Informationen finden Sie unter Rollen mit hoher Sensibilität.
  • MEDIUM, wenn eine Rolle mit mittlerer Vertraulichkeit zugewiesen wurde. Weitere Informationen finden Sie unter Rollen mit mittlerer Sensibilität.
• 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 angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

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

   • Betroffene Ressource

   • Zugehörige Links, 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 VirusTotal-Analyseseite.

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

4. Beachten Sie im JSON-Code für das Ergebnis die folgenden Felder:

   • detectionCategory:
     • subRuleName: genauere Informationen zum Typ der aufgetretenen anomalen Gewährung. Die Unterregel bestimmt die Schweregradklassifizierung dieses Ergebnisses.
   • evidence:
     • sourceLogId:
     • projectId: die ID des Projekts, das das Ergebnis enthält.
   • properties:
     • sensitiveRoleGrant:
       • bindingDeltas:
       • Action: die vom Nutzer durchgeführte Aktion.
       • Role: die dem Nutzer zugewiesene Rolle.
       • member: die E-Mail-Adresse des Nutzers, der die Rolle erhalten hat.

Schritt 2: Protokolle prüfen

1. Klicken Sie im Bereich „Details zu Ergebnissen“ 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 3: Forschungsangriffe und Reaktionsmethoden

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Gültige Konten: Cloudkonten.
2. Klicken Sie auf den Link in der Zeile Ähnliche Ergebnisse auf dem Tab Zusammenfassung der Ergebnisdetails, um ähnliche Ergebnisse aufzurufen. Ä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 ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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: New AI API Method

In einer Organisation, einem Ordner oder einem Projekt wurde eine anomale Administratoraktivität für KI-Dienste durch einen potenziell böswilligen Akteur erkannt. Ungewöhnliche Aktivitäten können Folgendes umfassen:

• Neue Aktivität eines Hauptkontos in einer Organisation, einem Ordner oder einem Projekt
• Aktivität, die seit einiger Zeit nicht mehr von einem Hauptkonto in einer Organisation, einem Ordner oder einem Projekt ausgeführt wurde

Schritt 1: Ergebnisdetails prüfen

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

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

   • Unter Was wurde erkannt?:
     • E-Mail-Adresse des Hauptkontos: das Konto, über das der Anruf getätigt wurde
     • Methodenname: die aufgerufene Methode
     • KI-Ressourcen: Die potenziell betroffenen KI-Ressourcen, z. B. die Vertex AI-Ressourcen und das KI-Modell.
   • Unter Betroffene Ressource:
     • Anzeigename der Ressource: Der Name der betroffenen Ressource, der mit dem Namen der Organisation, des Ordners oder des Projekts übereinstimmen kann.
     • Ressourcenpfad: Der Ort in der Ressourcenhierarchie, an dem die Aktivität stattgefunden hat.

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Persistence.
2. Prüfen Sie, ob die Aktion in der Organisation, im Ordner oder im Projekt gerechtfertigt war und ob sie vom legitimen Inhaber des Kontos ausgeführt wurde. Die Organisation, der Ordner oder das Projekt wird im Feld Ressourcenpfad angezeigt und das Konto in der Zeile E-Mail-Adresse des Hauptkontos.
3. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Persistence: New API Method

In einer Organisation, einem Ordner oder einem Projekt wurde eine ungewöhnliche Administratoraktivität durch einen potenziell böswilligen Akteur erkannt. Anomale Aktivitäten können Folgendes sein:

• Neue Aktivität eines Hauptkontos in einer Organisation, einem Ordner oder einem Projekt
• Aktivität, die von einem Hauptkonto in einer Organisation, einem Ordner oder einem Projekt seit einiger Zeit nicht mehr ausgeführt wurde

Schritt 1: Ergebnisdetails prüfen

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

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

   • Unter Was wurde erkannt?:
     • E-Mail-Adresse des Hauptkontos: das Konto, über das der Anruf getätigt wurde
     • Dienstname: Der API-Name des Google Cloud-Dienstes, der in der Aktion verwendet wird.
     • Methodenname: die aufgerufene Methode
   • Unter Betroffene Ressource:
     • Anzeigename der Ressource: Der Name der betroffenen Ressource, der mit dem Namen der Organisation, des Ordners oder des Projekts übereinstimmen kann.
     • Ressourcenpfad: Der Ort in der Ressourcenhierarchie, an dem die Aktivität stattgefunden hat.

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Persistence.
2. Prüfen Sie, ob die Aktion in der Organisation, im Ordner oder im Projekt gerechtfertigt war und ob sie vom legitimen Inhaber des Kontos ausgeführt wurde. Die Organisation, der Ordner oder das Projekt wird in der Zeile Ressourcenpfad angezeigt und das Konto in der Zeile E-Mail-Adresse des Hauptkontos.
3. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

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 Google Cloudzu, 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 angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

• Was wurde erkannt?, insbesondere die folgenden Felder:
  • E-Mail-Adresse des Hauptkontos: das potenziell manipulierte Nutzerkonto.
• Betroffene Ressource, insbesondere die folgenden Felder:
  • Vollständiger Projektname: 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 geschätzte aktuelle Standort des Nutzers.
     • callerIp: die externe IP-Adresse.
     • notSeenInLast: Zeitraum, der zum Festlegen einer Referenz für das normale Verhalten verwendet wird.
     • typicalGeolocations: die Standorte, an denen der Nutzer normalerweise aufGoogle Cloud -Ressourcen zugreift.

Schritt 2: Projekt- und Kontoberechtigungen prüfen

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

   IAM aufrufen

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

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

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich „Details zu Ergebnissen“ 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 MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten: Cloudkonten.
2. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Schritt 5: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Geography for AI Service

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 Google Cloud AI-Dienste zu, basierend auf der Standortbestimmung der anfragenden IP-Adresse.

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Persistence: New Geography for AI Service-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 angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

• Was wurde erkannt?, insbesondere die folgenden Felder:
  • E-Mail-Adresse des Hauptkontos: das potenziell manipulierte Nutzerkonto.
  • KI-Ressourcen: Die potenziell betroffenen KI-Ressourcen, z. B. die Vertex AI-Ressourcen und das KI-Modell.
• Betroffene Ressource, insbesondere die folgenden Felder:
  • Vollständiger Projektname: 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 geschätzte aktuelle Standort des Nutzers.
     • callerIp: die externe IP-Adresse.
     • notSeenInLast: Zeitraum, der zum Festlegen einer Referenz für das normale Verhalten verwendet wird.
     • typicalGeolocations: die Standorte, an denen der Nutzer normalerweise aufGoogle Cloud -Ressourcen zugreift.
   • aiModel:
     • name: die betroffene KI Model
   • vertexAi:
     • datasets: die betroffenen Vertex AI-Datasets
     • pipelines: die betroffenen Vertex AI-Trainingspipelines

Schritt 2: Projekt- und Kontoberechtigungen prüfen

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

   IAM aufrufen

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

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

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich „Details zu Ergebnissen“ 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 MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten: Cloudkonten.
2. Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.

Schritt 5: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Hauptkonto-E-Mail-Adresse: das potenziell manipulierte Dienstkonto.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Projektname: 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. Achten Sie in der JSON-Datei auf die folgenden Felder.
   • projectId: das Projekt, das das potenziell manipulierte Dienstkonto enthält.
   • callerUserAgent: der ungewöhnliche User-Agent.
   • anomalousSoftwareClassification: die Art der Software.
   • notSeenInLast: Zeitraum, der zum Festlegen einer Referenz für das normale Verhalten verwendet wird.

Schritt 2: Projekt- und Kontoberechtigungen prüfen

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

   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 in den Ergebnisdetails auf dem Tab Zusammenfassung in der Zeile E-Mail-Adresse des Hauptkontos aufgeführt ist, und prüfen Sie die zugewiesenen 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 E-Mail-Adresse des Hauptkontos aufgeführt ist.

6. Prüfen Sie die Schlüssel des Dienstkontos und die Erstellungsdaten der Schlüssel.

Schritt 3: Protokolle prüfen

1. Klicken Sie im Bereich „Details zu Ergebnissen“ 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 ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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.

Persistence: Service Account Created in sensitive namespace

Jemand hat ein Dienstkonto in einem sensiblen Namespace erstellt. Die Namespaceskube-system undkube-public sind für den Betrieb von GKE-Cluster von entscheidender Bedeutung. Unautorisierte Dienstkonten können die Stabilität und Sicherheit von Clustern beeinträchtigen. 1. Wenn das Dienstkonto nicht autorisiert ist, löschen Sie es und untersuchen Sie die Erstellungsmethode.

Persistence: Unmanaged Account Granted Sensitive Role

Erkennt Ereignisse, bei denen einem nicht verwalteten Konto eine vertrauliche Rolle zugewiesen wird. Nicht verwaltete Konten können nicht von Systemadministratoren gesteuert werden. Wenn der entsprechende Mitarbeiter das Unternehmen verlassen hat, kann der Administrator das Konto beispielsweise nicht löschen. Daher stellt die Zuweisung vertraulicher Rollen an nicht verwaltete Konten 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 Persistence: Unmanaged Account Granted Sensitive Role-Ergebnis, wie unter Ergebnisse prüfen beschrieben.

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

   Unter Was wurde erkannt?:

   • E-Mail-Adresse des Hauptkontos: Der Nutzer, der die Aktion zum Erteilen der Berechtigung ausgeführt hat.
   • Zugriffsgewährungen, die gegen die Richtlinien verstoßen. Hauptkontoname: Das nicht verwaltete Konto, das die Zugriffsgewährung erhält.
   • Verletzende Zugriffszuweisungen.Gewährte Rolle: Die gewährte sensible Rolle

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Wenden Sie sich an den Inhaber des Felds Haupt-E-Mail-Adresse. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
2. Fragen Sie den Inhaber des Felds Offending access grants.Principal name, um den Ursprung des nicht verwalteten Kontos zu ermitteln.

Schritt 3: Protokolle prüfen

1. Klicken Sie im Detailbereich für den Befund auf dem Tab „Zusammenfassung“ unter Zugehörige Links auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.

Schritt 4: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Entfernen Sie den Zugriff des Inhabers der Haupt-E-Mail-Adresse, wenn das Konto gehackt wurde.
• Entfernen Sie die neu zugewiesene sensible Rolle aus dem nicht verwalteten Konto.
• Erwägen Sie, das nicht verwaltete Konto mit dem Übertragungstool in ein verwaltetes Konto umzuwandeln und es unter die Kontrolle von Systemadministratoren zu stellen.

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

Erkennt, wenn das AlloyDB for PostgreSQL-Datenbank-Superuserkonto (postgres) in Nutzertabellen schreibt. Der Superuser (eine Rolle mit sehr weitreichendem Zugriff) sollte im Allgemeinen nicht zum Schreiben in Nutzertabellen verwendet werden. Für normale tägliche Aktivitäten sollte ein Nutzerkonto mit eingeschränkterem Zugriff verwendet werden. Wenn ein Superuser in eine Nutzertabelle schreibt, könnte das darauf hindeuten, dass ein Angreifer seine Rechte erweitert oder den Standardnutzer der Datenbank kompromittiert hat und Daten ändert. Es kann auch auf normale, aber unsichere Praktiken hinweisen.

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. Sehen Sie sich im Bereich „Ergebnisdetails“ auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Anzeigename der Datenbank: Der Name der Datenbank in der betroffenen AlloyDB for PostgreSQL-Instanz.
     • Nutzername der Datenbank: Der Superuser.
     • Datenbankabfrage: Die SQL-Abfrage, die beim Schreiben in Nutzertabellen ausgeführt wird.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Ressourcenname: Der Ressourcenname der betroffenen AlloyDB for PostgreSQL-Instanz.
     • Vollständiger Name des übergeordneten Elements: Der Ressourcenname der AlloyDB for PostgreSQL-Instanz.
     • Vollständiger Projektname: 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 das vollständige JSON für das Ergebnis aufzurufen.

Schritt 2: Protokolle prüfen

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

Schritt 3: Forschungsangriffe und Reaktionsmethoden

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

Schritt 4: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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, welche Nutzer eine Verbindung zur Datenbank herstellen dürfen.
• Ändern Sie das Passwort für den Superuser.
• Erstellen Sie einen neuen Nutzer mit eingeschränktem Zugriff für die verschiedenen Arten von Anfragen, die in der Instanz verwendet werden.
  • Gewähren Sie dem neuen Nutzer nur die Berechtigungen, die er zum Ausführen seiner Abfragen benötigt.
  • Aktualisieren Sie die Anmeldedaten für die Clients, die eine Verbindung zur AlloyDB for PostgreSQL-Instanz herstellen.

Privilege Escalation: AlloyDB Over-Privileged Grant

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

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

Schritt 1: Ergebnisdetails prüfen

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

2. Sehen Sie sich im Bereich „Ergebnisdetails“ auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Anzeigename der Datenbank: Der Name der Datenbank in der betroffenen AlloyDB for PostgreSQL-Instanz.
     • Datenbanknutzername: Der PostgreSQL-Nutzer, der übermäßige Berechtigungen gewährt hat.
     • Datenbankabfrage: Die ausgeführte PostgreSQL-Abfrage, mit der die Berechtigungen erteilt wurden.
     • Empfänger von Datenbanken: Die Empfänger der zu weit gefassten Berechtigungen.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Ressourcenname: Der Ressourcenname der betroffenen AlloyDB for PostgreSQL-Instanz.
     • Vollständiger Name des übergeordneten Elements: Der Ressourcenname der AlloyDB for PostgreSQL-Instanz.
     • Vollständiger Projektname: 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 das vollständige JSON für das Ergebnis aufzurufen.

Schritt 2: Datenbankberechtigungen prüfen

1. Verbindung zur AlloyDB for PostgreSQL-Instanz herstellen
2. Zugriffsberechtigungen auflisten und anzeigen für Folgendes:
   • Datenbanken. Verwenden Sie den Metacommand \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 Prozeduren. Verwenden Sie den Metacommand \df und prüfen Sie, welche Berechtigungen für Funktionen oder Prozeduren in der Datenbank zugewiesen sind, die in 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 im 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 MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Exfiltration Over Web Service.
2. Um festzustellen, ob zusätzliche Schritte zur Abhilfe erforderlich sind, kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung.

Schritt 5: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 überprivilegierten Berechtigungen.
• Ziehen Sie in Betracht, alle Berechtigungen für die Empfänger, die unter Datenbankempfänger aufgeführt sind, zu widerrufen, bis die Untersuchung abgeschlossen ist.
• Um den Zugriff auf die Datenbank einzuschränken (Database display name aus Schritt 1), entziehen Sie den Berechtigten (Database grantees aus Schritt 1) unnötige Berechtigungen.

Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity

Anomalous Impersonation of Service Account wird erkannt, indem die Audit-Logs zur Administratoraktivität daraufhin untersucht werden, ob in 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 Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Hauptkonto-E-Mail-Adresse: Das letzte Dienstkonto in der Identitätsübernahmeanfrage, das für den Zugriff auf Google Cloudverwendet wurde.
     • Dienstname: Der API-Name des Google Cloud -Dienstes, der an der Identitätsdiebstahlanfrage beteiligt ist.
     • Methodenname: Die aufgerufene Methode.
     • Informationen zur Dienstkontodelegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto unten in der Liste ist der Aufrufer der Identitätsübertragungsanfrage.
   • 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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
2. Untersuchen Sie die Principals in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
3. Wenden Sie sich an den Inhaber des Anrufers, der die Identität übernimmt, in der Liste Informationen zur Dienstkontodelegierung. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Erwägen Sie, das möglicherweise manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das möglicherweise 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.

Privilege Escalation: Anomalous Impersonation of Service Account for AI Admin Activity

Anomalous Impersonation of Service Account wird erkannt, wenn die Audit-Logs für Administratoraktivitäten eines KI-Dienstes zeigen, dass eine Anomalie in einer Anfrage zur Identitätsübernahme eines Dienstkontos aufgetreten ist.

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

Schritt 1: Ergebnisdetails prüfen

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

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Hauptkonto-E-Mail-Adresse: Das letzte Dienstkonto in der Identitätsübernahmeanfrage, das für den Zugriff auf Google Cloudverwendet wurde.
     • Methodenname: Die aufgerufene Methode.
     • Informationen zur Dienstkontodelegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto unten in der Liste ist der Aufrufer der Identitätswechselanfrage.
     • KI-Ressourcen: Die potenziell betroffenen KI-Ressourcen, z. B. die Vertex AI-Ressourcen und das KI-Modell.
   • 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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
2. Untersuchen Sie die Principals in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
3. Wenden Sie sich an den Inhaber des Anrufers, der die Identität übernimmt, in der Liste Informationen zur Dienstkontodelegierung. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Erwägen Sie, das möglicherweise manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das möglicherweise 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 von Cloud Customer Care reagieren
• 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.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity

Anomalous Multistep Service Account Delegation wird erkannt, indem die Audit-Logs zur Administratoraktivität daraufhin untersucht werden, 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 Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Hauptkonto-E-Mail-Adresse: Das letzte Dienstkonto in der Identitätsübernahmeanfrage, mit der auf Google Cloudzugegriffen wurde.
     • Dienstname: Der API-Name des Google Cloud -Dienstes, der an der Identitätsdiebstahlanfrage beteiligt ist.
     • Methodenname: Die aufgerufene Methode.
     • Informationen zur Dienstkontodelegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto unten in der Liste ist der Aufrufer der Identitätsübertragungsanfrage.
   • 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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
2. Untersuchen Sie die Principals in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
3. Wenden Sie sich an den Inhaber des Anrufers, der die Identität übernimmt, in der Liste Informationen zur Dienstkontodelegierung. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Erwägen Sie, das möglicherweise manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das möglicherweise 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.

Privilege Escalation: Anomalous Multistep Service Account Delegation for AI Admin Activity

Anomalous Multistep Service Account Delegation wird erkannt, wenn die Audit-Logs für Administratoraktivitäten eines KI-Dienstes zeigen, dass eine Anomalie in einer Anfrage zur Identitätsübernahme eines Dienstkontos aufgetreten ist.

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

Schritt 1: Ergebnisdetails prüfen

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

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Hauptkonto-E-Mail-Adresse: Das letzte Dienstkonto in der Identitätsübernahmeanfrage, das für den Zugriff auf Google Cloudverwendet wurde.
     • Methodenname: Die aufgerufene Methode.
     • Informationen zur Dienstkontodelegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto unten in der Liste ist der Aufrufer der Identitätswechselanfrage.
     • KI-Ressourcen: Die potenziell betroffenen KI-Ressourcen, z. B. die Vertex AI-Ressourcen und das KI-Modell.
   • 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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
2. Untersuchen Sie die Principals in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
3. Wenden Sie sich an den Inhaber des Anrufers, der die Identität übernimmt, in der Liste Informationen zur Dienstkontodelegierung. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Erwägen Sie, das möglicherweise manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das möglicherweise 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 von Cloud Customer Care reagieren
• 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.

Privilege Escalation: Anomalous Multistep Service Account Delegation for AI Data Access

Anomalous Multistep Service Account Delegation wird erkannt, wenn die Audit-Logs für Administratoraktivitäten eines KI-Dienstes zeigen, dass eine Anomalie in einer Anfrage zur Identitätsübernahme eines Dienstkontos aufgetreten ist.

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

Schritt 1: Ergebnisdetails prüfen

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

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Hauptkonto-E-Mail-Adresse: Das letzte Dienstkonto in der Anfrage zur Identitätsübernahme, das für den Zugriff auf Google Cloudverwendet wurde.
     • Methodenname: die aufgerufene Methode
     • Informationen zur Dienstkontodelegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto unten in der Liste ist der Aufrufer der Identitätswechselanfrage.
     • KI-Ressourcen: Die potenziell betroffenen KI-Ressourcen, z. B. die Vertex AI-Ressourcen und das KI-Modell.
   • 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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
2. Untersuchen Sie die Principals in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
3. Wenden Sie sich an den Inhaber des Anrufers, der die Identität übernimmt, in der Liste Informationen zur Dienstkontodelegierung. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Erwägen Sie, das möglicherweise manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das möglicherweise 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 von Cloud Customer Care reagieren
• 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.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access

Anomalous Multistep Service Account Delegation wird erkannt, indem die Audit-Logs für den Datenzugriff untersucht werden, um festzustellen, 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 Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Hauptkonto-E-Mail-Adresse: Das letzte Dienstkonto in der Anfrage zur Identitätsübernahme, das für den Zugriff auf Google Cloudverwendet wurde.
     • Dienstname: Der API-Name des Google Cloud -Dienstes, der an der Identitätswechselanfrage beteiligt ist.
     • Methodenname: die aufgerufene Methode
     • Informationen zur Dienstkontodelegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto unten in der Liste ist der Aufrufer der Identitätsübertragungsanfrage.
   • 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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
2. Untersuchen Sie die Principals in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
3. Wenden Sie sich an den Inhaber des Anrufers, der die Identität übernimmt, in der Liste Informationen zur Dienstkontodelegierung. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Erwägen Sie, das möglicherweise manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das möglicherweise 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.

Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity

Anomalous Service Account Impersonator wird erkannt, indem die Audit-Logs zur Administratoraktivität daraufhin untersucht werden, ob in 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 Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:

     • E-Mail-Adresse des Hauptkontos: Das endgültige Dienstkonto in der Identitätsübernahmeanfrage, das für den Zugriff auf Google Cloud verwendet wurde.
     • Dienstname: Der API-Name des Google Cloud-Dienstes, der an der Identitätsübernahme beteiligt ist.
     • Methodenname: die aufgerufene Methode
     • Informationen zur Dienstkontodelegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto unten in der Liste ist der Aufrufer der Identitätsübertragungsanfrage.

   • Betroffene Ressource

   • Zugehörige Links, 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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
2. Untersuchen Sie die Principals in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
3. Wenden Sie sich an den Inhaber des Anrufers, der die Identität übernimmt, in der Liste Informationen zur Dienstkontodelegierung. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Erwägen Sie, das möglicherweise manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das möglicherweise 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.

Privilege Escalation: Anomalous Service Account Impersonator for AI Admin Activity

Anomalous Service Account Impersonator wird erkannt, wenn die Audit-Logs für Administratoraktivitäten eines KI-Dienstes zeigen, dass eine Anomalie in einer Anfrage zur Identitätsübernahme eines Dienstkontos aufgetreten ist.

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

Schritt 1: Ergebnisdetails prüfen

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

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Hauptkonto-E-Mail-Adresse: Das letzte Dienstkonto in der Anfrage zur Identitätsübernahme, das für den Zugriff auf Google Cloudverwendet wurde.
     • Methodenname: die aufgerufene Methode
     • Informationen zur Dienstkontodelegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto unten in der Liste ist der Aufrufer der Identitätswechselanfrage.
     • KI-Ressourcen: Die potenziell betroffenen KI-Ressourcen, z. B. die Vertex AI-Ressourcen und das KI-Modell.
   • 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 E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
2. Untersuchen Sie die Principals in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
3. Wenden Sie sich an den Inhaber des Anrufers, der die Identität übernimmt, in der Liste Informationen zur Dienstkontodelegierung. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Erwägen Sie, das möglicherweise manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das möglicherweise 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 von Cloud Customer Care reagieren
• 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.

Privilege Escalation: Anomalous Service Account Impersonator for AI Data Access

Anomalous Service Account Impersonator wird erkannt, wenn die Audit-Logs für Administratoraktivitäten eines KI-Dienstes zeigen, dass eine Anomalie in einer Anfrage zur Identitätsübernahme eines Dienstkontos aufgetreten ist.

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

Schritt 1: Ergebnisdetails prüfen

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

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

   Unter Was wurde erkannt?:

   • Hauptkonto-E-Mail-Adresse: Das letzte Dienstkonto in der Anfrage zur Identitätsübernahme, das für den Zugriff auf Google Cloudverwendet wurde.
   • Methodenname: die aufgerufene Methode
   • Informationen zur Dienstkontodelegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto unten in der Liste ist der Aufrufer der Identitätswechselanfrage.
   • KI-Ressourcen: Die potenziell betroffenen KI-Ressourcen, z. B. die Vertex AI-Ressourcen und das KI-Modell.

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Wenden Sie sich im Feld E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
2. Untersuchen Sie die Principals in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
3. Wenden Sie sich an den Inhaber des Anrufers, der die Identität übernimmt, in der Liste Informationen zur Dienstkontodelegierung. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Erwägen Sie, das möglicherweise manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das möglicherweise 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 von Cloud Customer Care reagieren
• 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.

Privilege Escalation: Anomalous Service Account Impersonator for Data Access

Anomalous Service Account Impersonator wird erkannt, indem die Audit-Logs für den Datenzugriff daraufhin untersucht werden, 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 Privilege Escalation: Anomalous Service Account Impersonator for Data Access-Ergebnis, wie unter Ergebnisse prüfen beschrieben.

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

   Unter Was wurde erkannt?:

   • E-Mail-Adresse des Hauptkontos: Das endgültige Dienstkonto in der Identitätsübernahmeanfrage, das für den Zugriff auf Google Cloud verwendet wurde.
   • Dienstname: Der API-Name des Google Cloud-Dienstes, der an der Identitätsübernahme beteiligt ist.
   • Methodenname: die aufgerufene Methode
   • Informationen zur Dienstkontodelegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto unten in der Liste ist der Aufrufer der Identitätsübertragungsanfrage.

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Wenden Sie sich im Feld E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
2. Untersuchen Sie die Principals in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
3. Wenden Sie sich an den Inhaber des Anrufers, der die Identität übernimmt, in der Liste Informationen zur Dienstkontodelegierung. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Erwägen Sie, das möglicherweise manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das möglicherweise 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.

Privilege Escalation: Changes to sensitive Kubernetes RBAC objects

Zur Ausweitung der Rechte hat ein potenziell böswilliger Akteur versucht, ein ClusterRole-, RoleBinding- oder ClusterRoleBinding-Objekt der rollenbasierten Zugriffssteuerung (RBAC) der vertraulichen Rolle cluster-admin zu ändern, indem er eine PUT- oder PATCH-Anfrage stellte.

Schritt 1: Ergebnisdetails prüfen

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

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Hauptkonto-E-Mail-Adresse: Das Konto, mit dem 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 ausgefü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.

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

4. Sehen Sie sich die Details der angezeigten Bindung an.

Schritt 2: Protokolle prüfen

1. Rufen Sie auf dem Tab Zusammenfassung der Details zum Ergebnis in der Google Cloud -Konsole den Log-Explorer auf. Klicken Sie dazu auf den Link im Feld Cloud Logging-URI.

2. Wenn der Wert in Method name eine PATCH-Methode war, prüfen Sie den Anfragetext, um zu sehen, welche Eigenschaften geändert wurden.

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

3. Prüfen Sie mit den folgenden Filtern, ob das Hauptkonto andere Aktionen ausgeführt hat:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Ersetzen Sie Folgendes:

   • CLUSTER_NAME: Der Wert, den Sie in den Funddetails im Feld Resource display name (Anzeigename der Ressource) notiert haben.

   • PRINCIPAL_EMAIL: Der Wert, den Sie in den Details des Ergebnisses im Feld E-Mail-Adresse des Hauptkontos notiert haben.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Sehen Sie sich die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp an: Rechteausweitung.
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 prüfen und untersuchen, ob es die Rolle braucht, an die es gebunden ist.
4. Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten des Hauptkontos in den Logs gibt.

5. Wenn die E-Mail-Adresse des Hauptkontos kein Dienstkonto ist, wenden Sie sich an den Inhaber, um herauszufinden, ob der rechtmäßige Kontoinhaber die Aktion ausgeführt hat.

   Wenn die E‑Mail-Adresse des Hauptkontos ein Dienstkonto ist (IAM oder Kubernetes), identifizieren Sie die Quelle der Änderung, um deren Rechtmäßigkeit zu ermitteln.

6. Wenn Sie einen Reaktionsplan entwickeln möchten, kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung.

Privilege Escalation: ClusterRole with Privileged Verbs

Jemand hat ein RBAC-ClusterRole-Objekt erstellt, das die Verben bind, escalate oder impersonate enthält. Ein Subjekt, das an eine Rolle mit diesen Verben gebunden ist, kann andere Nutzer mit höheren Berechtigungen imitieren, an zusätzliche Role- oder ClusterRole-Objekte mit zusätzlichen Berechtigungen gebunden werden oder seine eigenen ClusterRole-Berechtigungen ändern. Das kann dazu führen, dass diese Themen cluster-admin-Berechtigungen erhalten. Weitere Informationen finden Sie in der Log-Meldung für diese Benachrichtigung.

1. Überprüfen Sie die ClusterRole und die zugehörigen ClusterRoleBindings, um festzustellen, ob die Eigentümer diese Berechtigungen tatsächlich benötigen.
2. Erstellen Sie nach Möglichkeit keine Rollen, die die Verben bind, escalate oder impersonate beinhalten.
3. Stellen Sie fest, ob die Audit-Logs in Cloud Logging weitere Anzeichen für schädliche Aktivitäten des Hauptkontos enthalten.
4. Verwenden Sie beim Zuweisen von Berechtigungen in einer RBAC-Rolle das Prinzip der geringsten Berechtigung und gewähren Sie die Mindestberechtigungen, die zum Ausführen einer Aufgabe erforderlich sind. Das Prinzip der geringsten Berechtigung reduziert das Risiko einer Rechteausweitung, wenn Ihr Cluster manipuliert wurde, und verringert die Wahrscheinlichkeit, dass übermäßiger Zugriff zu einem Sicherheitsvorfall führt.

Privilege Escalation: ClusterRoleBinding to Privileged Role

Jemand hat eine RBAC-ClusterRoleBinding erstellt, die auf die Standard-system:controller:clusterrole-aggregation-controller ClusterRole verweist. Diese Standard-ClusterRole hat das Verb escalate, mit dem Subjekte die Berechtigungen ihrer eigenen Rollen ändern und so eine Rechteausweitung ermöglichen können. Weitere Informationen finden Sie in der Log-Meldung für diese Benachrichtigung.

1. Sehen Sie sich alle ClusterRoleBinding an, in denen auf system:controller:clusterrole-aggregation-controller ClusterRole verwiesen wird.
2. Prüfen Sie alle Änderungen an der system:controller:clusterrole-aggregation-controller ClusterRole.
3. Stellen Sie fest, ob die Audit-Logs in Cloud Logging weitere Anzeichen für schädliche Aktivitäten des Hauptkontos enthalten, das das Objekt vom Typ ClusterRoleBinding erstellt hat.

Privilege Escalation: Create Kubernetes CSR for master cert

Zur Ausweitung der Rechte hat ein potenziell böswilliger Akteur eine Anfrage zur Zertifikatssignierung (Certificate Signing Request, CSR) für das Kubernetes-Masterzertifikat erstellt, die ihm die Zugriffsrechte der Rolle cluster-admin gewährt.

Schritt 1: Ergebnisdetails prüfen

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

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Hauptkonto-E-Mail-Adresse: Das Konto, mit dem 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 ausgefü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.

Schritt 2: Protokolle prüfen

1. Rufen Sie auf dem Tab Zusammenfassung der Details zum Ergebnis in der Google Cloud -Konsole den Log-Explorer auf. Klicken Sie dazu auf den Link im Feld Cloud Logging-URI.
2. Prüfen Sie den Wert im Feld protoPayload.resourceName, um die spezifische Anfrage zur Zertifikatsignierung zu ermitteln.

3. Prüfen Sie mit den folgenden Filtern, ob das Hauptkonto andere Aktionen ausgeführt hat:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Ersetzen Sie Folgendes:

   • CLUSTER_NAME: Der Wert, den Sie in den Funddetails im Feld Resource display name (Anzeigename der Ressource) notiert haben.

   • PRINCIPAL_EMAIL: Der Wert, den Sie in den Details des Ergebnisses im Feld E-Mail-Adresse des Hauptkontos notiert haben.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

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

3. Wenn die E-Mail-Adresse des Hauptkontos kein Dienstkonto ist, wenden Sie sich an den Inhaber, um herauszufinden, ob der rechtmäßige Kontoinhaber die Aktion ausgeführt hat.

   Wenn die E‑Mail-Adresse des Hauptkontos ein IAM- oder Kubernetes-Dienstkonto ist, identifizieren Sie die Quelle der Aktion, um deren Rechtmäßigkeit festzustellen.

4. Wenn Sie einen Reaktionsplan entwickeln möchten, kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung.

Privilege Escalation: Creation of sensitive Kubernetes bindings

Zur Ausweitung der Rechte 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 Privilege Escalation: Creation of sensitive Kubernetes bindings-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Hauptkonto-E-Mail-Adresse: Das Konto, mit dem der Anruf getätigt wurde.
     • Kubernetes-Bindungen: Die vertrauliche Kubernetes-Bindung oder ClusterRoleBinding, die erstellt wurde.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Anzeigename der Ressource: Der Kubernetes-Cluster, in dem die Aktion ausgefü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.

Schritt 2: Protokolle prüfen

1. Rufen Sie auf dem Tab Zusammenfassung der Details zum Ergebnis in der Google Cloud -Konsole den Log-Explorer auf. Klicken Sie dazu auf den Link im Feld Cloud Logging-URI.

2. Prüfen Sie mit den folgenden Filtern, ob das Hauptkonto andere Aktionen ausgeführt hat:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Ersetzen Sie Folgendes:

   • CLUSTER_NAME: Der Wert, den Sie in den Funddetails im Feld Resource display name (Anzeigename der Ressource) notiert haben.

   • PRINCIPAL_EMAIL: Der Wert, den Sie in den Details des Ergebnisses im Feld E-Mail-Adresse des Hauptkontos notiert haben.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Rechteausweitung.
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 prüfen und untersuchen, ob es die Rolle braucht, an die es gebunden ist.
4. Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten des Hauptkontos in den Logs gibt.

5. Wenn die E-Mail-Adresse des Hauptkontos kein Dienstkonto ist, wenden Sie sich an den Inhaber, um herauszufinden, ob der rechtmäßige Kontoinhaber die Aktion ausgeführt hat.

   Wenn die E‑Mail-Adresse des Hauptkontos ein IAM- oder Kubernetes-Dienstkonto ist, identifizieren Sie die Quelle der Aktion, um deren Rechtmäßigkeit festzustellen.

6. Wenn Sie einen Reaktionsplan entwickeln möchten, kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung.

Privilege Escalation: Default Compute Engine Service Account SetIAMPolicy

Erkennt, wenn das Compute Engine-Standarddienstkonto verwendet wird, um die IAM-Richtlinie für einen Cloud Run-Dienst festzulegen. Dies ist eine potenzielle Aktion nach einem Exploit, wenn ein Compute Engine-Token von einem serverlosen Dienst kompromittiert wird.

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

1. Überprüfen Sie die Audit-Logs in Cloud Logging, um festzustellen, ob dies eine vom Hauptkonto erwartete Aktivität war.
2. Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten des Hauptkontos in den Logs gibt.

Privilege Escalation: Dormant Service Account Granted Sensitive Role

Erkennt Ereignisse, bei denen einem inaktiven nutzerverwalteten Dienstkonto eine vertrauliche IAM-Rolle zugewiesen wird. Ein Dienstkonto gilt in diesem Zusammenhang als inaktiv, wenn es seit mehr als 180 Tagen nicht verwendet wurde.

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

Schritt 1: Ergebnisdetails prüfen

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

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

   Unter Was wurde erkannt?:

   • E-Mail-Adresse des Hauptkontos: Der Nutzer, der die Aktion zum Erteilen der Berechtigung ausgeführt hat.
   • Offending access grants.Principal name: Das inaktive Dienstkonto, dem die vertrauliche Rolle zugewiesen wurde.
   • Verstoßende Zugriffsgewährungen.Zugewiesene Rolle: Die zugewiesene vertrauliche IAM-Rolle

   Unter Betroffene Ressource:

   • Ressourcenanzeigename: Die Organisation, der Ordner oder das Projekt, in dem dem inaktiven Dienstkonto die vertrauliche IAM-Rolle zugewiesen wurde.

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Verwenden Sie Dienstkontotools wie die Aktivitätsanalyse, um die Aktivitäten des inaktiven Dienstkontos zu untersuchen.
2. Wenden Sie sich an den Inhaber des Felds Haupt-E-Mail-Adresse. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Protokolle prüfen

1. Klicken Sie im Detailbereich für den Befund auf dem Tab „Zusammenfassung“ unter Zugehörige Links auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.

Schritt 4: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Entfernen Sie den Zugriff des Inhabers der Haupt-E-Mail-Adresse, wenn das Konto gehackt wurde.
• Entfernen Sie die neu zugewiesene vertrauliche IAM-Rolle aus dem inaktiven Dienstkonto.
• Erwägen Sie, das möglicherweise manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das möglicherweise 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 von Cloud Customer Care reagieren
• 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.

Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access

Jemand hat eine RBAC-Bindung erstellt, die auf einen der folgenden Nutzer oder Gruppen verweist:

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

Diese Nutzer und Gruppen sind im Grunde anonym und sollten vermieden werden, wenn Rollenbindungen oder Clusterrollenbindungen für RBAC-Rollen erstellt werden. Prüfen Sie, ob die Bindung erforderlich ist. Wenn die Bindung nicht erforderlich ist, entfernen Sie sie. Weitere Informationen finden Sie in der Log-Meldung zu diesem Problem.

1. Überprüfen Sie alle erstellten Bindungen, die dem Nutzer system:anonymous, der Gruppe system:unauthenticated group oder der Gruppe system:authenticated Berechtigungen gewährt haben.
2. Stellen Sie fest, ob die Audit-Logs in Cloud Logging weitere Anzeichen für schädliche Aktivitäten des Hauptkontos enthalten.

Wenn es Anzeichen für schädliche Aktivitäten gibt, lesen Sie die Anleitung zum Prüfen und Entfernen der Bindungen, die diesen Zugriff zugelassen haben.

Privilege Escalation: 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 Privilege Escalation: 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 angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: das Konto, mit dem 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. Achten Sie in der JSON-Datei auf 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 remove_circle_outline Mitglied entfernen oder not_interested 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 „Details zu Ergebnissen“ 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.

Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials

Zur Ausweitung der Rechte hat ein potenziell böswilliger Akteur mit dem Befehl kubectl die Anfrage zur Zertifikatssignierung (Certificate Signing Request, CSR) abgefragt und dazu manipulierte Bootstrap-Anmeldedaten verwendet.

Das ist 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 Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Hauptkonto-E-Mail-Adresse: Das Konto, mit dem der Anruf getätigt wurde.
     • Methodenname: Die aufgerufene Methode.
   • Unter Betroffene Ressource:
     • Anzeigename der Ressource: Der Kubernetes-Cluster, in dem die Aktion ausgefü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.

Schritt 2: Protokolle prüfen

Wenn der Methodenname, den Sie in den Details des Ergebnisses im Feld Method name (Methodenname) notiert haben, eine GET-Methode ist, gehen Sie so vor:

1. Rufen Sie auf dem Tab Zusammenfassung der Funddetails in der Google Cloud -Konsole den Log-Explorer auf. Klicken Sie dazu auf den Link im Feld Cloud Logging-URI.
2. Prüfen Sie den Wert im Feld protoPayload.resourceName, um die spezifische Anfrage zur Zertifikatsignierung zu ermitteln.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Rechteausweitung.
2. Wenn die spezifische CSR im Logeintrag verfügbar ist, prüfen Sie die Vertraulichkeit des Zertifikats und finden Sie heraus, ob die Aktion gerechtfertigt war.
3. Wenn Sie einen Reaktionsplan entwickeln möchten, kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung.

Privilege Escalation: Impersonation Role Granted for Dormant Service Account

Erkennt Ereignisse, bei denen einem Hauptkonto eine Rolle zur Identitätsübernahme gewährt wird, mit der das Hauptkonto die Identität eines inaktiven nutzerverwalteten Dienstkontos übernehmen kann. Bei diesem Ergebnis ist das inaktive Dienstkonto die betroffene Ressource. Ein Dienstkonto gilt als inaktiv, wenn es seit mehr als 180 Tagen nicht verwendet wurde.

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

Schritt 1: Ergebnisdetails prüfen

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

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

   Unter Was wurde erkannt?:

   • E-Mail-Adresse des Hauptkontos: Der Nutzer, der die Aktion zum Erteilen der Berechtigung ausgeführt hat.
   • Rechtswidrige Zugriffsgewährungen.Name des Hauptkontos: Das Hauptkonto, dem die Identitätsübernahmerolle gewährt wurde

   Unter Betroffene Ressource:

   • Anzeigename der Ressource: Das inaktive Dienstkonto als Ressource
   • Vollständiger Projektname: Das Projekt, in dem sich das inaktive Dienstkonto befindet

Schritt 2: Angriffs- und Reaktionsmethoden untersuchen

1. Verwenden Sie Dienstkontotools wie die Aktivitätsanalyse, um die Aktivitäten des inaktiven Dienstkontos zu untersuchen.
2. Wenden Sie sich an den Inhaber des Felds Haupt-E-Mail-Adresse. Bestätigen Sie, dass die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.

Schritt 3: Protokolle prüfen

1. Klicken Sie im Detailbereich für den Befund auf dem Tab „Zusammenfassung“ unter Zugehörige Links auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.

Schritt 4: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 Maßnahme ergriffen wurde.
• Entfernen Sie den Zugriff des Inhabers der Haupt-E-Mail-Adresse, wenn das Konto gehackt wurde.
• Entfernen Sie die neu zugewiesene Identitätsübernahmerolle aus dem Zielmitglied.
• Erwägen Sie, das möglicherweise manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das möglicherweise manipulierte Projekt zu rotieren und zu löschen. Nach dem Löschen verlieren Anwendungen, die das Dienstkonto für die Authentifizierung verwenden, den Zugriff. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Anwendungen identifizieren und mit den Anwendungsbesitzern 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 von Cloud Customer Care reagieren
• 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.

Privilege Escalation: Launch of privileged Kubernetes container

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

Bei einem privilegierten Container ist das Feld privileged auf true gesetzt. Bei einem Container mit Funktionen zur Rechteausweitung ist das Feld allowPrivilegeEscalation auf true gesetzt. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter der API-Referenz zu SecurityContext v1 Core.

Schritt 1: Ergebnisdetails prüfen

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

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Hauptkonto-E-Mail-Adresse: Das Konto, mit dem 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 ausgefü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.

3. Notieren Sie sich auf dem Tab JSON die Werte der Ergebnis-Felder:

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

Schritt 2: Protokolle prüfen

1. Rufen Sie auf dem Tab Zusammenfassung der Details zum Ergebnis in der Google Cloud -Konsole den Log-Explorer auf. Klicken Sie dazu auf den Link im Feld Cloud Logging-URI.

2. Prüfen Sie mit den folgenden Filtern, ob das Hauptkonto andere Aktionen ausgeführt hat:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Ersetzen Sie Folgendes:

   • CLUSTER_NAME: Der Wert, den Sie in den Funddetails im Feld Resource display name (Anzeigename der Ressource) notiert haben.

   • PRINCIPAL_EMAIL: Der Wert, den Sie in den Details des Ergebnisses im Feld E-Mail-Adresse des Hauptkontos notiert haben.

Schritt 3: Forschungsangriffe und Reaktionsmethoden

1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Rechteausweitung.
2. Prüfen Sie, ob der erstellte Container wirklich Zugriff auf Hostressourcen und Kernel-Funktionen braucht.
3. Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten des Hauptkontos in den Logs gibt.

4. Wenn die E‑Mail-Adresse des Hauptkontos kein Dienstkonto ist, wenden Sie sich an den Inhaber, um herauszufinden, ob der rechtmäßige Kontoinhaber die Aktion ausgeführt hat.

   Wenn die E‑Mail-Adresse des Hauptkontos ein IAM- oder Kubernetes-Dienstkonto ist, identifizieren Sie die Quelle der Aktion, um deren Rechtmäßigkeit festzustellen.

5. Wenn Sie einen Reaktionsplan entwickeln möchten, kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung.

Privilege Escalation: 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 Privilege Escalation: 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 angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: Das Konto, mit dem die Änderungen vorgenommen wurden. Möglicherweise wurde es gehackt.
   • 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. Achten Sie in der JSON-Datei auf 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 „Details zu Ergebnissen“ 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.

Privilege Escalation: 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 Privilege Escalation: 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 angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Haupt-E-Mail-Adresse: Das Konto, mit dem die Änderungen vorgenommen wurden. Möglicherweise wurde es gehackt.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Name der Ressource: Die Ressource, für die 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. Achten Sie in der JSON-Datei auf die folgenden Felder.
   • groupName: die Google-Gruppe, in der die Änderungen vorgenommen wurden
   • bindingDeltas: die vertraulichen Rollen, die dieser Gruppe neu zugewiesen 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 „Details zu Ergebnissen“ 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.

Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape

Jemand hat einen Pod mit einer Namenskonvention bereitgestellt, die ähnelt der von gängigen Tools, die für Container-Escapes oder andere Angriffe auf den Cluster verwendet werden. Weitere Informationen finden Sie in der Log-Meldung für diese Benachrichtigung.

1. Bestätigen Sie, dass der Pod rechtmäßig ist.
2. Stellen Sie fest, ob die Audit-Logs in Cloud Logging weitere Anzeichen für schädliche Aktivitäten des Pods oder Hauptkontos enthalten.
3. Wenn das Hauptkonto kein IAM- oder Kubernetes-Dienstkonto ist, lassen Sie sich vom rechtmäßigen Inhaber des Kontos bestätigen, dass er die Aktion ausgeführt hat.
4. Wenn das Hauptkonto ein IAM- oder Kubernetes-Dienstkonto ist, identifizieren Sie die Quelle der Aktion, um deren Rechtmäßigkeit festzustellen.
5. Wenn der Pod nicht rechtmäßig ist, entfernen Sie ihn zusammen mit allen zugehörigen RBAC-Bindungen und Dienstkonten, die von der Arbeitslast verwendet wurden und die seine Erstellung zugelassen haben.

Privilege Escalation: Workload Created with a Sensitive Host Path Mount

Jemand hat eine Arbeitslast erstellt, die eine hostPath-Volumebereitstellung für einen sensiblen Pfad im Dateisystem des Hostknotens enthält. Der Zugriff auf diese Pfade im Hostdateisystem kann verwendet werden, um auf privilegierte oder vertrauliche Informationen auf dem Knoten zuzugreifen und Container zu verlassen. Lassen Sie nach Möglichkeit keine hostPath-Volumes in Ihrem Cluster zu. Weitere Informationen finden Sie in der Log-Meldung für diese Benachrichtigung.

1. Überprüfen Sie die Arbeitslast, um festzustellen, ob dieses hostPath-Volume für die beabsichtigte Funktion erforderlich ist. Wenn ja, achten Sie darauf, dass der Pfad zu einem möglichst spezifischen Verzeichnis führt. Verwenden Sie z. B. /etc/myapp/myfiles statt / oder /etc.
2. Stellen Sie fest, ob die Audit-Logs in Cloud Logging weitere Anzeichen für schädliche Aktivitäten im Zusammenhang mit dieser Arbeitslast enthalten.

Informationen zum Blockieren von hostPath-Volume-Bereitstellungen im Cluster finden Sie in der Anleitung zum Erzwingen von Pod-Sicherheitsstandards.

Privilege Escalation: Workload with shareProcessNamespace enabled

Jemand hat eine Arbeitslast mit der Option shareProcessNamespace auf true bereitgestellt, sodass alle Container denselben Linux-Prozess-Namespace verwenden können. Dadurch könnte ein nicht vertrauenswürdiger oder kompromittierter Container Berechtigungen eskalieren, indem er auf Umgebungsvariablen, Arbeitsspeicher und andere vertrauliche Daten von Prozessen zugreift und diese steuert, die in anderen Containern ausgeführt werden. Bei einigen Arbeitslasten ist diese Funktion aus legitimen Gründen erforderlich, z. B. für Sidecar-Container für die Log-Verarbeitung oder für Debugging-Container. Weitere Informationen finden Sie in der Log-Meldung für diese Benachrichtigung.

1. Bestätigen Sie, dass die Arbeitslast tatsächlich Zugriff auf einen freigegebenen Prozess-Namespace für alle Container in der Arbeitslast benötigt.
2. Prüfen Sie, ob die Audit-Logs in Cloud Logging weitere Anzeichen für schädliche Aktivitäten des Hauptkontos enthalten.
3. Wenn das Hauptkonto kein IAM- oder Kubernetes-Dienstkonto ist, lassen Sie sich vom Inhaber des Kontos bestätigen, dass er die Aktion ausgeführt hat.
4. Wenn das Hauptkonto ein IAM- oder Kubernetes-Dienstkonto ist, stellen Sie fest, ob der Grund für die Ausführung dieser Aktion durch das Dienstkonto rechtmäßig ist.

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 angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Schweregrad: Die dem Ergebnis zugewiesene Risikostufe. Die Schweregrad ist 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.
     • Hauptkonto-E-Mail-Adresse: das potenziell manipulierte Dienstkonto.
     • Anrufer-IP: die interne oder externe IP-Adresse
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Ressourcenname:
     • Vollständiger Projektname: 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 das vollständige JSON für das Ergebnis aufzurufen.

Schritt 2: Projekt- und Dienstkontoberechtigungen prüfen

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

   IAM aufrufen

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

3. Geben Sie auf der angezeigten Seite im Feld Filter den in E-Mail-Adresse des Hauptkontos 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. Klicken Sie im Bereich „Details zu Ergebnissen“ 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 ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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.

Metadaten-Erkennung für Compute Engine Administrator

Persistence: GCE Admin Added SSH Key

Persistence: GCE Admin Added Startup Script

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 Google Workspace-Logs auf Organisationsebene vorliegen, 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.

Initial Access: Suspicious Login Blocked

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

Initial Access: Account Disabled Hijacked

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

Impair Defenses: Two Step Verification Disabled

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

Initial Access: Government Based Attack

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

Persistence: SSO Enablement Toggle

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

Persistence: SSO Settings Changed

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

Impair Defenses: Strong Authentication Disabled

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

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 durchsucht 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

Cloud IDS-Ergebnisse werden von Cloud IDS generiert. Cloud IDS ist ein Sicherheitsdienst, der den Traffic zu und von IhrenGoogle Cloud -Ressourcen auf Bedrohungen überwacht. Wenn Cloud IDS eine Bedrohung erkennt, werden Informationen zur Bedrohung, z. B. die Quell-IP-Adresse, die Zieladresse und die Portnummer, an Event Threat Detection gesendet, das dann ein Ergebnis zur Bedrohung generiert.

Schritt 1: Ergebnisdetails prüfen

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

2. Sehen Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die aufgeführten Werte in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Protokoll: Das verwendete Netzwerkprotokoll
     • Ereigniszeit: Zeitpunkt des Ereignisses
     • Beschreibung: Weitere Informationen zum Ergebnis
     • Schweregrad: Der Schweregrad der Benachrichtigung
     • Ziel-IP: Die Ziel-IP-Adresse des Netzwerkverkehrs
     • Zielport: Der Zielport des Netzwerk-Traffics
     • Quell-IP: Die Quell-IP-Adresse des Netzwerk-Traffics
     • Quellport: Der Quellport des Netzwerk-Traffics
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Ressourcenname: 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 in der Threat Vault von Palo Alto Networks zu suchen.
   • Detection Service
     • Ergebniskategorie: Der Cloud IDS-Bedrohungsname

3. Klicken Sie auf den Tab JSON, um das vollständige JSON für das Ergebnis aufzurufen.

Schritt 2: Angriffs- und Reaktionsmethoden recherchieren

Nachdem Sie die Details des Ergebnisses geprüft haben, finden Sie in der Cloud IDS-Dokumentation zum Untersuchen von Bedrohungsbenachrichtigungen Informationen zur Ermittlung einer geeigneten Reaktion.

Weitere Informationen zum erkannten Ereignis finden Sie im ursprünglichen Logeintrag. Klicken Sie dazu in den Details des Findings auf den Link im Feld Cloud Logging-URI.

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 häufig Ausbeutungstools und Malware nach dem anfänglichen Manipulationsprozess. Es ist wichtig, dass Ihre Container unveränderbar sind. Dies ist ein Ergebnis mit niedriger Schwere, da Ihre Organisation diese Best Practice möglicherweise nicht befolgt. Es gibt entsprechende Execution: Added Malicious Binary Executed-Ergebnisse, wenn der Hash der Binärdatei ein bekannter Kompromittierungsindikator (IoC) ist. So reagieren Sie auf dieses Ergebnis:

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 angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Programmbinärdatei: 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 Ressourcenname: Der vollständige Ressourcenname des Clusters, einschließlich Projektnummer, Standort und Clustername.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • VirusTotal-Indikator: Link zur VirusTotal-Analyseseite.

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: der Name des bereitgestellten Container-Images.
     • VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.

4. Suchen Sie nach anderen Ergebnissen, die für diesen Container zu einem ähnlichen Zeitpunkt aufgetreten sind. Zugehörige Ergebnisse können darauf hindeuten, dass diese Aktivität böswillig war und nicht auf einen Verstoß gegen Best Practices zurückzuführen ist.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster 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 in der Zeile Vollständiger Ressourcenname auf dem Tab Zusammenfassung der Ergebnisdetails 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. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten auf.

   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 Cluster, der in der Zeile Vollständiger Ressourcenname auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist, 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. Rufen Sie in der Google Cloud Console den Log-Explorer auf.

   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 die Google Cloud Console auf.

   Google Cloud Konsole ö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 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. Prüfen Sie den SHA-256-Hashwert für die als schädlich gekennzeichnete Binärdatei auf VirusTotal, indem Sie auf den Link in VirusTotal-Indikator klicken. VirusTotal ist ein Alphabet-eigener Dienst, der Kontext zu potenziell schädlichen Dateien, URLs, Domains und IP-Adressen bereitstellt.
3. Wenn Sie einen Reaktionsplan entwickeln möchten, kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung und der VirusTotal-Analyse.

Schritt 7: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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. So 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 wichtig, dass Ihre Container unveränderbar 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 Kompromittierungsindikator (Indicator of Compromise, IoC) 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. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Binärprogramm des Programms: der vollständige Pfad der Prozessbinärdatei, die die Bibliothek geladen hat.
     • Bibliotheken: Details zur hinzugefügten Bibliothek.
     • Arguments: die Argumente, die beim Aufrufen der Prozessbinärdatei angegeben werden.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Ressourcenname: der vollständige Ressourcenname des Clusters.
   • Weitere Informationen, insbesondere die folgenden Felder:
     • VirusTotal-Indikator: Link zur VirusTotal-Analyseseite.

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. Suchen Sie nach anderen Ergebnissen, die für diesen Container zu einem ähnlichen Zeitpunkt aufgetreten sind. Zugehörige Ergebnisse können darauf hindeuten, dass diese Aktivität böswillig war und nicht auf einen Verstoß gegen Best Practices zurückzuführen ist.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster 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. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten auf.

   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 Cluster, der in der Zeile Vollständiger Ressourcenname auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist, 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. Rufen Sie in der Google Cloud Console den Log-Explorer auf.

   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 die Google Cloud Console auf.

   Google Cloud Konsole ö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. Prüfen Sie den SHA-256-Hashwert für die als schädlich gekennzeichnete Binärdatei auf VirusTotal, indem Sie auf den Link in VirusTotal-Indikator klicken. VirusTotal ist ein Alphabet-eigener Dienst, der Kontext zu potenziell schädlichen Dateien, URLs, Domains und IP-Adressen bereitstellt.
3. Wenn Sie einen Reaktionsplan entwickeln möchten, kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung und der VirusTotal-Analyse.

Schritt 7: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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 sollte, erstellen Sie das Container-Image mit der Bibliothek neu. So 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.

Command and Control: Steganography Tool Detected

Es wurde ein Prozess erkannt, der Steganografietools verwendet, die häufig in Unix-ähnlichen Distributionen zu finden sind, um möglicherweise die Kommunikation zu verschleiern. Dieses Verhalten deutet auf einen Versuch hin, C2-Traffic (Command-and-Control) oder vertrauliche Daten in scheinbar harmlosen digitalen Nachrichten zu verbergen, die mit einer externen Einheit ausgetauscht werden. Angreifer verwenden häufig Steganografie, um die Netzwerküberwachung zu umgehen und schädliche Aktivitäten weniger auffällig zu machen. Das Vorhandensein dieser Tools deutet auf einen bewussten Versuch hin, die illegale Datenübertragung zu verschleiern. Dieses Verhalten kann zu weiteren Kompromittierungen oder zur Exfiltration vertraulicher Informationen führen. Die verborgenen Inhalte zu identifizieren ist entscheidend, um die damit verbundenen Risiken genau einschätzen zu können.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Command and Control: Steganography Tool Detected-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Programmbinärdatei: der absolute Pfad der ausgeführten Binärdatei.
     • Argumente: Die Argumente, die während der Ausführung der Binärdatei übergeben werden.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Ressourcenname: 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. Achten Sie in der JSON-Datei auf die folgenden Felder.

   • resource:
     • project_display_name: der Name des Projekts, das den Cluster enthält.
   • finding:
     • processes:
     • binary:
       • path: der vollständige Pfad der ausgeführten Binärdatei.
     • args: die Argumente, die beim Ausführen der Binärdatei angegeben wurden.
   • 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 bereitgestellten Container-Images.
     • VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.

5. Suchen Sie nach anderen Ergebnissen, die für diesen Container zu einem ähnlichen Zeitpunkt aufgetreten sind. Zugehörige Ergebnisse deuten möglicherweise darauf hin, dass diese Aktivität böswillig war und nicht auf einem Verstoß gegen Best Practices beruht.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster auf.

   Zur Seite „Kubernetes-Cluster“

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 in der Zeile Vollständiger Ressourcenname auf dem Tab Zusammenfassung der Ergebnisdetails 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. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten auf.

   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 Cluster, der in der Zeile Vollständiger Ressourcenname auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist, 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. Rufen Sie in der Google Cloud Console den Log-Explorer auf.

   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 die Google Cloud Console auf.

   Google Cloud Konsole ö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 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 ausgeführte Binärdatei 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 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: Data Obfuscation: Steganography.
2. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 7: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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.

Credential Access: Find Google Cloud Credentials

Es wurde ein Prozess erkannt, der nach Google Cloud -Anmeldedaten sucht. Dieses Verhalten deutet auf einen Versuch hin, gespeicherte Secrets zu finden und zu extrahieren, die verwendet werden könnten, um Berechtigungen zu eskalieren, auf eingeschränkte Ressourcen zuzugreifen oder sich seitlich in der Umgebung zu bewegen. Angreifer suchen häufig nach Anmeldedaten, um sich unbefugten Zugriff auf Cloud-Ressourcen zu verschaffen, Berechtigungen zu eskalieren oder schädliche Aktionen auszuführen.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Credential Access: Find Google Cloud Credentials-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Programmbinärdatei: der absolute Pfad der ausgeführten Binärdatei.
     • Argumente: Die Argumente, die während der Ausführung der Binärdatei übergeben werden.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Ressourcenname: 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. Achten Sie in der JSON-Datei auf die folgenden Felder.

   • resource:
     • project_display_name: der Name des Projekts, das den Cluster enthält.
   • finding:
     • processes:
     • binary:
       • path: der vollständige Pfad der ausgeführten Binärdatei.
     • args: die Argumente, die beim Ausführen der Binärdatei angegeben wurden.
   • 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 bereitgestellten Container-Images.
     • VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.

5. Suchen Sie nach anderen Ergebnissen, die für diesen Container zu einem ähnlichen Zeitpunkt aufgetreten sind. Zugehörige Ergebnisse deuten möglicherweise darauf hin, dass diese Aktivität böswillig war und nicht auf einem Verstoß gegen Best Practices beruht.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster auf.

   Zur Seite „Kubernetes-Cluster“

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 in der Zeile Vollständiger Ressourcenname auf dem Tab Zusammenfassung der Ergebnisdetails 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. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten auf.

   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 Cluster, der in der Zeile Vollständiger Ressourcenname auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist, 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. Rufen Sie in der Google Cloud Console den Log-Explorer auf.

   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 die Google Cloud Console auf.

   Konsole Google Cloud ö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 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. 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: Unsecured Credentials: Private Keys (Nicht gesicherte Anmeldedaten: Private Schlüssel).
2. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 7: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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.

Credential Access: GPG Key Reconnaissance

Es wurde ein Prozess erkannt, der nach GPG-Schlüsseln sucht. Dieses Verhalten deutet auf einen Versuch hin, gespeicherte Sicherheitsschlüssel zu finden und zu extrahieren, die zum Verschlüsseln und Entschlüsseln von Dokumenten sowie zum Authentifizieren von Dokumenten mit digitalen Signaturen verwendet werden. Angreifer verwenden Sicherheitsschlüssel, um sich unbefugten Zugriff auf wichtige Informationen und Systeme zu verschaffen. Daher ist dies eine Erkennung mit hohem Schweregrad, die sofortige Untersuchungen erfordert.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Credential Access: GPG Key Reconnaissance-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Programmbinärdatei: der absolute Pfad der ausgeführten Binärdatei.
     • Argumente: Die Argumente, die während der Ausführung der Binärdatei übergeben werden.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Ressourcenname: 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. Achten Sie in der JSON-Datei auf die folgenden Felder.

   • resource:
     • project_display_name: der Name des Projekts, das den Cluster enthält.
   • finding:
     • processes:
     • binary:
       • path: der vollständige Pfad der ausgeführten Binärdatei.
     • args: die Argumente, die beim Ausführen der Binärdatei angegeben wurden.
   • 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 bereitgestellten Container-Images.
     • VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.

5. Suchen Sie nach anderen Ergebnissen, die für diesen Container zu einem ähnlichen Zeitpunkt aufgetreten sind. Zugehörige Ergebnisse deuten möglicherweise darauf hin, dass diese Aktivität böswillig war und nicht auf einem Verstoß gegen Best Practices beruht.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster auf.

   Zur Seite „Kubernetes-Cluster“

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 in der Zeile Vollständiger Ressourcenname auf dem Tab Zusammenfassung der Ergebnisdetails 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. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten auf.

   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 Cluster, der in der Zeile Vollständiger Ressourcenname auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist, 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. Rufen Sie in der Google Cloud Console den Log-Explorer auf.

   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 die Google Cloud Console auf.

   Google Cloud Konsole ö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 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. 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: Unsecured Credentials: Private Keys (Nicht gesicherte Anmeldedaten: Private Schlüssel).
2. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 7: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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.

Credential Access: Search Private Keys or Passwords

Es wurde ein Prozess erkannt, der im Container nach privaten Schlüsseln, Anmeldedaten oder anderen sensiblen Authentifizierungsinformationen sucht. Dieses Verhalten deutet auf einen Versuch hin, gespeicherte Secrets zu finden und zu extrahieren, die verwendet werden könnten, um Berechtigungen zu eskalieren, auf eingeschränkte Ressourcen zuzugreifen oder sich seitlich in der Umgebung zu bewegen. Angreifer suchen häufig nach SSH-Schlüsseln, API-Tokens oder Datenbankanmeldedaten, um unbefugten Zugriff auf kritische Systeme zu erhalten. Daher ist dies eine Erkennung mit hohem Schweregrad, die sofortige Untersuchungen erfordert.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Credential Access: Search Private Keys or Passwords-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Programmbinärdatei: der absolute Pfad der ausgeführten Binärdatei.
     • Argumente: Die Argumente, die während der Ausführung der Binärdatei übergeben werden.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Ressourcenname: 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. Achten Sie in der JSON-Datei auf die folgenden Felder.

   • resource:
     • project_display_name: der Name des Projekts, das den Cluster enthält.
   • finding:
     • processes:
     • binary:
       • path: der vollständige Pfad der ausgeführten Binärdatei.
     • args: die Argumente, die beim Ausführen der Binärdatei angegeben wurden.
   • 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 bereitgestellten Container-Images.
     • VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.

5. Suchen Sie nach anderen Ergebnissen, die für diesen Container zu einem ähnlichen Zeitpunkt aufgetreten sind. Zugehörige Ergebnisse deuten möglicherweise darauf hin, dass diese Aktivität böswillig war und nicht auf einem Verstoß gegen Best Practices beruht.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster auf.

   Zur Seite „Kubernetes-Cluster“

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 in der Zeile Vollständiger Ressourcenname auf dem Tab Zusammenfassung der Ergebnisdetails 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. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten auf.

   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 Cluster, der in der Zeile Vollständiger Ressourcenname auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist, 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. Rufen Sie in der Google Cloud Console den Log-Explorer auf.

   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 die Google Cloud Console auf.

   Konsole Google Cloud ö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 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 ausgeführte Binärdatei 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 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: Unsichere Anmeldedaten: Anmeldedaten in Dateien.
2. Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.

Schritt 7: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. 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.

Defense Evasion: Base64 ELF File Command Line

Es wurde ein Prozess ausgeführt, der ein Argument enthält, das eine ELF-Datei (Executable and Linkable Format) ist. Wenn die Ausführung einer codierten ELF-Datei erkannt wird, ist das ein Signal dafür, dass ein Angreifer versucht, Binärdaten für die Übertragung an reine ASCII-Befehlszeilen zu codieren. Angreifer können diese Technik verwenden, um die Erkennung zu umgehen und bösartigen Code auszuführen, der in eine ELF-Datei eingebettet ist.

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

Schritt 1: Ergebnisdetails prüfen

1. Öffnen Sie ein Defense Evasion: Base64 ELF File Command Line-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

   • Was wurde erkannt?, insbesondere die folgenden Felder:
     • Programmbinärdatei: der absolute Pfad der ausgeführten Binärdatei.
     • Argumente: Die Argumente, die während der Ausführung der Binärdatei übergeben werden.
   • Betroffene Ressource, insbesondere die folgenden Felder:
     • Vollständiger Ressourcenname: 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. Achten Sie in der JSON-Datei auf die folgenden Felder.

   • resource:
     • project_display_name: der Name des Projekts, das den Cluster enthält.
   • finding:
     • processes:
     • binary:
       • path: der vollständige Pfad der ausgeführten Binärdatei.
     • args: die Argumente, die beim Ausführen der Binärdatei angegeben wurden.
   • 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 bereitgestellten Container-Images.
     • VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.

5. Suchen Sie nach anderen Ergebnissen, die für diesen Container zu einem ähnlichen Zeitpunkt aufgetreten sind. Zugehörige Ergebnisse deuten möglicherweise darauf hin, dass diese Aktivität böswillig war und nicht auf einem Verstoß gegen Best Practices beruht.

Schritt 2: Cluster und Knoten prüfen

1. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster auf.

   Zur Seite „Kubernetes-Cluster“

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 in der Zeile Vollständiger Ressourcenname auf dem Tab Zusammenfassung der Ergebnisdetails 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. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten auf.

   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 Cluster, der in der Zeile Vollständiger Ressourcenname auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist, 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. Rufen Sie in der Google Cloud Console den Log-Explorer auf.

   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 die Google Cloud Console auf.

   Konsole Google Cloud ö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 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 ausgeführte Binärdatei 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 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.