Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
In diesem Dokument wird ein Typ von Bedrohungsergebnissen in Security Command Center beschrieben. Bedrohungsergebnisse werden von Bedrohungsdetektoren generiert, wenn sie eine potenzielle Bedrohung in Ihren Cloud-Ressourcen erkennen. Eine vollständige Liste der verfügbaren Bedrohungsergebnisse finden Sie im Index der Bedrohungsergebnisse.
Übersicht
Eine Binärdatei, die nicht Teil des ursprünglichen Container-Image war, wurde ausgeführt.
Angreifer installieren häufig Ausbeutungstools und Malware nach dem anfänglichen Manipulationsprozess. Es ist wichtig, dass Ihre Container unveränderbar sind. Dies ist ein Ergebnis mit geringer Schwere, da Ihre Organisation diese Best Practice möglicherweise nicht befolgt. Es gibt entsprechende Execution: Added
Malicious Binary Executed-Ergebnisse, wenn der Hash der Binärdatei ein bekannter Kompromittierungsindikator (Indicator of Compromise, IoC) ist.
So reagieren Sie
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 geöffnet und der Tab Zusammenfassung wird angezeigt.
Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:
Was wurde erkannt?, insbesondere die folgenden Felder:
Programmbinärdatei: der absolute Pfad der hinzugefügten Binärdatei.
Argumente: die Argumente, die beim Aufrufen der hinzugefügten Binärdatei angegeben werden.
Betroffene Ressource, insbesondere die folgenden Felder:
Vollständiger Ressourcenname: Der vollständige Ressourcenname des Clusters, einschließlich Projektnummer, Standort und Clustername.
Weitere Informationen, insbesondere die folgenden Felder:
VirusTotal-Indikator: Link zur VirusTotal-Analyseseite.
Klicken Sie auf JSON und notieren Sie sich die folgenden Felder:
resource:
project_display_name: der Name des Projekts, das den Cluster enthält.
sourceProperties:
Pod_Namespace: der Name des Kubernetes-Namespace des Pods.
Pod_Name: der Name des GKE-Pods.
Container_Name: der Name des betroffenen Containers.
Container_Image_Uri: der Name des bereitgestellten Container-Images.
VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.
Suchen Sie nach anderen Ergebnissen, die für diesen Container zu einem ähnlichen Zeitpunkt aufgetreten sind. Zugehörige Ergebnisse deuten möglicherweise darauf hin, dass diese Aktivität böswillig war und nicht auf einem Verstoß gegen die Best Practices beruht.
Schritt 2: Cluster und Knoten prüfen
Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster 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 Ressourcenname 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
Rufen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten auf.
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 Cluster, der in der Zeile Vollständiger Ressourcenname auf dem Tab Zusammenfassung der Ergebnisdetails aufgeführt ist, und dem in Pod_Namespace aufgeführten Pod-Namespace.
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
Rufen Sie in der Google Cloud Console den Log-Explorer auf.
Prüfen Sie den SHA-256-Hashwert für die als schädlich gekennzeichnete Binärdatei auf VirusTotal, indem Sie auf den Link in VirusTotal-Indikator klicken. VirusTotal ist ein Alphabet-eigener Dienst, der Kontext zu potenziell schädlichen Dateien, URLs, Domains und IP-Adressen bereitstellt.
Wenn Sie einen Reaktionsplan entwickeln möchten, kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung und der VirusTotal-Analyse.
Schritt 7: Antwort implementieren
Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken.
Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.
Wenn die Binärdatei im Container enthalten sein sollte, erstellen Sie das Container-Image mit der Binärdatei neu. So kann der Container unveränderlich sein.
Andernfalls wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Container.
Beenden oder löschen Sie den manipulierten Container und ersetzen Sie ihn durch einen neuen Container.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-05 (UTC)."],[],[],null,["| Premium and Enterprise [service tiers](/security-command-center/docs/service-tiers)\n\nThis document describes a threat finding type in Security Command Center. Threat findings are generated by\n[threat detectors](/security-command-center/docs/concepts-security-sources#threats) when they detect\na potential threat in your cloud resources. For a full list of available threat findings, see [Threat findings index](/security-command-center/docs/threat-findings-index).\n\nOverview\n\nA binary that was not part of the original container image was executed.\nAttackers commonly install exploitation tooling and malware after the initial\ncompromise. Ensuring that your containers are immutable is an important best\npractice. This is a low-severity finding, because your organization might not be\nfollowing this best practice. There are corresponding `Execution: Added\nMalicious Binary Executed` findings when the hash of the binary is a known\nindicator of compromise (IoC).\n\n[Container Threat Detection](/security-command-center/docs/concepts-container-threat-detection-overview) is the source\nof this finding.\n\nHow to respond\n\nTo respond to this finding, do the following:\n\nStep 1: Review finding details\n\n1. Open an `Added Binary Executed` finding as directed in\n [Reviewing findings](/security-command-center/docs/how-to-investigate-threats#reviewing_findings). The details panel for the\n finding opens to the **Summary** tab.\n\n2. On the **Summary** tab, review the information in the following sections:\n\n - **What was detected** , especially the following fields:\n - **Program binary**: the absolute path of the added binary.\n - **Arguments**: the arguments provided when invoking the added binary.\n - **Affected resource** , especially the following fields:\n - **Resource full name** : the [full resource name](/apis/design/resource_names) of the cluster including the project number, location, and cluster name.\n - **Related links** , especially the following fields:\n - **VirusTotal indicator**: link to the VirusTotal analysis page.\n3. Click the **JSON** and note the following fields:\n\n - `resource`:\n - `project_display_name`: the name of the project that contains the cluster.\n - `sourceProperties`:\n - `Pod_Namespace`: the name of the Pod's Kubernetes namespace.\n - `Pod_Name`: the name of the GKE Pod.\n - `Container_Name`: the name of the affected container.\n - `Container_Image_Uri`: the name of the container image being deployed.\n - `VM_Instance_Name`: the name of the GKE node where the Pod executed.\n4. Identify other findings that occurred at a similar time for this container. Related findings might indicate that this activity was malicious, instead of a failure to follow best practices.\n\nStep 2: Review cluster and node\n\n1. In the Google Cloud console, go to the **Kubernetes clusters** page.\n\n [Go to Kubernetes clusters](https://console.cloud.google.com/kubernetes/list)\n\n \u003cbr /\u003e\n\n2. On the Google Cloud console toolbar, select the project listed in\n `resource.project_display_name`, if necessary.\n\n3. Select the cluster listed on the **Resource full name** row in the\n **Summary** tab of the finding details. Note any metadata about\n the cluster and its owner.\n\n4. Click the **Nodes** tab. Select the node listed in `VM_Instance_Name`.\n\n5. Click the **Details** tab and note the\n `container.googleapis.com/instance_id` annotation.\n\nStep 3: Review Pod\n\n1. In the Google Cloud console, go to the **Kubernetes Workloads** page.\n\n [Go to Kubernetes Workloads](https://console.cloud.google.com/kubernetes/workload)\n\n \u003cbr /\u003e\n\n2. On the Google Cloud console toolbar, select the project listed in\n `resource.project_display_name`, if necessary.\n\n3. Filter on the cluster listed on the **Resource full name** row in the\n **Summary** tab of the finding details and the Pod namespace\n listed in `Pod_Namespace`, if necessary.\n\n4. Select the Pod listed in `Pod_Name`. Note any metadata about the Pod and\n its owner.\n\nStep 4: Check logs\n\n1. In the Google Cloud console, go to **Logs Explorer**.\n\n \u003cbr /\u003e\n\n [Go to Logs Explorer](https://console.cloud.google.com/logs/query)\n\n \u003cbr /\u003e\n\n2. On the Google Cloud console toolbar, select the project listed in\n `resource.project_display_name`, if necessary.\n\n3. Set **Select time range** to the period of interest.\n\n4. On the page that loads, do the following:\n\n 1. Find Pod logs for `Pod_Name` by using the following filter:\n - `resource.type=\"k8s_container\"`\n - `resource.labels.project_id=\"`\u003cvar class=\"edit\" translate=\"no\"\u003eresource.project_display_name\u003c/var\u003e`\"`\n - `resource.labels.location=\"`\u003cvar class=\"edit\" translate=\"no\"\u003elocation\u003c/var\u003e`\"`\n - `resource.labels.cluster_name=\"`\u003cvar class=\"edit\" translate=\"no\"\u003ecluster_name\u003c/var\u003e`\"`\n - `resource.labels.namespace_name=\"`\u003cvar class=\"edit\" translate=\"no\"\u003ePod_Namespace\u003c/var\u003e`\"`\n - `resource.labels.pod_name=\"`\u003cvar class=\"edit\" translate=\"no\"\u003ePod_Name\u003c/var\u003e`\"`\n 2. Find cluster audit logs by using the following filter:\n - `logName=\"projects/`\u003cvar class=\"edit\" translate=\"no\"\u003eresource.project_display_name\u003c/var\u003e`/logs/cloudaudit.googleapis.com%2Factivity\"`\n - `resource.type=\"k8s_cluster\"`\n - `resource.labels.project_id=\"`\u003cvar class=\"edit\" translate=\"no\"\u003eresource.project_display_name\u003c/var\u003e`\"`\n - `resource.labels.location=\"`\u003cvar class=\"edit\" translate=\"no\"\u003elocation\u003c/var\u003e`\"`\n - `resource.labels.cluster_name=\"`\u003cvar class=\"edit\" translate=\"no\"\u003ecluster_name\u003c/var\u003e`\"`\n - \u003cvar class=\"edit\" translate=\"no\"\u003ePod_Name\u003c/var\u003e\n 3. Find GKE node console logs by using the following filter:\n - `resource.type=\"gce_instance\"`\n - `resource.labels.instance_id=\"`\u003cvar class=\"edit\" translate=\"no\"\u003einstance_id\u003c/var\u003e`\"`\n\nStep 5: Investigate running container\n\nIf the container is still running, it might be possible to investigate the\ncontainer environment directly.\n\n1. Go to the Google Cloud console.\n\n [Open Google Cloud console](https://console.cloud.google.com/)\n2. On the Google Cloud console toolbar, select the project listed in\n `resource.project_display_name`, if necessary.\n\n3. Click **Activate Cloud Shell**\n\n4. Obtain GKE credentials for your cluster by running the\n following commands.\n\n For zonal clusters: \n\n gcloud container clusters get-credentials \u003cvar class=\"edit\" translate=\"no\"\u003ecluster_name\u003c/var\u003e --zone \u003cvar class=\"edit\" translate=\"no\"\u003elocation\u003c/var\u003e --project \u003cvar class=\"edit\" translate=\"no\"\u003eproject_name\u003c/var\u003e\n\n For regional clusters: \n\n gcloud container clusters get-credentials \u003cvar class=\"edit\" translate=\"no\"\u003ecluster_name\u003c/var\u003e --region \u003cvar class=\"edit\" translate=\"no\"\u003elocation\u003c/var\u003e --project \u003cvar class=\"edit\" translate=\"no\"\u003eproject_name\u003c/var\u003e\n\n Replace the following:\n - `cluster_name`: the cluster listed in `resource.labels.cluster_name`\n - `location`: the location listed in `resource.labels.location`\n - `project_name`: the project name listed in `resource.project_display_name`\n5. Retrieve the added binary by running:\n\n kubectl cp \u003cvar class=\"edit\" translate=\"no\"\u003ePod_Namespace\u003c/var\u003e/\u003cvar class=\"edit\" translate=\"no\"\u003ePod_Name\u003c/var\u003e:\u003cvar class=\"edit\" translate=\"no\"\u003eProcess_Binary_Fullpath\u003c/var\u003e -c \u003cvar class=\"edit\" translate=\"no\"\u003eContainer_Name\u003c/var\u003e \u003cvar translate=\"no\"\u003elocal_file\u003c/var\u003e\n\n Replace `local_file` with a local file path to store the added binary.\n6. Connect to the container environment by running:\n\n kubectl exec --namespace=\u003cvar class=\"edit\" translate=\"no\"\u003ePod_Namespace\u003c/var\u003e -ti \u003cvar class=\"edit\" translate=\"no\"\u003ePod_Name\u003c/var\u003e -c \u003cvar class=\"edit\" translate=\"no\"\u003eContainer_Name\u003c/var\u003e -- /bin/sh\n\n This command requires the container to have a shell installed at `/bin/sh`.\n\nStep 6: Research attack and response methods\n\n1. Review MITRE ATT\\&CK framework entries for this finding type: [Ingress Tool Transfer](https://attack.mitre.org/techniques/T1105/), [Native API](https://attack.mitre.org/techniques/T1106/).\n2. Check the SHA-256 hash value for the binary flagged as malicious on [VirusTotal](https://www.virustotal.com) by clicking the link in **VirusTotal indicator**. VirusTotal is an Alphabet-owned service that provides context on potentially malicious files, URLs, domains, and IP addresses.\n3. To develop a response plan, combine your investigation results with the MITRE research and VirusTotal analysis.\n\nStep 7: Implement your response\n\n\nThe following response plan might be appropriate for this finding, but might also impact operations.\nCarefully evaluate the information you gather in your investigation to determine the best way to\nresolve findings.\n\n- If the binary was intended to be included in the container, rebuild the container image with the binary included. This way, the container can be immutable.\n- Otherwise, contact the owner of the project with the compromised container.\n- Stop or [delete](/container-registry/docs/managing#deleting_images) the compromised container and replace it with a [new container](/compute/docs/containers).\n\nWhat's next\n\n- Learn [how to work with threat\n findings in Security Command Center](/security-command-center/docs/how-to-investigate-threats).\n- Refer to the [Threat findings index](/security-command-center/docs/threat-findings-index).\n- Learn how to [review a\n finding](/security-command-center/docs/how-to-investigate-threats#reviewing_findings) through the Google Cloud console.\n- Learn about the [services that\n generate threat findings](/security-command-center/docs/concepts-security-sources#threats)."]]
.