Execução: possível execução de comando remoto detectada
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Este documento descreve um tipo de descoberta de ameaça no Security Command Center. As descobertas de ameaças são geradas por
detectores de ameaças quando eles detectam
uma ameaça potencial nos seus recursos da nuvem. Para uma lista completa das descobertas de ameaças disponíveis, consulte o índice de descobertas de ameaças.
Visão geral
Um processo foi detectado gerando comandos comuns do UNIX por um soquete de rede,
potencialmente emulando um shell reverso. Esse comportamento sugere uma tentativa de
estabelecer acesso remoto não autorizado ao sistema, concedendo ao invasor a
capacidade de executar comandos arbitrários como se estivesse interagindo diretamente com
a máquina comprometida. Os adversários costumam usar shells reversos para burlar as restrições de firewall e ganhar controle persistente sobre um destino. A detecção da execução de comandos iniciada por um soquete significa um risco de segurança significativo, já que permite uma ampla variedade de atividades maliciosas, incluindo exfiltração de dados, movimentação lateral e mais exploração. Por isso, essa é uma descoberta crítica que exige investigação imediata para identificar a origem da conexão e as ações realizadas.
Como responder
Para responder a essa descoberta, faça o seguinte:
Etapa 1: verificar os detalhes da descoberta
Abra uma descoberta Execution: Possible Remote Command Execution Detected, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
Na guia Resumo, confira as informações nas seguintes seções:
O que foi detectado, especialmente os seguintes campos:
Binário do programa: o caminho absoluto do binário executado.
Argumentos: os argumentos transmitidos durante a execução binária.
Recurso afetado, especialmente os seguintes campos:
Nome completo do recurso: o nome completo do recurso
do cluster, inclusive o número, o local e o nome do cluster do projeto.
Na visualização detalhada da descoberta, clique na guia JSON.
No JSON, observe os seguintes campos.
resource:
project_display_name: o nome do projeto que contém o cluster.
finding:
processes:
binary:
path: o caminho completo do binário executado.
args: os argumentos fornecidos ao executar o binário.
sourceProperties:
Pod_Namespace: o nome do namespace do Kubernetes do pod.
Pod_Name: o nome do pod do GKE.
Container_Name: o nome do contêiner afetado.
Container_Image_Uri: o nome da imagem do contêiner que está sendo implantada.
VM_Instance_Name: o nome do nó do GKE em que o pod foi executado.
Identifique outras descobertas que ocorreram em um momento semelhante para esse contêiner.
As descobertas relacionadas podem indicar que essa atividade foi maliciosa, em vez de uma falha em seguir as práticas recomendadas.
Etapa 2: verificar o cluster e o nó
No console Google Cloud , acesse a página Clusters do Kubernetes.
Na barra de ferramentas do console do Google Cloud , selecione o projeto listado em
resource.project_display_name, se necessário.
Selecione o cluster listado na linha Nome completo do recurso na guia Resumo dos detalhes da descoberta. Anote os metadados sobre
o cluster e o proprietário dele.
Clique na guia Nós. Selecione o nó listado em VM_Instance_Name.
Clique na guia Detalhes e anote a
anotação container.googleapis.com/instance_id.
Etapa 3: verificar o pod
No console Google Cloud , acesse a página Cargas de trabalho do Kubernetes.
Na barra de ferramentas do console do Google Cloud , selecione o projeto listado em
resource.project_display_name, se necessário.
Filtre no cluster listado na linha Nome completo do recurso na guia
Resumo dos detalhes da descoberta e no namespace do pod
listado em Pod_Namespace, se necessário.
Selecione o pod listado em Pod_Name. Anote os metadados sobre o pod e
o proprietário dele.
Etapa 4: verificar os registros
No console Google Cloud , acesse Análise de registros.
Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa
do MITRE.
Etapa 7: implementar a resposta
O plano de resposta a seguir pode ser apropriado para essa descoberta, mas também pode afetar as operações.
Avalie cuidadosamente as informações coletadas na investigação para determinar a melhor maneira de
resolver as descobertas.
Entre em contato a pessoa a quem o projeto com o contêiner comprometido pertence.
Interrompa ou exclua o
contêiner comprometido e substitua-o por um
novo contêiner.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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 process was detected spawning common UNIX commands via a network socket,\npotentially emulating a reverse shell. This behavior suggests an attempt to\nestablish unauthorized remote access to the system, granting the attacker the\nability to execute arbitrary commands as if they were directly interacting with\nthe compromised machine. Adversaries frequently utilize reverse shells to bypass\nfirewall restrictions and gain persistent control over a target. The detection\nof command execution initiated through a socket signifies a significant security\nrisk, as it allows for a wide range of malicious activities, including data\nexfiltration, lateral movement, and further exploitation, making this a critical\nfinding that demands immediate investigation to identify the source of the\nconnection and the actions performed.\n\nHow to respond\n\nTo respond to this finding, do the following:\n\nStep 1: Review finding details\n\n1. Open an `Execution: Possible Remote Command Execution Detected` finding as\n directed in [Reviewing findings](/security-command-center/docs/how-to-investigate-threats#reviewing_findings). The details panel for\n the 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 executed binary.\n - **Arguments**: the arguments passed during binary execution.\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.\n3. In the detail view of the finding, click the **JSON** tab.\n\n4. In the JSON, note the following fields.\n\n - `resource`:\n - `project_display_name`: the name of the project that contains the cluster.\n - `finding`:\n - `processes`:\n - `binary`:\n - `path`: the full path of the executed binary.\n - `args`: the arguments that were provided while executing the binary.\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.\n5. Identify other findings that occurred at a similar time for this container.\n Related findings might indicate that this activity was malicious, instead of\n 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 [Go to Logs Explorer](https://console.cloud.google.com/logs/query)\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 \\\n --zone \u003cvar class=\"edit\" translate=\"no\"\u003eLOCATION\u003c/var\u003e \\\n --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 \\\n --region \u003cvar class=\"edit\" translate=\"no\"\u003eLOCATION\u003c/var\u003e \\\n --project \u003cvar class=\"edit\" translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the cluster listed in `resource.labels.cluster_name`\n - \u003cvar translate=\"no\"\u003eLOCATION\u003c/var\u003e: the location listed in `resource.labels.location`\n - \u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e: the project name listed in `resource.project_display_name`\n5. Retrieve the executed binary:\n\n kubectl cp \\\n \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 \\\n -c \u003cvar class=\"edit\" translate=\"no\"\u003eCONTAINER_NAME\u003c/var\u003e \\\n \u003cvar translate=\"no\"\u003eLOCAL_FILE\u003c/var\u003e\n\n Replace \u003cvar translate=\"no\"\u003elocal_file\u003c/var\u003e with a local file path to store the\n added binary.\n6. Connect to the container environment by running the following command:\n\n kubectl exec \\\n --namespace=\u003cvar class=\"edit\" translate=\"no\"\u003ePOD_NAMESPACE\u003c/var\u003e \\\n -ti \u003cvar class=\"edit\" translate=\"no\"\u003ePOD_NAME\u003c/var\u003e \\\n -c \u003cvar class=\"edit\" translate=\"no\"\u003eCONTAINER_NAME\u003c/var\u003e \\\n -- /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 Interpreter](https://attack.mitre.org/techniques/T1059/).\n2. To develop a response plan, combine your investigation results with MITRE research.\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)."]]
