이 문서에서는 Security Command Center의 위협 발견 항목 유형에 대해 설명합니다. 위협 발견 항목은 위협 감지기가 클라우드 리소스에서 잠재적인 위협을 감지할 때 생성됩니다. 사용 가능한 위협 발견 항목의 전체 목록은 위협 발견 항목 색인을 참고하세요.
개요
원본 컨테이너 이미지에 포함되지 않은 바이너리가 실행되었습니다.
공격자는 일반적으로 초기 침해 후 익스플로잇 도구와 멀웨어를 설치합니다. 컨테이너를 변경할 수 없도록 하는 것은 중요한 권장사항입니다. 조직에서 이 권장사항을 따르지 않을 수 있으므로 심각도가 낮은 발견 항목입니다. 바이너리의 해시가 알려진 침해 지표 (IoC)인 경우 해당하는 Execution: Added
Malicious Binary Executed 발견 항목이 있습니다.
대응 방법
이 발견 항목에 대응하려면 다음을 수행하세요.
1단계: 발견 항목 세부정보 검토하기
발견 항목 검토의 지시에 따라 Added Binary Executed 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
특히 다음 필드를 포함하는 감지된 항목:
프로그램 바이너리: 추가된 바이너리의 절대 경로
인수: 추가된 바이너리를 호출할 때 제공되는 인수
특히 다음 필드를 포함하는 영향을 받는 리소스:
리소스 전체 이름: 프로젝트 번호, 위치, 클러스터 이름을 포함한 클러스터의 전체 리소스 이름
특히 다음 필드를 포함하는 관련 링크:
VirusTotal 표시기: VirusTotal 분석 페이지 링크
JSON을 클릭하고 다음 필드를 확인합니다.
resource:
project_display_name: 클러스터가 포함된 프로젝트 이름
sourceProperties:
Pod_Namespace: 포드의 Kubernetes 네임스페이스 이름
Pod_Name: GKE 포드의 이름
Container_Name: 영향을 받는 컨테이너의 이름
Container_Image_Uri: 배포 중인 컨테이너 이미지의 이름
VM_Instance_Name: 포드가 실행된 GKE 노드의 이름
이 컨테이너에서 비슷한 시점에 발생한 다른 발견 항목을 식별합니다. 관련 발견 항목은 권장사항을 따르지 않은 것이 아니라 악의적인 활동이었음을 의미할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 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)."]]
를 클릭합니다.