Esecuzione: è stata rilevata una possibile esecuzione di comandi remoti
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questo documento descrive un tipo di risultato di minaccia in Security Command Center. I risultati delle minacce vengono generati dai
rilevatori di minacce quando rilevano
una potenziale minaccia nelle tue risorse cloud. Per un elenco completo dei risultati relativi alle minacce disponibili, consulta l'Indice dei risultati relativi alle minacce.
Panoramica
È stato rilevato un processo che genera comandi UNIX comuni tramite un socket di rete,
emulando potenzialmente una shell inversa. Questo comportamento suggerisce un tentativo di
stabilire un accesso remoto non autorizzato al sistema, concedendo all'aggressore la
possibilità di eseguire comandi arbitrari come se interagisse direttamente con
la macchina compromessa. Gli avversari utilizzano spesso le shell inverse per aggirare
le restrizioni del firewall e ottenere il controllo persistente di un target. Il rilevamento
dell'esecuzione di comandi avviata tramite un socket indica un rischio
per la sicurezza significativo, in quanto consente un'ampia gamma di attività dannose, tra cui l'esfiltrazione
di dati, lo spostamento laterale e un ulteriore sfruttamento, il che rende questa scoperta
critica che richiede un'indagine immediata per identificare l'origine della
connessione e le azioni eseguite.
Come rispondere
Per rispondere a questo risultato:
Passaggio 1: esamina i dettagli del risultato
Apri un risultato Execution: Possible Remote Command Execution Detected come
indicato in Revisione dei risultati. Si apre il riquadro dei dettagli per
il risultato nella scheda Riepilogo.
Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
Che cosa è stato rilevato, in particolare i seguenti campi:
Programma binario: il percorso assoluto del binario eseguito.
Arguments: gli argomenti passati durante l'esecuzione del file binario.
Risorsa interessata, in particolare i seguenti campi:
Nome completo della risorsa: il nome completo della risorsa
del cluster, inclusi il numero di progetto, la località e il nome del cluster.
Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
Nel JSON, prendi nota dei seguenti campi.
resource:
project_display_name: il nome del progetto che contiene il cluster.
finding:
processes:
binary:
path: il percorso completo del file binario eseguito.
args: gli argomenti forniti durante l'esecuzione del file binario.
sourceProperties:
Pod_Namespace: il nome dello spazio dei nomi Kubernetes del pod.
Pod_Name: il nome del pod GKE.
Container_Name: il nome del container interessato.
Container_Image_Uri: il nome dell'immagine del container di cui viene eseguito il deployment.
VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.
Identifica altri risultati che si sono verificati in un momento simile per questo container.
I risultati correlati potrebbero indicare che questa attività era dannosa, anziché
un mancato rispetto delle best practice.
Passaggio 2: esamina il cluster e il nodo
Nella console Google Cloud , vai alla pagina Cluster Kubernetes.
Nella barra degli strumenti della console Google Cloud , seleziona il progetto elencato in
resource.project_display_name, se necessario.
Seleziona il cluster elencato nella riga Nome completo risorsa nella scheda
Riepilogo dei dettagli del problema. Prendi nota di eventuali metadati
sul cluster e sul suo proprietario.
Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.
Fai clic sulla scheda Dettagli e prendi nota dell'annotazione
container.googleapis.com/instance_id.
Passaggio 3: rivedi il pod
Nella console Google Cloud , vai alla pagina Workload Kubernetes.
Nella barra degli strumenti della console Google Cloud , seleziona il progetto elencato in
resource.project_display_name, se necessario.
Filtra in base al cluster elencato nella riga Nome completo risorsa nella scheda
Riepilogo dei dettagli del problema e dello spazio dei nomi del pod
elencato in Pod_Namespace, se necessario.
Seleziona il pod elencato in Pod_Name. Prendi nota di eventuali metadati relativi al pod e
al suo proprietario.
Per sviluppare un piano di risposta, combina i risultati dell'indagine con la ricerca MITRE.
Passaggio 7: implementa la risposta
Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni.
Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati.
Contatta il proprietario del progetto con il container compromesso.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)."]]
