Dieses Thema bietet informelle Anleitungen zum Untersuchen und Reagieren von Bedrohungen. Verwenden Sie zusätzliche Ressourcen, um den Security Command Center-Ergebnissen Kontext hinzuzufügen. Mit den folgenden Schritten können Sie verstehen, was bei einem potenziellen Angriff passiert ist, und mögliche Antworten für die betroffenen Ressourcen entwickeln.
Die Techniken auf dieser Seite können nicht garantiert werden, dass sie vor vorherigen, aktuellen oder zukünftigen Bedrohungen wirksam sind. Unter Bedrohungen beheben erfahren Sie, warum Security Command Center keine offizielle Korrekturmaßnahme für Bedrohungen bietet.
Hinweis
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 durch die Identifizierung bekannter Angreifer Taktiken, Techniken und Verfahren in Ihrem Logging-Stream von früheren Verhaltensweisen Ihrer Organisation oder Ihres Projekts. Wenn Sie die Premium-Stufe von Security Command Center auf Organisationsebene aktivieren, können mit Event Threat Detection auch Ihre Google Workspace-Protokolle gescannt werden.
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 Premium-Stufe von Security Command Center auf Organisationsebene können Sie auch Ergebnisse konfigurieren, die in Cloud Logging geschrieben werden sollen.
Ergebnisse prüfen
So prüfen Sie die gefundenen Bedrohungen in der Google Cloud Console:
Rufen Sie in der Google Cloud Console die Seite Ergebnisse von Security Command Center auf.
Wählen Sie bei Bedarf Ihr Google Cloud-Projekt, Ihren Ordner oder Unternehmen.
Klicken Sie im Bereich Schnellfilter auf einen geeigneten Filter, um das gewünschte Ergebnis in der Tabelle Ergebnisse der Ergebnisabfrage anzuzeigen. Wenn Sie beispielsweise im Unterabschnitt Anzeigename der Quelle die Option Event Threat Detection oder Container Threat Detection auswählen, werden in den Ergebnissen nur Ergebnisse des ausgewählten Dienstes angezeigt.
Die Tabelle enthält die Ergebnisse für die ausgewählte Quelle.
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 Details des Ergebnisses an.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.
In den folgenden Abschnitten werden potenzielle Antworten auf Bedrohungsergebnisse beschrieben.
Deaktivierung von Ergebnissen zu Bedrohungen
Nachdem Sie ein Problem behoben haben,
das ein Bedrohungsergebnis ausgelöst hat,
Security Command Center legt den Status des Ergebnisses nicht automatisch fest
an INACTIVE
. Der Status eines gefundenen Bedrohungen bleibt ACTIVE
, es sei denn, Sie
state
manuell auf INACTIVE
festlegen.
Bei einem falsch positiven Ergebnis sollten Sie den Status des Ergebnisses so belassen:
ACTIVE
und blenden Sie stattdessen das Ergebnis aus.
Für dauerhafte oder wiederkehrende falsch-positive Ergebnisse erstellen Sie eine Ausblendungsregel. Das Festlegen einer Ausblendungsregel kann die Anzahl der benötigten Ergebnisse reduzieren was es einfacher macht, eine wahre Bedrohung zu erkennen.
Bei einer echten Bedrohung müssen Sie Folgendes tun, bevor Sie den Status des Ergebnisses auf INACTIVE
festlegen:
die Bedrohung zu beseitigen und die
erkannte Bedrohung, das Ausmaß des Angriffs und alle anderen damit verbundenen Erkenntnisse
und Probleme.
Informationen zum Ausblenden eines Ergebnisses oder zum Ändern seines Status finden Sie in den folgenden Themen:
Event Threat Detection-Antworten
Weitere Informationen zu Event Threat Detection finden Sie unter Funktionsweise von Event Threat Detection.
Dieser Abschnitt enthält keine Antworten auf Ergebnisse, die von benutzerdefinierten Modulen für Event Threat Detection generiert wurden, da die empfohlenen Maßnahmen für diese Erkennungsmechanismen von Ihrer Organisation festgelegt werden.
Evasion: Access from Anonymizing Proxy
Der anomale Zugriff von einem anonymen Proxy wird durch Untersuchung der Cloud-Audit-Logs auf Google Cloud-Dienständerungen erkannt, die von anonymen Proxy-IP-Adressen wie Tor-IP-Adressen stammen.
So reagieren Sie auf diese Ergebnisse:
Schritt 1: Ergebnisdetails prüfen
- Öffnen Sie ein
Evasion: Access from Anonymizing Proxy
-Ergebnis wie unter Ergebnisse prüfen. Der Bereich mit den Details zum Ergebnis wird geöffnet. Daraufhin wird der Tab Zusammenfassung angezeigt. Sehen Sie sich auf dem Tab Zusammenfassung des Bereichs „Ergebnisdetails“ die Werte in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Haupt-E-Mail-Adresse: Das Konto, das die Änderungen vorgenommen hat (ein potenziell gehacktes Konto).
- IP-Adresse: Die Proxy-IP-Adresse, an der die Änderungen vorgenommen werden aus.
- 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 allen ähnlichen Ergebnissen
- Erkannte Daten, insbesondere die folgenden Felder:
Optional: Klicken Sie auf den Tab JSON, um weitere Ergebnisfelder aufzurufen.
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
- Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Proxy: Multi-Hop-Proxy.
- Wenden Sie sich im Feld
principalEmail
an den Inhaber des Kontos. Bestätigen Sie, dass die Aktion vom legitimen Inhaber ausgeführt wurde. - Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
Defense Evasion: Breakglass Workload Deployment Created
Breakglass Workload Deployment Created
wird erkannt, indem in Cloud-Audit-Logs geprüft wird, ob es Bereitstellungen für Arbeitslasten gibt, bei denen das Break-Glass-Flag verwendet wird, um die Einstellungen für die Binärautorisierung zu überschreiben.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
- Öffnen Sie das Ergebnis
Defense Evasion: Breakglass Workload Deployment Created
. wie unter Ergebnisse überprüfen beschrieben. Das Panel für die werden die Ergebnisdetails mit dem Tab Zusammenfassung geöffnet. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- E-Mail-Adresse des Hauptkontos: das Konto, über das die Änderung vorgenommen wurde.
- Methodenname: die aufgerufene Methode.
- Kubernetes-Pods: Pod-Name und Namespace.
- Betroffene Ressource, insbesondere das folgende Feld:
- Anzeigename der Ressource: der GKE-Namespace, wobei die Bereitstellung erfolgte.
- Weitere Informationen:
- Cloud Logging-URI: Link zu Logging-Einträgen.
- MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation.
- Ähnliche Ergebnisse: Links zu allen ähnlichen Ergebnissen
- Was erkannt wurde, insbesondere die folgenden Felder:
Schritt 2: Protokolle prüfen
- Klicken Sie auf dem Tab Zusammenfassung der Details zur Feststellung in der Google Cloud Console auf den Link im Feld Cloud Logging URI, um den Log-Explorer aufzurufen.
- Prüfen Sie den Wert im Feld
protoPayload.resourceName
, um die entsprechende Anfrage zur Zertifikatsignierung zu ermitteln. Prüfen Sie mit den folgenden Methoden, welche Aktionen das Hauptkonto ausgeführt hat: Filter:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
Ersetzen Sie Folgendes:
CLUSTER_NAME
: der Wert, den Sie im Feld Anzeigename der Ressource in den Ergebnisdetails.PRINCIPAL_EMAIL
: Der Wert, den Sie in den Details zur Feststellung im Feld Haupt-E-Mail-Adresse angegeben haben.
Schritt 3: Forschungsangriffe und Reaktionsmethoden
- Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Defense Evasion: Breakglass Workload Deployment.
- Klicken Sie auf den Link in der Zeile Ähnliche Ergebnisse auf dem Tab Zusammenfassung der Ergebnisdetails, um ähnliche Ergebnisse aufzurufen.
- 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 durch die Prüfung von Cloud-Audit-Logs erkannt
um zu sehen, ob es Aktualisierungen für Arbeitslasten gibt, die das Break-Glass-Flag zum Überschreiben verwenden
Steuerelemente für die Binärautorisierung
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
- Ö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. Darauf ist der Tab Zusammenfassung zu sehen. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- E-Mail-Adresse des Hauptkontos: das Konto, über das die Änderung vorgenommen wurde.
- Methodenname: die aufgerufene Methode.
- Kubernetes-Pods: Pod-Name und Namespace.
- Betroffene Ressource, insbesondere das folgende Feld:
- Anzeigename der Ressource: der GKE-Namespace, wobei die Aktualisierung durchgeführt wurde.
- Weitere Informationen:
- Cloud Logging-URI: Link zu Logging-Einträgen.
- MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation.
- Ähnliche Ergebnisse: Links zu allen ähnlichen Ergebnissen
- Was erkannt wurde, insbesondere die folgenden Felder:
Schritt 2: Protokolle prüfen
- Klicken Sie auf dem Tab Zusammenfassung der Details zur Feststellung in der Google Cloud Console auf den Link im Feld Cloud Logging URI, um den Log-Explorer aufzurufen.
- Prüfen Sie den Wert im Feld
protoPayload.resourceName
, um die entsprechende Anfrage zur Zertifikatsignierung zu ermitteln. Prüfen Sie mit den folgenden Methoden, welche Aktionen das Hauptkonto ausgeführt hat: Filter:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
Ersetzen Sie Folgendes:
CLUSTER_NAME
: der Wert, den Sie im Feld Anzeigename der Ressource in den Ergebnisdetails.PRINCIPAL_EMAIL
: Der Wert, den Sie in den Details zur Feststellung im Feld Haupt-E-Mail-Adresse angegeben haben.
Schritt 3: Forschungsangriffe und Reaktionsmethoden
- Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Defense Evasion: Breakglass Workload Deployment.
- Wenn Sie ähnliche Ergebnisse ansehen möchten, klicken Sie auf den Link unter Ähnliche Ergebnisse. in der Zeile Ähnliche Ergebnisse auf dem Tab Zusammenfassung des Ergebnisdetails.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
Defense Evasion: Manually Deleted Certificate Signing Request (CSR)
Jemand hat eine Anfrage zur Zertifikatssignierung (Certificate Signing Request, CSR) manuell gelöscht. CSRs werden automatisch von einem Garbage Collection Controller entfernt. Böswillige Akteure können sie jedoch manuell löschen, um eine Erkennung zu vermeiden. Wenn der gelöschte CSR für ein genehmigtes und ausgestelltes Zertifikat war, hat der potenziell böswillige Akteur jetzt eine zusätzliche Authentifizierungsmethode für den Zugriff auf den Cluster. Berechtigungen die mit dem Zertifikat verknüpft sind, variieren je nach Art des Zertifikats, aber sehr privilegiert sein. Kubernetes unterstützt keinen Widerruf von Zertifikaten. Weitere Informationen finden Sie in der Lognachricht zu dieser Benachrichtigung.
- Ü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. - Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten gibt:
in den Audit-Logs in Cloud Logging. Beispiel:
- Hat sich das Hauptkonto, das die CSR gelöscht hat, von der Person unterschieden, die die CSR erstellt hat oder genehmigt?
- Hat das Hauptkonto versucht, das Hauptkonto anzufordern, zu erstellen, zu genehmigen oder zu löschen Kundendienstmitarbeiter kontaktieren?
- 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 auf Änderungen an VPC Service Controls-Perimetern untersucht die den Schutz des Perimeters reduzieren 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
- Ö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. Darauf ist der Tab Zusammenfassung zu sehen. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere das folgende Feld:
- E-Mail-Adresse des Hauptkontos: das Konto, über das 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 allen ähnlichen Ergebnissen
- Was erkannt wurde, insbesondere das folgende Feld:
Klicken Sie auf den Tab JSON.
Achten Sie in der JSON-Datei auf die folgenden Felder.
sourceProperties
properties
name
: der Name des geänderten VPC Service Controls-PerimeterspolicyLink
: der Link zur Zugriffsrichtlinie, die den Perimeter steuertdelta
: die Änderungen, entwederREMOVE
oderADD
, an einem Perimeter, der den Schutz reduziert hatrestricted_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
- Klicken Sie im Bereich „Details zu Ergebnissen“ auf dem Tab Zusammenfassung auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.
- 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
- Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Defense Evasion: Modify Authentication Process.
- Klicken Sie auf den Link in der Zeile Ähnliche Ergebnisse auf dem Tab Zusammenfassung der Ergebnisdetails, um ähnliche Ergebnisse aufzurufen.
- 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 diese Feststellung geeignet, kann sich aber 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 der der Standardarbeitslasten ähnelt, die GKE für den regulären Clusterbetrieb erstellt. Diese Technik wird als Masquerading bezeichnet. Weitere Informationen finden Sie in der Protokollmeldung zu dieser Benachrichtigung.
- Bestätigen Sie, dass der Pod rechtmäßig ist.
- Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten auf dem Pod oder in den Audit-Logs in Cloud Logging.
- Wenn das Hauptkonto kein Dienstkonto ist (IAM oder Kubernetes), wenden Sie sich an den Kontoinhaber, um zu erfahren, ob der rechtmäßige Kontoinhaber die Aktion durchgeführt hat.
- Wenn das Hauptkonto ein Dienstkonto ist (IAM oder Kubernetes), um die Quelle der Aktion zu ermitteln, um ihre Rechtmäßigkeit zu ermitteln.
- Wenn der Pod nicht legitim ist, entfernen Sie ihn zusammen mit der zugehörigen RBAC Bindungen und Dienstkonten, die die Arbeitslast verwendet hat und die ihre Erstellung.
Discovery: Can get sensitive Kubernetes object check
Ein potenziell böswilliger Akteur versucht herauszufinden, welche sensiblen Objekte in
GKE, die mit dem Befehl kubectl
auth can-i get
abgefragt werden können. Insbesondere
Der Akteur hat 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
- Ergebnis
Discovery: Can get sensitive Kubernetes object check
öffnen als finden Sie im Abschnitt Ergebnisse überprüfen. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Feldern:
- Unter Was wurde erkannt:
- Kubernetes-Zugriffsüberprüfungen: Die angeforderten Informationen zur Zugriffsüberprüfung basierend auf der
SelfSubjectAccessReview
-K8s-Ressource. - E-Mail-Adresse des Hauptkontos: das Konto, von dem der Aufruf stammt.
- Kubernetes-Zugriffsüberprüfungen: Die angeforderten Informationen zur Zugriffsüberprüfung basierend auf der
- Unter Betroffene Ressource:
- Anzeigename der Ressource: der Kubernetes-Cluster, in dem die Aktion ausgeführt wird aufgetreten.
- Unter Weitere Informationen:
- Cloud Logging-URI: Link zu Logging-Einträgen.
- Unter Was wurde erkannt:
Schritt 2: Protokolle prüfen
- Klicken Sie auf dem Tab Zusammenfassung im Bereich mit den Details zum Ergebnis auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.
Prüfen Sie auf der Seite, die geladen wird, mithilfe der folgenden Filter, ob der Hauptnutzer 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 im Feld Anzeigename der Ressource in den Ergebnisdetails.PRINCIPAL_EMAIL
: Der Wert, den Sie in den Details zur Feststellung im Feld Haupt-E-Mail-Adresse angegeben haben.
Schritt 3: Forschungsangriffe und Reaktionsmethoden
- Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Discovery
- Prüfen Sie die Empfindlichkeit des abgefragten Objekts und stellen Sie fest, ob weitere Anzeichen schädlicher Aktivitäten des Hauptkontos in den Logs.
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 Zugriffsprüfung, um deren und Legitimität.
Um einen Reaktionsplan zu entwickeln, kombinieren Sie Ihre MITRE-Studien.
Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments
Jemand hat einen Pod erstellt, der Befehle oder Argumente enthält, die normalerweise mit einer Reverse-Shell in Verbindung gebracht werden. Angreifer verwenden Reverse-Shells, um ihren ursprünglichen Zugriff auf einen Cluster zu erweitern oder aufrechtzuerhalten und beliebige Befehle auszuführen. Weitere Informationen finden Sie in der Lognachricht zu diesem Benachrichtigung.
- Prüfen Sie, ob der Pod einen rechtmäßigen Grund hat, diese Befehle und Argumente anzugeben.
- Prüfen Sie, ob die Audit-Logs in Cloud Logging weitere Anzeichen für schädliche Aktivitäten des Pods oder Hauptkontos enthalten.
- Wenn das Hauptkonto kein Dienstkonto ist (IAM oder Kubernetes), wenden Sie sich an den Kontoinhaber, um zu erfahren, ob der rechtmäßige Kontoinhaber die Aktion durchgeführt hat.
- 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.
- Wenn der Pod nicht legitim ist, entfernen Sie ihn zusammen mit der zugehörigen RBAC Bindungen und Dienstkonten, die die Arbeitslast verwendet hat und die ihre Erstellung.
Execution: Suspicious Exec or Attach to a System Pod
Jemand hat die Befehle exec
oder attach
verwendet, um eine Shell aufzurufen oder einen Befehl in einem Container auszuführen, der im Namespace kube-system
ausgeführt wird. Diese Methoden werden manchmal für legitime Zwecke zur Fehlerbehebung verwendet. Die kube-system
namespace
ist jedoch für Systemobjekte vorgesehen, die von Kubernetes erstellt wurden und für unerwartete
sollten Sie die Ausführung von
Befehlen oder die Shell-Erstellung überprüfen. Weitere Informationen finden Sie in der Protokollmeldung zu dieser Benachrichtigung.
- Prüfen Sie die Audit-Logs in Cloud Logging, um festzustellen, ob dies erwartet wurde des Hauptkontos.
- Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten des Hauptkontos in den Logs gibt.
Lesen Sie die Anleitung zur Verwendung des Prinzips der geringsten Berechtigung für die RBAC-Rollen und Clusterrollen, die diesen Zugriff erlaubt haben.
Exfiltration: BigQuery Data Exfiltration
Die von der Exfiltration: BigQuery
Data Exfiltration
zurückgegebenen Ergebnisse enthalten eine von zwei möglichen Unterregeln. Jede Unterregel hat einen anderen Schweregrad:
- Untergeordnete Regel
exfil_to_external_table
mit Schweregrad =HIGH
:- Eine Ressource wurde außerhalb Ihrer Organisation oder Ihres Projekts gespeichert.
- Untergeordnete Regel
vpc_perimeter_violation
mit Schweregrad =LOW
:- VPC Service Controls hat einen Kopiervorgang oder einen Zugriff auf BigQuery-Ressourcen blockiert.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
- Öffnen Sie das Ergebnis
Exfiltration: BigQuery Data Exfiltration
wie unter Ergebnisse prüfen. Sehen Sie sich auf dem Tab Zusammenfassung des Bereichs „Ergebnisdetails“ die Werte in den folgenden Abschnitten an:
- Erkannte Inhalte:
- Severity: Der Schweregrad ist entweder
HIGH
für die untergeordnete Regelexfil_to_external_table
oderLOW
für die untergeordnete Regelvpc_perimeter_violation
. - E-Mail-Adresse des Hauptkontos: das Konto, das für die Exfiltrierung der Daten verwendet wird.
- Exfiltrationsquellen: Details zu den Tabellen, aus denen Daten stammen die ausgeschleust wurden.
- Exfiltrationsziele: Details zu den Tabellen, die exfiltriert wurden Daten gespeichert.
- Severity: Der Schweregrad ist entweder
- Betroffene Ressource:
- Vollständiger Name der Ressource: der vollständige Ressourcenname des Projekts, Ordner oder Organisation, aus der 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 allen ähnlichen Ergebnissen
- Chronicle: Link zu Google SecOps.
- Erkannte Inhalte:
Klicken Sie auf den Tab Quell-Properties und überprüfen Sie die angezeigten Felder. insbesondere:
detectionCategory
:subRuleName
: entwederexfil_to_external_table
odervpc_perimeter_violation
evidence
:sourceLogId
:projectId
: das Google Cloud-Projekt, das enthält das BigQuery-Quell-Dataset.
properties
dataExfiltrationAttempt
jobLink
: der Link zum BigQuery-Job, der Daten exfiltriert hat.query
: Die für das BigQuery-Dataset ausgeführte SQL-Abfrage.
Optional können Sie auf den Tab JSON klicken, um eine vollständige Liste der JSON-Attribute des Ergebnisses.
Schritt 2: In Google Security Operations prüfen
Sie können Google Security Operations verwenden, um dieses Ergebnis zu untersuchen. Google SecOps ist ein Google Cloud-Dienst, mit dem Sie Bedrohungen untersuchen und verwandte Entitäten in einer einheitlichen Zeitleiste. Mit Google SecOps werden Ergebnisdaten angereichert, sodass Sie und die Untersuchung erleichtern.
Sie können Google SecOps nur verwenden, wenn Sie Security Command Center auf Organisationsebene aktivieren.
Wechseln Sie in der Google Cloud Console zur Seite Ergebnisse des Security Command Center.
Scrollen Sie im Bereich Schnellfilter nach unten zu Anzeigename der Quelle.
Wählen Sie im Bereich Anzeigename der Quelle die Option Event Threat Detection aus.
Die Tabelle wird mit den Ergebnissen der Ereignis-Bedrohungserkennung gefüllt.
Klicken Sie in der Tabelle unter Kategorie auf ein
Exfiltration: BigQuery Data Exfiltration
-Ergebnis. Der Detailbereich für sich das Ergebnis öffnet.Klicken Sie im Bereich Weitere Informationen des Bereichs mit den Ergebnisdetails auf In Chronicle prüfen
Folgen Sie der Anleitung in der Google SecOps-Benutzeroberfläche.
Verwenden Sie die folgenden Leitfäden, um Prüfungen in Google SecOps durchzuführen:
Schritt 3: Berechtigungen und Einstellungen prüfen
Öffnen Sie in der Google Cloud Console die Seite IAM.
Wählen Sie gegebenenfalls das Projekt aus, das im Feld
projectId
der bei der Suche nach JSON.Geben Sie auf der angezeigten Seite die E-Mail-Adresse in das Feld Filter ein. E-Mail-Adresse des Hauptkontos und prüfen Sie, welche Berechtigungen dem Konto zugewiesen sind.
Schritt 4: Protokolle prüfen
- Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf das Link zum Cloud Logging-URI, um den Log-Explorer zu öffnen.
Logs zu Administratoraktivitäten für BigQuery-Jobs finden Sie mit folgende Filter verwenden:
protoPayload.methodName="Jobservice.insert"
protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"
Schritt 5: Angriffs- und Reaktionsmethoden untersuchen
- Prüfen Sie den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp: Exfiltration over Web Service: Exfiltration to Cloud Storage.
- Wenn Sie ähnliche Ergebnisse ansehen möchten, klicken Sie auf den Link unter Ähnliche Ergebnisse. in der Zeile Ähnliche Ergebnisse auf dem Tab Zusammenfassung des Ergebnisdetails. Ähnliche Ergebnisse sind für dieselbe Instanz und dasselbe Netzwerk identisch.
- Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.
Schritt 6: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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
undexfiltration.targets
). - Verwenden Sie Sensitive Data Protection, um betroffene Datasets auf vertrauliche Informationen zu scannen. Sie können auch Sensitive Data Protection-Daten an Security Command Center senden Je nach Umfang der Informationen Die Kosten für den Schutz sensibler Daten können beträchtlich 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 Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
- Öffnen Sie ein
Exfiltration: BigQuery Data Extraction
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet. Sehen Sie sich auf dem Tab Zusammenfassung des Bereichs „Ergebnisdetails“ die Werte in den folgenden Abschnitten an:
- Erkannte Inhalte:
- Haupt-E-Mail-Adresse: Das Konto, das zur Exfiltration der Daten verwendet wurde.
- Exfiltrationsquellen: Details zu den Tabellen, aus denen Daten stammen die ausgeschleust wurden.
- Exfiltrationsziele: Details zu den Tabellen, die exfiltriert wurden Daten gespeichert.
- Betroffene Ressource:
- Vollständiger Name der Ressource: der Name des BigQuery- Ressource, deren Daten exfiltriert wurden.
- Vollständiger Name des Projekts: das Google Cloud-Projekt, das enthält das BigQuery-Quell-Dataset.
- Weitere Informationen:
- Cloud Logging-URI: Link zu Logging-Einträgen.
- MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation.
- Ähnliche Ergebnisse: Links zu allen ähnlichen Ergebnissen
- Erkannte Inhalte:
Klicken Sie im Bereich mit den Ergebnisdetails auf den Tab JSON.
Notieren Sie sich in der JSON-Datei die folgenden Felder.
sourceProperties
:evidence
:sourceLogId
:projectId
: das Google Cloud-Projekt, das enthält das BigQuery-Quell-Dataset.
properties
:extractionAttempt
:jobLink
: der Link zum BigQuery-Job, der Daten exfiltriert hat
Schritt 2: Berechtigungen und Einstellungen prüfen
Öffnen Sie in der Google Cloud Console die Seite IAM.
Wählen Sie gegebenenfalls das Projekt aus, das im Feld
projectId
der JSON zu finden (aus Schritt 1).Geben Sie auf der angezeigten Seite die E-Mail-Adresse in das Feld Filter ein. unter E-Mail-Adresse des Hauptkontos (aus Schritt 1) aufgeführt sind und prüfen, welche Berechtigungen dem Konto zugewiesen sind.
Schritt 3: Protokolle prüfen
- Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf das Link zum Cloud Logging-URI, um den Log-Explorer zu öffnen.
- 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
- Prüfen Sie den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp: Exfiltration over Web Service: Exfiltration to Cloud Storage.
- Klicken Sie auf dem Tab Details in der Zeile Ähnliche Ergebnisse auf den Link, um ähnliche Ergebnisse aufzurufen. Ähnliche Ergebnisse sind für dieselbe Instanz und dasselbe Netzwerk identisch.
- 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 diese Feststellung geeignet, kann sich aber 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
- Erwägen Sie das Widerrufen von Berechtigungen. für das Hauptkonto, das in der Zeile E-Mail-Adresse des Hauptkontos im Zusammenfassung der Ergebnisdetails, bis die Untersuchung abgeschlossen ist.
- Um eine weitere Daten-Exfiltration zu verhindern, Restriktive IAM-Richtlinien hinzufügen auf die betroffenen BigQuery-Datasets, im Feld Exfiltrationsquellen auf dem Tab Zusammenfassung der Ergebnisdetails.
- 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 Umfang der Informationen Die Kosten für den Schutz sensibler Daten können beträchtlich sein. Befolgen Sie die Best Practices für Kosten für den Schutz sensibler Daten unter Kontrolle haben.
- 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
- Öffnen Sie ein
Exfiltration: BigQuery Data to Google Drive
-Ergebnis wie finden Sie im Abschnitt Ergebnisse überprüfen. Sehen Sie sich auf dem Tab Zusammenfassung des Bereichs mit den Ergebnisdetails die in den folgenden Abschnitten:
- Erkannte Inhalte, darunter:
- Haupt-E-Mail-Adresse: Das Konto, das zur Exfiltration 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 Name des Projekts: Das Google Cloud-Projekt, das das BigQuery-Quell-Dataset enthält.
- Weitere Informationen, darunter:
- Cloud Logging-URI: Link zu Logging-Einträgen.
- MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation.
- Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
- Erkannte Inhalte, darunter:
Klicken Sie auf den Tab JSON, um weitere Informationen zu erhalten.
Notieren Sie sich die folgenden Felder in der JSON-Datei.
sourceProperties
:evidence
:sourceLogId
:projectId
: das Google Cloud-Projekt, das enthält das BigQuery-Quell-Dataset.
properties
:extractionAttempt
:jobLink
: der Link zum BigQuery-Job, der Daten exfiltriert hat
Schritt 2: Berechtigungen und Einstellungen prüfen
Öffnen Sie in der Google Cloud Console die Seite IAM.
Wählen Sie bei Bedarf das Projekt aus, das im Feld
projectId
in der JSON-Datei des Ergebnisses aufgeführt ist (Schritt 1).Geben Sie auf der angezeigten Seite die E-Mail-Adresse in das Feld Filter ein. aufgeführt in
access.principalEmail
(aus Schritt 1) und prüfen, welche Berechtigungen dem Konto zugewiesen sind.
Schritt 3: Protokolle prüfen
- Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf das Link zum Cloud Logging-URI, um den Log-Explorer zu öffnen.
- 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
- Prüfen Sie den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp: Exfiltration over Web Service: Exfiltration to Cloud Storage.
- Klicken Sie auf den Link in der Zeile Ähnliche Ergebnisse auf dem Tab Zusammenfassung der Ergebnisdetails, um ähnliche Ergebnisse aufzurufen. Ähnliche Ergebnisse sind für dieselbe Instanz und dasselbe Netzwerk identisch.
- 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 diese Feststellung geeignet, kann sich aber 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
). - Um betroffene Datasets auf vertrauliche Informationen zu scannen, verwenden Sie Schutz sensibler Daten Sie können auch Sensitive Data Protection-Daten an Security Command Center senden Je nach Umfang der Informationen Die Kosten für den Schutz sensibler Daten können beträchtlich sein. Befolgen Sie die Best Practices für Kosten für den Schutz sensibler Daten unter Kontrolle haben.
- 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 Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
- Öffnen Sie wie beschrieben ein
Exfiltration: Cloud SQL Data Exfiltration
-Ergebnis. finden Sie unter Ergebnisse überprüfen. Der Detailbereich für die wird der Tab Zusammenfassung geöffnet. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- Haupt-E-Mail-Adresse: Das Konto, das zur Exfiltration der Daten verwendet wird.
- Exfiltrationsquellen: Details zu 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 Name der Ressource: der Ressourcenname von Cloud SQL deren Daten exfiltriert wurden.
- Vollständiger Name des Projekts: das Google Cloud-Projekt, das enthält die Cloud SQL-Quelldaten.
- 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 allen ähnlichen Ergebnissen
- Was erkannt wurde, insbesondere die folgenden Felder:
Klicken Sie auf den Tab JSON.
Beachten Sie in der JSON-Datei für das Ergebnis die folgenden Felder:
sourceProperties
:evidence
:sourceLogId
:projectId
: das Google Cloud-Projekt, das die Quell-Cloud SQL-Instanz enthält.
properties
bucketAccess
: gibt an, ob der Cloud Storage-Bucket öffentlich zugänglich oder außerhalb der Organisation befindetexportScope
: 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
Öffnen Sie in der Google Cloud Console die Seite IAM.
Wählen Sie ggf. das Projekt der in
projectId
aufgeführten Instanz aus Schritt 1 aus.Geben Sie auf der angezeigten Seite im Feld Filter die E-Mail-Adresse ein, die in der Zeile Haupt-E-Mail-Adresse auf dem Tab Zusammenfassung der Details zum Ergebnis aufgeführt ist (aus Schritt 1). Prüfen Sie, welche Berechtigungen dem Konto zugewiesen sind.
Schritt 3: Protokolle prüfen
- Öffnen Sie in der Google Cloud Console den Log-Explorer. Klicken Sie dazu auf den Link in Cloud Logging URI (aus Schritt 1). Die Seite Log-Explorer enthält alle Logs für den entsprechenden Cloud SQL-Instanz.
Schritt 4: Angriffs- und Reaktionsmethoden untersuchen
- Prüfen Sie den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp: Exfiltration over Web Service: Exfiltration to Cloud Storage.
- Prüfen Sie die ähnlichen Ergebnisse. Klicken Sie dazu auf den Link in der Zeile Ähnliche Ergebnisse, die in Schritt 1 beschrieben wurde. Ähnlich Ergebnisse haben denselben Ergebnistyp in derselben Cloud SQL Instanz.
- 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 diese Feststellung geeignet, kann sich aber 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.
- Beschränken Sie den Zugriff auf die Cloud SQL Admin API und den Export aus der Cloud SQL Admin API mit VPC Service Controls.
- Um IAM-Rollen mit zu vielen Berechtigungen zu identifizieren und zu beheben, verwenden Sie IAM Recommender.
Exfiltration: Cloud SQL Restore Backup to External Organization
Die Daten-Exfiltration aus einer Cloud SQL-Sicherung wird durch Untersuchung um festzustellen, ob Daten aus der Sicherung in einem Cloud SQL-Instanz außerhalb der Organisation oder des Projekts. 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
- Öffnen Sie ein
Exfiltration: Cloud SQL Restore Backup to External Organization
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Sehen Sie sich auf dem Tab Zusammenfassung des Bereichs mit den Ergebnisdetails die in den folgenden Abschnitten:
- Was erkannt wurde, insbesondere die folgenden Felder:
- Haupt-E-Mail-Adresse: Das Konto, das zur Exfiltration der Daten verwendet wurde.
- Exfiltrationsquellen: Details zur Cloud SQL-Instanz aus der die Sicherung erstellt wurde.
- Exfiltrationsziele: Details zur Cloud SQL-Instanz in dem die Sicherungsdaten wiederhergestellt wurden.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Name der Ressource: Der Ressourcenname der Sicherung, die im wiederhergestellt.
- Vollständiger Name des Projekts: Das Google Cloud-Projekt, das folgendes Element enthält: Cloud SQL-Instanz, aus der die Sicherung erstellt wurde.
- Was erkannt wurde, insbesondere die folgenden Felder:
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 allen ähnlichen Ergebnissen
Klicken Sie auf den Tab JSON.
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-Quell-Dataset enthält.
properties
:restoreToExternalInstance
:backupId
: die ID des wiederhergestellten Sicherungslaufs
Schritt 2: Berechtigungen und Einstellungen prüfen
Öffnen Sie in der Google Cloud Console die Seite IAM.
Wählen Sie ggf. das Projekt der Instanz aus, die im Feld
projectId
in der JSON-Ergebnisdatei (aus Schritt 1)Geben Sie auf der angezeigten Seite im Feld Filter die E-Mail-Adresse ein, die unter Hauptkonto-E-Mail-Adresse (aus Schritt 1) aufgeführt ist, und prüfen Sie, welche Berechtigungen dem Konto zugewiesen sind.
Schritt 3: Protokolle prüfen
- Öffnen Sie in der Google Cloud Console den Log-Explorer. 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
- Prüfen Sie den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp: Exfiltration over Web Service: Exfiltration to Cloud Storage.
- Klicken Sie auf den Link in der Zeile Ähnliche Ergebnisse, um ähnliche Ergebnisse aufzurufen. (von Schritt 1). Ähnliche Ergebnisse haben denselben Ergebnistyp auf derselben Cloud SQL-Instanz.
- 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 diese Feststellung geeignet, kann sich aber 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
- Erwägen Sie, dem Hauptkonto Berechtigungen zu widerrufen. der in der Zeile E-Mail-Adresse des Hauptkontos auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist, bis die Prüfung abgeschlossen ist.
- Um eine weitere Daten-Exfiltration zu stoppen, fügen Sie den betroffenen Cloud SQL-Instanzen restriktive Richtlinien hinzu.
- Beschränken Sie den Zugriff auf die Cloud SQL Admin API mithilfe von VPC Service Controls.
- Um IAM-Rollen mit zu vielen Berechtigungen zu identifizieren und zu beheben, verwenden Sie IAM Recommender.
Exfiltration: Cloud SQL Over-Privileged Grant
Erkennt, wenn alle Berechtigungen für eine PostgreSQL-Datenbank (oder alle Berechtigungen Funktionen oder Verfahren in einer Datenbank) einer oder mehreren Datenbanken Nutzenden.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
- Öffnen Sie das
Exfiltration: Cloud SQL Over-Privileged Grant
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Sehen Sie sich auf dem Tab Zusammenfassung des Bereichs „Ergebnisdetails“ die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- Darstellungsname der Datenbank: Der Name der betroffenen Datenbank in der Cloud SQL PostgreSQL-Instanz.
- Datenbanknutzername: der PostgreSQL-Nutzer, der zu viele Berechtigungen gewährt hat.
- Datenbankabfrage: Die ausgeführte PostgreSQL-Abfrage, mit der die Berechtigungen gewährt wurden.
- Empfänger von Datenbankberechtigungen: die Empfänger der zu weit gefassten Berechtigungen.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Ressourcenname: Der Ressourcenname der betroffenen Cloud SQL-PostgreSQL-Instanz.
- Vollständiger Name des übergeordneten Elements: der Ressourcenname von Cloud SQL PostgreSQL-Instanz.
- Vollständiger Name des Projekts: Das Google Cloud-Projekt, das folgendes Element enthält: PostgreSQL-Instanz von Cloud SQL an.
- 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.
- Was erkannt wurde, insbesondere die folgenden Felder:
Klicken Sie auf den Tab JSON, um den vollständigen JSON-Code für das Ergebnis aufzurufen.
Schritt 2: Datenbankberechtigungen prüfen
- Verbindung zur PostgreSQL-Datenbank herstellen
- Zugriffsberechtigungen auflisten und einblenden
für Folgendes:
- Datenbanken Verwenden Sie den Metabefehl
\l
oder\list
und prüfen Sie, welche Berechtigungen für die Datenbank zugewiesen sind, die im Anzeigenamen der Datenbank (aus Schritt 1) aufgeführt ist. - Funktionen oder Verfahren Verwenden Sie den Metabefehl
\df
, um zu prüfen, welche Berechtigungen für Funktionen oder Prozeduren in der Datenbank zugewiesen sind, die unter Datenbank-Anzeigename (aus Schritt 1) aufgeführt sind.
- Datenbanken Verwenden Sie den Metabefehl
Schritt 3: Protokolle prüfen
- Rufen Sie in der Google Cloud Console den Log-Explorer auf, indem Sie auf dem Link im Cloud Logging-URI (von Schritt 1). Die Seite Log-Explorer enthält alle Logs, die sich auf die relevante Cloud SQL-Instanz beziehen.
- Prüfen Sie im Log-Explorer die PostgreSQL-
pgaudit
-Logs, in denen Abfragen an die Datenbank mit den folgenden Filtern ausgeführt:protoPayload.request.database="var class="edit">database"
Schritt 4: Angriffs- und Reaktionsmethoden untersuchen
- Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Exfiltration over Web Service.
- Wenn Sie feststellen möchten, ob zusätzliche Abhilfemaßnahmen erforderlich sind, kombinieren Sie Ihre Prüfergebnisse mit MITRE Forschung.
Schritt 5: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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 zu vielen Berechtigungen.
- Sie sollten das Widerrufen in Betracht ziehen. alle Berechtigungen für die Empfänger, die in der Liste Empfänger der Datenbank aufgeführt sind bis die Untersuchung abgeschlossen ist.
- Wenn Sie den Zugriff auf die Datenbank einschränken möchten (Datenbank-Anzeigename aus Schritt 1), entziehen Sie den Berechtigungsnehmern unnötige Berechtigungen (Datenbank-Berechtigungsnehmer aus Schritt 1).
Initial Access: Database Superuser Writes to User Tables
Erkennt, wenn das Superuser-Konto der Cloud SQL-Datenbank (postgres
für PostgreSQL und root
für MySQL) in Nutzertabellen schreibt. Der Superuser (eine Rolle mit sehr weit gefassten Zugriffsrechten) sollte in der Regel nicht
die zum Schreiben in Nutzertabellen verwendet werden. Ein Nutzerkonto mit eingeschränktem Zugriff sollte verwendet werden
für normale tägliche Aktivitäten. Wenn ein Superuser in eine Nutzertabelle schreibt,
darauf hinweisen, dass ein Angreifer seine Rechte ausgeweitet oder den Dienst kompromittiert hat.
Standardnutzer der Datenbank
und ändert Daten. 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
- Öffnen Sie ein
Initial Access: Database Superuser Writes to User Tables
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Sehen Sie sich auf dem Tab Zusammenfassung des Bereichs mit den Ergebnisdetails die in den folgenden Abschnitten:
- Was erkannt wurde, insbesondere die folgenden Felder:
- Darstellungsname der Datenbank: Der Name der betroffenen Datenbank in der 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 Name der Ressource: der Ressourcenname von Cloud SQL der betroffenen Instanz.
- Vollständiger Name des übergeordneten Elements: Der Ressourcenname der Cloud SQL-Instanz.
- Vollständiger Name des Projekts: Das Google Cloud-Projekt, das die Cloud SQL-Instanz enthält.
- Weitere Informationen, insbesondere die folgenden Felder:
- Cloud Logging-URI: Link zu Logging-Einträgen.
- MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation.
- Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
- Was erkannt wurde, insbesondere die folgenden Felder:
Klicken Sie auf den Tab JSON, um die vollständige JSON-Datei für das Ergebnis aufzurufen.
Schritt 2: Protokolle prüfen
- Öffnen Sie in der Google Cloud Console Log-Explorer. Klicken Sie dazu auf den Link in
cloudLoggingQueryURI
(aus Schritt 1). Die Seite Log-Explorer enthält alle Logs, die sich auf die relevante Cloud SQL-Instanz beziehen. - Prüfen Sie die Protokolle mit den PostgreSQL-pgaudit-Logs oder den Cloud SQL for MySQL-Audit-Logs, die die vom Superuser ausgeführten Abfragen enthalten, mit den folgenden Filtern:
protoPayload.request.user="SUPERUSER"
Schritt 3: Forschungsangriffe und Reaktionsmethoden
- Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Exfiltration over Web Service.
- Um festzustellen, ob zusätzliche Schritte zur Abhilfe erforderlich sind, kombinieren Sie Ihre Untersuchungsergebnisse mit dem MITRE-Forschung.
Schritt 4: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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 die Nutzer, die eine Verbindung zur Datenbank herstellen dürfen.
- Für PostgreSQL siehe Nutzer erstellen und verwalten
- Für MySQL siehe Nutzer mit integrierter Authentifizierung verwalten
Sie sollten das Passwort für den Superuser ändern.
Erstellen Sie gegebenenfalls einen neuen Nutzer mit eingeschränktem Zugriff für die verschiedenen Abfragetypen, die für die Instanz verwendet werden.
Gewähren Sie dem neuen Nutzer nur die Berechtigungen, die zum Ausführen seiner Abfragen erforderlich sind.
- Für PostgreSQL siehe Grant (Befehl)
- MySQL: Zugriffssteuerung und Kontoverwaltung
Aktualisieren Sie die Anmeldedaten für die Clients, die eine Verbindung zur Cloud SQL-Instanz herstellen
Initial Access: Anonymous GKE resource created from the internet
Erkennt, wenn ein potenziell böswilliger Akteur einen der folgenden Kubernetes-Standardnutzer oder ‑Nutzergruppen verwendet hat, um eine neue Kubernetes-Ressource im Cluster zu erstellen:
system:anonymous
system:authenticated
system:unauthenticated
Diese Nutzer und Gruppen sind praktisch anonym. Rollenbasierter Zugriff RBAC-Bindung in Ihrem Cluster, die diesem Nutzer die Berechtigung zum Erstellen gewährt hat diese Ressourcen im Cluster.
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 Protokollmeldung zu diesem Ergebnis.
Wie Sie dieses Problem vermeiden können, erfahren Sie unter Standardrollen und -gruppen vermeiden.
Initial Access: GKE resource modified anonymously from the internet
Erkennt, wenn ein potenziell böswilliger Akteur eine der folgenden Kubernetes-Optionen verwendet hat Standardnutzern oder -nutzergruppen zum Ändern einer Kubernetes-Ressource im Cluster:
system:anonymous
system:authenticated
system:unauthenticated
Diese Nutzer und Gruppen sind praktisch anonym. Über eine rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) in Ihrem Cluster wurde diesem Nutzer die Berechtigung erteilt, diese Ressourcen im Cluster zu ändern.
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 Protokollmeldung zu diesem Ergebnis.
Informationen zur Behebung dieses Problems finden Sie unter Vermeiden Sie Standardrollen und -gruppen.
Initial Access: Dormant Service Account Action
Erkennt Ereignisse, bei denen ein inaktiver vom Nutzer verwalteter Dienst Konto eine Aktion ausgelöst. In diesem Kontext ist ein Dienstkonto gilt als inaktiv, wenn sie länger als 180 Tage inaktiv ist.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
- Öffnen Sie das
Initial Access: Dormant Service Account Action
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Felder.
Gehen Sie unter Was wurde erkannt so vor:
- Hauptkonto-E-Mail-Adresse: das inaktive Dienstkonto, das die Aktion ausgeführt hat
- 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
- Verwenden Sie Dienstkontotools wie die Aktivitätsanalyse, um die Aktivitäten des inaktiven Dienstkontos zu untersuchen.
- Wenden Sie sich im Feld E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
Schritt 3: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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, für das die Maßnahme ergriffen wurde.
- Prüfen Sie, ob Sie das potenziell manipulierte Dienstkonto löschen, rotieren und löschen können. alle Dienstkonto-Zugriffsschlüssel für das potenziell manipulierte Projekt. Nachher Anwendungen, die das Dienstkonto zur Authentifizierung nutzen, verlieren Zugriff haben. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen und arbeiten mit den Inhabern der Anwendungen zusammen, 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.
- Antworten Sie auf alle Benachrichtigungen vom Google Cloud-Support.
- Mit dem Organisationsrichtliniendienst können Sie einschränken, wer Dienstkonten erstellen kann.
- Um IAM-Rollen mit zu vielen Berechtigungen zu identifizieren und zu beheben, verwenden Sie IAM Recommender.
Initial Access: Dormant Service Account Key Created
Erkennt Ereignisse, bei denen ein inaktiver vom Nutzer verwalteter Dienst Kontoschlüssel erstellt wurde. In diesem Kontext ist ein Dienstkonto gilt als inaktiv, wenn sie länger als 180 Tage inaktiv ist.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
- Öffne
Initial Access: Dormant Service Account Key Created
, wie unter Ergebnisse überprüfen beschrieben. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Feldern.
Unter Was erkannt wurde:
- E-Mail-Adresse des Hauptkontos: der Nutzer, der den Dienstkontoschlüssel erstellt hat
Unter Betroffene Ressource:
- Ressourcen-Anzeigename: der neu erstellte inaktive Dienstkontoschlüssel
- Vollständiger Name des Projekts: Das Projekt, in dem sich das inaktive Dienstkonto befindet.
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
- Verwenden Sie Dienstkontotools wie die Aktivitätsanalyse, um die Aktivitäten des inaktiven Dienstkontos zu untersuchen.
- Wenden Sie sich an den Inhaber des Felds E-Mail-Adresse des Hauptkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
Schritt 3: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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, für das die Maßnahme ergriffen wurde.
- Entfernen Sie den Zugriff des Inhabers der primären E-Mail-Adresse, wenn diese gehackt wurde.
- Machen Sie den neu erstellten Dienstkontoschlüssel auf der Seite „Dienstkonten“ ungültig.
- Erwägen Sie, das potenziell manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das potenziell 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 und arbeiten mit den Inhabern der Anwendungen zusammen, 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.
- Antworten Sie auf alle Benachrichtigungen von Cloud Customer Care.
- 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: Leaked Service Account Key Used
Erkennt Ereignisse, bei denen ein gehackter Dienstkontoschlüssel zur Authentifizierung des Aktion ausführen. Ein gehackter Dienstkontoschlüssel wurde das öffentliche Internet. So werden Dienstkontoschlüssel beispielsweise häufig irrtümlich in öffentlichen GitHub-Repositories veröffentlicht.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
- Öffne
Initial Access: Leaked Service Account Key Used
, wie unter Ergebnisse überprüfen beschrieben. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Felder.
Unter Was erkannt wurde:
- Hauptkonto-E-Mail-Adresse: das Dienstkonto, das für diese Aktion verwendet wurde
- Dienstname: Der API-Name des Google Cloud-Dienstes, auf den über das Dienstkonto zugegriffen wurde.
- Methodenname: der Methodenname der Aktion
- Name des Dienstkontoschlüssels: Der gehackte Dienstkontoschlüssel, der zur Authentifizierung dieser Aktion verwendet wird
- Beschreibung: die Beschreibung, was erkannt wurde, einschließlich des Ortes im öffentlichen Internet, an dem der Dienstkontoschlüssel zu finden ist
Geben Sie unter Betroffene Ressource Folgendes an:
- Anzeigename der Ressource: Die an der Aktion beteiligte Ressource
Schritt 2: Protokolle prüfen
- Öffnen Sie in der Google Cloud Console den Log-Explorer. Klicken Sie dazu auf den Link unter Cloud Logging-URI.
- Wählen Sie in der Symbolleiste der Google Cloud Console Ihr Projekt oder Ihre Organisation aus.
Suchen Sie auf der Seite, die geladen wird, mit dem folgenden Filter nach zugehörigen Protokollen:
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
protoPayload.authenticationInfo.serviceAccountKeyName="SERVICE_ACCOUNT_KEY_NAME"
Ersetzen Sie PRINCIPAL_EMAIL durch den Wert, den Sie in den Details zur Suche im Feld Haupt-E-Mail-Adresse notiert haben. Ersetzen Sie SERVICE_ACCOUNT_KEY_NAME durch den Wert, den Sie in den Details zur Feststellung im Feld Name des Dienstkontoschlüssels notiert haben.
Schritt 3: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet, kann sich aber 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 in der Seite "Dienstkonten".
- Nehmen Sie die Webseite oder das GitHub-Repository, in dem der Dienstkontoschlüssel gepostet wurde, offline.
- Sie können das manipulierte Dienstkonto löschen.
- Rotieren und löschen Sie alle Dienstkonto-Zugriffsschlüssel für das potenziell manipulierte Projekt. Nachher Anwendungen, die das Dienstkonto zur Authentifizierung nutzen, verlieren Zugriff haben. Ihr Sicherheitsteam sollte vor dem Löschen alle betroffenen und arbeiten mit den Inhabern der Anwendungen zusammen, 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.
- Antworten Sie auf alle Benachrichtigungen von Cloud Customer Care.
Initial Access: Excessive Permission Denied Actions
Erkennt Ereignisse, bei denen ein Hauptkonto wiederholt Berechtigung verweigert auslöst bei mehreren Methoden und Diensten.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
- Öffne
Initial Access: Excessive Permission Denied Actions
, wie unter Ergebnisse überprüfen beschrieben. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte des folgenden Feldern.
Gehen Sie unter Was wurde erkannt so vor:
- E-Mail-Adresse des Hauptkontos: das Hauptkonto, das mehrere Fehler vom Typ „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 beim letzten Fehler „Zugriff verweigert“ aufgerufen wurde.
Notieren Sie sich in den Ergebnisdetails auf dem Tab Quellattribute die Werte der folgenden Felder in der JSON-Datei:
- properties.failedActions: Die aufgetretenen Fehler „Berechtigung verweigert“. Zu jedem Eintrag gehören der Dienstname, der Methodenname, die Anzahl fehlgeschlagener Versuche und den Zeitpunkt, zu dem der Fehler zuletzt aufgetreten ist. Es werden maximal 10 Einträge angezeigt.
Schritt 2: Protokolle prüfen
- Öffnen Sie in der Google Cloud Console den Log-Explorer. Klicken Sie dazu auf den Link unter Cloud Logging-URI.
- Wählen Sie in der Symbolleiste der Cloud Console Ihr Projekt aus.
Suchen Sie auf der Seite, die geladen wird, mit dem folgenden Filter nach zugehörigen Protokollen:
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
protoPayload.status.code=7
Ersetzen Sie PRINCIPAL_EMAIL durch den Wert, den Sie in den Details zur Suche im Feld Haupt-E-Mail-Adresse notiert haben.
Schritt 3: Forschungsangriffe und Reaktionsmethoden
- Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten: Cloudkonten.
- 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 diese Feststellung geeignet, kann sich aber 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 im Feld E-Mail-Adresse des Hauptkontos an den Inhaber des Kontos. 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, IAM-Nutzer usw.
- Wenden Sie sich an den Inhaber des Projekts mit dem Konto und löschen oder deaktivieren Sie das Konto gegebenenfalls.
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
- Öffnen Sie ein
Brute Force: SSH
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Sehen Sie sich auf dem Tab Zusammenfassung des Bereichs mit den Ergebnisdetails die in den folgenden Abschnitten:
Was wurde erkannt, insbesondere die folgenden Felder:
- Caller-IP: Die IP-Adresse, von der der Angriff gestartet wurde.
- Nutzername: Das Konto, mit dem die Anmeldung erfolgt ist.
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 allen ähnlichen Ergebnissen
- Chronicle: Link zu Google SecOps.
Klicken Sie auf den Tab JSON.
Achten Sie in der JSON-Datei auf die folgenden Felder.
sourceProperties
:evidence
:sourceLogId
: Projekt-ID und Zeitstempel zur Identifizierung des LogeintragsprojectId
: das Projekt, das das Ergebnis enthält
properties
:attempts
:Attempts
: Die Anzahl der Anmeldeversucheusername
: das Konto, mit dem Sie sich angemeldet habenvmName
: der Name der VMauthResult
: das Ergebnis der SSH-Authentifizierung
Schritt 2: In Google Security Operations prüfen
Sie können Google Security Operations verwenden, um dieses Ergebnis zu untersuchen. Google SecOps ist ein Google Cloud-Dienst, mit dem Sie Bedrohungen zu untersuchen und verwandte Entitäten auf nutzerfreundliche Weise Zeitleiste. Google SecOps reichert Ergebnisdaten an und ermöglicht Ihnen, interessante Indikatoren zu identifizieren und Untersuchungen zu vereinfachen.
Sie können Google SecOps nur verwenden, wenn Sie Security Command Center auf Organisationsebene aktivieren.
Wechseln Sie in der Google Cloud Console zur Seite Ergebnisse des Security Command Center.
Scrollen Sie im Bereich Schnellfilter nach unten zu Anzeigename der Quelle.
Wählen Sie im Bereich Anzeigename der Quelle die Option Event Threat Detection aus.
Die Tabelle enthält die Ergebnisse für den ausgewählten Quelltyp.
Klicken Sie in der Tabelle unter Kategorie auf ein
Brute Force: SSH
-Ergebnis. Der Detailbereich für das Ergebnis wird geöffnet.Klicken Sie im Bereich Weitere Informationen des Bereichs mit den Ergebnisdetails auf In Chronicle prüfen
Folgen Sie der Anleitung in der Google SecOps-Benutzeroberfläche.
Verwenden Sie die folgenden Leitfäden, um Prüfungen in Google SecOps durchzuführen:
Schritt 3: Berechtigungen und Einstellungen prüfen
Rufen Sie in der Google Cloud Console das Dashboard auf.
Wählen Sie das in
projectId
angegebene Projekt aus.Rufen Sie die Karte Ressourcen auf und klicken Sie auf Compute Engine.
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.Klicken Sie im Navigationsbereich auf VPC-Netzwerk und dann auf Firewall. Entfernen oder deaktivieren Sie zu freizügige Firewallregeln für Port 22.
Schritt 4: Protokolle prüfen
- Rufen Sie in der Google Cloud Console den Log-Explorer auf, indem Sie auf Link im Cloud Logging-URI.
- Suchen Sie auf der Seite, die geladen wird, VPC-Flusslogs in Bezug auf die IP-Adresse
die in der Zeile E-Mail-Adresse des Hauptkontos im
Zusammenfassung der Ergebnisdetails mithilfe des folgenden Filters:
logName="projects/projectId/logs/syslog"
labels."compute.googleapis.com/resource_name"="vmName"
Schritt 5: Angriffs- und Reaktionsmethoden untersuchen
- Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten: Lokale Konten.
- Sehen Sie sich die zugehörigen Ergebnisse an. Klicken Sie dazu auf dem Tab Zusammenfassung der Ergebnisdetails in der Zeile Ähnliche Ergebnisse auf den Link auf Ähnliche Ergebnisse. Ähnliche Ergebnisse haben denselben Ergebnistyp und dieselbe Instanz und dasselbe Netzwerk.
- 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 diese Feststellung geeignet, kann sich aber 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: 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
Öffnen Sie ein
Credential Access: External Member Added To Privileged Group
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- E-Mail-Adresse des Hauptkontos: das Konto, in 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 allen ähnlichen Ergebnissen
- Was erkannt wurde, insbesondere die folgenden Felder:
Klicken Sie im Detailbereich auf den Tab JSON.
Achten Sie in der JSON-Datei auf die folgenden Felder.
groupName
: die Google-Gruppe, in der die Änderungen vorgenommen wurdenexternalMember
: das neu hinzugefügte externe MitgliedsensitiveRoles
: die mit dieser Gruppe verknüpften vertraulichen Rollen
Schritt 2: Gruppenmitglieder prüfen
Öffnen Sie Google Groups.
Öffnen Sie Google Groups.
Klicken Sie auf den Namen der Gruppe, die Sie prüfen möchten.
Klicken Sie im Navigationsmenü auf Mitglieder.
Wenn das neu hinzugefügte externe Mitglied nicht in dieser Gruppe sein soll, klicken Sie auf das Kästchen neben dem Mitgliedsnamen und wählen Sie dann
Mitglied entfernen oder Mitglied sperren aus.Zum Entfernen von Mitgliedern müssen Sie Google Workspace-Administrator sein oder die Rolle Inhaber oder Manager in der Google-Gruppe haben. Weitere Informationen finden Sie unter Mitgliedern einer Gruppe Rollen zuweisen.
Schritt 3: Protokolle prüfen
- Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf das Link zum Cloud Logging-URI, um den Log-Explorer zu öffnen.
Wählen Sie bei Bedarf Ihr Projekt aus.
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
- Sehen Sie sich den MITRE ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten.
- Um festzustellen, ob zusätzliche Schritte zur Abhilfe erforderlich sind, kombinieren Sie Ihre Untersuchungsergebnisse mit dem MITRE-Forschung.
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, mit der Angreifer dauerhaften Zugriff auf einen manipulierten Cluster erhalten. Die Berechtigungen, die mit dem Zertifikat verknüpft sind, variieren je nach Subjekt, enthalten, aber mitunter sehr privilegiert sein. Weitere Informationen finden Sie in der Protokollmeldung zu dieser Benachrichtigung.
- Ü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. - Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten gibt:
in den Audit-Logs in Cloud Logging. Beispiel:
- Unterscheidet sich der Prinzipal, der versucht hat, die CSR zu genehmigen, von der wer hat sie erstellt?
- Hat das Hauptkonto versucht, das Hauptkonto anzufordern, zu erstellen, zu genehmigen oder zu löschen Kundendienstmitarbeiter kontaktieren?
- Wenn die Genehmigung durch einen CSR nicht erwartet wurde oder als schädlich eingestuft wird, der Cluster erfordert eine Rotation der Anmeldedaten, um das Zertifikat zu entwerten. Lesen Sie die Anleitung zum Rotieren der Clusteranmeldedaten.
Credential Access: Manually Approved Kubernetes Certificate Signing Request (CSR)
Jemand hat eine Anfrage für die Signierung des Zertifikats (Certificate Signing Request, CSR) manuell genehmigt. Ein ist eine gängige Methode für Angreifer, dauerhaften Zugriff auf einen manipulierten Cluster erstellen. Die mit dem Zertifikat verknüpften Berechtigungen variieren je nach dem enthaltenen Subjekt, können aber sehr hoch sein. Weitere Informationen finden Sie in der Lognachricht zu dieser Benachrichtigung.
- Prüfen Sie die Audit-Logs in Cloud Logging und zusätzliche Benachrichtigungen für andere CSR bezogenen Ereignissen zu, um festzustellen, ob CSR-bezogene Aktionen zu erwarten sind für das Prinzipal.
- Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten gibt:
in den Audit-Logs in Cloud Logging. Beispiel:
- Hat sich der Hauptkonto, der die CSR genehmigt hat, von der Person, die diese erstellt hat, nicht unterschieden es?
- Hat der Kundenbetreuer einen integrierten Unterzeichner angegeben, muss dieser aber letztlich manuell erfolgen. genehmigt, weil er die Kriterien des Unterzeichners nicht erfüllt?
- Hat das Hauptkonto versucht, das Hauptkonto anzufordern, zu erstellen, zu genehmigen oder zu löschen Kundendienstmitarbeiter kontaktieren?
- 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: Privileged Group Opened To Public
Dieser Hinweis ist nicht für Aktivierungen auf Projektebene 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
Öffnen Sie ein
Credential Access: Privileged Group Opened To Public
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Haupt-E-Mail-Adresse: Das Konto, über das die Änderungen vorgenommen wurden, das möglicherweise manipuliert wurde.
- Betroffene Ressource
- Weitere Informationen, insbesondere die folgenden Felder:
- Cloud Logging-URI: Link zu Logging-Einträgen.
- MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation.
- Ähnliche Ergebnisse: Links zu allen ähnlichen Ergebnissen
- Klicken Sie auf den Tab JSON.
- Notieren Sie sich in der JSON-Datei die folgenden Felder.
groupName
: die Google-Gruppe, in der die Änderungen vorgenommen wurdensensitiveRoles
: die mit dieser Gruppe verknüpften vertraulichen RollenwhoCanJoin
: die Einstellung für die Teilnahmemöglichkeiten der Gruppe
- Erkannte Daten, insbesondere die folgenden Felder:
Schritt 2: Einstellungen für den Gruppenzugriff prüfen
Rufen Sie die Admin-Konsole für Google Groups auf. Sie müssen ein Google Workspace-Administrator sein, um sich in der Konsole anzumelden.
Klicken Sie im Navigationsbereich auf Verzeichnis und wählen Sie dann Gruppen aus.
Klicken Sie auf den Namen der Gruppe, die Sie prüfen möchten.
Klicken Sie auf Zugriffseinstellungen und prüfen Sie dann unter Wer kann der Gruppe beitreten die Beitreten-Einstellung für die Gruppe.
Ändern Sie bei Bedarf im Drop-down-Menü die Einstellung für die Beitretenmöglichkeiten.
Schritt 3: Protokolle prüfen
- Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf das Link zum Cloud Logging-URI, um den Log-Explorer zu öffnen.
Wählen Sie bei Bedarf Ihr Projekt aus.
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
- Sehen Sie sich den MITRE ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten.
- Um festzustellen, ob zusätzliche Schritte zur Abhilfe erforderlich sind, kombinieren Sie Ihre Untersuchungsergebnisse mit dem MITRE-Forschung.
Credential Access: Secrets Accessed in Kubernetes Namespace
Erkennt, wenn das default
Kubernetes-Dienstkonto eines Pods zum 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-Objekt oder einem ClusterRole-Objekt gewährt.
Credential Access: Sensitive Role Granted To Hybrid Group
Erkennt, wenn sensible Rollen oder Berechtigungen einer Google-Gruppe mit externen Mitgliedern zugewiesen werden. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie ein
Credential Access: Sensitive Role Granted To Hybrid Group
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für die wird der Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Haupt-E-Mail-Adresse: Das Konto, über das die Änderungen vorgenommen wurden, das möglicherweise manipuliert wurde.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Name der Ressource: Die Ressource, auf der die neue Rolle zugewiesen 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 allen ähnlichen Ergebnissen
- Klicken Sie auf den Tab JSON.
- Notieren Sie sich in der JSON-Datei die folgenden Felder.
groupName
: die Google-Gruppe, in der die Änderungen vorgenommen wurdenbindingDeltas
: die vertraulichen Rollen, die dieser Gruppe neu zugewiesen werden.
- Erkannte Daten, insbesondere die folgenden Felder:
Schritt 2: Gruppenberechtigungen prüfen
Rufen Sie in der Google Cloud Console die Seite IAM auf.
Geben Sie im Feld Filter den in
groupName
aufgeführten Kontonamen ein.Prüfen Sie die sensiblen Rollen, die der Gruppe zugewiesen wurden.
Wenn die neu hinzugefügte vertrauliche Rolle nicht benötigt wird, heben Sie die Rolle auf.
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
- Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf das Link zum Cloud Logging-URI, um den Log-Explorer zu öffnen.
Wählen Sie bei Bedarf Ihr Projekt aus.
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
- Sehen Sie sich den MITRE ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten.
- Um festzustellen, ob zusätzliche Schritte zur Abhilfe erforderlich sind, kombinieren Sie Ihre Untersuchungsergebnisse mit dem MITRE-Forschung.
Malware: Cryptomining Bad IP
Malware wird durch Untersuchung der VPC-Flusslogs und Cloud DNS-Logs auf Verbindungen zu bekannten Befehls- und Kontrolldomains und IP-Adressen erkannt. Gehen Sie so vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie ein
Malware: Cryptomining Bad IP
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für die wird der Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, 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, wenn verfügbar.
- Protokoll: die IANA Protokoll, das der Verbindung zugeordnet ist.
- Betroffene Ressource
- Weitere Informationen mit den folgenden Feldern:
- Logging-URI: Link zu Logging-Einträgen.
- MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation.
- Ähnliche Ergebnisse: Links zu allen ähnlichen Ergebnissen
- Erkannte Daten, insbesondere die folgenden Felder:
Klicken Sie in der Detailansicht des Ergebnisses auf den Tab Quell-Properties.
Maximieren Sie Eigenschaften und notieren Sie die Projekt- und Instanzwerte im folgendes Feld hinzu:
instanceDetails
: Notieren Sie sich sowohl die Projekt-ID als auch den Namen des Compute Engine-Instanz. Die Projekt-ID und der Instanzname werden angezeigt. Dies wird im folgenden Beispiel gezeigt:/projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME
Klicken Sie auf den Tab JSON, um die vollständige JSON-Datei für das Ergebnis aufzurufen.
Schritt 2: Berechtigungen und Einstellungen prüfen
Öffnen Sie in der Google Cloud Console die Seite Dashboard.
Wählen Sie das in
properties_project_id
angegebene Projekt aus.Rufen Sie die Karte Ressourcen auf und klicken Sie auf Compute Engine.
Klicken Sie auf die VM-Instanz, die mit
properties_sourceInstance
übereinstimmt. Untersuchen Sie die potenziell manipulierte Instanz auf Malware.Klicken Sie im Navigationsbereich auf VPC-Netzwerk und dann auf Firewall. Firewallregeln mit zu vielen Berechtigungen entfernen oder deaktivieren
Schritt 3: Protokolle prüfen
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Cloud Console Ihr Projekt aus.
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
- Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ressourcendiebstahl.
- Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.
Schritt 5: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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.
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
Ö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.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Inhalte
- 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. Wenn vorhanden ist, enthält dieser einen JNDI-Lookup.
Schritt 2: Protokolle prüfen
- Öffnen Sie in der Google Cloud Console den Log-Explorer. Klicken Sie dazu auf den Link im Feld Cloud Logging URI aus Schritt 1.
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
- Prüfen Sie den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp: Exploit Public-Facing Application.
- Klicken Sie auf den Link in der Zeile Ähnliche Ergebnisse auf dem Tab Zusammenfassung der Ergebnisdetails, um ähnliche Ergebnisse aufzurufen. Ähnliche Ergebnisse sind der gleiche Ergebnistyp und die dieselbe Instanz und dasselbe Netzwerk.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
Schritt 4: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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 von Google Cloud zur Untersuchung und Reaktion auf die Sicherheitslücke „Apache Log4j 2“.
- Implementieren Sie die empfohlenen Schutzmaßnahmen unter Apache Log4j-Sicherheitslücken.
- Wenn Sie Google Cloud Armor verwenden, stellen Sie
cve-canary rule
in einer neuen oder vorhandenen Google Cloud Armor-Sicherheitsrichtlinie bereit. Weitere Informationen finden Sie unter Google Cloud Armor-WAF-Regel zur Bewahrung vor der Apache Log4j-Sicherheitslücke.
Active Scan: Log4j Vulnerable to RCE
Unterstützte Log4j-Sicherheitslücken-Scanner fügen verschleierte JNDI-Lookups in HTTP-Parametern, URLs und Textfeldern mit Callbacks zu Domains ein, die von den Scannern gesteuert werden. Dieses Ergebnis wird generiert, wenn DNS-Abfragen für die nicht verschleierten Domains gefunden werden. Solche Abfragen treten nur auf, wenn eine JNDI-Suche erfolgreich war und eine aktive Log4j-Sicherheitslücke anzeigt. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie ein
Active Scan: Log4j Vulnerable to RCE
-Ergebnis, wie unter Ergebnisdetails prüfen beschrieben. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Inhalte
- Betroffene Ressource, insbesondere das folgende Feld:
- Vollständiger Name der Ressource: die vollständiger Ressourcenname des Compute Engine-Instanz, die für die 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.
Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON.
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, an die die DNS-Abfrage gesendet wurde. gemacht wurde.
Schritt 2: Protokolle prüfen
- Rufen Sie in der Google Cloud Console den Log-Explorer auf, indem Sie auf dem Link im Feld Cloud Logging-URI aus Schritt 1.
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
- Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Exploitation of Remote Services.
- 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.
- 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 diese Feststellung geeignet, kann sich aber 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 von Google Cloud für die Untersuchung und Reaktion dem „Apache Log4j 2“- Sicherheitslücken.
- Implementieren Sie die empfohlenen Schutzmaßnahmen unter Apache Log4j-Sicherheitslücken.
- Wenn Sie Google Cloud Armor verwenden, stellen Sie
cve-canary rule
in einer neuen oder vorhandenen Google Cloud Armor-Sicherheitsrichtlinie bereit. Weitere Informationen finden Sie unter Google Cloud Armor-WAF-Regel zur Bewahrung vor der Apache Log4j-Sicherheitslücke.
Leaked credentials
Dieses Ergebnis ist für Aktivierungen auf Projektebene nicht verfügbar.
Dieses Ergebnis wird generiert, wenn die Anmeldedaten des Google Cloud-Dienstkontos versehentlich online gehackt oder manipuliert wurden. So reagieren Sie auf dieses Ergebnis:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie ein
account_has_leaked_credentials
-Ergebnis, wie unter Ergebnisdetails prüfen beschrieben. Der Detailbereich für das Ergebnis wird der Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Inhalte
- Betroffene Ressource
Klicken Sie auf den Tab Quellattribute und notieren Sie sich die folgenden Felder:
Compromised_account
: das potenziell manipulierte DienstkontoProject_identifier
: das Projekt, das die potenziell gehackten Kontoanmeldedaten enthältURL
: der Link zum GitHub-Repository
Klicken Sie auf den Tab JSON, um die vollständige JSON-Datei für das Ergebnis aufzurufen.
Schritt 2: Projekt- und Dienstkontoberechtigungen prüfen
Öffnen Sie in der Google Cloud Console die Seite IAM.
Wählen Sie bei Bedarf das in
Project_identifier
aufgeführte Projekt aus.Geben Sie auf der angezeigten Seite im Feld Filter den in
Compromised_account
aufgeführten Kontonamen ein und prüfen Sie die zugewiesenen Berechtigungen.Rufen Sie in der Google Cloud Console die Seite Dienstkonten auf.
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
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Cloud Console Ihr Projekt aus.
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
- Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten: Cloudkonten.
- Klicken Sie auf den Link in
relatedFindingURI
, um ähnliche Ergebnisse abzurufen. Ähnliche Ergebnisse haben denselben Ergebnistyp und dieselbe Instanz und dasselbe Netzwerk. - Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.
Schritt 5: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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. Event Threat Detection bietet derzeit eine allgemeine Malware-Erkennung.
(Malware: Bad IP
und Malware: Bad Domain
) und Detektoren
insbesondere für Log4j-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
Öffnen Sie den entsprechenden Malware-Befund. In den folgenden Schritten wird der
Malware: Bad IP
Ergebnis, wie in Ergebnisse prüfen. Der Detailbereich für die wird der Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- Indikatordomain: Bei
Bad domain
-Ergebnissen die Domain, die das Ergebnis ausgelöst hat. - Indikator-IP: Bei
Bad IP
-Ergebnissen die IP-Adresse, die den Hinweis ausgelöst hat. - Quell-IP: Bei
Bad IP
Ergebnissen eine bekannte IP-Adresse für Malware-Befehle und ‑Kontrollen. - 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.
- Indikatordomain: Bei
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Ressourcenname: Der vollständige Ressourcenname der betroffenen Compute Engine-Instanz.
- Vollständiger Name des Projekts: Der vollständige Ressourcenname des Projekts, das das Ergebnis enthält.
- Weitere Informationen, insbesondere die folgenden Felder:
- Cloud Logging-URI: Link zu Logging-Einträgen.
- MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation.
- Ähnliche Ergebnisse: Links zu allen ähnlichen Ergebnissen
- Chronicle: Link zu Google SecOps.
- VirusTotal-Indikator: Link zur VirusTotal-Analyseseite.
Klicken Sie auf den Tab JSON und notieren Sie sich das folgende Feld:
evidence
:sourceLogId
:projectID
: die ID des Projekts, in dem das Problem festgestellt wurde.
properties
:InstanceDetails
: die Ressourcenadresse für die Compute Engine Instanz.
- Was erkannt wurde, insbesondere die folgenden Felder:
Schritt 2: In Google Security Operations prüfen
Mit Google Security Operations können Sie dies prüfen. zu finden. Google SecOps ist ein Google Cloud-Dienst, mit dem Sie Bedrohungen zu untersuchen und verwandte Entitäten auf nutzerfreundliche Weise Zeitleiste. Mit Google SecOps werden Ergebnisdaten angereichert, sodass Sie und die Untersuchung erleichtern.
Sie können Google SecOps nur verwenden, wenn Sie Security Command Center auf Organisationsebene aktivieren.
Wechseln Sie in der Google Cloud Console zur Seite Ergebnisse des Security Command Center.
Scrollen Sie im Bereich Schnellfilter nach unten zu Anzeigename der Quelle.
Wählen Sie im Bereich Anzeigename der Quelle die Option Event Threat Detection aus.
Die Tabelle enthält die Ergebnisse für den ausgewählten Quelltyp.
Klicken Sie in der Tabelle unter Kategorie auf das
Malware: Bad IP
-Ergebnis. Der Detailbereich für das Ergebnis wird geöffnet.Klicken Sie im Bereich Weitere Informationen des Bereichs mit den Ergebnisdetails auf In Chronicle prüfen
Folgen Sie der Anleitung in der Google SecOps-Benutzeroberfläche.
Verwenden Sie die folgenden Leitfäden, um Prüfungen in Google SecOps durchzuführen:
Schritt 3: Berechtigungen und Einstellungen prüfen
Öffnen Sie in der Google Cloud Console die Seite Dashboard.
Wählen Sie auf dem Tab Zusammenfassung in der Zeile Project full name (Vollständiger Projektname) das Projekt aus.
Rufen Sie die Karte Ressourcen auf und klicken Sie auf Compute Engine.
Klicken Sie auf die VM-Instanz, die mit dem Namen und der Zone in Vollständiger Name der Ressource übereinstimmt. Prüfen Sie die Instanzdetails einschließlich der Netzwerk- und Zugriffseinstellungen.
Klicken Sie im Navigationsbereich auf VPC-Netzwerk und dann auf Firewall. Firewallregeln mit zu vielen Berechtigungen entfernen oder deaktivieren
Schritt 4: Protokolle prüfen
- Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf das Link zum Cloud Logging-URI, um den Log-Explorer zu öffnen.
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 Auswahl des aufgeführten Projekts inprojectId
SOURCE_IP
mit der IP-Adresse in der Zeile Quell-IP auf dem Tab Zusammenfassung der Ergebnisdetails.
Schritt 5: Angriffs- und Reaktionsmethoden untersuchen
- Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Dynamische Lösung und Befehl und Kontrolle.
- Wenn Sie ähnliche Ergebnisse ansehen möchten, klicken Sie auf den Link unter Ähnliche Ergebnisse. in der Zeile Ähnliche Ergebnisse auf dem Tab Zusammenfassung des Ergebnisdetails. Ähnliche Ergebnisse haben denselben Ergebnistyp und dieselbe Instanz und dasselbe Netzwerk.
- 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.
- 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 diese Feststellung geeignet, kann sich aber 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: Outgoing DoS
Event Threat Detection erkennt die mögliche Verwendung einer Instanz, um einen Denial-of-Service-Angriff (DoS) zu starten. Dazu werden VPC-Flusslogs analysiert. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie das Ergebnis
Malware: Outgoing DoS
, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet.Auf dem Tab Zusammenfassung finden Sie die Informationen in den folgenden Abschnitten:
- Erkannte Inhalte
- Quell-IP: die Quell-IP-Adresse der DoS-Aktivität.
- Quellport: Der Quellport der Verbindung.
- Ziel-IP: die Ziel-IP-Adresse der DoS-Aktivität.
- Zielport: Der Zielport der Verbindung.
- Betroffene Ressource
- Weitere Informationen, insbesondere die folgenden Felder:
- Cloud Logging-URI: Link zu Logging-Einträgen.
- MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation.
- Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
- Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON.
- Achten Sie in der JSON-Datei auf die folgenden Felder.
sourceInstanceDetails
: die betroffene Compute Engine-VM-Instanz
- Erkannte Inhalte
Schritt 2: Berechtigungen und Einstellungen prüfen
Öffnen Sie in der Google Cloud Console die Seite Dashboard.
Wählen Sie das in
sourceInstanceDetails
angegebene Projekt aus.Rufen Sie die Karte Ressourcen auf und klicken Sie auf Compute Engine.
Klicken Sie auf die VM-Instanz, die mit dem Instanznamen und der Zone in
sourceInstanceDetails
übereinstimmt. Prüfen Sie die Instanzdetails einschließlich der Netzwerk- und Zugriffseinstellungen.Klicken Sie im Navigationsbereich auf VPC-Netzwerk und dann auf Firewall. Firewallregeln mit zu vielen Berechtigungen entfernen oder deaktivieren
Schritt 3: Protokolle prüfen
- Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf das Link zum Cloud Logging-URI, um den Log-Explorer zu öffnen.
Suchen Sie auf der Seite, die geladen wird, VPC-Flusslogs in Bezug auf die IP-Adresse Adresse in
srcIP
. Verwenden Sie dazu den folgenden Filter:logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="srcIP" OR jsonPayload.connection.dest_ip="destIP")
Ersetzen Sie Folgendes:
PROJECT_ID
durch die ID des Projekts in dem das Problem festgestellt wurde.SOURCE_IP
durch die aufgeführte IP-Adresse zum FeldsrcIP
in der JSON-Ergebnisdatei.DESTINATION_IP
mit der IP-Adresse, die im FelddestIp
in der JSON-Datei für den Fund aufgeführt ist.
Schritt 4: Angriffs- und Reaktionsmethoden untersuchen
- Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Network Denial of Service.
- 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.
- Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.
Schritt 5: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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, bei dem der ausgehende DoS-Traffic auftritt.
- Untersuchen Sie die potenziell manipulierte Instanz und entfernen Sie erkannte Malware. Verwenden Sie eine Lösung zur Endpunkterkennung und -antwort, um Unterstützung bei der Erkennung und Entfernung zu erhalten.
- Prüfen Sie Audit-Logs und Syslogs, die mit der manipulierten Instanz verknüpft sind, um Aktivitäten und Sicherheitslücken zu verfolgen, die das Einfügen von Malware ermöglichen.
- Beenden Sie bei Bedarf die manipulierte Instanz und ersetzen Sie sie durch eine neue Instanz.
- Blockieren Sie die schädlichen IP-Adressen, indem Sie Firewallregeln aktualisieren oder Google Cloud Armor verwenden. Sie können Google Cloud Armor auf der Seite Integrierte Dienste des Security Command Center aktivieren. Abhängig vom Datenvolumen können die Google Cloud Armor-Kosten beträchtlich sein. Weitere Informationen finden Sie in der Preisübersicht für Google Cloud Armor.
- Verwenden Sie die IAM-Richtlinie Shielded VM und Trusted Images, um den Zugriff und die Verwendung von VM-Images zu steuern.
Persistence: IAM Anomalous Grant
Audit-Logs werden untersucht, um das Hinzufügen von IAM-Rollenzuweisungen zu erkennen, die als verdächtig eingestuft werden können.
Im Folgenden finden Sie Beispiele für anomale Berechtigungen:
- Externen Nutzer, z. B. gmail.com-Nutzer, als Projektinhaber einladen ü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
Das IAM Anomalous Grant
-Ergebnis ist einzigartig, da es Folgendes enthält:
Unterregeln, die genauere Informationen zu den einzelnen Instanzen liefern
dieser Erkenntnis. Die Schweregradklassifizierung dieses Ergebnisses hängt davon ab,
für die untergeordnete Regel. Für jede untergeordnete Regel ist möglicherweise eine andere Antwort erforderlich.
In der folgenden Liste sind alle möglichen Unterregeln 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 Hochsensible Rollen.MEDIUM
, wenn eine Rolle mit mittlerer Vertraulichkeit gewährt wurde. Weitere Informationen finden Sie unter Rollen mit mittlerer Vertraulichkeit.
external_member_invited_to_policy
:HIGH
external_member_added_to_policy
:HIGH
, wenn eine Rolle mit hoher Vertraulichkeit oder eine Rolle mit mittlerer Vertraulichkeit auf Organisationsebene gewährt wurde. Weitere Informationen finden Sie unter Besonders sensible Rollen:MEDIUM
, wenn eine Rolle mit mittlerer Vertraulichkeit gewährt wurde. Weitere Informationen finden Sie unter Rollen mit mittlerer Vertraulichkeit.
custom_role_given_sensitive_permissions
:MEDIUM
service_account_granted_sensitive_role_to_member
:HIGH
policy_modified_by_default_compute_service_account
:HIGH
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie das Ergebnis
Persistence: IAM Anomalous Grant
, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für die wird der Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- E-Mail-Adresse des Hauptkontos: E-Mail-Adresse des Nutzers oder Dienstkontos, die bzw. das die die Rolle zugewiesen hat.
Betroffene Ressource
Weitere Informationen, insbesondere die folgenden Felder:
- Cloud Logging-URI: Link zu Logging-Einträgen.
- MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation.
- Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
- VirusTotal-Indikator: Link zur VirusTotal-Analyseseite.
- Chronicle: Verknüpfung mit Google SecOps.
- Was erkannt wurde, insbesondere die folgenden Felder:
Klicken Sie auf den Tab JSON. Der vollständige JSON-Code des Ergebnisses wird angezeigt.
Beachten Sie in der JSON-Datei für das Ergebnis die folgenden Felder:
detectionCategory
:subRuleName
: Weitere Informationen zum Typ der aufgetretenen anomalen Berechtigung Die Unterregel bestimmt die Einstufung des Schweregrads 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: In Google Security Operations prüfen
Sie können Google Security Operations verwenden, um dieses Ergebnis zu untersuchen. Google SecOps ist ein Google Cloud-Dienst, mit dem Sie Bedrohungen zu untersuchen und verwandte Entitäten auf nutzerfreundliche Weise Zeitleiste. Google SecOps reichert Ergebnisdaten an und ermöglicht Ihnen, interessante Indikatoren zu identifizieren und Untersuchungen zu vereinfachen.
Wenn Sie Security Command Center auf Projektebene aktivieren, können Sie die Ergebnisse nicht in Chronicle untersuchen.
Wechseln Sie in der Google Cloud Console zur Seite Ergebnisse des Security Command Center.
Scrollen Sie im Bereich Schnellfilter nach unten zu Anzeigename der Quelle.
Wählen Sie im Bereich Anzeigename der Quelle die Option Event Threat Detection aus.
Die Tabelle enthält die Ergebnisse für den ausgewählten Quelltyp.
Klicken Sie in der Tabelle unter Kategorie auf ein
Persistence: IAM Anomalous Grant
-Ergebnis. Der Detailbereich für das Ergebnis wird geöffnet.Klicken Sie im Bereich Weitere Informationen des Bereichs mit den Ergebnisdetails auf In Chronicle prüfen
Folgen Sie der Anleitung in der Google SecOps-Benutzeroberfläche.
Verwenden Sie die folgenden Leitfäden, um Prüfungen in Google SecOps durchzuführen:
Schritt 3: Protokolle prüfen
- Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf das Link zum Cloud Logging-URI, um den Log-Explorer zu öffnen.
- Suchen Sie auf der Seite, die geladen wird, mithilfe der folgenden Filter nach neuen oder aktualisierten IAM-Ressourcen:
protoPayload.methodName="SetIamPolicy"
protoPayload.methodName="google.iam.admin.v1.UpdateRole"
protoPayload.methodName="google.iam.admin.v1.CreateRole"
Schritt 4: Angriffs- und Reaktionsmethoden untersuchen
- Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Gültige Konten: Cloudkonten.
- 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.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
Schritt 5: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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: Impersonation Role Granted for Dormant Service Account
Erkennt Ereignisse, bei denen einem Hauptkonto eine Identitätsübernahmerolle gewährt wird, mit der es die Identität eines inaktiven nutzerverwalteten Dienstkontos übernehmen kann. In diesem Fall ist das inaktive Dienstkonto die betroffene Ressource. Ein Dienstkonto gilt als inaktiv, wenn es seit mehr als 180 Tagen inaktiv ist.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
- Öffnen Sie das
Persistence: Impersonation Role Granted for Dormant Service Account
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Felder.
Gehen Sie unter Was wurde erkannt so vor:
- Haupt-E-Mail-Adresse: der Nutzer, der die Gewährung ausgeführt hat
- Offending access grants.Principal name: Das Hauptkonto, dem die Identitätsdiebstahl-Rolle zugewiesen wurde.
Unter Betroffene Ressource:
- Anzeigename der Ressource: das inaktive Dienstkonto als Ressource
- Vollständiger Name des Projekts: Das Projekt, in dem sich das inaktive Dienstkonto befindet.
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
- Dienstkonto verwenden Tools wie Aktivität Analysetool, um die Aktivität des inaktiven Dienstkontos zu untersuchen.
- Wenden Sie sich an den Inhaber des Felds Haupt-E-Mail-Adresse. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
Schritt 3: Protokolle prüfen
- Auf dem Tab Zusammenfassung des Bereichs mit den Ergebnisdetails unter Weitere Informationen Klicken Sie auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.
Schritt 4: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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, für das die Maßnahme ergriffen wurde.
- Entfernen Sie den Zugriff des Inhabers der E-Mail-Adresse des Hauptkontos, falls diese manipuliert wurde.
- Entfernen Sie die neu zugewiesene Rolle zur Identitätsübernahme des Zielmitglieds.
- Erwägen Sie, das potenziell manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das potenziell manipulierte Projekt zu rotieren und zu löschen. Nachher Anwendungen, die das Dienstkonto zur Authentifizierung nutzen, verlieren Zugriff haben. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen Anwendungen identifizieren und mit den Anwendungsinhabern 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.
- Reagieren Sie auf alle Benachrichtigungen von Cloud Customer Care.
- 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.
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 zum Beispiel der Parameter entsprechender Mitarbeiter das Unternehmen verlassen hat, kann der Administrator das Konto nicht löschen. Wenn Sie nicht verwalteten Konten vertrauliche Rollen zuweisen, Sicherheitsrisiken für das Unternehmen.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
- Öffne
Persistence: Unmanaged Account Granted Sensitive Role
, wie unter Ergebnisse überprüfen beschrieben. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Felder.
Gehen Sie unter Was wurde erkannt so vor:
- E-Mail-Adresse des Hauptkontos: der Nutzer, der die Berechtigung erteilt hat
- Verstößiger Zugriff „grants.Principal name“: das nicht verwaltete Konto, das die Erteilung erhält
- Verstörende Zugriffsberechtigungen.Role gewährt: die vertrauliche Rolle gewährt
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
- Wenden Sie sich an den Inhaber des Felds Haupt-E-Mail-Adresse. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
- Erkundigen Sie sich beim Inhaber des Felds Offending access grants.Principal name (Verletzende Zugriffsberechtigungen – Name des Hauptbevollmächtigten), woher das nicht verwaltete Konto stammt.
Schritt 3: Protokolle prüfen
- Auf dem Tab Zusammenfassung des Bereichs mit den Ergebnisdetails unter Weitere Informationen Klicken Sie auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.
Schritt 4: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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, für das die Maßnahme ergriffen wurde.
- Entfernen Sie den Zugriff des Inhabers der primären E-Mail-Adresse, wenn diese gehackt wurde.
- Entfernen Sie die neu gewährte sensible Rolle aus dem nicht verwalteten Konto.
- Sie können das nicht verwaltete Konto mit dem Übertragungstool in ein verwaltetes Konto umwandeln. und dieses Konto zur Kontrolle durch Systemadministratoren verschieben.
Persistence: New API Method
In einer Organisation, einem Ordner oder einem Projekt wurden ungewöhnliche Administratoraktivitäten durch einen potenziell böswilligen Akteur erkannt. Folgende ungewöhnliche Aktivitäten gelten:
- Neue Aktivität eines Hauptkontos in einer Organisation, einem Ordner oder einem Projekt
- Aktivität, die seit einiger Zeit von einem Hauptkonto in einer Organisation, einem Ordner oder einem Projekt nicht mehr gesehen wurde
Schritt 1: Ergebnisdetails prüfen
- Öffnen Sie das
Persistence: New API Method
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Felder:
- Unter Was wurde erkannt:
- Haupt-E-Mail-Adresse: das Konto, von dem aus 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.
- Unter Was wurde erkannt:
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
- Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Persistenz.
- Prüfen Sie, ob die Maßnahme in der Organisation, im Ordner oder im Projekt gerechtfertigt ist und ob sie vom rechtmäßigen Inhaber des Kontos ausgeführt wurde. Die Organisation, der Ordner oder das Projekt wird in der Zeile Ressourcenpfad und das Konto in der Zeile E-Mail-Adresse des Hauptkontos angezeigt.
- 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 die Google Cloud zu, basierend auf der Standortbestimmung der anfragenden IP-Adresse.
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie ein
Persistence: New Geography
-Ergebnis wie unter Befunddetails weiter oben zu diesem Thema ansehen Seite. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- E-Mail-Adresse des Hauptkontos: das potenziell manipulierte Nutzerkonto.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Name des Projekts: das Projekt, das das potenziell manipulierte Nutzerkonto enthält.
- Weitere Informationen, insbesondere die folgenden Felder:
- Cloud Logging-URI: Link zu Logging-Einträgen.
- MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation.
- Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
- Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON.
Notieren Sie sich 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
ist die externe IP-Adresse.notSeenInLast
: der Zeitraum, der verwendet wird, um eine Basislinie für die normalen Verhaltens.typicalGeolocations
: die Standorte, an denen der Nutzer normalerweise auf Google Cloud-Ressourcen zugreift.
Schritt 2: Projekt- und Kontoberechtigungen prüfen
Öffnen Sie in der Google Cloud Console die Seite IAM.
Wählen Sie gegebenenfalls das Projekt aus, das im Feld
projectID
der nach JSON suchen.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
- Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf das Link zum Cloud Logging-URI, um den Log-Explorer zu öffnen.
- Wählen Sie bei Bedarf Ihr Projekt aus.
- 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
- Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten: Cloudkonten.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
Schritt 5: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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
undnotSeenInLast
, 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
Öffnen Sie wie beschrieben ein
Persistence: New User Agent
-Ergebnis. weiter oben im Abschnitt Ergebnisdetails ansehen Seite. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Hauptkonto-E-Mail-Adresse: das potenziell manipulierte Dienstkonto.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Name des Projekts: das Projekt, das die potenziell gehacktes Dienstkonto.
- 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.
- Notieren Sie sich in der JSON-Datei die folgenden Felder.
projectId
: das Projekt, das die potenziell manipulierte Datei enthält Dienstkonto.callerUserAgent
: der ungewöhnliche User-Agent.anomalousSoftwareClassification
: der Typ der Software.notSeenInLast
: der Zeitraum, der verwendet wird, um einen Ausgangswert für „Normal“ zu bestimmen verhalten.
- Erkannte Daten, insbesondere die folgenden Felder:
Schritt 2: Projekt- und Kontoberechtigungen prüfen
Öffnen Sie in der Google Cloud Console die Seite IAM.
Wählen Sie bei Bedarf das in
projectId
aufgeführte Projekt aus.Geben Sie auf der angezeigten Seite im Feld Filter den Kontonamen ein, der in der Zeile E-Mail-Adresse des Hauptkontos auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist, und prüfen Sie die zugewiesenen Rollen.
Rufen Sie in der Google Cloud Console die Seite Dienstkonten auf.
Geben Sie auf der angezeigten Seite den Kontonamen im Feld Filter ein. die in der Zeile E-Mail-Adresse des Hauptkontos auf dem Tab Zusammenfassung aufgeführt ist der Ergebnisdetails.
Prüfen Sie die Schlüssel und das Erstellungsdatum des Dienstkontos.
Schritt 3: Protokolle prüfen
- Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf das Link zum Cloud Logging-URI, um den Log-Explorer zu öffnen.
- Wählen Sie bei Bedarf Ihr Projekt aus.
- 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
- Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Gültige Konten: Cloudkonten.
- Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.
Schritt 5: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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
undbehaviorPeriod
, um festzustellen, ob der Zugriff abnormal ist und ob das Konto manipuliert wurde. - Projektressourcen löschen, die von nicht autorisierten Konten erstellt wurden, z. B. unbekannte Compute Engine-Instanzen, Snapshots, Dienstkonten und IAM-Nutzer.
- Informationen zum Einschränken der Erstellung neuer Ressourcen auf bestimmte Regionen finden Sie unter Ressourcenstandorte einschränken.
- Um IAM-Rollen mit zu vielen Berechtigungen zu identifizieren und zu beheben, verwenden Sie IAM Recommender.
Privilege Escalation: Changes to sensitive Kubernetes RBAC objects
Zur Rechteausweitung hat ein potenziell böswilliger Akteur versucht,
Rollenbasierter Zugriff ClusterRole
, RoleBinding
oder ClusterRoleBinding
Steuerelement (RBAC) des vertraulichen cluster-admin
-Elements
Rolle mithilfe einer PUT
- oder PATCH
-Anfrage.
Schritt 1: Ergebnisdetails prüfen
Ö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 mit dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- E-Mail-Adresse des Hauptkontos: das Konto, von dem der Aufruf stammt.
- Methodenname: die aufgerufene Methode.
- Kubernetes-Bindungen: das 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 wird aufgetreten.
- 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 allen ähnlichen Ergebnissen
- Was erkannt wurde, insbesondere die folgenden Felder:
Klicken Sie im Abschnitt Was wurde erkannt auf den Namen der Bindung. in der Zeile Kubernetes bindings. Die Bindungsdetails werden angezeigt.
Notieren Sie sich die Bindungsdetails in der angezeigten Bindung.
Schritt 2: Protokolle prüfen
- Auf dem Tab Zusammenfassung der Ergebnisdetails in der Rufen Sie in der Google Cloud Console den Log-Explorer auf, indem Sie auf den Link im Cloud Logging-URI angeben.
Wenn der Wert in Methodenname eine
PATCH
-Methode war, prüfen Sie die Anfrage body, um zu sehen, welche Eigenschaften geändert wurden.Bei
update
- (PUT
-) Aufrufen wird das gesamte Objekt in der Anfrage gesendet, sodass die Änderungen nicht so klar sind.Mit den folgenden Filtern können Sie nach anderen Aktionen des Hauptkontos suchen:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
Ersetzen Sie Folgendes:
CLUSTER_NAME
: der Wert, den Sie im Feld Anzeigename der Ressource in den Ergebnisdetails.PRINCIPAL_EMAIL
: Der Wert, den Sie in den Details zur Feststellung im Feld Haupt-E-Mail-Adresse angegeben haben.
Schritt 3: Forschungsangriffe und Reaktionsmethoden
- Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Rechteausweitung.
- Prüfen Sie die Empfindlichkeit des Objekts und finden Sie heraus, ob die Änderung gerechtfertigt ist.
- Bei Bindungen können Sie das Subjekt prüfen und untersuchen, ob es die Rolle braucht, an die es gebunden ist.
- Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten gibt: in den Logs gespeichert.
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 und Legitimität.
Um einen Reaktionsplan zu entwickeln, kombinieren Sie Ihre MITRE-Studien.
Privilege Escalation: Create Kubernetes CSR for master cert
Zur Ausweitung der Berechtigungen hat ein potenziell böswilliger Akteur eine Anfrage zur Zertifikatssignierung (Certificate Signing Request, CSR) für das Kubernetes-Masterzertifikat erstellt, die ihm Zugriff auf cluster-admin
gewährt.
Schritt 1: Ergebnisdetails prüfen
Öffne
Privilege Escalation: Create Kubernetes CSR for master cert
Ergebnis, wie unter Ergebnisse überprüfen beschrieben. Der Detailbereich für die wird der Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- E-Mail-Adresse des Hauptkontos: das Konto, von dem der Aufruf stammt.
- Methodenname: die aufgerufene Methode.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Anzeigename der Ressource: der Kubernetes-Cluster, in dem die Aktion ausgeführt wird aufgetreten.
- 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 allen ähnlichen Ergebnissen
- Was erkannt wurde, insbesondere die folgenden Felder:
Schritt 2: Protokolle prüfen
- Klicken Sie auf dem Tab Zusammenfassung der Details zur Feststellung in der Google Cloud Console auf den Link im Feld Cloud Logging URI, um den Log-Explorer aufzurufen.
- Prüfen Sie den Wert im Feld
protoPayload.resourceName
, um die entsprechende Anfrage zur Zertifikatsignierung zu ermitteln. Prüfen Sie mit den folgenden Methoden, welche Aktionen das Hauptkonto ausgeführt hat: Filter:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
Ersetzen Sie Folgendes:
CLUSTER_NAME
: der Wert, den Sie im Feld Anzeigename der Ressource in den Ergebnisdetails.PRINCIPAL_EMAIL
: Der Wert, den Sie in den Details zur Feststellung im Feld Haupt-E-Mail-Adresse angegeben haben.
Schritt 3: Forschungsangriffe und Reaktionsmethoden
- Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Rechteausweitung.
- Untersuchen Sie, ob die Erteilung des
cluster-admin
-Zugriffs gerechtfertigt war. Wenn die Haupt-E-Mail-Adresse keine Dienstkonto enthält, wenden Sie sich an den Inhaber des Kontos, um zu erfahren, ob die der rechtmäßige Eigentümer die Aktion durchgeführt hat.
Wenn die E-Mail-Adresse des Hauptkontos ein Dienstkonto ist (IAM oder Kubernetes), identifizieren Sie die Quelle der Aktion, um deren Rechtmäßigkeit festzustellen.
Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
Privilege Escalation: Creation of sensitive Kubernetes bindings
Zur Rechteausweitung hat ein potenziell böswilliger Akteur versucht, ein neues
Objekt RoleBinding
oder ClusterRoleBinding
für cluster-admin
Rolle.
Schritt 1: Ergebnisdetails prüfen
Öffne
Privilege Escalation: Creation of sensitive Kubernetes bindings
Ergebnis, wie unter Ergebnisse überprüfen beschrieben. Der Detailbereich des Ergebnisses wird auf dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- Haupt-E-Mail-Adresse: das Konto, über das der Anruf getätigt wurde.
- Kubernetes-Bindungen: das 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 wird aufgetreten.
- 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 allen ähnlichen Ergebnissen
- Was erkannt wurde, insbesondere die folgenden Felder:
Schritt 2: Protokolle prüfen
- Auf dem Tab Zusammenfassung der Ergebnisdetails in der Rufen Sie in der Google Cloud Console den Log-Explorer auf, indem Sie auf den Link im Cloud Logging-URI angeben.
Prüfen Sie mit den folgenden Methoden, welche Aktionen das Hauptkonto ausgeführt hat: Filter:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
Ersetzen Sie Folgendes:
CLUSTER_NAME
: der Wert, den Sie im Feld Anzeigename der Ressource in den Ergebnisdetails.PRINCIPAL_EMAIL
: Der Wert, den Sie in den Details zur Feststellung im Feld Haupt-E-Mail-Adresse angegeben haben.
Schritt 3: Forschungsangriffe und Reaktionsmethoden
- Sehen Sie sich die Einträge im MITRE ATT&CK-Framework für diesen Ergebnistyp an: Ausweitung von Berechtigungen:
- Prüfen Sie die Vertraulichkeit der erstellten Bindung und ob die Rollen für die Subjekte erforderlich sind.
- Bei Bindungen können Sie das Subjekt prüfen und untersuchen, ob es die Rolle benötigt, an die sie gebunden ist.
- Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten gibt: in den Logs gespeichert.
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 Aktion, um deren und Legitimität.
Um einen Reaktionsplan zu entwickeln, kombinieren Sie Ihre MITRE-Studien.
Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access
Ein Nutzer 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 praktisch anonym und sollten beim Erstellen von Rollenbindungen oder Clusterrollenbindungen an RBAC-Rollen vermieden werden. Prüfen Sie die Bindung, um sicherzustellen, dass sie erforderlich ist. Wenn die Bindung nicht erforderlich ist, entfernen Sie sie. Weitere Informationen finden Sie in der Protokollmeldung zu diesem Ergebnis.
- Prüfen Sie alle erstellten Bindungen, die Berechtigungen für die
system:anonymous
-Nutzer,system:unauthenticated group
odersystem:authenticated
-Gruppe. - Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten gibt: in den Audit-Logs in Cloud Logging.
Wenn es Anzeichen für schädliche Aktivitäten gibt, lesen Sie die Anleitung zum Prüfen und Entfernen der Bindungen, die diesen Zugriff gewährt haben.
Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials
Zur Ausweitung der Berechtigungen hat ein potenziell böswilliger Akteur mit dem Befehl kubectl
eine Anfrage zur Zertifikatssignierung (Certificate Signing Request, CSR) abgefragt und dazu manipulierte Bootstrap-Anmeldedaten verwendet.
Im Folgenden finden Sie ein Beispiel für einen Befehl, der von dieser Regel erkannt wird:
kubectl --client-certificate kubelet.crt --client-key kubelet.key --server YOUR_SERVER get csr CSR_NAME
Schritt 1: Ergebnisdetails prüfen
Ö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 mit dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- E-Mail-Adresse des Hauptkontos: das Konto, von dem der Aufruf stammt.
- Methodenname: die aufgerufene Methode.
- Unter Betroffene Ressource:
- Anzeigename der Ressource: Der Kubernetes-Cluster, in dem die Aktion stattgefunden hat.
- 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 allen ähnlichen Ergebnissen
- Was erkannt wurde, insbesondere die folgenden Felder:
Schritt 2: Protokolle prüfen
Wenn der Methodenname, den Sie in den Details des Ergebnisses im Feld Methodenname angegeben haben, eine GET
-Methode ist, gehen Sie so vor:
- Klicken Sie auf dem Tab Zusammenfassung der Details zur Feststellung in der Google Cloud Console auf den Link im Feld Cloud Logging URI, um den Log-Explorer aufzurufen.
- Prüfen Sie den Wert im Feld
protoPayload.resourceName
, um die entsprechende Anfrage zur Zertifikatsignierung zu ermitteln.
Schritt 3: Forschungsangriffe und Reaktionsmethoden
- Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Rechteausweitung.
- Wenn die spezifische CSR im Logeintrag verfügbar ist, prüfen Sie die Vertraulichkeit des Zertifikats und ob die Aktion gerechtfertigt war.
- Um einen Reaktionsplan zu entwickeln, kombinieren Sie Ihre MITRE-Studien.
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.
In einem privilegierten Container ist das Feld privileged
auf
true
. Ein Container mit der Fähigkeit zur Rechteausweitung hat
Das Feld „allowPrivilegeEscalation
“ wurde auf „true
“ festgelegt. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter SecurityContext v1 Core in der API-Referenz.
Schritt 1: Ergebnisdetails prüfen
Öffne
Privilege Escalation: Launch of privileged Kubernetes container
Ergebnis, wie unter Ergebnisse überprüfen beschrieben. Der Detailbereich des Ergebnisses wird auf dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- E-Mail-Adresse des Hauptkontos: das Konto, von dem der Aufruf stammt.
- 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 wird aufgetreten.
- 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.
- Was erkannt wurde, insbesondere die folgenden Felder:
Notieren Sie sich auf dem Tab JSON die Werte der Ergebnisfelder:
- findings.kubernetes.pods[].containers: Der privilegierte Container wurde aktiviert innerhalb des Pods.
Schritt 2: Protokolle prüfen
- Auf dem Tab Zusammenfassung der Ergebnisdetails in der Rufen Sie in der Google Cloud Console den Log-Explorer auf, indem Sie auf den Link im Cloud Logging-URI angeben.
Prüfen Sie mit den folgenden Methoden, welche Aktionen das Hauptkonto ausgeführt hat: Filter:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
Ersetzen Sie Folgendes:
CLUSTER_NAME
: der Wert, den Sie im Feld Anzeigename der Ressource in den Ergebnisdetails.PRINCIPAL_EMAIL
: Der Wert, den Sie in den Details zur Feststellung im Feld Haupt-E-Mail-Adresse angegeben haben.
Schritt 3: Forschungsangriffe und Reaktionsmethoden
- Sehen Sie sich die Einträge im MITRE ATT&CK-Framework für diesen Ergebnistyp an: Ausweitung von Berechtigungen:
- Prüfen Sie, ob der erstellte Container Zugriff auf Hostressourcen und Kernel-Funktionen.
- Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten des Hauptkontos in den Logs gibt.
Wenn die E-Mail-Adresse des Hauptkontos kein Dienstkonto ist, wenden Sie sich an den Inhaber des Kontos, 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 Aktion, um deren Rechtmäßigkeit festzustellen.
Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
Privilege Escalation: Dormant Service Account Granted Sensitive Role
Erkennt Ereignisse, bei denen einem inaktiven vom Nutzer verwalteten Dienst eine sensible IAM-Rolle gewährt wird Konto. In diesem Kontext ist ein Dienstkonto gilt als inaktiv, wenn sie länger als 180 Tage inaktiv ist.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
- Öffne
Privilege Escalation: Dormant Service Account Granted Sensitive Role
, wie unter Ergebnisse überprüfen beschrieben. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Feldern.
Gehen Sie unter Was wurde erkannt so vor:
- E-Mail-Adresse des Hauptkontos: der Nutzer, der die Berechtigung erteilt hat
- Offending access grants.Principal name: Das inaktive Dienstkonto, das die sensible Rolle erhalten hat
- Verletzende Zugriffsberechtigungen. Zugewiesene Rolle: Die zugewiesene vertrauliche IAM-Rolle
Unter Betroffene Ressource:
- Anzeigename der Ressource: Organisation, Ordner oder Projekt, in dem dem inaktiven Dienstkonto die vertrauliche IAM-Rolle gewährt wurde.
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
- Verwenden Sie Dienstkontotools wie die Aktivitätsanalyse, um die Aktivitäten des inaktiven Dienstkontos zu untersuchen.
- Wenden Sie sich an den Inhaber des Felds Haupt-E-Mail-Adresse. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
Schritt 3: Protokolle prüfen
- Auf dem Tab Zusammenfassung des Bereichs mit den Ergebnisdetails unter Weitere Informationen Klicken Sie auf den Link Cloud Logging-URI, um den Log-Explorer zu öffnen.
Schritt 4: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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, für das die Maßnahme ergriffen wurde.
- Entfernen Sie den Zugriff des Inhabers der E-Mail-Adresse des Hauptkontos, falls diese manipuliert wurde.
- Entfernen Sie die neu zugewiesene vertrauliche IAM-Rolle aus dem inaktiven Dienstkonto.
- Erwägen Sie, das potenziell manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das potenziell manipulierte Projekt zu rotieren und zu löschen. Nachher Ressourcen, die das Dienstkonto zur Authentifizierung nutzen, verlieren Zugriff haben. 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.
- Antworten Sie auf alle Benachrichtigungen von Cloud Customer Care.
- Mit dem Organisationsrichtliniendienst können Sie einschränken, wer Dienstkonten erstellen kann.
- Verwenden Sie IAM, um zu moderate Rollen zu identifizieren und zu korrigieren. Recommender verwendet.
Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity
Eine anomale Dienstkonto-Identitätsübernahme wird erkannt, indem die Audit-Logs für Administratoraktivitäten geprüft werden, um festzustellen, ob bei einer Identitätsübernahmesanfrage für ein Dienstkonto eine Anomalie aufgetreten ist.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie das Ergebnis
Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity
wie unter Ergebnisse prüfen. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- E-Mail-Adresse des Hauptkontos: Das letzte 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ätsdiebstahlanfrage beteiligt ist.
- Methodenname: die aufgerufene Methode.
- Informationen zur Dienstkonto-Delegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto unten in der Liste ist der Aufrufer der Identitätsübernahmeanfrage.
- 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 allen ähnlichen Ergebnissen
- Erkannte Daten, insbesondere die folgenden Felder:
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
- Wenden Sie sich im Feld Hauptkonto-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
- Prüfen Sie die Principals in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
- Wenden Sie sich an den Inhaber des Identitätswechsel-Anrufers in der Liste Informationen zur Dienstkonto-Delegierung. Prüfen, ob der rechtmäßige Inhaber die Aktion ausführen.
Schritt 3: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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, für das die Maßnahme ergriffen wurde.
- Erwägen Sie, das potenziell manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das potenziell 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 und mit Ressourceninhabern zusammenzuarbeiten, 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.
- Antworten Sie auf alle Benachrichtigungen vom Google Cloud-Support.
- Um einzuschränken, wer Dienstkonten erstellen kann, verwenden Sie Organisationsrichtliniendienst
- 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 durch Prüfen des
Audit-Logs zu Administratoraktivitäten, um festzustellen, ob in einem Dienstkonto eine Anomalie aufgetreten ist
Antrag auf Identitätsübernahme
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie das Ergebnis
Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity
wie unter Ergebnisse prüfen. Der Detailbereich des Ergebnisses wird auf dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- E-Mail-Adresse des Hauptkontos: Das letzte 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ätsdiebstahlanfrage beteiligt ist.
- Methodenname: die aufgerufene Methode.
- Informationen zur Dienstkonto-Delegierung: Details zu Dienstkonten in der Delegationskette. Das Hauptkonto unten in der Liste ist der Aufrufer der Identitätsübernahmeanfrage.
- 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 allen ähnlichen Ergebnissen
- Erkannte Daten, insbesondere die folgenden Felder:
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
- Wenden Sie sich im Feld Hauptkonto-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
- Prüfen Sie die Principals in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
- Wenden Sie sich an den Inhaber des Identitätswechsel-Anrufers in der Liste Informationen zur Dienstkonto-Delegierung. Prüfen, ob der rechtmäßige Inhaber die Aktion ausführen.
Schritt 3: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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.
- Prüfen Sie, ob Sie das potenziell manipulierte Dienstkonto löschen, rotieren und löschen können. alle Dienstkonto-Zugriffsschlüssel für das potenziell manipulierte Projekt. Nachher Ressourcen, die das Dienstkonto zur Authentifizierung nutzen, verlieren Zugriff haben. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen und mit Ressourceninhabern zusammenzuarbeiten, 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.
- Antworten Sie auf alle Benachrichtigungen vom Google Cloud-Support.
- Um einzuschränken, wer Dienstkonten erstellen kann, verwenden Sie Organisationsrichtliniendienst
- 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 durch Prüfung der Daten erkannt
Audit-Logs aufrufen, um festzustellen, ob in einem Dienstkonto eine Anomalie aufgetreten ist
Antrag auf Identitätsübernahme
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Ö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 mit dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Haupt-E-Mail-Adresse: das letzte Dienstkonto bei der Identitätsübernahme Anfrage, die für den Zugriff auf Google Cloud verwendet wurde
- Dienstname: der API-Name des Google Cloud-Dienstes, der an der Anfrage zur Identitätsübernahme beteiligt ist
- Methodenname: die aufgerufene Methode
- Informationen zur Delegation des Dienstkontos: Details zu den Dienstkonten in der Delegationskette. Das Hauptkonto unten in der Liste ist der Aufrufer der Identitätsübernahmeanfrage.
- 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 allen ähnlichen Ergebnissen
- Erkannte Daten, insbesondere die folgenden Felder:
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
- Wenden Sie sich im Feld Hauptkonto-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
- Prüfen Sie die Principals in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
- Wenden Sie sich an den Inhaber des Identitätswechsel-Anrufers in der Liste Informationen zur Dienstkonto-Delegierung. Prüfen, ob der rechtmäßige Inhaber die Aktion ausführen.
Schritt 3: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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, für das die Maßnahme ergriffen wurde.
- Erwägen Sie, das potenziell manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das potenziell 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.
- Antworten Sie auf alle Benachrichtigungen vom Google Cloud-Support.
- Um einzuschränken, wer Dienstkonten erstellen kann, verwenden Sie Organisationsrichtliniendienst
- 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
wurde durch Prüfung des Administrators ermittelt
Aktivitäts-Audit-Logs, um festzustellen, ob in einem Dienstkonto eine Anomalie aufgetreten ist
Antrag auf Identitätsübernahme
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie das Ergebnis
Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity
wie unter Ergebnisse prüfen. Der Detailbereich für die wird der Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
Was erkannt wurde, insbesondere die folgenden Felder:
- Haupt-E-Mail-Adresse: das letzte Dienstkonto bei der Identitätsübernahme Anfrage, die für den Zugriff auf Google Cloud verwendet wurde
- Dienstname: der API-Name des Google Cloud-Dienstes, der an der Anfrage zur Identitätsübernahme beteiligt ist
- Methodenname: die aufgerufene Methode
- Informationen zur Delegation des Dienstkontos: Details zu den Dienstkonten in der Delegationskette. Das Hauptkonto unten in der Liste ist der Aufrufer der Identitätsübernahmeanfrage.
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 allen ähnlichen Ergebnissen
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
- Wenden Sie sich im Feld Hauptkonto-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
- Prüfen Sie die Principals in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
- Wenden Sie sich an den Inhaber des Identitätswechsel-Anrufers in der Liste Informationen zur Dienstkonto-Delegierung. Prüfen, ob der rechtmäßige Inhaber die Aktion ausführen.
Schritt 3: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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, für das die Maßnahme ergriffen wurde.
- Erwägen Sie, das potenziell manipulierte Dienstkonto zu löschen und alle Dienstkontoschlüssel für das potenziell manipulierte Projekt zu rotieren und zu löschen. Nachher Ressourcen, die das Dienstkonto zur Authentifizierung nutzen, verlieren Zugriff haben. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen und mit Ressourceninhabern zusammenzuarbeiten, 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.
- Antworten Sie auf alle Benachrichtigungen des Google Cloud-Supports.
- Um einzuschränken, wer Dienstkonten erstellen kann, verwenden Sie Organisationsrichtliniendienst
- 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
Die anomale Dienstkonto-Identitätsübernahme wird erkannt, indem die Audit-Logs für den Datenzugriff geprüft 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
- Offen
Privilege Escalation: Anomalous Service Account Impersonator for Data Access
, wie unter Ergebnisse überprüfen beschrieben. Notieren Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte der folgenden Felder.
Gehen Sie unter Was wurde erkannt so vor:
- E-Mail-Adresse des Hauptkontos: Das letzte 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 Anfrage zur Identitätsübernahme beteiligt ist
- Methodenname: die aufgerufene Methode
- Delegationsinformationen für Dienstkonten: Details zu Dienstkonten in der Delegationskette ist das Hauptkonto am Ende der Liste der Aufrufer die Anfrage zur Identitätsübernahme
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
- Wenden Sie sich im Feld Hauptkonto-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
- Prüfen Sie die Principals in der Delegierungskette, um festzustellen, ob die Anfrage ungewöhnlich ist und ob ein Konto manipuliert wurde.
- Wenden Sie sich an den Inhaber des Identitätswechsel-Anrufers in der Liste Informationen zur Dienstkonto-Delegierung. Prüfen, ob der rechtmäßige Inhaber die Aktion ausführen.
Schritt 3: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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, für das die Maßnahme ergriffen wurde.
- Prüfen Sie, ob Sie das potenziell manipulierte Dienstkonto löschen, rotieren und löschen können. alle Dienstkonto-Zugriffsschlüssel für das potenziell manipulierte Projekt. 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.
- Antworten Sie auf alle Benachrichtigungen vom Google Cloud-Support.
- Um einzuschränken, wer Dienstkonten erstellen kann, verwenden Sie Organisationsrichtliniendienst
- Um IAM-Rollen mit zu vielen Berechtigungen zu identifizieren und zu beheben, verwenden Sie IAM Recommender.
Privilege Escalation: ClusterRole with Privileged Verbs
Jemand hat ein RBAC-ClusterRole
-Objekt erstellt, das bind
, escalate
oder
impersonate
Verben Ein Subjekt, das mit diesen Verben an eine Rolle gebunden ist,
die Identität anderer Nutzer mit höheren Berechtigungen anzunehmen, an zusätzliche Role
binden
oder ClusterRole
-Objekte, die zusätzliche Berechtigungen enthalten, oder ihre eigenen ändern
ClusterRole
-Berechtigungen. Dies könnte dazu führen, dass diese Personen
cluster-admin
Berechtigungen. Weitere Informationen finden Sie in der Lognachricht zu diesem
Benachrichtigung.
- Sieh dir dazu die
ClusterRole
und die zugehörigenClusterRoleBindings
an ob die Subjekte diese Berechtigungen tatsächlich benötigen. - Erstellen Sie nach Möglichkeit keine Rollen, die
bind
,escalate
oderimpersonate
Verben - Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten gibt: in den Audit-Logs in Cloud Logging.
- 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 eines Sicherheitsvorfalls durch übermäßige Zugriffsrechte.
Privilege Escalation: ClusterRoleBinding to Privileged Role
Jemand hat einen RBAC-ClusterRoleBinding
erstellt, der auf die Standardsystem:controller:clusterrole-aggregation-controller
ClusterRole
verweist. Diese standardmäßige ClusterRole
hat das Verb escalate
, mit dem Subjekte die Berechtigungen ihrer eigenen Rollen ändern können, was eine Rechteausweitung ermöglicht. Weitere Informationen
finden Sie in der Lognachricht für diese Benachrichtigung.
- Prüfen Sie alle
ClusterRoleBinding
, die auf diesystem:controller:clusterrole-aggregation-controller
ClusterRole
. - Überprüfen Sie alle Änderungen am
system:controller:clusterrole-aggregation-controller
,ClusterRole
. - Prüfen Sie, ob die Audit-Logs in Cloud Logging weitere Anzeichen für schädliche Aktivitäten des Hauptkontos enthalten, das die
ClusterRoleBinding
erstellt hat.
Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape
Ein Nutzer hat einen Pod mit einer Namenskonvention ähnlich den gängigen Tools bereitgestellt, die für und andere Angriffe auf den Cluster auszuführen. Weitere Informationen finden Sie in der Protokollmeldung zu dieser Benachrichtigung.
- Bestätigen Sie, dass der Pod rechtmäßig ist.
- Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten auf dem Pod oder in den Audit-Logs in Cloud Logging.
- Wenn das Hauptkonto kein Dienstkonto ist (IAM oder Kubernetes), wenden Sie sich an den Kontoinhaber, um zu erfahren, ob der rechtmäßige Kontoinhaber die Aktion durchgeführt hat.
- Wenn das Hauptkonto ein Dienstkonto ist (IAM oder Kubernetes), um die Quelle der Aktion zu ermitteln, um ihre Rechtmäßigkeit zu ermitteln.
- 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 auf einen sensiblen Pfad im Dateisystem des Hostknotens enthält. Zugriff auf diese Pfade auf dem Host
kann über das Dateisystem auf privilegierte oder vertrauliche Informationen
und für Container-Escape-Zeichen. Erlauben Sie nach Möglichkeit keine hostPath
-Volumes in Ihrem Cluster. Weitere Informationen finden Sie in der Protokollmeldung zu dieser Benachrichtigung.
- Prüfen Sie die Arbeitslast, um festzustellen, ob dieses
hostPath
-Volume für die gewünschte Funktionalität bietet. Wenn ja, achten Sie darauf, dass der Pfad zu einem möglichst spezifischen Verzeichnis führt. Beispiel:/etc/myapp/myfiles
statt/
oder/etc
. - Prüfen Sie, 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 bereitgestellt, für die die Option shareProcessNamespace
auf
true
, wodurch alle Container denselben Linux-Prozess-Namespace nutzen können. So könnte ein nicht vertrauenswürdiger oder manipulierter Container Berechtigungen eskalieren, indem er auf Umgebungsvariablen, Arbeitsspeicher und andere vertrauliche Daten von Prozessen zugreift, die in anderen Containern ausgeführt werden. Für einige Arbeitslasten ist diese Funktion aus legitimen Gründen erforderlich, z. B. für Sidecar-Container zur Protokollbehandlung oder für Debugging-Container. Weitere Informationen finden Sie im Protokoll.
für diese Warnung angezeigt.
- Prüfen Sie, ob die Arbeitslast tatsächlich Zugriff auf einen freigegebenen Prozess-Namespace für alle Container in der Arbeitslast benötigt.
- Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten des Hauptkontos gibt in die Audit-Logs in Cloud Logging.
- Wenn das Hauptkonto kein Dienstkonto ist (IAM oder Kubernetes), wenden Sie sich an den Kontoinhaber, um zu erfahren, ob er die Aktion ausführen.
- 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
Öffnen Sie wie beschrieben ein
Discovery: Service Account Self-Investigation
-Ergebnis. weiter oben im Abschnitt Ergebnisdetails ansehen Seite. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- Schweregrad: Die dem Ergebnis zugeordnete Risikostufe. Der Schweregrad
ist
HIGH
, wenn der API-Aufruf, der dieses Ergebnis ausgelöst hat, war nicht autorisiert. Das Dienstkonto ist nicht berechtigt, seine eigenen IAM-Berechtigungen mit derprojects.getIamPolicy
API verwenden. - Hauptkonto-E-Mail-Adresse: das potenziell manipulierte Dienstkonto.
- Aufrufende IP-Adresse: die interne oder externe IP-Adresse
- Schweregrad: Die dem Ergebnis zugeordnete Risikostufe. Der Schweregrad
ist
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Name der Ressource:
- Vollständiger Name des Projekts: das Projekt, das die potenziell gehackten Kontoanmeldedaten enthält.
- Weitere Informationen, insbesondere die folgenden Felder:
- Cloud Logging-URI: Link zu Logging-Einträgen.
- MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation.
- Ähnliche Ergebnisse: Links zu ähnlichen Ergebnissen.
- Klicken Sie auf den Tab JSON, um den vollständigen JSON-Code für das Ergebnis aufzurufen.
- Was erkannt wurde, insbesondere die folgenden Felder:
Schritt 2: Projekt- und Dienstkontoberechtigungen prüfen
Öffnen Sie in der Google Cloud Console die Seite IAM.
Wählen Sie gegebenenfalls das Projekt aus, das im Feld
projectID
der nach JSON suchen.Geben Sie auf der angezeigten Seite den Kontonamen im Feld Filter ein. E-Mail-Adresse des Hauptkontos und prüfen Sie die zugewiesenen Berechtigungen.
Rufen Sie in der Google Cloud Console die Seite Dienstkonten auf.
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
- Klicken Sie im Bereich mit den Ergebnisdetails auf dem Tab Zusammenfassung auf das Link zum Cloud Logging-URI, um den Log-Explorer zu öffnen.
- Wählen Sie bei Bedarf Ihr Projekt aus.
- 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
- Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Permission Groups Discovery: Cloud Groups.
- Um einen Antwortplan zu entwickeln, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Studie.
Schritt 5: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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.
Inhibit System Recovery: Deleted Google Cloud Backup and DR host
Event Threat Detection untersucht Audit-Logs, um das Löschen von Hosts zu erkennen, Anwendungen ausführen, die durch den Dienst für Sicherung und Notfallwiederherstellung geschützt sind. Nach dem Löschen eines Hosts können die mit dem Host verknüpften Anwendungen nicht mehr gesichert werden.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
- Öffne
Inhibit System Recovery: Deleted Google Cloud Backup and DR host
wie unter Ergebnisse überprüfen beschrieben. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet. - Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Anwendungsname: Der Name einer Datenbank oder VM, die mit Sicherung und Notfallwiederherstellung verbunden ist.
- Hostname: Der Name eines Hosts, der mit dem Sicherungs- und Notfallwiederherstellungssystem verbunden ist.
- Principal subject: Ein Nutzer, der eine Aktion erfolgreich ausgeführt hat.
- Betroffene Ressource
- Anzeigename der Ressource: 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
- Erkannte Daten, insbesondere die folgenden Felder:
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
Wenden Sie sich im Feld E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
Schritt 3: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung 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.
- Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf.
- Prüfen Sie, ob der gelöschte Host nicht mehr in der Liste der Sicherungs- und Notfallwiederherstellungshosts aufgeführt ist.
- Wählen Sie die Option Host hinzufügen aus, um den gelöschten Host wieder hinzuzufügen.
Inhibit System Recovery: Google Cloud Backup and DR remove plan
Security Command Center untersucht Audit-Logs, um das anomale Löschen eines Sicherungsplan für den Sicherungs- und Notfallwiederherstellungsdienst, der zum Anwenden von Sicherungsrichtlinien auf eine Anwendung verwendet wird.
Schritt 1: Ergebnisdetails prüfen
- Öffnen Sie das
Inhibit System Recovery: Google Cloud Backup and DR remove plan
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Details für das Ergebnis wird der Tab Zusammenfassung geöffnet. - Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Anwendungsname: Der Name einer Datenbank oder VM, die mit Sicherung und Notfallwiederherstellung verbunden ist.
- Profilname: Gibt das Speicherziel für Sicherungen von Anwendungs- und VM-Daten an.
- Vorlagenname: Der Name für eine Reihe von Richtlinien, die die Sicherungshäufigkeit, den Zeitplan und die Aufbewahrungsdauer definieren
- Betroffene Ressource
- Anzeigename der Ressource: das Projekt, in dem der Plan 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
- Erkannte Daten, insbesondere die folgenden Felder:
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
Wenden Sie sich im Feld E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
Schritt 3: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet. Sorgfältig die bei der Untersuchung gesammelten Informationen auszuwerten, um die beste Lösung Lösung von Erkenntnissen zu finden.
- Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf.
- Suchen Sie auf dem Tab App-Manager die betroffenen Anwendungen, die nicht mehr geschützt werden und jeweils Sicherungsrichtlinien überprüfen.
Inhibit System Recovery: Google Cloud Backup and DR delete template
Security Command Center untersucht Audit-Logs, um das anomale Löschen eines Vorlage. Eine Vorlage ist eine Basiskonfiguration für Sicherungen, die auf mehrere Anwendungen angewendet werden kann.
Schritt 1: Ergebnisdetails prüfen
- Öffnen Sie das
Inhibit System Recovery: Google Cloud Backup and DR delete template
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet. - Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- Vorlagenname: Der Name für eine Reihe von Richtlinien, die die Sicherungshäufigkeit, den Zeitplan und die Aufbewahrungsdauer definieren
- Principal subject: Ein Nutzer, der eine Aktion erfolgreich ausgeführt hat.
- Betroffene Ressource
- Anzeigename der Ressource: Projekt, in dem die Vorlage 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
- Was erkannt wurde, insbesondere die folgenden Felder:
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
Wenden Sie sich im Feld E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
Schritt 3: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet. Sorgfältig die bei der Untersuchung gesammelten Informationen auszuwerten, um die beste Lösung Lösung von Erkenntnissen zu finden.
- Rufen Sie im Projekt, in dem die Maßnahme ergriffen wurde, die Verwaltungskonsole auf.
- Suchen Sie auf dem Tab App-Manager nach den betroffenen Anwendungen, die nicht mehr geschützt werden und jeweils Sicherungsrichtlinien überprüfen.
- Wenn Sie eine Vorlage wieder hinzufügen möchten, rufen Sie den Tab Sicherungspläne auf, wählen Sie Vorlagen und dann die Option Vorlage erstellen aus.
Inhibit System Recovery: Google Cloud Backup and DR delete policy
Audit-Logs werden untersucht, 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
- Öffnen Sie das
Inhibit System Recovery: Google Cloud Backup and DR delete policy
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet. - Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Richtlinienname: Der Name einer einzelnen Richtlinie, der Häufigkeit, Zeitplan und Aufbewahrungszeit der Sicherung definiert.
- Hauptsubjekt: Ein Nutzer, der eine Aktion erfolgreich ausgeführt hat
- Betroffene Ressource
- Anzeigename der Ressource: Projekt, in dem die Richtlinie 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
- Erkannte Daten, insbesondere die folgenden Felder:
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
Wenden Sie sich im Feld E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
Schritt 3: Antwort implementieren
Der folgende Reaktionsplan kann für dieses Ergebnis geeignet sein. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln. 1. Rufen Sie im Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf. 2. Wählen Sie auf dem Tab App-Manager die betroffene Anwendung aus und prüfen Sie die Richtlinieneinstellungen, die auf diese Anwendung angewendet werden.
Inhibit System Recovery: 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
- Öffnen Sie das Ergebnis
Inhibit System Recovery: Google Cloud Backup and DR delete profile
, wie unter Ergebnisse überprüfen beschrieben. Der Detailbereich des Ergebnisses wird auf dem Tab Zusammenfassung geöffnet. - Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Profile name (Profilname): gibt das Speicherziel für Sicherungen von Anwendungs- und VM-Daten an
- Principal subject: Ein Nutzer, der eine Aktion erfolgreich ausgeführt hat.
- Betroffene Ressource
- Ressourcen-Anzeigename: das Projekt, in dem das Profil 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
- Erkannte Daten, insbesondere die folgenden Felder:
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
Wenden Sie sich im Feld E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
Schritt 3: Antwort implementieren
Der folgende Reaktionsplan kann für dieses Ergebnis geeignet sein. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln. 1. Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf. 2. Wählen Sie auf dem Tab Sicherungspläne die Option Profile aus, um eine Liste aller Profile aufzurufen. 3. Prüfen Sie die Profile, um sicherzustellen, dass alle erforderlichen Profile vorhanden sind. 4. Wenn das gelöschte Profil irrtümlich entfernt wurde, wählen Sie Profil erstellen aus, um Speicherziele für Ihre Sicherungs- und Notfallwiederherstellungs-Appliances zu definieren.
Inhibit System Recovery: Google Cloud Backup and DR delete storage pool
Audit-Logs werden untersucht, um das Löschen eines Speicherpools zu erkennen. Ein Speicherpool verknüpft einen Cloud Storage-Bucket mit Sicherung und Notfallwiederherstellung.
Schritt 1: Ergebnisdetails prüfen
- Öffnen Sie das
Inhibit System Recovery: Google Cloud Backup and DR delete storage pool
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet. - Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- Speicherpoolname: der Name für Storage-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
- Weitere Informationen, insbesondere die folgenden Felder:
- MITRE ATTACK-Methode: Link zur MITRE ATT&CK-Dokumentation
- Logging-URI: Link zum Öffnen des Log-Explorers
- Was erkannt wurde, insbesondere die folgenden Felder:
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
Wenden Sie sich im Feld E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
Schritt 3: Antwort implementieren
Der folgende Reaktionsplan kann für dieses Ergebnis geeignet sein. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln. 1. Rufen Sie im Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf. 2. Wählen Sie auf dem Tab „Verwalten“ die Option Speicherpools aus, um eine Liste aller Speicherpools zu erhalten. 3. Prüfen Sie die Verknüpfungen von Speicherpools mit Sicherungsgeräten. 4. Wenn einer aktiven Appliance kein Speicherpool zugewiesen ist, wählen Sie OnVault-Pool hinzufügen aus, um ihn wieder hinzuzufügen.
Data Destruction: Google Cloud Backup and DR expire image
Ein potenziell böswilliger Akteur hat das Löschen eines Back-up-Images angefordert.
Schritt 1: Ergebnisdetails prüfen
- Ö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 mit dem Tab Zusammenfassung geöffnet. - Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Richtlinienname: Der Name einer einzelnen Richtlinie, der Sicherungshäufigkeit, -zeitplan und -aufbewahrungsdauer definiert.
- Vorlagenname: Der Name für eine Reihe von Richtlinien, die die Sicherungshäufigkeit, den Zeitplan und die Aufbewahrungsdauer definieren
- Profile name (Profilname): gibt das Speicherziel für Sicherungen von Anwendungs- und VM-Daten an
- Principal subject: Ein Nutzer, der eine Aktion erfolgreich ausgeführt hat.
- Betroffene Ressource
- Ressourcen-Anzeigename: das Projekt, in dem das Sicherungs-Image 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
- Erkannte Daten, insbesondere die folgenden Felder:
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
Wenden Sie sich im Feld E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
Schritt 3: Antwort implementieren
Der folgende Reaktionsplan kann für dieses Ergebnis geeignet sein. Bewerten Sie sorgfältig die Informationen, die Sie im Rahmen Ihrer Untersuchung gesammelt haben, um den besten Weg zur Lösung der Ergebnisse zu finden. 1. Rufen Sie im Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf. 2. Rufen Sie den Tab „Überwachen“ auf und wählen Sie „Jobs“ aus, um den Status des Löschjobs für Back-ups zu prüfen. 3. Wenn ein Löschjob nicht autorisiert ist, rufen Sie die IAM-Berechtigungen auf, um zu prüfen, welche Nutzer Zugriff auf Sicherungsdaten haben.
Data Destruction: Google Cloud Backup and DR expire all images
Ein potenziell böswilliger Akteur hat die Löschung aller Backup-Images angefordert, die mit einer Anwendung verknüpft sind.
Schritt 1: Ergebnisdetails prüfen
- Öffnen Sie das Ergebnis
Inhibit System Recovery: Google Cloud Backup and DR expire all images
, wie unter Ergebnisse überprüfen beschrieben. Der Detailbereich des Ergebnisses wird auf dem Tab Zusammenfassung geöffnet. - Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Richtlinienname: Der Name einer einzelnen Richtlinie, der Sicherungshäufigkeit, -zeitplan und -aufbewahrungsdauer definiert.
- Vorlagenname: Der Name für eine Reihe von Richtlinien, die die Sicherungshäufigkeit, den Zeitplan und die Aufbewahrungsdauer definieren
- Profile name (Profilname): gibt das Speicherziel für Sicherungen von Anwendungs- und VM-Daten an
- Principal subject: Ein Nutzer, der eine Aktion erfolgreich ausgeführt hat.
- Betroffene Ressource
- Ressourcen-Anzeigename: das Projekt, in dem die Sicherungsbilder gelöscht wurden
- Weitere Informationen, insbesondere die folgenden Felder:
- MITRE ATTACK-Methode: Link zur MITRE ATT&CK-Dokumentation
- Logging-URI: Link zum Öffnen des Log-Explorers
- Erkannte Daten, insbesondere die folgenden Felder:
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
Wenden Sie sich im Feld E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
Schritt 3: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln. 1. Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf. 2. Rufen Sie den Tab „Überwachen“ auf und wählen Sie „Jobs“ aus, um den Status des Löschjobs für Back-ups zu prüfen. 3. Wenn ein Löschauftrag nicht autorisiert ist, rufen Sie die IAM-Berechtigungen auf, um Nutzer mit Zugriff auf Sicherungsdaten zu überprüfen.
Data Destruction: Google Cloud Backup and DR remove appliance
Audit-Logs werden untersucht, um die Entfernung einer Sicherungs- und Wiederherstellungs-Appliance zu erkennen. Eine Sicherungs- und Wiederherstellungs-Appliance ist eine wichtige Komponente für Sicherungsvorgänge.
Schritt 1: Ergebnisdetails prüfen
- Öffnen Sie das Ergebnis
Inhibit System Recovery: Google Cloud Backup and DR remove appliance
, wie unter Ergebnisse überprüfen beschrieben. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet. - Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Appliance-Name: Der Name einer Datenbank oder VM, die mit Sicherung und Notfallwiederherstellung verbunden ist.
- Principal subject: Ein Nutzer, der eine Aktion erfolgreich ausgeführt hat.
- Betroffene Ressource
- Anzeigename der Ressource: das Projekt, in dem das Gerät 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
- Erkannte Daten, insbesondere die folgenden Felder:
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
Wenden Sie sich im Feld E-Mail-Adresse des Hauptkontos an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber ausgeführt wurde.
Schritt 3: Antwort implementieren
Der folgende Reaktionsplan kann für dieses Ergebnis geeignet sein. Bewerten Sie sorgfältig die Informationen, die Sie im Rahmen Ihrer Untersuchung gesammelt haben, um den besten Weg zur Lösung der Ergebnisse zu finden. 1. Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf. 2. Suchen Sie auf dem Tab App-Manager nach den betroffenen Anwendungen, die nicht mehr geschützt sind, und prüfen Sie die Sicherungsrichtlinien für jede Anwendung. 3. Wenn Sie eine neue Appliance erstellen und den Schutz auf nicht geschützte Apps anwenden möchten, rufen Sie in der Google Cloud Console „Sicherung und Notfallwiederherstellung“ auf und wählen Sie die Option „Weitere Sicherungs- oder Wiederherstellungs-Appliance bereitstellen“ aus. 4. Konfigurieren Sie im Menü Speicher jede neue Appliance mit einem Speicherziel. Nachdem Sie eine Appliance konfiguriert haben, wird sie als Option angezeigt, wenn Sie ein Profil für Ihre Anwendungen erstellen.
Impact: Google Cloud Backup and DR reduced backup expiration
Event Threat Detection untersucht Audit-Logs, um festzustellen, ob das Ablaufdatum für die Sicherung einer Sicherungs- und Notfallwiederherstellungs-Appliance reduziert.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
- Öffnen Sie das
Impact: Google Cloud Backup and DR reduced backup expiration
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Bereich mit den Details zum Ergebnis wird auf dem Tab Zusammenfassung geöffnet. - Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- Beschreibung: Informationen zur Erkennung
- Inhaber des Hauptkontos: ein Nutzer oder ein Dienstkonto, das erfolgreich hat eine Aktion ausgeführt
- Betroffene Ressource
- Ressourcen-Anzeigename: das Projekt, in dem das Ablaufdatum der Sicherung verkürzt wurde.
- Weitere Informationen, insbesondere die folgenden Felder:
- MITRE-ATTACK-Methode: Link zur Dokumentation zu MITRE ATT&CK
- Logging-URI: Link zum Öffnen des Log-Explorers.
- Was erkannt wurde, insbesondere die folgenden Felder:
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
Wenden Sie sich im Feld Inhaber des Hauptkontos an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
Schritt 3: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet. Sorgfältig die bei der Untersuchung gesammelten Informationen auszuwerten, um die beste Lösung Lösung von Erkenntnissen zu finden.
- Rufen Sie im Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf.
- Suchen Sie auf dem Tab App-Manager nach der betroffenen Anwendung, für die die Gültigkeitsdauer der Sicherung verkürzt wurde, und prüfen Sie, ob die Gültigkeitsdauer vom Hauptkontoinhaber beabsichtigt war.
- 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 prüft Prüfprotokolle, um festzustellen, ob der Sicherungsplan geändert wurde, um die Sicherungshäufigkeit zu reduzieren.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
- Öffne
Impact: Google Cloud Backup and DR reduced backup frequency
wie unter Ergebnisse überprüfen beschrieben. Die Der Detailbereich des Ergebnisses wird auf dem Tab Zusammenfassung geöffnet. - Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- Beschreibung: Informationen zur Erkennung
- Inhaber des Hauptkontos: ein Nutzer oder ein Dienstkonto, das erfolgreich hat eine Aktion ausgeführt
- Betroffene Ressource
- Anzeigename der Ressource: das Projekt, für das die Sicherungshäufigkeit reduziert wurde.
- Weitere Informationen, insbesondere die folgenden Felder:
- MITRE-ATTACK-Methode: Link zur Dokumentation zu MITRE ATT&CK
- Logging-URI: Link zum Öffnen des Log-Explorers.
- Was erkannt wurde, insbesondere die folgenden Felder:
Schritt 2: Angriffs- und Reaktionsmethoden untersuchen
Wenden Sie sich im Feld Inhaber des Hauptkontos an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
Schritt 3: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet. Sorgfältig die bei der Untersuchung gesammelten Informationen auszuwerten, um die beste Lösung Lösung von Erkenntnissen zu finden.
- Rufen Sie in dem Projekt, in dem die Aktion ausgeführt wurde, die Verwaltungskonsole auf.
- Suchen Sie auf dem Tab App Manager nach der Anwendung, für die Sie die Sicherung verwenden möchten. und überprüfen Sie, ob die Änderung beabsichtigt war. Prinzipal.
- Um eine neue Sicherung der Anwendung zu starten, wählen Sie Sicherungskonfigurationen verwalten, um On-Demand-Sicherungen zu erstellen oder eine neue Sicherung planen.
Impact: Suspicious Kubernetes Container Names - Coin Mining
Jemand hat einen Pod mit einer Namenskonvention ähnlich der gängigen Kryptowährung bereitgestellt Minenarbeiter:innen. Dies kann ein Versuch eines Angreifers sein, der Zugriff auf den Cluster, um seine Ressourcen für das Mining von Kryptowährungen zu verwenden. Weitere Informationen finden Sie in der Protokollmeldung zu dieser Benachrichtigung.
- Bestätigen Sie, dass der Pod rechtmäßig ist.
- Prüfen Sie, ob es weitere Anzeichen für schädliche Aktivitäten auf dem Pod oder in den Audit-Logs in Cloud Logging.
- Wenn das Hauptkonto kein Dienstkonto ist (IAM oder Kubernetes), wenden Sie sich an den Kontoinhaber, um zu erfahren, ob der rechtmäßige Kontoinhaber die Aktion durchgeführt hat.
- Wenn das Hauptkonto ein Dienstkonto ist (IAM oder Kubernetes), um die Quelle der Aktion zu ermitteln, um ihre Rechtmäßigkeit zu ermitteln.
- 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.
Lateral Movement: Modified Boot Disk Attached to Instance
Audit-Logs werden geprüft, um verdächtige Laufwerksbewegungen unter den Ressourcen von Compute Engine-Instanzen zu erkennen. Ein potenziell geändertes Bootlaufwerk wurde an Ihre Compute Engine angehängt.
Schritt 1: Ergebnisdetails prüfen
- Öffnen Sie das Ergebnis
Lateral Movement: Modify Boot Disk Attaching to Instance
, wie unter Ergebnisse überprüfen beschrieben. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet. Notieren Sie sich auf dem Tab Zusammenfassung die Werte der folgenden Felder.
Gehen Sie unter Was wurde erkannt so vor:
- Hauptkonto-E-Mail-Adresse: das Dienstkonto, das die Aktion ausgeführt hat
- 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
- Dienstkonto verwenden Tools wie Aktivität Analysetool, um die Aktivität des zugehörigen Dienstkontos zu untersuchen.
- Wenden Sie sich im Feld Hauptkonto-E-Mail-Adresse an den Inhaber des Dienstkontos. Prüfen Sie, ob die Aktion vom rechtmäßigen Inhaber durchgeführt wurde.
Schritt 3: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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, für das die Maßnahme ergriffen wurde.
- Erwägen Sie die Verwendung Secure Boot für Ihr Compute Engine-VM-Instanzen
- Prüfen Sie, ob Sie das potenziell manipulierte Dienstkonto löschen, rotieren und löschen können. alle Dienstkonto-Zugriffsschlüssel für das potenziell manipulierte Projekt. Nachher Anwendungen, die das Dienstkonto zur Authentifizierung verwenden, verlieren Zugriff haben. Bevor Sie fortfahren, sollte Ihr Sicherheitsteam alle betroffenen und arbeiten mit den Inhabern der Anwendungen zusammen, 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.
- Antworten Sie auf alle Benachrichtigungen des Google Cloud-Supports.
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
- Öffnen Sie das
Privilege Escalation: AlloyDB Over-Privileged Grant
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Sehen Sie sich auf dem Tab Zusammenfassung des Bereichs „Ergebnisdetails“ die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Anzeigename der Datenbank: Der Name der betroffenen Datenbank in der AlloyDB for PostgreSQL-Instanz.
- Datenbanknutzername: der PostgreSQL-Nutzer, der nicht erforderliche Berechtigungen gewährt hat.
- Datenbankabfrage: Die ausgeführte PostgreSQL-Abfrage, mit der die Berechtigungen gewährt wurden.
- Empfänger von Datenbankberechtigungen: 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 von AlloyDB for PostgreSQL Instanz.
- Vollständiger Name des Projekts: Das Google Cloud-Projekt, das folgendes Element enthält: AlloyDB for PostgreSQL-Instanz.
- Weitere Informationen, insbesondere die folgenden Felder:
- Cloud Logging-URI: Link zu Logging-Einträgen.
- MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation.
- Erkannte Daten, insbesondere die folgenden Felder:
Klicken Sie auf den Tab JSON, um den vollständigen JSON-Code für das Ergebnis aufzurufen.
Schritt 2: Datenbankberechtigungen prüfen
- Verbinden Sie sich mit der AlloyDB for PostgreSQL-Instanz.
- Zugriffsberechtigungen auflisten und einblenden
für Folgendes:
- Datenbanken Verwenden Sie den Metabefehl
\l
oder\list
und prüfen Sie, welche Berechtigungen für die Datenbank zugewiesen sind, die unter Datenbank-Anzeigename (aus Schritt 1) aufgeführt ist. - Funktionen oder Verfahren. Verwenden Sie den Metabefehl
\df
und prüfen, welche Berechtigungen Funktionen oder Verfahren im Datenbank, die unter Anzeigename der Datenbank aufgeführt ist (von Schritt 1).
- Datenbanken Verwenden Sie den Metabefehl
Schritt 3: Protokolle prüfen
- Öffnen Sie in der Google Cloud Console den Log-Explorer. 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.
- Prüfen Sie im Log-Explorer die PostgreSQL-
pgaudit
-Logs, in denen Abfragen an die Datenbank mit den folgenden Filtern ausgeführt:protoPayload.request.database="var class="edit">database"
Schritt 4: Angriffs- und Reaktionsmethoden untersuchen
- Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Exfiltration over Web Service.
- Wenn Sie feststellen möchten, ob zusätzliche Abhilfemaßnahmen erforderlich sind, kombinieren Sie Ihre Prüfergebnisse mit MITRE Forschung.
Schritt 5: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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 zu vielen Berechtigungen.
- Sie sollten das Widerrufen in Betracht ziehen. alle Berechtigungen für die Empfänger, die in der Liste Empfänger der Datenbank aufgeführt sind bis die Untersuchung abgeschlossen ist.
- Beschränken Sie den Zugriff auf die Datenbank (über Anzeigename der Datenbank oder Schritt 1: Widerrufen nicht erforderlich von den Empfängern der Datenbank von Schritt 1:
Privilege Escalation: AlloyDB Database Superuser Writes to User Tables
Erkennt, wenn das AlloyDB for PostgreSQL-Datenbank-Superuser-Konto (postgres
)
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änktem Zugriff verwendet werden. Wenn ein Superuser in eine Nutzertabelle schreibt, könnte das darauf hindeuten, dass ein Angreifer seine Berechtigungen 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
- Öffnen Sie ein
Privilege Escalation: AlloyDB Database Superuser Writes to User Tables
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Sehen Sie sich auf dem Tab Zusammenfassung des Bereichs „Ergebnisdetails“ die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Anzeigename der Datenbank: der Name der Datenbank in der AlloyDB for PostgreSQL-Instanz, die betroffen war.
- Database user name (Name des Datenbanknutzers): 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 von AlloyDB for PostgreSQL Instanz.
- Vollständiger Name des Projekts: Das Google Cloud-Projekt, das folgendes Element enthält: AlloyDB for PostgreSQL-Instanz.
- Weitere Informationen, insbesondere die folgenden Felder:
- Cloud Logging-URI: Link zu Logging-Einträgen.
- MITRE ATT&CK-Methode: Link zur MITRE ATT&CK-Dokumentation.
- Erkannte Daten, insbesondere die folgenden Felder:
Klicken Sie auf den Tab JSON, um die vollständige JSON-Datei für das Ergebnis aufzurufen.
Schritt 2: Protokolle prüfen
- Öffnen Sie in der Google Cloud Console Log-Explorer. Klicken Sie dazu auf den Link in
cloudLoggingQueryURI
(aus Schritt 1). Die Seite Log-Explorer enthält alle Logs für den entsprechenden AlloyDB for PostgreSQL-Instanz. - Prüfen Sie die Logs auf pgaudit-Logs für PostgreSQL, die die Abfragen enthalten
vom Superuser mit folgenden Filtern ausgeführt:
protoPayload.request.user="postgres"
Schritt 3: Forschungsangriffe und Reaktionsmethoden
- Sehen Sie sich den MITRE-ATT&CK-Framework-Eintrag für diesen Ergebnistyp an: Exfiltration over Web Service.
- Um festzustellen, ob zusätzliche Schritte zur Abhilfe erforderlich sind, kombinieren Sie Ihre Untersuchungsergebnisse mit dem MITRE-Forschung.
Schritt 4: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet, kann sich aber 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 die Nutzer, die eine Verbindung zur Datenbank herstellen dürfen.
- Sie sollten das Passwort für den Superuser ändern.
- Erstellen Sie einen neuen Nutzer mit eingeschränktem Zugriff.
für die verschiedenen Abfragetypen ab, die für die Instanz verwendet werden.
- Gewähren Sie dem neuen Nutzer nur die Berechtigungen, die zum Ausführen seiner Abfragen erforderlich sind.
- Aktualisieren Sie die Anmeldedaten für die Clients, die eine Verbindung zur AlloyDB for PostgreSQL-Instanz herstellen
Metadaten-Erkennung für Compute Engine Administrator
Persistence: GCE Admin Added SSH Key
Beschreibung | Aktionen | |
---|---|---|
Der Metadatenschlüssel ssh-keys der Compute Engine-Instanz wurde auf einer vorhandenen Instanz geändert.
|
Der Metadatenschlüssel ssh-keys der Compute Engine-Instanz wurde auf einer Instanz geändert, die vor mehr als sieben Tagen erstellt wurde. Prüfen Sie, ob die Änderung absichtlich von einem Mitglied vorgenommen oder von einem Angreifer implementiert wurde, um neuen Zugriff auf Ihre Organisation einzuführen.
|
Prüfen Sie Logs mit den folgenden Filtern:
Dabei gilt:
|
Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: |
Persistence: GCE Admin Added Startup Script
Beschreibung | Aktionen | |
---|---|---|
Der Metadatenschlüssel startup-script oder startup-script-url der Compute Engine-Instanz wurde auf einer vorhandenen Instanz geändert.
|
Einer der Metadatenschlüssel startup-script oder startup-script-url der Compute Engine-Instanz wurde auf einer Instanz geändert, die vor mehr als sieben Tagen erstellt wurde. Prüfen Sie, ob die Änderung absichtlich von einem Mitglied vorgenommen oder von einem Angreifer implementiert wurde, um neuen Zugriff auf Ihre Organisation einzuführen.
|
Prüfen Sie Logs mit den folgenden Filtern:
Dabei gilt:
|
Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: |
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 es sich bei Google Workspace-Logs um Logs auf Organisationsebene handelt, können sie nur mit Event Threat Detection gescannt werden, wenn Sie Security Command Center auf Organisationsebene aktivieren.
Event Threat Detection reichert Logereignisse an und schreibt Ergebnisse in Security Command Center. Die folgende Tabelle enthält Google Workspace-Bedrohungen, relevante MITRE ATT&CK-Framework-Einträge und Details zu den Ereignissen, die Ergebnisse auslösen. Sie können Logs auch mit bestimmten Filtern prüfen und alle Informationen kombinieren, um auf Google Workspace-Bedrohungen zu reagieren.
Initial Access: Disabled Password Leak
Dieses Ergebnis ist nicht verfügbar, wenn Sie Security Command Center auf Projektebene aktivieren.
Beschreibung | Aktionen | |
---|---|---|
Das Konto eines Mitglieds ist deaktiviert, weil ein Passwortleck erkannt wurde. | Setzen Sie die Passwörter für die betroffenen Konten zurück und raten Sie Mitgliedern, starke, eindeutige Passwörter für Unternehmenskonten zu verwenden. |
Prüfen Sie Logs mit den folgenden Filtern:
Ersetzen Sie |
Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: |
Initial Access: Suspicious Login Blocked
Dieses Ergebnis ist nicht verfügbar, wenn Sie Security Command Center auf Projektebene aktivieren.
Beschreibung | Aktionen | |
---|---|---|
Es wurde eine verdächtige Anmeldung im Konto eines Mitglieds erkannt und blockiert. | Auf dieses Konto kann ein Ziel von Angreifern sein. Das Nutzerkonto muss den Sicherheitsrichtlinien Ihrer Organisation für starke Passwörter und Multi-Faktor-Authentifizierung entsprechen. |
Prüfen Sie Logs mit den folgenden Filtern:
Ersetzen Sie |
Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen:
|
Initial Access: Account Disabled Hijacked
Dieses Ergebnis ist nicht verfügbar, wenn Sie Security Command Center auf Projektebene aktivieren.
Beschreibung | Aktionen | |
---|---|---|
Das Konto eines Mitglieds wurde aufgrund verdächtiger Aktivitäten gesperrt. | Dieses Konto wurde gehackt. Setzen Sie das Kontopasswort zurück und fordern Sie Nutzer auf, starke, eindeutige Passwörter für Unternehmenskonten zu erstellen. |
Prüfen Sie Logs mit den folgenden Filtern:
Ersetzen Sie |
Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: |
Impair Defenses: Two Step Verification Disabled
Dieses Ergebnis ist nicht verfügbar, wenn Sie Security Command Center auf Projektebene aktivieren.
Beschreibung | Aktionen | |
---|---|---|
Ein Mitglied hat die Bestätigung in zwei Schritten deaktiviert. | Prüfen Sie, ob der Nutzer die Bestätigung in zwei Schritten deaktivieren wollte. Wenn Ihre Organisation die Bestätigung in zwei Schritten erfordert, sorgen Sie dafür, dass der Nutzer sie sofort aktiviert. |
Prüfen Sie Logs mit den folgenden Filtern:
Ersetzen Sie |
Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen:
|
Initial Access: Government Based Attack
Dieses Ergebnis ist nicht verfügbar, wenn Sie Security Command Center auf Projektebene aktivieren.
Beschreibung | Aktionen | |
---|---|---|
Angreifer, die von staatlichen Stellen unterstützt werden, haben möglicherweise versucht, ein Mitgliedskonto oder einen Computer zu manipulieren. | Auf dieses Konto kann ein Ziel von Angreifern sein. Das Nutzerkonto muss den Sicherheitsrichtlinien Ihrer Organisation für starke Passwörter und Multi-Faktor-Authentifizierung entsprechen. |
Prüfen Sie Logs mit den folgenden Filtern:
Ersetzen Sie |
Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen:
|
Persistence: SSO Enablement Toggle
Dieses Ergebnis ist nicht verfügbar, wenn Sie Security Command Center auf Projektebene aktivieren.
Beschreibung | Aktionen | |
---|---|---|
Die Einstellung "SSO (Einmalanmeldung) aktivieren" für das Administratorkonto wurde deaktiviert. | Die SSO-Einstellungen für Ihre Organisation wurden geändert. Prüfen Sie, ob die Änderung absichtlich von einem Mitglied vorgenommen oder von einem Angreifer implementiert wurde, um neuen Zugriff auf Ihre Organisation einzuführen. |
Prüfen Sie Logs mit den folgenden Filtern:
Dabei gilt:
|
Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: |
Persistence: SSO Settings Changed
Dieses Ergebnis ist nicht verfügbar, wenn Sie Security Command Center auf Projektebene aktivieren.
Beschreibung | Aktionen | |
---|---|---|
Die SSO-Einstellungen für das Administratorkonto wurden geändert. | Die SSO-Einstellungen für Ihre Organisation wurden geändert. Prüfen Sie, ob die Änderung absichtlich von einem Mitglied vorgenommen oder von einem Angreifer implementiert wurde, um neuen Zugriff auf Ihre Organisation einzuführen. |
Prüfen Sie Logs mit den folgenden Filtern:
Dabei gilt:
|
Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: |
Impair Defenses: Strong Authentication Disabled
Dieses Ergebnis ist nicht verfügbar, wenn Sie Security Command Center auf Projektebene aktivieren.
Beschreibung | Aktionen | |
---|---|---|
Die Bestätigung in zwei Schritten wurde für die Organisation deaktiviert. | Die Bestätigung in zwei Schritten ist für Ihre Organisation nicht mehr erforderlich. Prüfen Sie, ob dies eine beabsichtigte Richtlinienänderung durch einen Administrator war oder ob es sich um einen Versuch durch einen Angreifer handelt, um den Kontodiebstahl zu vereinfachen. |
Prüfen Sie Logs mit den folgenden Filtern:
Ersetzen Sie |
Untersuchen Sie Ereignisse, die dieses Ergebnis auslösen: |
Auf Google Workspace-Bedrohungen reagieren
Ergebnisse für Google Workspace sind nur für die Aktivierung von Security Command Center auf Organisationsebene verfügbar. Google Workspace-Logs können nicht auf Aktivierungen auf Projektebene geprüft werden.
Als Google Workspace-Administrator können Sie die Sicherheitstools des Dienstes verwenden, um diese Bedrohungen zu beheben:
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-Bedrohungserkennungen
Cloud IDS: THREAT_ID
Cloud IDS-Ergebnisse werden von Cloud IDS generiert, einem Sicherheitsdienst, der den Traffic zu und von Ihren Google Cloud-Ressourcen auf Bedrohungen überwacht. Wenn Cloud IDS eine Bedrohung erkennt, sendet es Informationen zur Bedrohung, z. B. die Quell-IP-Adresse, die Zieladresse und die Portnummer, an Event Threat Detection. Dieser Dienst stellt dann eine Bedrohungswarnung aus.
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie das
Cloud IDS: THREAT_ID
-Ergebnis, wie unter Ergebnisse prüfen beschrieben.Sehen Sie sich in den Ergebnisdetails auf dem Tab Zusammenfassung die Werte in folgenden Abschnitten:
- Erkannte Daten, insbesondere die folgenden Felder:
- Protokoll: das verwendete Netzwerkprotokoll
- Ereigniszeit: Zeitpunkt, an dem das Ereignis aufgetreten ist
- Beschreibung: Weitere Informationen zur Feststellung
- Schweregrad: Der Schweregrad der Benachrichtigung
- Ziel-IP: Die Ziel-IP-Adresse des Netzwerktraffics.
- Zielport: Der Zielport des Netzwerktraffics.
- Quell-IP: Die Quell-IP-Adresse des Netzwerkverkehrs.
- Quellport: Der Quellport des Netzwerkverkehrs.
- 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.
- Erkennungsdienst
- Ergebniskategorie: Name der Cloud IDS-Bedrohung
- Erkannte Daten, insbesondere die folgenden Felder:
Klicken Sie auf den Tab JSON, um die vollständige JSON-Datei für das Ergebnis aufzurufen.
Schritt 2: Angriffs- und Reaktionsmethoden nachschlagen
Nachdem Sie sich die Details zur Feststellung angesehen haben, lesen Sie die Cloud IDS-Dokumentation zur Untersuchung von Bedrohungswarnungen, um eine geeignete Reaktion zu bestimmen.
Weitere Informationen zum erkannten Ereignis finden Sie im ursprünglichen Logeintrag. Klicken Sie dazu in den Details zur Feststellung 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. Nach der ersten Manipulation installieren Angreifer in der Regel Exploit-Tools und Malware. Eine wichtige Best Practice besteht darin, dafür zu sorgen, dass Ihre Container unveränderlich sind. Dieser Hinweis ist von geringer Bedeutung, da Ihre Organisation diese Best Practice möglicherweise nicht befolgt. Entsprechende Execution: Added Malicious Binary Executed
-Ergebnisse werden ausgegeben, wenn der Hash des Binärprogramms ein bekannter Kompromittierungsindikator (IoC) ist. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie ein
Added Binary Executed
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Programm-Binä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.
- Erkannte Daten, insbesondere die folgenden Felder:
Klicken Sie auf JSON und sehen Sie sich die folgenden Felder an:
resource
:project_display_name
: der Name des Projekts, das Folgendes enthält: des Clusters.
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.
Suchen Sie nach weiteren Ergebnissen, die für diesen Container zu einer ähnlichen Zeit aufgetreten sind. Ähnliche Ergebnisse können darauf hinweisen, dass diese Aktivität schädlich war und nicht, dass Best Practices nicht befolgt wurden.
Schritt 2: Cluster und Knoten prüfen
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie den Cluster aus, der in der Zeile Vollständiger Name der Ressource auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.
Klicken Sie auf den Tab Knoten. Wählen Sie den in
VM_Instance_Name
aufgeführten Knoten aus.Klicken Sie auf den Tab Details und notieren Sie sich die Annotation
container.googleapis.com/instance_id
.
Schritt 3: Pod überprüfen
Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Filtern Sie nach dem Cluster, der in der Zeile Vollständiger Name der Ressource im Tab Zusammenfassung der Ergebnisdetails und des Pod-Namespace die in
Pod_Namespace
aufgeführt sind.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
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.
Gehen Sie auf der Seite, die geladen wird, so vor:
- 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"
- 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
- Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Suchen Sie mit dem folgenden Filter Pod-Logs für
Schritt 5: Laufenden Container prüfen
Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.
Öffnen Sie die Google Cloud Console.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Klicken Sie auf Cloud Shell aktivieren .
Rufen Sie GKE-Anmeldedaten für Ihren Cluster ab, indem Sie den folgenden Befehle.
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 inresource.labels.cluster_name
aufgeführte Clusterlocation
: der inresource.labels.location
aufgeführte Standortproject_name
: der inresource.project_display_name
aufgeführte Projektname
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.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
- Sehen Sie sich die Einträge im MITRE ATT&CK-Framework für diesen Ergebnistyp an: Übertragung von Ingress-Tools Native API.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
Schritt 7: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet, kann sich aber 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 enthaltenen 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 eine wichtige Best Practice, dafür zu sorgen, dass Ihre Container unveränderlich sind. Dieses Ergebnis ist niedrig,
dass Ihre Organisation diese Best Practice möglicherweise nicht einhält. Es gibt entsprechende Execution: Added Malicious Library Loaded
-Ergebnisse, wenn der Hash des Binärprogramms ein bekannter Indikator für Manipulation (IoC) ist. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie ein
Added Library Loaded
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, 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.
- Argumente: die Argumente, die beim Aufrufen des Prozesses angegeben werden binär.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Name der Ressource: der vollständige Ressourcenname des Clusters.
- Erkannte Daten, insbesondere die folgenden Felder:
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, in dem der Pod ausgeführt.
Suchen Sie nach weiteren Ergebnissen, die für diesen Container zu einer ähnlichen Zeit aufgetreten sind. Ähnliche Ergebnisse können darauf hinweisen, dass diese Aktivität schädlich war und nicht, dass Best Practices nicht befolgt wurden.
Schritt 2: Cluster und Knoten prüfen
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie den in
resource.name
aufgeführten Cluster aus. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.Klicken Sie auf den Tab Knoten. Wählen Sie den in
VM_Instance_Name
aufgeführten Knoten aus.Klicken Sie auf den Tab Details und notieren Sie sich die Annotation
container.googleapis.com/instance_id
.
Schritt 3: Pod überprüfen
Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Filtern Sie nach dem Cluster, der in der Zeile Vollständiger Name der Ressource im Tab Zusammenfassung der Ergebnisdetails und des Pod-Namespace die in
Pod_Namespace
aufgeführt sind.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
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.
Gehen Sie auf der Seite, die geladen wird, so vor:
- 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"
- 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
- Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Suchen Sie mit dem folgenden Filter Pod-Logs für
Schritt 5: Laufenden Container prüfen
Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.
Öffnen Sie die Google Cloud Console.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Klicken Sie auf Cloud Shell aktivieren .
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
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.
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
- Sehen Sie sich die Einträge im MITRE ATT&CK-Framework für diesen Ergebnistyp an: Übertragung von Ingress-Tools Freigegebene Module.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
Schritt 7: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet, kann sich aber 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 neu und fügen Sie die Bibliothek hinzu. 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.
Execution: Added Malicious Binary Executed
Eine schädliche Binärdatei, die nicht Teil des ursprünglichen Container-Images war, wurde ausgeführt haben. Angreifer installieren häufig Ausbeutungstools und Malware nach dem anfänglichen Manipulationsprozess. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie ein
Execution: Added Malicious Binary Executed
-Ergebnis wie in Ergebnisse prüfen. Der Detailbereich für die wird der Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Programm-Binärdatei: der absolute Pfad der hinzugefügten Binärdatei.
- Argumente: die Argumente, die beim Aufrufen der hinzugefügten Binärdatei angegeben werden.
- Container: Der Name des betroffenen Containers.
- Container-URI: Der Name des Container-Images, das bereitgestellt wird.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger 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.
- Erkannte Daten, insbesondere die folgenden Felder:
Klicken Sie auf den Tab JSON und sehen Sie sich die folgenden Felder an:
sourceProperties
:VM_Instance_Name
: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.
Schritt 2: Cluster und Knoten prüfen
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie den Cluster aus, der in der Zeile Vollständiger Name der Ressource auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.
Klicken Sie auf den Tab Knoten. Wählen Sie den in
VM_Instance_Name
aufgeführten Knoten aus.Klicken Sie auf den Tab Details und notieren Sie sich die Annotation
container.googleapis.com/instance_id
.
Schritt 3: Pod überprüfen
Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Filtern Sie nach dem Cluster, der in der Zeile Vollständiger Name der Ressource im Tab Zusammenfassung der Ergebnisdetails und des Pod-Namespace die in
Pod_Namespace
aufgeführt sind.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
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.
Gehen Sie auf der Seite, die geladen wird, so vor:
- 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"
- 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
- Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Suchen Sie mit dem folgenden Filter Pod-Logs für
Schritt 5: Laufenden Container prüfen
Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.
Öffnen Sie die Google Cloud Console.
Wählen Sie in der Symbolleiste der Google Cloud Console das Projekt aus, das in
resource.project_display_name
, falls erforderlich.Klicken Sie auf Cloud Shell aktivieren .
Rufen Sie GKE-Anmeldedaten für Ihren Cluster ab, indem Sie den folgenden Befehle.
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 inresource.labels.cluster_name
aufgeführte Clusterlocation
: der inresource.labels.location
aufgeführte Standortproject_name
: der inresource.project_display_name
aufgeführte Projektname
Rufen Sie die hinzugefügte schädliche Binärdatei ab:
kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name local_file
Ersetzen Sie
local_file
durch einen lokalen Pfad, um die hinzugefügte schädliche Binärdatei zu speichern.Stellen Sie eine Verbindung zur Containerumgebung her:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Bei diesem Befehl muss für den Container eine Shell unter
/bin/sh
installiert sein.
Schritt 6: Forschungsangriffs- und Reaktionsmethoden
- Sehen Sie sich die Einträge im MITRE ATT&CK-Framework für diesen Ergebnistyp an: Übertragung von Ingress-Tools Native API.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
- Prüfen Sie den SHA-256-Hashwert für das Binärprogramm, das auf VirusTotal als schädlich gekennzeichnet wurde, 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.
Schritt 7: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet, kann sich aber 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.
Execution: Added Malicious Library Loaded
Eine schädliche Bibliothek, die nicht Teil des ursprünglichen Container-Images war, wurde geladen. Angreifer könnten schädliche Bibliotheken in vorhandene Programme laden, um den Schutz vor Codeausführungen zu umgehen und schädlichen Code zu verbergen. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie ein
Execution: Added Malicious Library Loaded
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, 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.
- Argumente: die Argumente, die beim Aufrufen der Prozessbinärdatei angegeben werden.
- Container: Der Name des betroffenen Containers.
- Container-URI: Der Name des Container-Images, das bereitgestellt wird.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Name der Ressource: der vollständige Ressourcenname des Clusters.
- Weitere Informationen, insbesondere die folgenden Felder:
- VirusTotal-Indikator: Link zur VirusTotal-Analyseseite.
- Erkannte Daten, insbesondere die folgenden Felder:
Klicken Sie auf den Tab JSON und sehen Sie sich die folgenden Felder an:
sourceProperties
:VM_Instance_Name
: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.
Schritt 2: Cluster und Knoten prüfen
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie den Cluster aus, der in der Zeile Vollständiger Name der Ressource auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.
Klicken Sie auf den Tab Knoten. Wählen Sie den in
VM_Instance_Name
aufgeführten Knoten aus.Klicken Sie auf den Tab Details und notieren Sie sich die Annotation
container.googleapis.com/instance_id
.
Schritt 3: Pod überprüfen
Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Filtern Sie nach dem Cluster, der in der Zeile Vollständiger Name der Ressource im Tab Zusammenfassung der Ergebnisdetails und des Pod-Namespace die in
Pod_Namespace
aufgeführt sind.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
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.
Gehen Sie auf der Seite, die geladen wird, so vor:
- 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"
- 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
- Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Suchen Sie mit dem folgenden Filter Pod-Logs für
Schritt 5: Laufenden Container prüfen
Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.
Öffnen Sie die Google Cloud Console.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Klicken Sie auf Cloud Shell aktivieren .
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
Rufen Sie die hinzugefügte schädliche Bibliothek ab:
kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name local_file
Ersetzen Sie local_file durch einen lokalen Pfad, um die hinzugefügte schädliche Bibliothek zu speichern.
Stellen Sie eine Verbindung zur Containerumgebung her:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Bei diesem Befehl muss für den Container eine Shell unter
/bin/sh
installiert sein.
Schritt 6: Forschungsangriffs- und Reaktionsmethoden
- Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ingress-Tool-Übertragung, Freigegebene Module.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
- Überprüfen Sie den SHA-256-Hashwert der Bibliothek, die in VirusTotal von indem Sie auf den Link in der VirusTotal-Anzeige klicken. VirusTotal, ein Alphabet-eigener Dienst, der Kontext zu potenziell schädlichen Dateien, URLs, Domains und IP-Adressen bereitstellt.
Schritt 7: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet, kann sich aber 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.
Execution: Built in Malicious Binary Executed
Eine Binärdatei, die ausgeführt wurde, mit den folgenden Informationen:
- Im ursprünglichen Container-Image enthalten.
- Anhand von Threat Intelligence als schädlich identifiziert.
Der Angreifer hat die Kontrolle über das Container-Image-Repository oder die Erstellungspipeline, in die die schädliche Binärdatei in das Container-Image eingeschleust wird. Gehen Sie so vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie ein
Execution: Built in Malicious Binary Executed
-Ergebnis wie in Ergebnisse prüfen. Der Detailbereich für die wird der Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Programmbinärdatei: der absolute Pfad der integrierten Binärdatei.
- Argumente: die Argumente, die beim Aufrufen der integrierten Binärdatei angegeben werden.
- Containers: der Name des betroffenen Containers.
- Container-URI: Der Name des Container-Images, das bereitgestellt wird.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Name der Ressource: der vollständige Ressourcenname des Clusters, einschließlich Projektnummer, Standort und Clustername.
- Weitere Informationen, insbesondere die folgenden Felder:
- VirusTotal-Indikator: Link zur VirusTotal-Analyseseite.
- Erkannte Daten, insbesondere die folgenden Felder:
Klicken Sie auf JSON und notieren Sie sich die folgenden Felder:
sourceProperties
:VM_Instance_Name
: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.
Schritt 2: Cluster und Knoten prüfen
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie den Cluster aus, der in der Zeile Vollständiger Name der Ressource auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.
Klicken Sie auf den Tab Knoten. Wählen Sie den in
VM_Instance_Name
aufgeführten Knoten aus.Klicken Sie auf den Tab Details und notieren Sie sich die Annotation
container.googleapis.com/instance_id
.
Schritt 3: Pod überprüfen
Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Filtern Sie nach dem Cluster, der in der Zeile Vollständiger Name der Ressource im Tab Zusammenfassung der Ergebnisdetails und des Pod-Namespace die in
Pod_Namespace
aufgeführt sind.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
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.
Gehen Sie auf der Seite, die geladen wird, so vor:
- 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"
- 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
- Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Suchen Sie mit dem folgenden Filter Pod-Logs für
Schritt 5: Laufenden Container prüfen
Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.
Öffnen Sie die Google Cloud Console.
Wählen Sie in der Symbolleiste der Google Cloud Console das Projekt aus, das in
resource.project_display_name
, falls erforderlich.Klicken Sie auf Cloud Shell aktivieren .
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 inresource.labels.cluster_name
aufgeführte Clusterlocation
: der inresource.labels.location
aufgeführte Standortproject_name
: der inresource.project_display_name
aufgeführte Projektname
Rufen Sie die integrierte schädliche Binärdatei ab:
kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name local_file
Ersetzen Sie
local_file
durch einen lokalen Pfad zum Speichern der erstellten schädlichen Binärdatei.Stellen Sie eine Verbindung zur Containerumgebung her:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Bei diesem Befehl muss für den Container eine Shell unter
/bin/sh
installiert sein.
Schritt 6: Forschungsangriffs- und Reaktionsmethoden
- Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Ingress-Tool-Übertragung, Native API.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
- Überprüfen Sie den SHA-256-Hashwert für das Binärprogramm, das in VirusTotal von indem Sie auf den Link in der VirusTotal-Anzeige klicken. VirusTotal, ein Alphabet-eigener Dienst, der Kontext zu potenziell schädlichen Dateien, URLs, Domains und IP-Adressen bereitstellt.
Schritt 7: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet, kann sich aber 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.
Execution: Malicious Python executed
Ein ML-Modell (maschinelles Lernen) hat ausgeführten Python-Code als schädlich identifiziert. Angreifer können Python verwenden, um ohne Binärprogramme Tools zu übertragen und Befehle auszuführen. Es ist eine wichtige Best Practice, dafür zu sorgen, dass Ihre Container unveränderlich sind. Die Verwendung von Scripts zum Übertragen von Tools kann die Angriffstechnik des Übertragungstools nachahmen und zu unerwünschten Erkennungen führen.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie ein
Execution: Malicious Python executed
-Ergebnis wie in Ergebnisse prüfen. Der Detailbereich für die wird der Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- Programmbinärdatei: Details zum aufgerufenen Interpreter des Skripts.
- Skript: absoluter Pfad des Skriptnamens auf dem Laufwerk dies
wird nur für Skripts angezeigt, die auf das Laufwerk geschrieben wurden, nicht für Literal-
Skriptausführung, z. B.
python3 -c
. - Argumente: die Argumente, die beim Aufrufen des Skripts angegeben werden.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Ressourcenname: der vollständige Ressourcenname des Clusters, einschließlich Projektnummer, Standort und Clustername
- Was erkannt wurde, insbesondere die folgenden Felder:
Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON.
Notieren Sie sich die folgenden Felder in der JSON-Datei.
finding
:processes
:script
:contents
: Inhalt des ausgeführten Skripts, der möglicherweise für Leistungsgründe, kann Ihnen dies bei der Untersuchungsha256
: SHA-256-Hash vonscript.contents
resource
:project_display_name
: der Name des Projekts, das das Asset enthält.
sourceProperties
:Pod_Namespace
: der Name des Kubernetes-Namespace des Pods.Pod_Name
: der Name des GKE-Pods.Container_Name
: der Name des betroffenen Containers.Container_Image_Uri
: der Name des ausgeführten Container-Images.VM_Instance_Name
: der Name des GKE-Knotens, in dem der Pod ausgeführt.
Ermitteln Sie andere Ergebnisse, die zu einem ähnlichen Zeitpunkt für diesen Container aufgetreten sind. Wenn das Script beispielsweise ein Binärprogramm ablegt, suchen Sie nach Ergebnissen im Zusammenhang mit dem Binärprogramm.
Schritt 2: Cluster und Knoten prüfen
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Wählen Sie in der Symbolleiste der Google Cloud Console das Projekt aus, das in
resource.project_display_name
, falls erforderlich.Wählen Sie den Cluster aus, der in der Zeile Vollständiger Name der Ressource im Tab Zusammenfassung der Ergebnisdetails. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.
Klicken Sie auf den Tab Knoten. Wählen Sie den in
VM_Instance_Name
aufgeführten Knoten aus.Klicken Sie auf den Tab Details und notieren Sie sich die Annotation
container.googleapis.com/instance_id
.
Schritt 3: Pod überprüfen
Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Filtern Sie bei Bedarf nach dem in
resource.name
aufgeführten Cluster und dem inPod_Namespace
aufgeführten Pod-Namespace.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
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.
Gehen Sie auf der Seite, die geladen wird, so vor:
- 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"
- 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
- Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Suchen Sie mit dem folgenden Filter Pod-Logs für
Schritt 5: Laufenden Container prüfen
Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Klicken Sie auf den Namen des Clusters in
resource.labels.cluster_name
.Klicken Sie auf der Seite Cluster auf Verbinden und dann auf In Cloud Shell ausführen.
Cloud Shell startet Befehle für den Cluster im Terminal und fügt sie hinzu.
Drücken Sie die Eingabetaste. Wenn das Dialogfeld Cloud Shell autorisieren angezeigt wird, klicken Sie auf Autorisieren.
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
- Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Befehls- und Skriptinterpreter, Ingress-Tool Transfer.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
Schritt 7: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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 Python beabsichtigte Änderungen am Container vornimmt, erstellen Sie das Container-Image neu, damit keine Änderungen erforderlich sind. 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.
Execution: Modified Malicious Binary Executed
Eine Binärdatei, die ausgeführt wurde, mit den folgenden Informationen:
- Im ursprünglichen Container-Image enthalten.
- Sie wurden während der Containerlaufzeit geändert.
- Auf Grundlage von Bedrohungsdaten als schädlich eingestuft.
Angreifer installieren häufig Ausbeutungstools und Malware nach dem anfänglichen Manipulationsprozess. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie ein
Execution: Modified Malicious Binary Executed
-Ergebnis wie in Ergebnisse prüfen. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Programm-Binärdatei: Der absolute Pfad der geänderten Binärdatei.
- Argumente: die Argumente, die beim Aufrufen der geänderten Binärdatei angegeben werden.
- Container: Der Name des betroffenen Containers.
- Container-URI: Der Name des Container-Images, das bereitgestellt wird.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger 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.
- Erkannte Daten, insbesondere die folgenden Felder:
Klicken Sie auf JSON und notieren Sie sich die folgenden Felder:
sourceProperties
:VM_Instance_Name
: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.
Schritt 2: Cluster und Knoten prüfen
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Wählen Sie in der Symbolleiste der Google Cloud Console das Projekt aus, das in
resource.project_display_name
, falls erforderlich.Wählen Sie den Cluster aus, der in der Zeile Vollständiger Name der Ressource auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.
Klicken Sie auf den Tab Knoten. Wählen Sie den in
VM_Instance_Name
aufgeführten Knoten aus.Klicken Sie auf den Tab Details und notieren Sie sich die Annotation
container.googleapis.com/instance_id
.
Schritt 3: Pod überprüfen
Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Filtern Sie nach dem Cluster, der in der Zeile Vollständiger Name der Ressource im Tab Zusammenfassung der Ergebnisdetails und des Pod-Namespace die in
Pod_Namespace
aufgeführt sind.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
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.
Gehen Sie auf der Seite, die geladen wird, so vor:
- 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"
- 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
- Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Suchen Sie mit dem folgenden Filter Pod-Logs für
Schritt 5: Laufenden Container prüfen
Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.
Öffnen Sie die Google Cloud Console.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Klicken Sie auf Cloud Shell aktivieren .
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 inresource.labels.cluster_name
aufgeführte Clusterlocation
: der inresource.labels.location
aufgeführte Standortproject_name
: der inresource.project_display_name
aufgeführte Projektname
Rufen Sie die geänderte schädliche Binärdatei ab:
kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name local_file
Ersetzen Sie
local_file
durch einen lokalen Pfad, um die geänderte schädliche Binärdatei zu speichern.Stellen Sie eine Verbindung zur Containerumgebung her:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Bei diesem Befehl muss für den Container eine Shell unter
/bin/sh
installiert sein.
Schritt 6: Forschungsangriffs- und Reaktionsmethoden
- Sehen Sie sich die Einträge im MITRE ATT&CK-Framework für diesen Ergebnistyp an: Übertragung von Ingress-Tools Native API.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
- Prüfen Sie den SHA-256-Hashwert für das Binärprogramm, das auf VirusTotal als schädlich gekennzeichnet wurde, 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.
Schritt 7: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet, kann sich aber 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.
Execution: Modified Malicious Library Loaded
Eine mit der Bibliothek geladene Bibliothek:
- Im ursprünglichen Container-Image enthalten.
- Sie wurden während der Containerlaufzeit geändert.
- Auf Grundlage von Bedrohungsdaten als schädlich eingestuft.
Angreifer könnten schädliche Bibliotheken in vorhandene Programme laden, um den Schutz vor Codeausführungen zu umgehen und schädlichen Code zu verbergen. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie ein
Execution: Modified Malicious Library Loaded
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Binärprogramm des Programms: der vollständige Pfad der Prozessbinärdatei, die die Bibliothek geladen hat.
- Libraries: Details zur geänderten Bibliothek.
- Argumente: die Argumente, die beim Aufrufen des Prozesses angegeben werden binär.
- Container: Der Name des betroffenen Containers.
- Container-URI: Der Name des Container-Images, das bereitgestellt wird.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Name der Ressource: der vollständige Ressourcenname des Clusters.
- Weitere Informationen, insbesondere die folgenden Felder:
- VirusTotal-Indikator: Link zur VirusTotal-Analyseseite.
- Erkannte Daten, insbesondere die folgenden Felder:
Klicken Sie auf den Tab JSON und sehen Sie sich die folgenden Felder an:
sourceProperties
:VM_Instance_Name
: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.
Schritt 2: Cluster und Knoten prüfen
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie den in
resource.name
aufgeführten Cluster aus. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.Klicken Sie auf den Tab Knoten. Wählen Sie den in
VM_Instance_Name
aufgeführten Knoten aus.Klicken Sie auf den Tab Details und notieren Sie sich die Annotation
container.googleapis.com/instance_id
.
Schritt 3: Pod überprüfen
Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Filtern Sie nach dem Cluster, der in der Zeile Vollständiger Name der Ressource im Tab Zusammenfassung der Ergebnisdetails und des Pod-Namespace die in
Pod_Namespace
aufgeführt sind.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
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.
Gehen Sie auf der Seite, die geladen wird, so vor:
- 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"
- 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
- Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Suchen Sie mit dem folgenden Filter Pod-Logs für
Schritt 5: Laufenden Container prüfen
Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.
Öffnen Sie die Google Cloud Console.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Klicken Sie auf Cloud Shell aktivieren .
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
Rufen Sie die geänderte schädliche Bibliothek ab:
kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name local_file
Ersetzen Sie local_file durch einen lokalen Pfad zum Speichern der geänderten schädlichen Bibliothek.
Stellen Sie eine Verbindung zur Containerumgebung her:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Bei diesem Befehl muss für den Container eine Shell unter
/bin/sh
installiert sein.
Schritt 6: Forschungsangriffs- und Reaktionsmethoden
- Sehen Sie sich die Einträge im MITRE ATT&CK-Framework für diesen Ergebnistyp an: Übertragung von Ingress-Tools Freigegebene Module.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
- Prüfen Sie den SHA-256-Hashwert der Bibliothek, die auf VirusTotal als schädlich gekennzeichnet wurde, 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.
Schritt 7: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet, kann sich aber 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.
Malicious Script Executed
Ein Modell für maschinelles Lernen hat ausgeführten Bash-Code als schädlich erkannt. Angreifer können Bash verwenden, um Tools zu übertragen und Befehle ohne Binärdateien auszuführen. Eine wichtige Best Practice besteht darin, dafür zu sorgen, dass Ihre Container unveränderlich sind. Die Verwendung von Scripts zum Übertragen von Tools kann die Angriffstechnik des Übertragungstools nachahmen und zu unerwünschten Erkennungen führen.
Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie das Ergebnis
Malicious Script Executed
, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für die wird der Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- Binärprogramm des Programms: Details zum Interpreter, der das Script aufgerufen hat.
- Script: absoluter Pfad des Namens des Skripts auf dem Laufwerk; dieses Attribut erscheint nur bei Skripten, die auf das Laufwerk geschrieben werden, nicht bei der literalen Skriptausführung, z. B.
bash -c
. - Argumente: die Argumente, die beim Aufrufen des Skripts angegeben werden.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Ressourcenname: der vollständige Ressourcenname des Clusters, einschließlich Projektnummer, Standort und Clustername
- Was erkannt wurde, insbesondere die folgenden Felder:
Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON.
Notieren Sie sich die folgenden Felder in der JSON-Datei.
finding
:processes
:script
:contents
: Inhalt des ausgeführten Skripts, der möglicherweise für Leistungsgründe, kann Ihnen dies bei der Untersuchungsha256
: SHA-256-Hash vonscript.contents
resource
:project_display_name
: der Name des Projekts, das das Asset enthält.
sourceProperties
:Pod_Namespace
: der Name des Kubernetes-Namespace des Pods.Pod_Name
: der Name des GKE-Pods.Container_Name
: der Name des betroffenen Containers.Container_Image_Uri
: der Name des ausgeführten Container-Images.VM_Instance_Name
: der Name des GKE-Knotens, in dem der Pod ausgeführt.
Ermitteln Sie andere Ergebnisse, die zu einem ähnlichen Zeitpunkt für diesen Container aufgetreten sind. Wenn das Script beispielsweise ein Binärprogramm ablegt, suchen Sie nach Ergebnissen im Zusammenhang mit dem Binärprogramm.
Schritt 2: Cluster und Knoten prüfen
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Wählen Sie in der Symbolleiste der Google Cloud Console das Projekt aus, das in
resource.project_display_name
, falls erforderlich.Wählen Sie den Cluster aus, der in der Zeile Vollständiger Name der Ressource im Tab Zusammenfassung der Ergebnisdetails. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.
Klicken Sie auf den Tab Knoten. Wählen Sie den in
VM_Instance_Name
aufgeführten Knoten aus.Klicken Sie auf den Tab Details und notieren Sie sich die Annotation
container.googleapis.com/instance_id
.
Schritt 3: Pod überprüfen
Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.
Wählen Sie in der Symbolleiste der Google Cloud Console das Projekt aus, das in
resource.project_display_name
, falls erforderlich.Filtern Sie bei Bedarf nach dem in
resource.name
aufgeführten Cluster und dem inPod_Namespace
aufgeführten Pod-Namespace.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
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.
Gehen Sie auf der Seite, die geladen wird, so vor:
- 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"
- 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
- Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Suchen Sie mit dem folgenden Filter Pod-Logs für
Schritt 5: Laufenden Container prüfen
Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Klicken Sie auf den Namen des Clusters in
resource.labels.cluster_name
.Klicken Sie auf der Seite Cluster auf Verbinden und dann auf In Cloud Shell ausführen.
Cloud Shell startet Befehle für den Cluster im Terminal und fügt sie hinzu.
Drücken Sie die Eingabetaste. Wenn das Dialogfeld Cloud Shell autorisieren angezeigt wird, klicken Sie auf Autorisieren.
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
- Sehen Sie sich die Einträge im MITRE ATT&CK-Framework für diesen Ergebnistyp an: Befehls- und Skriptinterpreter Übertragung von Ingress-Tools.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
Schritt 7: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet, kann sich aber 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 das Skript beabsichtigte Änderungen am Container vorgenommen hat, erstellen Sie das Container-Image so neu, dass keine Änderungen erforderlich sind. 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.
Malicious URL Observed
Container Threat Detection hat eine schädliche URL in der Argumentliste eines ausgeführt werden kann. Angreifer können Malware oder schädliche Bibliotheken über schädliche URLs laden.
Führen Sie die folgenden Schritte aus, um auf dieses Ergebnis zu reagieren.
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie das Ergebnis
Malicious URL Observed
, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für die wird der Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- URI: Der schädliche URI, der erkannt wurde.
- Hinzugefügte Binärdatei: der vollständige Pfad der Prozessbinärdatei, die die Argumente mit der schädlichen URL empfangen hat.
- Arguments (Argumente): Die Argumente, die beim Aufrufen der Prozessbinärdatei angegeben werden.
- Umgebungsvariablen: die Umgebungsvariablen, die in wenn die Prozessbinärdatei aufgerufen wurde.
- Containers: Der Name des Containers.
- Kubernetes-Pods: Pod-Name und Namespace.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Anzeigename der Ressource: der Name der betroffenen Ressource.
- Vollständiger Name der Ressource: der vollständige Ressourcenname
des Clusters. Der vollständige Ressourcenname enthält die folgenden Informationen:
- Das Projekt, das den Cluster enthält:
projects/PROJECT_ID
- Der Standort, an dem sich der Cluster befindet:
zone/ZONE
oderlocations/LOCATION
- Der Name des Clusters:
projects/CLUSTER_NAME
- Das Projekt, das den Cluster enthält:
- Was erkannt wurde, insbesondere die folgenden Felder:
Notieren Sie sich auf dem Tab JSON im Attribut
sourceProperties
den Wert der PropertyVM_Instance_Name
.
Schritt 2: Cluster und Knoten prüfen
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Wählen Sie in der Symbolleiste der Google Cloud Console das Projekt aus, das in Vollständiger Name der Ressource (
resource.name
), falls erforderlich. Der Projektname wird im vollständigen Ressourcennamen nach/projects/
angezeigt.Klicken Sie auf den Clusternamen, den Sie unter Anzeigename der Ressource notiert haben. (
resource.display_name
) der Ergebniszusammenfassung. Die Seite Cluster wird geöffnet.Notieren Sie sich auf der Seite mit den Clusterdetails im Abschnitt Metadaten alle benutzerdefinierten Informationen, die bei der Behebung der Bedrohung hilfreich sein könnten, z. B. Informationen zur Identifizierung des Clusterinhabers.
Klicken Sie auf den Tab „Knoten“.
Wählen Sie aus den aufgeführten Knoten den Knoten aus, der entspricht dem Wert von
VM_Instance_Name
, den Sie im Ergebnis notiert haben JSON.Auf dem Tab Details der Seite Knotendetails im Annotations den Wert des Attributs
container.googleapis.com/instance_id
-Anmerkung.
Schritt 3: Pod überprüfen
Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das Projekt aus, das Sie im vollständigen Namen der Ressource (
resource.name
) des Clusters in der Zusammenfassung der Ergebnisse notiert haben.Klicken Sie auf Systemarbeitslasten anzeigen.
Filtern Sie die Liste der Arbeitslasten nach dem Clusternamen, den Sie in Vollständiger Name der Ressource (
resource.name
) der Ergebniszusammenfassung und, falls den Sie notierten Namespace (kubernetes.pods.ns
) des Pods.Klicken Sie auf den Namen der Arbeitslast, der dem Wert von
VM_Instance_Name
entspricht. die Sie zuvor in der JSON-Ergebnisdatei notiert haben. Die Seite Pod-Details wird geöffnet.Notieren Sie sich auf der Seite Pod-Details alle Informationen zum Pod, die Ihnen bei der Behebung der Bedrohung helfen könnten.
Schritt 4: Protokolle prüfen
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das Projekt aus, das unter Vollständiger Name der Ressource (
resource.name
) angezeigt wird.Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.
Gehen Sie auf der Seite, die geladen wird, so vor:
- Suchen Sie mit dem folgenden Filter Pod-Logs für Ihren Pod (
kubernetes.pods.name
):resource.type="k8s_container"
resource.labels.project_id="PROJECT_ID"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.namespace_name="NAMESPACE_NAME"
resource.labels.pod_name="POD_NAME"
- Suchen Sie mit dem folgenden Filter Cluster-Audit-Logs:
logName="projects/PROJECT_NAME/logs/cloudaudit.googleapis.com%2Factivity"
resource.type="k8s_cluster"
resource.labels.project_id="PROJECT_ID"
resource.labels.location="LOCATION_OR_ZONE"
resource.labels.cluster_name="CLUSTER_NAME/var>"
POD_NAME
- Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
resource.type="gce_instance"
resource.labels.instance_id="INSTANCE_ID"
- Suchen Sie mit dem folgenden Filter Pod-Logs für Ihren Pod (
Schritt 5: Ausgeführten Container prüfen
Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Klicken Sie auf den Namen des Clusters in
resource.labels.cluster_name
.Klicken Sie auf der Seite Cluster auf Verbinden und dann auf In Cloud Shell ausführen.
Cloud Shell startet Befehle für den Cluster im Terminal und fügt sie hinzu.
Drücken Sie die Eingabetaste. Wenn das Dialogfeld Cloud Shell autorisieren angezeigt wird, klicken Sie auf Autorisieren.
Stellen Sie eine Verbindung zur Containerumgebung her, indem Sie den folgenden Befehl ausführen:
kubectl exec --namespace=POD_NAMESPACE -ti POD_NAME -c CONTAINER_NAME -- /bin/sh
Ersetzen Sie
CONTAINER_NAME
durch den Namen des Containers. die Sie in der Zusammenfassung der Ergebnisse notiert haben.Bei diesem Befehl muss für den Container eine Shell unter
/bin/sh
installiert sein.
Schritt 6: Forschungsangriffs- und Reaktionsmethoden
- Prüfen Sie den Status der Safe Browsing-Website. um Details dazu zu erhalten, warum die URL als schädlich eingestuft ist.
- Sehen Sie sich die Einträge im MITRE ATT&CK-Framework für diesen Ergebnistyp an: Übertragung von Ingress-Tools.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
Schritt 7: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet, kann sich aber 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.
Reverse Shell
Ein Prozess, bei dem die Stream-Weiterleitung an einen Remote-Socket gestartet wurde. Das Erstellen einer mit dem Netzwerk verbundenen Shell kann es einem Angreifer ermöglichen, nach einem begrenzten anfänglichen Kompromiss beliebige Aktionen auszuführen. Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie ein
Reverse Shell
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für die wird der Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Was erkannt wurde, insbesondere die folgenden Felder:
- Programmbinärdatei: der absolute Pfad des mit dem Prozess gestarteten Prozesses. an einen Remote-Socket weitergeleitet werden.
- Arguments (Argumente): Die Argumente, die beim Aufrufen der Prozessbinärdatei angegeben werden.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Name der Ressource: Der vollständige Ressourcenname des Clusters.
- Vollständiger Projektname:
- Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON.
- Notieren Sie sich in der JSON-Datei die folgenden Felder.
resource
:project_display_name
: der Name des Projekts, das das Asset enthält.
sourceProperties
:Pod_Namespace
: der Name des Kubernetes-Namespace des Pods.Pod_Name
: der Name des GKE-Pods.Container_Name
: der Name des betroffenen Containers.VM_Instance_Name
: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.Reverse_Shell_Stdin_Redirection_Dst_Ip
: die Remote-IP-Adresse der VerbindungReverse_Shell_Stdin_Redirection_Dst_Port
: der Remote-PortReverse_Shell_Stdin_Redirection_Src_Ip
: die lokale IP-Adresse der VerbindungReverse_Shell_Stdin_Redirection_Src_Port
: der lokale PortContainer_Image_Uri
ist der Name des ausgeführten Container-Images.
- Was erkannt wurde, insbesondere die folgenden Felder:
Schritt 2: Cluster und Knoten prüfen
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie den in
resource.name
aufgeführten Cluster aus. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.Klicken Sie auf den Tab Knoten. Wählen Sie den in
VM_Instance_Name
aufgeführten Knoten aus.Klicken Sie auf den Tab Details und notieren Sie sich die Annotation
container.googleapis.com/instance_id
.
Schritt 3: Pod überprüfen
Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Filtern Sie bei Bedarf nach dem in
resource.name
aufgeführten Cluster und dem inPod_Namespace
aufgeführten Pod-Namespace.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
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.
Gehen Sie auf der Seite, die geladen wird, so vor:
- 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"
- 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
- Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Suchen Sie mit dem folgenden Filter Pod-Logs für
Schritt 5: Laufenden Container prüfen
Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.
Öffnen Sie die Google Cloud Console.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Klicken Sie auf Cloud Shell aktivieren .
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
Starten Sie eine Shell in der Containerumgebung, indem Sie Folgendes ausführen:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Bei diesem Befehl muss für den Container eine Shell unter
/bin/sh
installiert sein.Führen Sie den folgenden Befehl in der Container-Shell aus, um alle im Container ausgeführten Prozesse aufzurufen:
ps axjf
Bei diesem Befehl muss für den Container
/bin/ps
installiert sein.
Schritt 6: Forschungsangriffs- und Reaktionsmethoden
- Sehen Sie sich die Einträge im MITRE ATT&CK-Framework für diesen Ergebnistyp an: Befehls- und Skriptinterpreter Übertragung von Ingress-Tools.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
Schritt 7: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet, kann sich aber 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.
Unexpected Child Shell
Container Threat Detection hat einen Prozess erkannt, der unerwartet einen untergeordneten Shell-Prozess hervorgerufen hat. Dieses Ereignis kann darauf hindeuten, dass ein Angreifer versucht, Shell-Befehle und -Scripts zu missbrauchen.
Führen Sie die folgenden Schritte aus, um auf dieses Ergebnis zu reagieren.
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie ein
Unexpected Child Shell
-Ergebnis wie in Ergebnisse prüfen. Der Detailbereich für das Ergebnis wird mit dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- Übergeordneter Prozess: Prozess, der unerwartet den untergeordneten Shell-Prozess erstellt hat.
- Untergeordneter Prozess: Der untergeordnete Shell-Prozess.
- Argumente: Argumente, die der Binärdatei des untergeordneten Shell-Prozesses übergeben werden.
- Umgebungsvariablen: die Umgebungsvariablen des Binärprogramms des untergeordneten Shell-Prozesses.
- Container: Der Name des Containers.
- Containers URI: der Image-URI des Containers.
- Kubernetes-Pods: der Pod-Name und der Namespace.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Anzeigename der Ressource: der Name der betroffenen Ressource.
- Vollständiger Name der Ressource: der vollständige Ressourcenname
des Clusters. Der vollständige Ressourcenname enthält Folgendes:
Informationen:
- Das Projekt, das den Cluster enthält:
projects/PROJECT_ID
- Der Standort, an dem sich der Cluster befindet:
zone/ZONE
oderlocations/LOCATION
- Der Name des Clusters:
projects/CLUSTER_NAME
- Das Projekt, das den Cluster enthält:
- Erkannte Daten, insbesondere die folgenden Felder:
Klicken Sie auf den Tab JSON und notieren Sie sich die folgenden Felder:
+processes
: ein Array mit allen Prozessen, die sich auf die Abweichung beziehen. Dieses Array enthält den untergeordneten Shell-Prozess und den übergeordneten Prozess.
+resource
:
+project_display_name
: Der Name des Projekts, das die Assets enthält.
+sourceProperties
:
+VM_Instance_Name
: der Name des GKE-Knotens, an dem der
Pod ausgeführt.
Schritt 2: Cluster und Knoten prüfen
Rufen Sie in der Google Cloud Console die Seite mit den Kubernetes-Clustern auf.
Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in
resource.project_display_name
aufgeführte Projekt aus.Wählen Sie den in
resource.name
aufgeführten Cluster aus. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.Klicken Sie auf den Tab Knoten. Wählen Sie den in
VM_Instance_Name
aufgeführten Knoten aus.Klicken Sie auf den Tab Details und notieren Sie sich die Annotation
container.googleapis.com/instance_id
.
Schritt 3: Pod überprüfen
Öffnen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten.
Wählen Sie in der Symbolleiste der Google Cloud Console das Projekt aus, das Sie sich notiert haben. im Vollständiger Name der Ressource (
resource.name
) des Clusters in der Zusammenfassung der Ergebnisse.Klicken Sie auf Systemarbeitslasten anzeigen.
Filtern Sie die Liste der Arbeitslasten nach dem Clusternamen, den Sie unter Vollständiger Name der Ressource (
resource.name
) in der Zusammenfassung der Ergebnisse notiert haben, und bei Bedarf nach dem von Ihnen notierten Pod-Namespace (kubernetes.pods.ns
).Klicken Sie auf den Arbeitslastnamen, der dem Wert von
VM_Instance_Name
entspricht. die Sie zuvor in der JSON-Ergebnisdatei notiert haben. Die Pod-Details wird geöffnet.Notieren Sie sich auf der Seite Pod-Details alle Informationen zum Pod, die Ihnen bei der Behebung der Bedrohung helfen könnten.
Schritt 4: Protokolle prüfen
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Google Cloud Console das Projekt aus, das in
resource.project_display_name
Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.
Gehen Sie auf der Seite, die geladen wird, so vor:
- 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"
- 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
- Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Suchen Sie mit dem folgenden Filter Pod-Logs für
Schritt 5: Ausgeführten Container prüfen
Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.
Öffnen Sie die Google Cloud Console.
Wählen Sie in der Symbolleiste der Google Cloud Console das Projekt aus, das in
resource.project_display_name
Klicken Sie auf Cloud Shell aktivieren .
Rufen Sie die GKE-Anmeldedaten für Ihren Cluster ab, indem Sie die folgenden Befehle ausführen.
Führen Sie für zonale Cluster den folgenden Befehl aus:
gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
Führen Sie für regionale Cluster den folgenden Befehl aus:
gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
Führen Sie folgenden Befehl aus, um eine Shell in der Containerumgebung zu starten:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Bei diesem Befehl muss für den Container eine Shell unter
/bin/sh
installiert sein.Führen Sie den folgenden Befehl in der Container-Shell aus, um alle im Container ausgeführten Prozesse aufzurufen:
ps axjf
Bei diesem Befehl muss für den Container
/bin/ps
installiert sein.
Schritt 6: Forschungsangriffs- und Reaktionsmethoden
- Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Befehls- und Skriptinterpreter: Unix-Shell.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
Schritt 7: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für diese Feststellung geeignet, kann sich aber 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.
VM Threat Detection-Antwort
Weitere Informationen zu VM Threat Detection finden Sie unter Übersicht: VM Threat Detection.
Execution: Cryptocurrency Mining Hash Match
Die VM Threat Detection hat das Mining von Kryptowährungen erkannt. Dazu wurden Speicher-Hashes laufender Programme mit Speicher-Hashes von bekannter Kryptowährung-Mining-Software abgeglichen.
So reagieren Sie auf diese Ergebnisse:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie ein
Execution: Cryptocurrency Mining Hash Match
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich des Ergebnisses wird auf dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
Erkannte Daten, insbesondere die folgenden Felder:
- Binärfamilie: die erkannte Kryptowährungs-Anwendung.
- Programm-Binärdatei: der absolute Pfad des Prozesses.
- Argumente: die Argumente, die beim Aufrufen der Prozessbinärdatei angegeben werden.
- Prozessnamen: der Name des Prozesses, der in der VM-Instanz ausgeführt wird, der mit den erkannten Signaturübereinstimmungen verknüpft ist.
VM Threat Detection kann Kernel-Builds aus wichtigen Linux-Distributionen erkennen. Wenn der Kernel-Build der betroffenen VM erkannt wird, lassen sich die Prozessdetails der Anwendung identifizieren und das Feld
processes
des Ergebnisses ausfüllen. Wenn VM Threat Detection den Kernel nicht neu erkennen kann, z. B. weil der Kernel benutzerdefiniert erstellt wurde, ist das Feldprocesses
des Ergebnisses nicht ausgefüllt.Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Ressourcenname: Der vollständige Ressourcenname der betroffenen VM-Instanz, einschließlich der ID des Projekts, das sie enthält.
Wenn Sie die vollständige JSON-Datei für dieses Ergebnis aufrufen möchten, klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON.
indicator
signatures
:memory_hash_signature
: eine Signatur, die den Hashes der Speicherseiten entspricht.detections
binary
: der Name der Binärdatei der Kryptowährung-Anwendung, z. B.linux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0
.percent_pages_matched
: der Prozentsatz an Seiten im Speicher, die mit Seiten in bekannten Kryptowährungsanwendungen in der Seiten-Hash-Datenbank übereinstimmen.
Schritt 2: Protokolle prüfen
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Google Cloud Console das Projekt aus, das die Die VM-Instanz, wie in der Zeile Vollständiger Name der Ressource angegeben in auf dem Tab Zusammenfassung der Ergebnisdetails.
Prüfen Sie, ob in den Logs Zeichen für Angriffe auf die betroffene VM-Instanz enthalten sind. Beispielsweise können Sie nach verdächtigen oder unbekannten Aktivitäten und Zeichen von kompromittierten Anmeldedaten suchen.
Schritt 3: Berechtigungen und Einstellungen prüfen
Öffnen Sie in der Google Cloud Console die Seite Dashboard.
Wählen Sie in den Ergebnisdetails auf dem Tab Zusammenfassung in der Zeile Vollständiger Name der Ressource das Projekt aus.
Rufen Sie die Karte Ressourcen auf und klicken Sie auf Compute Engine.
Klicken Sie auf die VM-Instanz, die mit dem Projekt übereinstimmt, das im vollständigen Namen der Ressource angegeben ist. Prüfen Sie die Instanzdetails einschließlich der Netzwerk- und Zugriffseinstellungen.
Schritt 4: Angriffs- und Reaktionsmethoden untersuchen
- Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für Ausführung.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
Schritt 5: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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.
Verwenden Sie eine Lösung zur Endpunkterkennung und -antwort, um Unterstützung bei der Erkennung und Entfernung zu erhalten.
- Wenden Sie sich an den Inhaber der VM.
Prüfen Sie, ob die Anwendung eine Mining-Anwendung ist:
Wenn der Prozessname und der binäre Pfad der erkannten Anwendung verfügbar sind, berücksichtigen Sie die Werte in den Zeilen Programm-Binärdatei, Argumente und Prozessnamen auf dem Tab Zusammenfassung der Details zur Feststellung in Ihrer Untersuchung.
Wenn die Prozessdetails nicht verfügbar sind, prüfen Sie, ob der Binärname aus der Speicher-Hash-Signatur Hinweise enthalten kann. Betrachten Sie eine Binärdatei mit dem Namen
linux-x86-64_xmrig_2.14.1
. Mit dem Befehlgrep
können Sie nach wichtigen Dateien im Speicher suchen. Verwenden Sie einen aussagekräftigen Teil des Binärnamens in Ihrem Suchmuster, in diesem Fallxmrig
. Sehen Sie sich die Suchergebnisse an.Untersuchen Sie die laufenden Prozesse, insbesondere die Prozesse mit hoher CPU-Auslastung, um festzustellen, ob es Prozesse gibt, die Sie nicht erkennen. Bestimmen Sie, ob die zugehörigen Anwendungen Mining-Anwendungen sind.
Suchen Sie im Speicher nach gängigen Strings, die von Mining-Anwendungen verwendet werden, z. B.
btc.com
,ethminer
,xmrig
,cpuminer
undrandomx
. Weitere Beispiele für Strings, nach denen Sie suchen können, finden Sie unter Softwarenamen und YARA-Regeln und in der zugehörigen Dokumentation für die einzelnen aufgeführten Softwares.
Wenn Sie feststellen, dass es sich bei der Anwendung um eine Mining-Anwendung handelt und ihr Prozess noch ausgeführt wird, beenden Sie den Prozess. Suchen Sie die ausführbare Binärdatei der Anwendung im Speicher der VM und löschen Sie sie.
Beenden Sie bei Bedarf die manipulierte Instanz und ersetzen Sie sie durch eine neue Instanz.
Execution: Cryptocurrency Mining YARA Rule
Die VM Threat Detection hat das Mining von Kryptowährungen erkannt. Dazu wurden Speichermuster wie Proof of Work-Konstanten abgeglichen, die bekanntermaßen von Kryptowährung-Mining-Software verwendet werden.
So reagieren Sie auf diese Ergebnisse:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie wie beschrieben ein
Execution: Cryptocurrency Mining YARA Rule
-Ergebnis. finden Sie unter Ergebnisse überprüfen. Der Detailbereich des Ergebnisses wird auf dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
Was erkannt wurde, insbesondere die folgenden Felder:
- YARA-Regelname: Die Regel, die für YARA-Detektoren ausgelöst wird.
- Programm-Binärdatei: der absolute Pfad des Prozesses.
- Argumente: die Argumente, die beim Aufrufen der Prozessbinärdatei angegeben werden.
- Prozessnamen: die Namen der Prozesse, die in der VM ausgeführt werden -Instanz, die mit den erkannten Signaturübereinstimmungen verknüpft ist.
VM Threat Detection kann Kernel-Builds aus wichtigen Linux-Distributionen erkennen. Wenn der Kernel-Build der betroffenen VM erkannt wird, lassen sich die Prozessdetails der Anwendung identifizieren und das Feld
processes
des Ergebnisses ausfüllen. Wenn VM Threat Detection den Kernel nicht neu erkennen kann, z. B. weil der Kernel benutzerdefiniert erstellt wurde, ist das Feldprocesses
des Ergebnisses nicht ausgefüllt.Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Ressourcenname: Der vollständige Ressourcenname der betroffenen VM-Instanz, einschließlich der ID des Projekts, das sie 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.
- Chronicle: Verknüpfung mit Google SecOps.
Den vollständigen JSON-Code für dieses Ergebnis finden Sie in der Detailansicht von Klicken Sie auf den Tab JSON.
Schritt 2: Protokolle prüfen
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Google Cloud Console das Projekt aus, das die VM-Instanz enthält, wie in der Zeile Vollständiger Name der Ressource auf dem Tab Zusammenfassung der Details zum Ergebnis angegeben.
Prüfen Sie, ob in den Logs Zeichen für Angriffe auf die betroffene VM-Instanz enthalten sind. Beispielsweise können Sie nach verdächtigen oder unbekannten Aktivitäten und Zeichen von kompromittierten Anmeldedaten suchen.
Schritt 3: Berechtigungen und Einstellungen prüfen
Öffnen Sie in der Google Cloud Console die Seite Dashboard.
Wählen Sie das Projekt aus, das in den Ressourcennamen, der auf der In der Zeile Vollständiger Name der Ressource auf dem Tab Zusammenfassung der Ergebnisdetails.
Rufen Sie die Karte Ressourcen auf und klicken Sie auf Compute Engine.
Klicken Sie auf die VM-Instanz, die mit
resourceName
übereinstimmt. Prüfen Sie die Instanzdetails einschließlich der Netzwerk- und Zugriffseinstellungen.
Schritt 4: Angriffs- und Reaktionsmethoden untersuchen
- Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für Ausführung.
- Wenn Sie einen Antwortplan entwickeln möchten, kombinieren Sie Ihre Prüfungsergebnisse mit der MITRE-Forschung.
Schritt 5: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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.
Verwenden Sie eine Lösung zur Endpunkterkennung und -antwort, um Unterstützung bei der Erkennung und Entfernung zu erhalten.
- Wenden Sie sich an den Inhaber der VM.
Prüfen Sie, ob die Anwendung eine Mining-Anwendung ist:
Wenn der Prozessname und der Binärpfad der erkannten Anwendung verfügbar sind, die Werte der Programmbinärdatei, Argumente und Zeilen Prozessnamen auf dem Tab Zusammenfassung der Ergebnisdetails bei Ihrer Untersuchung.
Untersuchen Sie die laufenden Prozesse, insbesondere die Prozesse mit hoher CPU-Auslastung, um festzustellen, ob es Prozesse gibt, die Sie nicht erkennen. Bestimmen Sie, ob die zugehörigen Anwendungen Mining-Anwendungen sind.
Suchen Sie im Speicher nach gängigen Strings, die von Mining-Anwendungen verwendet werden, z. B.
btc.com
,ethminer
,xmrig
,cpuminer
undrandomx
. Weitere Beispiele für Strings, nach denen Sie suchen können, finden Sie unter Softwarenamen und YARA-Regeln und in der zugehörigen Dokumentation für die einzelnen aufgeführten Softwares.
Wenn Sie feststellen, dass es sich bei der Anwendung um eine Mining-Anwendung handelt und ihr Prozess noch ausgeführt wird, beenden Sie den Prozess. Suchen Sie die ausführbare Binärdatei der Anwendung im Speicher der VM und löschen Sie sie.
Beenden Sie bei Bedarf die manipulierte Instanz und ersetzen Sie sie durch eine neue Instanz.
Execution: cryptocurrency mining combined detection
VM Threat Detection hat mehrere Kategorien von Ergebnissen in einem einzigen
aus einer einzigen Quelle abrufen. Eine einzelne Anwendung kann gleichzeitig
Execution: Cryptocurrency Mining YARA Rule
und
Execution: Cryptocurrency Mining Hash Match findings
.
Um auf ein kombiniertes Ergebnis zu reagieren, folgen Sie der Anleitung für beide Antworten
Execution: Cryptocurrency Mining YARA Rule
und
Execution: Cryptocurrency Mining Hash Match findings
Malware: Malicious file on disk (YARA)
VM Threat Detection hat durch das Scannen einer VM eine potenziell schädliche Datei erkannt nichtflüchtige Speicher für bekannte Malware-Signaturen.
So reagieren Sie auf diese Ergebnisse:
Schritt 1: Ergebnisdetails prüfen
Öffnen Sie das
Malware: Malicious file on disk (YARA)
-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich des Ergebnisses wird auf dem Tab Zusammenfassung geöffnet.Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
- Erkannte Daten, insbesondere die folgenden Felder:
- YARA-Regelname: die YARA-Regel, die übereinstimmt hat.
- Files: die Partitions-UUID und der relative Pfad der potenziell die gefundene schädliche Datei ist.
- Betroffene Ressource, insbesondere die folgenden Felder:
- Vollständiger Name der Ressource: der vollständige Ressourcenname der betroffenen VM-Instanz, einschließlich der ID des Projekts, das sie enthält.
- Erkannte Daten, insbesondere die folgenden Felder:
Den vollständigen JSON-Code für dieses Ergebnis finden Sie in der Detailansicht von Klicken Sie auf den Tab JSON.
Achten Sie in der JSON-Datei auf die folgenden Felder:
indicator
signatures
:yaraRuleSignature
: eine Signatur, die der YARA-Regel entspricht, die wurde zugeordnet.
Schritt 2: Protokolle prüfen
Öffnen Sie in der Google Cloud Console den Log-Explorer.
Wählen Sie in der Symbolleiste der Google Cloud Console das Projekt aus, das die Die VM-Instanz, wie in der Zeile Vollständiger Name der Ressource angegeben in auf dem Tab Zusammenfassung der Ergebnisdetails.
Prüfen Sie, ob in den Logs Zeichen für Angriffe auf die betroffene VM-Instanz enthalten sind. Beispielsweise können Sie nach verdächtigen oder unbekannten Aktivitäten und Zeichen von kompromittierten Anmeldedaten suchen.
Schritt 3: Berechtigungen und Einstellungen prüfen
Öffnen Sie in der Google Cloud Console die Seite Dashboard.
Wählen Sie das Projekt aus, das in den Ressourcennamen, der auf der In der Zeile Vollständiger Name der Ressource auf dem Tab Zusammenfassung der Ergebnisdetails.
Rufen Sie die Karte Ressourcen auf und klicken Sie auf Compute Engine.
Klicken Sie auf die VM-Instanz, die mit
resourceName
übereinstimmt. Prüfen Sie die Instanzdetails einschließlich der Netzwerk- und Zugriffseinstellungen.
Schritt 4: Angriffs- und Reaktionsmethoden untersuchen
Prüfen Sie den SHA-256-Hashwert der Datei, die auf VirusTotal als schädlich gekennzeichnet wurde. VirusTotal ist ein Alphabet-eigener Dienst, der Kontext zu potenziell schädlichen Dateien, URLs, Domains und IP-Adressen bereitstellt.
Schritt 5: Antwort implementieren
Der folgende Reaktionsplan könnte für dieses Ergebnis geeignet sein, kann sich aber auch auf den Betrieb 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 VM.
Suchen Sie bei Bedarf die potenziell schädliche Datei und löschen Sie sie. Um die Partitions-UUID und relativer Pfad der Datei finden Sie im Feld Dateien auf auf dem Tab „Zusammenfassung“ der Ergebnisdetails. Um bei der Erkennung und eine Endpunkterkennungs- und Abwehrlösung einsetzen.
Beenden Sie bei Bedarf die manipulierte Instanz und ersetzen Sie sie durch eine neue Instanz.
Erwägen Sie für forensische Analysen, die virtuellen Maschinen zu sichern nichtflüchtige Speicher. Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Datenschutzoptionen.
Zur weiteren Untersuchung können Sie Vorfallreaktionsdienste wie Mandiant:
Sicherheitslücken schließen
Sicherheitslücken prüfen und beheben, um ein erneutes Auftreten von Bedrohungen zu vermeiden sowie die Ergebnisse zu Fehlkonfigurationen.
So finden Sie ähnliche Ergebnisse:
Rufen Sie in der Google Cloud Console die Seite Ergebnisse von Security Command Center auf.
Sehen Sie sich das Bedrohungsergebnis an und kopieren Sie den Wert eines Attributs, das wahrscheinlich in allen zugehörigen Ergebnissen zu Sicherheitslücken oder Fehlkonfigurationen enthalten ist, z. B. die Haupt-E-Mail-Adresse oder der Name der betroffenen Ressource.
Öffnen Sie auf der Seite Ergebnisse den Abfrageeditor, indem Sie auf Abfrage bearbeiten:
Klicken Sie auf Filter hinzufügen. Das Menü Filter auswählen wird geöffnet.
Wählen Sie links im Menü aus der Liste der Filterkategorien die Kategorie mit dem Attribut, das Sie in der Bedrohung notiert haben zu finden.
Wenn Sie sich beispielsweise den vollständigen Namen der betroffenen Ressource notiert haben, wählen Sie Ressource aus. Die Attributtypen der Kategorie Resource sind wird in der Spalte auf der rechten Seite angezeigt, einschließlich des Felds Vollständiger Name .
Wählen Sie aus den angezeigten Attributen den Attributtyp aus, den Sie in der Sicherheitswarnung angegeben haben. Rechts wird ein Suchbereich für Attributwerte geöffnet, in dem alle gefundenen Werte des ausgewählten Attributtyps angezeigt werden.
Fügen Sie in das Feld Filter den Attributwert ein, den Sie aus dem Sicherheitsrisiko kopiert haben. Die angezeigte Werteliste wird aktualisiert und zeigt nur die mit dem eingefügten Wert übereinstimmen.
Wählen Sie in der Liste der angezeigten Werte einen oder mehrere Werte aus und klicken Sie auf Übernehmen. Der Bereich Abfrageergebnisse wird aktualisiert und zeigt jetzt nur noch die übereinstimmende Ergebnisse.
Wenn die Ergebnisse viele Ergebnisse enthalten, filtern Sie die Ergebnisse nach im Bereich Schnellfilter weitere Filter auswählen.
Wenn beispielsweise nur
Vulnerability
undMisconfiguration
angezeigt werden sollen, Klassenergebnisse, die die ausgewählten Attributwerte enthalten, Scrollen Sie in den Schnellfiltern nach unten zum Abschnitt Klasse suchen. und wählen Sie Sicherheitslücken und Fehlkonfiguration aus.
Zusätzlich zu den von Google bereitgestellten Indikatoren für Manipulation können Nutzer, die Kunden von Palo Alto Networks sind, die AutoFocus Threat Intelligence von Palo Alto Networks in die Event Threat Detection integrieren. AutoFocus ist ein Bedrohungserkennungsdienst, der Informationen über Netzwerkbedrohungen bereitstellt. Weitere Informationen finden Sie in der AutoFocus in der Google Cloud Console.
Bedrohungen beheben
Die Behebung von Event Threat Detection- und Container Threat Detection-Ergebnissen ist nicht so einfach wie die Behebung von Fehlkonfigurationen und Sicherheitslücken, Security Command Center.
Konfigurationsfehler und Compliance-Verstöße identifizieren Schwachstellen in Ressourcen, die ausgenutzt werden könnten. Normalerweise haben Fehlkonfigurationen bekannte, einfach zu implementierende Fehlerbehebungen, wie das Aktivieren einer Firewall oder das Rotieren eines Verschlüsselungsschlüssels.
Bedrohungen unterscheiden sich von Sicherheitslücken dadurch, dass sie dynamisch sind und darauf hindeuten, dass eine oder mehrere Ressourcen aktiv genutzt werden können. Eine Korrekturempfehlung ist möglicherweise nicht effektiv beim Sichern Ihrer Ressourcen, da die genauen Methoden, mit denen der Exploit erreicht wurde, möglicherweise nicht bekannt sind.
Beispiel: Ein Added Binary Executed
-Ergebnis gibt an, dass eine nicht autorisierte Binärdatei in einem Container gestartet wurde. Eine grundlegende Korrekturempfehlung bietet möglicherweise an, den Container unter Quarantäne zu stellen und die Binärdatei zu löschen, ohne die zugrunde liegende Ursache zu beheben, die dem Angreifer Zugriff auf die Binärdatei ermöglicht. Sie müssen herausfinden, wie das Container-Image beschädigt wurde, um den Exploit zu beheben. Um festzustellen, ob die Datei über einen falsch konfigurierten Port oder auf andere Weise hinzugefügt wurde, ist eine gründliche Untersuchung erforderlich. Ein Analyst mit entsprechenden Kenntnissen über Ihr System muss Ihr System unter Umständen auf Schwachstellen prüfen.
Böswillige Akteure greifen Ressourcen mithilfe verschiedener Techniken an. Deshalb ist die Anwendung einer Korrektur für einen bestimmten Exploit möglicherweise nicht auf Varianten dieses Angriffs wirksam. Als Reaktion auf ein Brute Force: SSH
-Ergebnis können Sie beispielsweise die Berechtigungsstufen einiger Nutzerkonten verringern, um den Zugriff auf Ressourcen einzuschränken. Schwache Passwörter können jedoch immer noch einen Angriffspfad darstellen.
Die Breite der Angriffsvektoren erschwert die Behebung von Maßnahmen, die in allen Situationen funktionieren. Die Rolle von Security Command Center in Ihrem Cloud-Sicherheitsplan besteht darin, betroffene Ressourcen nahezu in Echtzeit zu identifizieren, Ihnen mitteilen, welche Bedrohungen Sie haben, und Nachweise und Kontext für Ihre Untersuchungen bereitzustellen. Das Sicherheitspersonal muss jedoch die umfassenden Informationen in den Ergebnissen von Security Command Center verwenden, um die besten Möglichkeiten zur Behebung von Problemen und zum Schutz von Ressourcen vor zukünftigen Angriffen zu ermitteln.
Nächste Schritte
In der Event Threat Detection-Übersicht finden Sie weitere Informationen über den Dienst und die erkannten Bedrohungen.
Weitere Informationen finden Sie unter Container Threat Detection – Übersicht um mehr über die Funktionsweise des Dienstes zu erfahren.
Weitere Informationen zum Dienst und zu den erkannten Bedrohungen finden Sie unter VM Threat Detection – Übersicht.