Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Ce document décrit un type de résultat de menace dans Security Command Center. Les résultats de menace sont générés par les détecteurs de menaces lorsqu'ils détectent une menace potentielle dans vos ressources cloud. Pour obtenir la liste complète des résultats de menace disponibles, consultez l'index des résultats de menace.
Présentation
Un fichier binaire ne faisant pas partie de l'image de conteneur d'origine a été exécuté.
Les pirates informatiques installent généralement les outils d'exploitation et les logiciels malveillants après le piratage initial. Il est important de s'assurer que vos conteneurs sont immuables. Il s'agit d'un problème de faible gravité, car il se peut que votre organisation ne suive pas cette bonne pratique. Des résultats Execution: Added
Malicious Binary Executed correspondants s'affichent lorsque le hachage du fichier binaire est un indicateur de compromission (IoC) connu.
Comment répondre
Pour répondre à ce résultat, procédez comme suit :
Étape 1 : Examiner les détails du résultat
Ouvrez un résultat Added Binary Executed comme indiqué dans la section Examiner les résultats. Le panneau d'informations sur le résultat s'ouvre sur l'onglet Résumé.
Dans l'onglet Récapitulatif, examinez les informations des sections suivantes :
Ce qui a été détecté, en particulier les champs suivants :
Binaire du programme : chemin d'accès absolu du binaire ajouté.
Arguments : arguments fournis lors de l'appel du binaire ajouté.
Ressource concernée, en particulier les champs suivants :
Nom complet de la ressource : nom complet de la ressource du cluster, y compris le numéro de projet, l'emplacement et le nom du cluster.
Liens associés, en particulier les champs suivants :
Indicateur VirusTotal : lien vers la page d'analyse VirusTotal.
Cliquez sur JSON et notez les champs suivants :
resource :
project_display_name : nom du projet contenant le cluster.
sourceProperties :
Pod_Namespace : nom de l'espace de noms Kubernetes du pod.
Pod_Name : nom du pod GKE.
Container_Name : nom du conteneur concerné.
Container_Image_Uri : nom de l'image de conteneur en cours de déploiement.
VM_Instance_Name : nom du nœud GKE sur lequel le pod a été exécuté.
Identifiez d'autres résultats qui se sont produits à une période similaire pour ce conteneur. Les résultats associés peuvent indiquer que cette activité était malveillante, plutôt qu'un manquement aux bonnes pratiques.
Étape 2 : Vérifier le cluster et le nœud
Dans la console Google Cloud , accédez à la page Clusters Kubernetes.
Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Sélectionnez le cluster listé sur la ligne Nom complet de la ressource dans l'onglet Résumé des détails du résultat. Notez toutes les métadonnées concernant le cluster et son propriétaire.
Cliquez sur l'onglet Nœuds. Sélectionnez le nœud répertorié dans VM_Instance_Name.
Cliquez sur l'onglet Détails et notez l'annotation container.googleapis.com/instance_id.
Étape 3 : Examiner le pod
Dans la console Google Cloud , accédez à la page Charges de travail Kubernetes.
Dans la barre d'outils de la console Google Cloud , sélectionnez le projet listé dans resource.project_display_name, si nécessaire.
Filtrez le cluster listé dans la ligne Nom complet de la ressource de l'onglet Résumé des détails du résultat et l'espace de noms du pod listé dans Pod_Namespace, si nécessaire.
Sélectionnez le pod répertorié dans Pod_Name. Notez les métadonnées concernant le pod et son propriétaire.
Étape 4 : Vérifier les journaux
Dans la console Google Cloud , accédez à l'explorateur de journaux.
Vérifiez la valeur de hachage SHA-256 du fichier binaire signalé comme malveillant sur VirusTotal en cliquant sur le lien dans l'indicateur VirusTotal. VirusTotal est un service appartenant à Alphabet qui fournit du contexte sur les fichiers, URL, domaines et adresses IP potentiellement malveillants.
Pour élaborer un plan d'intervention, combinez les résultats de vos enquêtes avec les recherches MITRE et l'analyse VirusTotal.
Étape 7 : Mettre en œuvre votre réponse
Le plan de réponse suivant peut être adapté à ce résultat, mais peut également avoir une incidence sur les opérations.
Évaluez soigneusement les informations que vous collectez dans votre enquête pour déterminer la meilleure façon de solutionner les menaces détectées.
Si le binaire était censé être inclus dans le conteneur, recréez l'image de conteneur en incluant le binaire. Le conteneur peut ainsi être immuable.
Sinon, contactez le propriétaire du projet contenant le conteneur compromis.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)."]]
