Ejecución: Se detectó una posible ejecución de comandos remotos
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En este documento, se describe un tipo de resultado de amenazas en Security Command Center. Los detectores de amenazas generan resultados de amenazas cuando detectan una amenaza potencial en tus recursos de Cloud. Para obtener una lista completa de los resultados de amenazas disponibles, consulta el Índice de resultados de amenazas.
Descripción general
Se detectó un proceso que generaba comandos comunes de UNIX a través de un socket de red, lo que podría emular una shell inversa. Este comportamiento sugiere un intento de establecer acceso remoto no autorizado al sistema, lo que le otorga al atacante la capacidad de ejecutar comandos arbitrarios como si estuviera interactuando directamente con la máquina vulnerada. Los adversarios suelen utilizar shells inversos para eludir las restricciones del firewall y obtener el control persistente de un objetivo. La detección de la ejecución de comandos iniciada a través de un socket significa un riesgo de seguridad importante, ya que permite una amplia gama de actividades maliciosas, como la filtración de datos, el movimiento lateral y una mayor explotación, lo que convierte este hallazgo en un descubrimiento crítico que exige una investigación inmediata para identificar la fuente de la conexión y las acciones realizadas.
Cómo responder
Para responder a este hallazgo, haz lo siguiente:
Paso 1: Revisa los detalles del hallazgo
Abre un hallazgo de Execution: Possible Remote Command Execution Detected como se indica en Revisa los hallazgos. Se abre el panel de detalles del hallazgo en la pestaña Resumen.
En la pestaña Resumen, revisa la información de las siguientes secciones:
Qué se detectó, especialmente los siguientes campos:
Programa binario: Es la ruta de acceso absoluta del archivo binario ejecutado.
Arguments: Son los argumentos que se pasan durante la ejecución del objeto binario.
Recurso afectado, en especial los siguientes campos:
Nombre completo del recurso: Es el nombre completo del recurso del clúster, incluido el número de proyecto, la ubicación y el nombre del clúster.
En la vista de detalles del hallazgo, haz clic en la pestaña JSON.
En el JSON, ten en cuenta los siguientes campos.
resource:
project_display_name: Es el nombre del proyecto que contiene el clúster.
finding:
processes:
binary:
path: Es la ruta de acceso completa del objeto binario ejecutado.
args: Son los argumentos que se proporcionaron durante la ejecución del objeto binario.
sourceProperties:
Pod_Namespace: El nombre del espacio de nombres de Kubernetes del Pod.
Pod_Name: Es el nombre del Pod de GKE.
Container_Name: Es el nombre del contenedor afectado.
Container_Image_Uri: Es el nombre de la imagen de contenedor que se implementa.
VM_Instance_Name: el nombre del nodo de GKE en el que se ejecutó el Pod
Identifica otros hallazgos que se produjeron en un momento similar para este contenedor.
Los hallazgos relacionados pueden indicar que esta actividad fue maliciosa, en lugar de un incumplimiento de las prácticas recomendadas.
Paso 2: Revisa el clúster y el nodo
En la consola de Google Cloud , ve a la página de clústeres de Kubernetes.
En la barra de herramientas de la consola de Google Cloud , selecciona el proyecto que aparece enresource.project_display_name, si es necesario.
Selecciona el clúster que aparece en la fila Nombre completo del recurso en la pestaña Resumen de los detalles del hallazgo. Toma nota de los metadatos sobre el clúster y su propietario.
Haz clic en la pestaña Nodos. Selecciona el nodo que aparece en VM_Instance_Name.
Haz clic en la pestaña Detalles y anota la anotación container.googleapis.com/instance_id.
Paso 3: Revisa el pod
En la consola de Google Cloud , ve a la página Cargas de trabajo de Kubernetes.
En la barra de herramientas de la consola de Google Cloud , selecciona el proyecto que aparece enresource.project_display_name, si es necesario.
Si es necesario, filtra el clúster que aparece en la fila Nombre completo del recurso de la pestaña Resumen de los detalles del hallazgo y el espacio de nombres de Pod que aparece en Pod_Namespace.
Selecciona el pod que aparece en Pod_Name. Toma nota de los metadatos del Pod y su propietario.
Paso 4: Comprueba los registros
En la consola de Google Cloud , ve al Explorador de registros.
Para desarrollar un plan de respuesta, combina los resultados de la investigación con la investigación del MITRE.
Paso 7: Implementa tu respuesta
El siguiente plan de respuesta podría ser adecuado para este hallazgo, pero también podría afectar las operaciones.
Evalúa con cuidado la información que recopilas en tu investigación para determinar la mejor manera de resolver los resultados.
Comunícate con el propietario del proyecto en el que se encuentra el contenedor vulnerado.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)."]]
.