이 문서에서는 Security Command Center의 위협 발견 항목 유형에 대해 설명합니다. 위협 발견 항목은 위협 감지기가 클라우드 리소스에서 잠재적인 위협을 감지할 때 생성됩니다. 사용 가능한 위협 발견 항목의 전체 목록은 위협 발견 항목 색인을 참고하세요.
개요
머신러닝 모델이 실행된 Python 코드를 악성으로 식별했습니다.
공격자는 Python을 사용하여 도구를 전송하고 바이너리 없이 명령어를 실행할 수 있습니다. 컨테이너를 변경할 수 없도록 하는 것은 중요한 권장사항입니다.
스크립트를 사용하여 도구를 전송하면 인그레스 도구 전송의 공격자 기법을 모방하여 원치 않는 감지를 할 수 있습니다.
대응 방법
이 발견 항목에 대응하려면 다음을 수행하세요.
1단계: 발견 항목 세부정보 검토하기
발견 항목 검토의 지시에 따라 Execution: Malicious Python executed 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
특히 다음 필드를 포함하는 감지된 항목:
프로그램 바이너리: 스크립트를 호출한 인터프리터에 대한 세부정보
스크립트: 디스크에 있는 스크립트 이름의 절대 경로. 이 속성은 디스크에 작성된 스크립트에만 표시되며 리터럴 스크립트 실행에는 표시되지 않습니다(예: python3 -c).
인수: 스크립트를 호출할 때 제공된 인수
특히 다음 필드를 포함하는 영향을 받는 리소스:
리소스 전체 이름: 프로젝트 번호, 위치, 클러스터 이름을 포함한 클러스터의 전체 리소스 이름
특히 다음 필드를 포함하는 관련 링크:
VirusTotal 표시기: VirusTotal 분석 페이지 링크
발견 항목의 세부정보 보기에서 JSON 탭을 클릭합니다.
JSON에서 다음 필드를 확인합니다.
finding:
processes:
script:
contents: 실행된 스크립트의 콘텐츠. 성능상의 이유로 잘릴 수 있으며 조사에 도움이 될 수 있습니다.
sha256: script.contents의 SHA-256 해시
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| **Preview**\n|\n|\n| This feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nA machine learning model identified executed Python code as malicious.\nAttackers can use Python to transfer tools and execute commands without binaries. Ensuring that your containers are immutable is an important [best practice](https://kubernetes.io/docs/concepts/containers/#container-images).\nUsing scripts to transfer tools can mimic the attacker technique of [ingress tool transfer](https://attack.mitre.org/techniques/T1105/) and result in unwanted detections.\n\nHow to respond\n\nTo respond to this finding, do the following:\n\nStep 1: Review finding details\n\n1. Open an `Execution: Malicious Python 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**: details about the interpreter that invoked the script.\n - **Script** : absolute path of the name of the script on disk; this attribute only appears for scripts written to disk, not for literal script execution---for example, `python3 -c`.\n - **Arguments**: the arguments provided when invoking the script.\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. In the detail view of the finding, click the **JSON** tab.\n\n4. In the JSON, note the following fields.\n\n - `finding`:\n - `processes`:\n - `script`:\n - `contents`: contents of the executed script, which might be truncated for performance reasons; this can aid in your investigation\n - `sha256`: the SHA-256 hash of `script.contents`\n - `resource`:\n - `project_display_name`: the name of the project that contains the asset.\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 executed.\n - `VM_Instance_Name`: the name of the GKE node where the Pod executed.\n5. Identify other findings that occurred at a similar time for this container. For instance, if the script drops a binary, check for findings related to the binary.\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)\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)\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 in `resource.name` 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. In the Google Cloud console, go to the **Kubernetes clusters** page.\n\n [Go to Kubernetes clusters](https://console.cloud.google.com/kubernetes/list)\n2. Click the name of the cluster shown in `resource.labels.cluster_name`.\n\n3. On the **Clusters** page, click **Connect** , and then click **Run in\n Cloud Shell**.\n\n Cloud Shell launches and adds commands for the cluster in the\n terminal.\n4. Press \u003ckbd\u003eEnter\u003c/kbd\u003e and, if the **Authorize Cloud Shell** dialog appears,\n click **Authorize**.\n\n5. Connect to the container environment by running the following command:\n\n kubectl exec --namespace=\u003cvar class=\"edit\" translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003ePod_Namespace\u003c/span\u003e\u003c/var\u003e -ti \u003cvar class=\"edit\" translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003ePod_Name\u003c/span\u003e\u003c/var\u003e -c \u003cvar class=\"edit\" translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003eContainer_Name\u003c/span\u003e\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: [Command and Scripting\n Interpreter](https://attack.mitre.org/techniques/T1059/), [Ingress Tool Transfer](https://attack.mitre.org/techniques/T1105/).\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 Python was making intended changes to the container, rebuild the container image such that no changes are needed. This way, the container can be [immutable](https://kubernetes.io/docs/concepts/containers/#container-images).\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)."]]
