Organízate con las colecciones
Guarda y clasifica el contenido según tus preferencias.
En este documento se describe un tipo de hallazgo de amenazas en Security Command Center. Los hallazgos de amenazas los generan los detectores de amenazas cuando detectan una amenaza potencial en tus recursos de la nube. Para ver una lista completa de las detecciones de amenazas disponibles, consulta el índice de detecciones de amenazas.
Información general
Se ha ejecutado un archivo binario malicioso que no formaba parte de la imagen del contenedor original. Los atacantes suelen instalar herramientas de explotación y malware después de la brecha inicial.
Cómo responder
Para responder a esta observación, sigue estos pasos:
Paso 1: Revisa los detalles de la detección
Abre un Execution: Added Malicious Binary Executed tal como se indica en el artículo Revisar los resultados. Se abrirá el panel de detalles del
resultado en la pestaña Resumen.
En la pestaña Resumen, consulte la información de las siguientes secciones:
Qué se detectó, especialmente los siguientes campos:
Binario del programa: la ruta absoluta del binario añadido.
Argumentos: los argumentos proporcionados al invocar el archivo binario añadido.
Contenedores: el nombre del contenedor afectado.
URI de los contenedores: el nombre de la imagen del contenedor que se va a desplegar.
Recurso afectado, especialmente los siguientes campos:
Nombre completo del recurso: el nombre completo del recurso
del clúster, incluido el número de proyecto, la ubicación y el nombre del clúster.
Enlaces relacionados, especialmente los siguientes campos:
Indicador de VirusTotal: enlace a la página de análisis de VirusTotal.
Haz clic en la pestaña JSON y anota los siguientes campos:
sourceProperties:
VM_Instance_Name: el nombre del nodo de GKE en el que se ha ejecutado el pod.
Paso 2: Revisa el clúster y el nodo
En la Google Cloud consola, ve a la página Clústeres de Kubernetes.
En la barra de herramientas de la consola Google Cloud , selecciona el proyecto que aparece en
resource.project_display_name, si es necesario.
Seleccione el clúster que aparece en la fila Nombre completo del recurso de la pestaña Resumen de los detalles de la detección. Anota los metadatos del clúster y de su propietario.
Haz clic en la pestaña Nodos. Selecciona el nodo que aparece en VM_Instance_Name.
Haga clic en la pestaña Detalles y anote la anotación container.googleapis.com/instance_id.
Paso 3: Revisar el Pod
En la Google Cloud consola, ve a la página Cargas de trabajo de Kubernetes.
En la barra de herramientas de la consola Google Cloud , selecciona el proyecto que aparece en
resource.project_display_name, si es necesario.
Filtra por el clúster que aparece en la fila Nombre completo del recurso de la pestaña Resumen de los detalles de la detección y el espacio de nombres del pod que se indica en Pod_Namespace, si es necesario.
Selecciona el pod que aparece en Pod_Name. Anota los metadatos del Pod y de su propietario.
Paso 4: Consulta los registros
En la Google Cloud consola, ve a Explorador de registros.
Comprueba el valor del hash SHA-256 del archivo binario marcado como malicioso en VirusTotal haciendo clic en el enlace del indicador de VirusTotal. VirusTotal es un servicio propiedad de Alphabet que proporciona contexto sobre archivos, URLs, dominios y direcciones IP potencialmente maliciosos.
Para desarrollar un plan de respuesta, combina los resultados de tu investigación con la investigación de MITRE y el análisis de VirusTotal.
Paso 7: Implementa tu respuesta
El siguiente plan de respuesta puede ser adecuado para este resultado, pero también puede afectar a las operaciones.
Evalúa detenidamente la información que recojas en tu investigación para determinar la mejor forma de resolver los resultados.
Ponte en contacto con el propietario del proyecto que contiene el contenedor vulnerado.
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-10 (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 malicious binary that was not part of the original container image was\nexecuted. Attackers commonly install exploitation tooling and malware after\nthe initial compromise.\n\nHow to respond\n\nTo respond to this finding, do the following:\n\nStep 1: Review finding details\n\n1. Open an `Execution: Added Malicious 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 - **Containers**: the name of the affected container.\n - **Containers URI**: the name of the container image being deployed.\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** tab and note the following fields:\n\n - `sourceProperties`:\n - `VM_Instance_Name`: the name of the GKE node where the Pod executed.\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 malicious binary:\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 path to store the added malicious binary.\n6. Connect to the container environment:\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- 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)."]]
