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

Este documento descreve um tipo de descoberta de ameaça no Security Command Center. As descobertas de ameaças são geradas por detectores de ameaças quando eles detectam uma ameaça potencial nos seus recursos da nuvem. Para uma lista completa das descobertas de ameaças disponíveis, consulte o índice de descobertas de ameaças.

Visão geral

Um processo foi detectado ao iniciar uma ferramenta de compilador de código em um ambiente de contêiner. Esse comportamento sugere uma possível tentativa de desenvolver ou compilar software malicioso no contêiner isolado, possivelmente para ofuscar atividades maliciosas e evitar controles de segurança tradicionais baseados em host. Os adversários podem usar essa técnica para criar ferramentas personalizadas ou modificar binários atuais em um ambiente menos analisado antes de implantá-los no sistema subjacente ou em outros destinos. A presença de um compilador de código em um contêiner, especialmente se for inesperada, exige investigação, já que pode indicar que um invasor está se preparando para introduzir backdoors persistentes ou comprometer o software do cliente por meio de binários adulterados.

Como responder

Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

  1. Abra uma descoberta Defense Evasion: Launch Code Compiler Tool In Container, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.

  2. Na guia Resumo, confira as informações nas seguintes seções:

    • O que foi detectado, especialmente os seguintes campos:
      • Binário do programa: o caminho absoluto do binário executado.
      • Argumentos: os argumentos transmitidos durante a execução binária.
    • Recurso afetado, especialmente os seguintes campos:
      • Nome completo do recurso: o nome completo do recurso do cluster, inclusive o número, o local e o nome do cluster do projeto.
  3. Na visualização detalhada da descoberta, clique na guia JSON.

  4. No JSON, observe os seguintes campos.

    • resource:
      • project_display_name: o nome do projeto que contém o cluster.
    • finding:
      • processes:
      • binary:
        • path: o caminho completo do binário executado.
      • args: os argumentos fornecidos ao executar o binário.
    • sourceProperties:
      • Pod_Namespace: o nome do namespace do Kubernetes do pod.
      • Pod_Name: o nome do pod do GKE.
      • Container_Name: o nome do contêiner afetado.
      • Container_Image_Uri: o nome da imagem do contêiner que está sendo implantada.
      • VM_Instance_Name: o nome do nó do GKE em que o pod foi executado.
  5. Identifique outras descobertas que ocorreram em um momento semelhante para esse contêiner. As descobertas relacionadas podem indicar que essa atividade foi maliciosa, em vez de uma falha em seguir as práticas recomendadas.

Etapa 2: verificar o cluster e o nó

  1. No console Google Cloud , acesse a página Clusters do Kubernetes.

    Acesse os clusters do Kubernetes

  2. Na barra de ferramentas do console do Google Cloud , selecione o projeto listado em resource.project_display_name, se necessário.

  3. Selecione o cluster listado na linha Nome completo do recurso na guia Resumo dos detalhes da descoberta. Anote os metadados sobre o cluster e o proprietário dele.

  4. Clique na guia Nós. Selecione o nó listado em VM_Instance_Name.

  5. Clique na guia Detalhes e anote a anotação container.googleapis.com/instance_id.

Etapa 3: verificar o pod

  1. No console Google Cloud , acesse a página Cargas de trabalho do Kubernetes.

    Acesse Cargas de trabalho do Kubernetes

  2. Na barra de ferramentas do console do Google Cloud , selecione o projeto listado em resource.project_display_name, se necessário.

  3. Filtre no cluster listado na linha Nome completo do recurso na guia Resumo dos detalhes da descoberta e no namespace do pod listado em Pod_Namespace, se necessário.

  4. Selecione o pod listado em Pod_Name. Anote os metadados sobre o pod e o proprietário dele.

Etapa 4: verificar os registros

  1. No console Google Cloud , acesse Análise de registros.

    Acessar a Análise de registros

  2. Na barra de ferramentas do console do Google Cloud , selecione o projeto listado em resource.project_display_name, se necessário.

  3. Defina Selecionar período como o período de interesse.

  4. Na página carregada, faça o seguinte:

    1. Encontre registros de pods para Pod_Name usando este filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • resource.labels.namespace_name="POD_NAMESPACE"
      • resource.labels.pod_name="POD_NAME"
    2. Encontre os registros de auditoria do cluster usando este filtro:
      • logName="projects/RESOURCE.PROJECT_DISPLAY_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • POD_NAME
    3. Encontre os registros do console do nó do GKE usando este filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Etapa 5: investigar o contêiner em execução

Se o contêiner ainda estiver em execução, talvez seja possível investigar o ambiente do contêiner diretamente.

  1. Acesse o console do Google Cloud .

    Abrir o Google Cloud console

  2. Na barra de ferramentas do console do Google Cloud , selecione o projeto listado em resource.project_display_name, se necessário.

  3. Clique em Ativar o Cloud Shell.

  4. Veja as credenciais do GKE do cluster executando os comandos a seguir.

    Para clusters zonais:

    gcloud container clusters get-credentials CLUSTER_NAME \
          --zone LOCATION \
          --project PROJECT_NAME
    

    Para clusters regionais:

    gcloud container clusters get-credentials CLUSTER_NAME \
          --region LOCATION \
          --project PROJECT_NAME
    

    Substitua:

    • CLUSTER_NAME: o cluster listado em resource.labels.cluster_name
    • LOCATION: o local listado em resource.labels.location
    • PROJECT_NAME: o nome do projeto listado em resource.project_display_name
  5. Recupere o binário executado:

    kubectl cp \
          POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
          -c CONTAINER_NAME \
          LOCAL_FILE
    

    Substitua local_file por um caminho de arquivo local para armazenar o binário adicionado.

  6. Conecte-se ao ambiente do contêiner executando o seguinte comando:

    kubectl exec \
          --namespace=POD_NAMESPACE \
          -ti POD_NAME \
          -c CONTAINER_NAME \
          -- /bin/sh
    

    Esse comando exige que o contêiner tenha um shell instalado em /bin/sh.

Etapa 6: pesquisar métodos de ataque e resposta

  1. Revise as entradas do framework MITRE ATT&CK para esse tipo de descoberta: Arquivos ou informações ofuscados: compilação após a entrega.
  2. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 7: implementar a resposta

O plano de resposta a seguir pode ser apropriado para essa descoberta, mas também pode afetar as operações. Avalie cuidadosamente as informações coletadas na investigação para determinar a melhor maneira de resolver as descobertas.

  • Entre em contato a pessoa a quem o projeto com o contêiner comprometido pertence.
  • Interrompa ou exclua o contêiner comprometido e substitua-o por um novo contêiner.

A seguir