Investigar e responder a ameaças

Este documento oferece orientações informais para ajudar você a investigar descobertas de atividades suspeitas no seu ambiente do Google Cloud de atores potencialmente maliciosos. Este documento também oferece outros recursos para adicionar contexto às descobertas do Security Command Center. Seguindo essas etapas, você entenderá o que aconteceu durante um possível ataque e desenvolverá possíveis respostas para os recursos afetados.

Não há garantias de as técnicas nesta página sejam eficientes contra ameaças anteriores, atuais ou futuras. Consulte Como corrigir ameaças para entender por que o Security Command Center não fornece orientações oficiais para a correção de ameaças.

Antes de começar

Você precisa dos papéis adequados do Identity and Access Management (IAM, na sigla em inglês) para visualizar ou editar descobertas e registros e para modificar recursos do Google Cloud . Se você encontrar erros de acesso no Security Command Center, peça ajuda ao administrador e consulte Controle de acesso para saber mais sobre os papéis. Para resolver erros de recursos, leia a documentação dos produtos afetados.

Noções básicas sobre as descobertas de ameaças

O Event Threat Detection produz descobertas de segurança combinando eventos nos fluxos de registros do Cloud Logging com indicadores de comprometimento (IoC, na sigla em inglês) conhecidos. Os IoCs, desenvolvidos por fontes internas de segurança do Google, identificam possíveis vulnerabilidades e ataques. O Event Threat Detection também detecta ameaças ao identificar táticas, técnicas e procedimentos adversos conhecidos no fluxo de geração de registros e detectar desvios do comportamento anterior da organização ou do projeto. Se você ativar o nível Premium do Security Command Center no nível da organização, o Event Threat Detection também poderá verificar os registros do Google Workspace.

O Container Threat Detection gera descobertas coletando e analisando o comportamento observado de baixo nível no kernel convidado de contêineres.

As descobertas são gravadas na Central de comando de segurança. Se você ativar o nível Premium do Security Command Center no nível da organização, também poderá configurar as descobertas para serem gravadas no Cloud Logging.

Como revisar descobertas

Para analisar as ameaças no Google Cloud console, siga estas etapas:

1. No console do Google Cloud , acesse a página Descobertas do Security Command Center.

   Acesse Descobertas

2. Se necessário, selecione o Google Cloud projeto, a pasta ou a organização.

3. Na seção Filtros rápidos, clique em um filtro apropriado para exibir a descoberta necessária na tabela Resultados da consulta de descobertas. Por exemplo, se você selecionar Event Threat Detection ou Container Threat Detection na subseção Source display name, somente descobertas do serviço selecionado aparecem nos resultados.

   A tabela será preenchida com descobertas da origem selecionada.

4. Para ver detalhes sobre uma descoberta específica, clique no nome da descoberta em Category. O painel de detalhes da descoberta se expande para exibir um resumo dos detalhes da descoberta.

5. Para visualizar a definição JSON da descoberta, clique na guia JSON.

As descobertas informam os nomes e identificadores numéricos de recursos envolvidos em um incidente, além de variáveis de ambiente e propriedades de recursos. Use essas informações para isolar rapidamente os recursos afetados e determinar o possível escopo de um evento.

Para ajudar na investigação, as descobertas de ameaças também contêm links para os seguintes recursos externos:

• Entradas do framework do MITRE ATT&CK. O framework explica técnicas de ataques contra recursos da nuvem e fornece orientações para correção.

• VirusTotal, um serviço pertencente à Alphabet que fornece contexto sobre arquivos, URLs, domínios e endereços IP potencialmente maliciosos. Se disponível, o campo Indicador do VirusTotal fornece um link para o VirusTotal, ajudando você a investigar melhor possíveis problemas de segurança.

  O VirusTotal é uma oferta com preços separados e limites de uso e recursos diferentes. Você é responsável por entender e obedecer às políticas de uso da API do VirusTotal e aos custos associados. Para mais informações, consulte a documentação do VirusTotal.

As seções a seguir descrevem possíveis respostas para as descobertas de ameaças.

Desativação das descobertas de ameaças

Depois que você resolve um problema que acionou uma descoberta de ameaças, o Security Command Center não define automaticamente o estado da descoberta como INACTIVE. O estado de uma descoberta de ameaças permanece como ACTIVE, a menos que você defina manualmente a propriedade state como INACTIVE.

Para um falso positivo, considere deixar o estado da descoberta como ACTIVE e, em vez disso, silenciar a descoberta.

Para falsos positivos persistentes ou recorrentes, crie uma regra de silenciamento. Definir uma regra de silenciamento pode reduzir o número de descobertas que você precisa gerenciar, o que facilita a identificação de uma verdadeira ameaça quando ela ocorrer.

Em caso de ameaça real, antes de definir o estado da descoberta comoINACTIVE, elimine a ameaça e conclua uma investigação completa da ameaça detectada, a extensão da intrusão e qualquer outra descoberta e problema relacionado.

Para silenciar uma descoberta ou mudar o estado dela, consulte os seguintes tópicos:

• Silenciar descobertas
• Mudar o estado de uma descoberta

Respostas do Event Threat Detection

Para saber mais sobre o Event Threat Detection, consulte como o Event Threat Detection funciona.

Esta seção não contém respostas para descobertas geradas por módulos personalizados do Event Threat Detection, porque sua organização define as ações recomendadas para esses detectores.

Active Scan: Log4j Vulnerable to RCE

Os verificadores de vulnerabilidade de Log4j suportados injetam pesquisas JNDI ofuscadas em parâmetros HTTP, URLs e campos de texto com callbacks para domínios controlados pelos verificadores. Essa descoberta é gerada quando são encontradas consultas DNS nos domínios não ofuscados. Essas consultas só ocorrerão se uma pesquisa JNDI for bem-sucedida, indicando uma vulnerabilidade Log4j ativa. Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Active Scan: Log4j Vulnerable to RCE, conforme direcionado em Como verificar detalhes da descoberta. 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
   • Recurso afetado, especialmente o seguinte campo:
     • Nome completo do recurso: o nome completo do recurso da instância do Compute Engine que está vulnerável ao RCE do Log4j.
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

3. Na visualização detalhada da descoberta, clique na guia JSON.

4. No JSON, observe os seguintes campos.

   • properties
     • scannerDomain: o domínio usado pelo scanner como parte da pesquisa JNDI. Isso informa qual scanner identificou a vulnerabilidade.
     • sourceIp: o endereço IP usado para fazer a consulta DNS
     • vpcName: o nome da rede na instância em que a consulta DNS foi feita.

Etapa 2: verificar os registros

1. No console do Google Cloud , acesse o Explorador de registros clicando no link no campo URI do Cloud Logging da etapa 1.

2. Na página carregada, verifique os campos httpRequest para tokens de string, como ${jndi:ldap://, que podem indicar possíveis tentativas de exploração.

   Consulte CVE-2021-44228: como detectar a exploração do Log4Shell na documentação do Logging para ver strings de exemplo e pesquisar um exemplo de consulta.

Etapa 3: pesquisar métodos de ataque e resposta

1. Analise a entrada do framework da MITRE ATT&CK para esse tipo de descoberta: Exploração de serviços remotos.
2. Verifique as descobertas relacionadas clicando no link em Descobertas relacionadas na linha Descobertas relacionadas na guia Resumo dos detalhes da descoberta. As descobertas relacionadas são o mesmo tipo de descoberta e a mesma instância e rede.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 4: 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.

• Faça upgrade para a versão mais recente do Log4j2.
• Siga as recomendações doGoogle Cloudpara investigar e responder à vulnerabilidade "Apache Log4j 2".
• Implemente as técnicas recomendadas de mitigação nas vulnerabilidades de segurança do Apache Log4j.
• Se você usa o Google Cloud Armor, implante o cve-canary rule em uma política de segurança nova ou existente do Google Cloud Armor. Saiba mais em Regra do WAF do Google Cloud Armor para ajudar a mitigar a vulnerabilidade do Apache Log4j.

Brute Force: SSH

Detecção da força bruta do SSH em um host Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Brute Force: SSH, conforme direcionado em Como verificar descobertas.

2. Na guia Resumo do painel de detalhes da descoberta, revise as informações nas seguintes seções:

   • O que foi detectado, especialmente os seguintes campos:

     • IP do autor da chamada: é o endereço IP que iniciou o ataque.
     • Nome de usuário: a conta que fez login.

   • Recurso afetado

   • Links relacionados, principalmente os seguintes campos:

     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

3. Clique na guia JSON.

4. No JSON, observe os seguintes campos.

   • sourceProperties:
     • evidence:
       • sourceLogId: o ID do projeto e o carimbo de data/hora para identificar a entrada de registro
       • projectId: o projeto que contém a descoberta;
     • properties:
       • attempts:
       • Attempts: o número de tentativas de login;
         • username: a conta que fez login;
         • vmName: o nome da instância da máquina virtual
         • authResult: o resultado da autenticação SSH;

Etapa 2: verificar as permissões e configurações

1. No console Google Cloud , acesse o Painel.

   Ir para o Painel

2. Selecione o projeto especificado em projectId.

3. Acesse o card Recursos e clique em Compute Engine.

4. Clique na instância de VM que corresponde ao nome e à zona em vmName. Verifique os detalhes da instância, incluindo as configurações de rede e acesso.

5. No painel de navegação, clique em Rede VPC e em Firewall. Remova ou desative regras de firewall excessivamente permissivas na porta 22.

Etapa 3: verificar os registros

1. No console Google Cloud , acesse o Explorador de registros clicando no link em URI do Cloud Logging.
2. Na página carregada, localize os registros de fluxo de VPC relacionados ao endereço IP listado na linha E-mail principal na guia Resumo da descoberta usando o seguinte filtro:
   • logName="projects/projectId/logs/syslog"
   • labels."compute.googleapis.com/resource_name"="vmName"

Etapa 4: pesquisar métodos de ataque e resposta

1. Verifique a entrada do framework do MITRE ATT&CK em busca deste tipo de descoberta: Contas válidas: contas locais.
2. Verifique as descobertas relacionadas clicando no link em Descobertas relacionadas na linha Descobertas relacionadas na guia Resumo dos detalhes da descoberta. As descobertas relacionadas são o mesmo tipo de descoberta e a mesma instância e rede.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 5: 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 pertence com a tentativa de força bruta bem-sucedida.
• Investigue a instância possivelmente comprometida e remova qualquer malware descoberto. Para ajudar na detecção e remoção, use uma solução de detecção e resposta de endpoints.
• Considere desativar o acesso SSH à VM. Para saber mais sobre como desativar chaves SSH, consulte Restringir chaves SSH de VMs. Essa etapa pode interromper o acesso autorizado à VM. Portanto, considere as necessidades da organização antes de continuar.
• Use a autenticação SSH apenas com chaves autorizadas.
• Bloqueie os endereços IP maliciosos atualizando regras de firewall ou usando o Google Cloud Armor. Ative o Google Cloud Armor na página Serviços integrados do Security Command Center. Dependendo da quantidade de informações, os custos do Google Cloud Armor podem ser significativos. Consulte o guia de preços do Google Cloud Armor para mais informações.

Credential Access: CloudDB Failed login from Anonymizing Proxy IP

Detecta uma falha de login na sua instância de banco de dados de um endereço IP de anonimização conhecido. Esses endereços de anonimização são nós do Tor. Isso pode indicar que um invasor está tentando acessar sua instância sem autorização.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Credential Access: CloudDB Failed login from Anonymizing Proxy IP, conforme direcionado em Como verificar descobertas.

2. Na guia Resumo do painel de detalhes da descoberta, revise as informações nas seguintes seções:

   • O que foi detectado, especialmente os seguintes campos:
   • Endereço IP do indicador, o endereço IP de anonimização.
   • Nome de exibição do banco de dados: o nome do banco de dados na instância do PostgreSQL, MySQL ou AlloyDB do Cloud SQL que foi afetada.
   • Nome de usuário do banco de dados: o usuário.
   • Nome completo do projeto: o projeto do Google Cloud que contém a instância do Cloud SQL.

Etapa 2: pesquisar métodos de ataque e resposta

1. Analise a entrada do framework do MITRE ATT&CK para esse tipo de descoberta: Acesso a credenciais.
2. Para determinar se outras etapas de correção são necessárias, combine seus resultados da investigação com a pesquisa do MITRE.

Etapa 3: 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.

• Analise os usuários autorizados a se conectar ao banco de dados.

  • Para o PostgreSQL, consulte Criar e gerenciar usuários
  • Para o MySQL, consulte Gerenciar usuários com a autenticação integrada

• Considere mudar a senha do usuário.

  • Para PostgreSQL, consulte Definir a senha do usuário padrão

  • Para o MySQL, consulte Definir a senha do usuário padrão

  • Atualize as credenciais dos clientes que se conectam à instância do Cloud SQL.

• Analisar o acesso à rede da sua instância

  • Para PostgreSQL, consulte Definir a senha do usuário padrão
  • Para o MySQL, consulte Definir a senha do usuário padrão

Credential Access: Failed Attempt to Approve Kubernetes Certificate Signing Request (CSR)

Alguém tentou aprovar manualmente uma solicitação de assinatura de certificado (CSR), mas a ação falhou. A criação de um certificado para autenticação de cluster é um método comum de acesso persistente a um cluster comprometido. As permissões associadas ao certificado variam dependendo do assunto incluído, mas podem ser altamente privilegiadas. Para mais detalhes, consulte a mensagem de registro deste alerta.

1. Analise os registros de auditoria no Cloud Logging e os outros alertas para outros eventos relacionados à CSR para determinar se alguma foi approved e emitida e se as ações relacionadas à CSR são atividades esperadas pelo principal.
2. Determine se há outros sinais de atividade maliciosa do principal nos registros de auditoria no Cloud Logging. Por exemplo:
   • O principal que tentou aprovar a CSR é diferente de quem a criou?
   • O principal tentou solicitar, criar, aprovar ou excluir outras CSRs?
3. Se a aprovação de uma CSR não era esperada ou for considerada maliciosa, o cluster vai exigir uma rotação de credenciais para invalidar o certificado. Consulte as orientações sobre como fazer a rotação das credenciais do cluster.

Credential Access: Manually Approved Kubernetes Certificate Signing Request (CSR)

Alguém aprovou manualmente uma solicitação de assinatura de certificado (CSR, na sigla em inglês). A criação de um certificado para autenticação de cluster é um método comum de acesso persistente a um cluster comprometido. As permissões associadas ao certificado variam dependendo do assunto incluído, mas podem ser altamente privilegiadas. Para mais detalhes, consulte a mensagem de registro desse alerta.

1. Analise os registros de auditoria no Cloud Logging e os outros alertas para outros eventos relacionados à CSR para determinar se as ações relacionadas à CSR são atividades esperadas pelo principal.
2. Determine se há outros sinais de atividade maliciosa do principal nos registros de auditoria no Cloud Logging. Por exemplo:
   • O principal que aprovou a CSR é diferente de quem a criou?
   • A CSR especificou um signatário integrado, mas precisou ser aprovada de modo manual porque não atendeu aos critérios do signatário?
   • O principal tentou solicitar, criar, aprovar ou excluir outras CSRs?
3. Se a aprovação de uma CSR não era esperada ou for considerada maliciosa, o cluster vai exigir uma rotação de credenciais para invalidar o certificado. Consulte as orientações sobre como fazer a rotação das credenciais do cluster.

Credential Access: Secrets Accessed in Kubernetes Namespace

Detecta quando a default conta de serviço do Kubernetes de um pod foi usada para acessar objetos Secret no cluster. A conta de serviço do Kubernetes default não pode ter acesso a objetos Secret, a menos que você tenha concedido esse acesso explicitamente com um objeto Role ou ClusterRole.

Defense Evasion: Breakglass Workload Deployment Created

Breakglass Workload Deployment Created é detectado ao examinar os Registros de auditoria do Cloud para ver se há implantações em cargas de trabalho que usam a flag de implantação forçada para substituir os controles de autorização binária.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Defense Evasion: Breakglass Workload Deployment Created, conforme instruído em Como verificar descobertas. O painel com os detalhes da descoberta será aberto, exibindo a guia Resumo.

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

   • O que foi detectado, especialmente os seguintes campos:
     • E-mail principal: a conta que realizou a modificação.
     • Nome do método: o método que foi chamado.
     • Pods do Kubernetes: o nome e o namespace do pod.
   • Recurso afetado, especialmente o seguinte campo:
     • Nome de exibição do recurso: o namespace do GKE em que ocorreu a implantação.
   • Links relacionados:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

Etapa 2: verificar os registros

1. Na guia Resumo dos detalhes da descoberta no console do Google Cloud , acesse o Explorador de registros clicando no link no campo URI do Cloud Logging.
2. Verifique o valor no campo protoPayload.resourceName para identificar a solicitação de assinatura de certificado específica.

3. Verifique se há outras ações realizadas pelo principal usando os seguintes filtros:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Substitua:

   • CLUSTER_NAME: o valor que você anotou no campo Nome de exibição do recurso nos detalhes da descoberta.

   • PRINCIPAL_EMAIL: o valor que você anotou no campo E-mail principal nos detalhes da descoberta.

Etapa 3: pesquisar métodos de ataque e resposta

1. Revise a entrada do framework MITRE ATT&CK para esse tipo de descoberta: Evasão de defesa: implantação forçada da carga de trabalho criada.
2. Verifique as descobertas relacionadas clicando no link em Descobertas relacionadas na linha Descobertas relacionadas na guia Resumo dos detalhes da descoberta.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Defense Evasion: Breakglass Workload Deployment Updated

Breakglass Workload Deployment Updated é detectado ao examinar os Registros de auditoria do Cloud para ver se há atualizações em cargas de trabalho que usam a flag de implantação forçada para substituir os controles de autorização binária.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Defense Evasion: Breakglass Workload Deployment Updated, conforme instruído em Como verificar descobertas. O painel com os detalhes da descoberta será aberto, exibindo a guia Resumo.

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

   • O que foi detectado, especialmente os seguintes campos:
     • E-mail principal: a conta que realizou a modificação.
     • Nome do método: o método que foi chamado.
     • Pods do Kubernetes: o nome e o namespace do pod.
   • Recurso afetado, especialmente o seguinte campo:
     • Nome de exibição do recurso: o namespace do GKE em que ocorreu a atualização.
   • Links relacionados:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

Etapa 2: verificar os registros

1. Na guia Resumo dos detalhes da descoberta no console do Google Cloud , acesse o Explorador de registros clicando no link no campo URI do Cloud Logging.
2. Verifique o valor no campo protoPayload.resourceName para identificar a solicitação de assinatura de certificado específica.

3. Verifique se há outras ações realizadas pelo principal usando os seguintes filtros:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Substitua:

   • CLUSTER_NAME: o valor que você anotou no campo Nome de exibição do recurso nos detalhes da descoberta.

   • PRINCIPAL_EMAIL: o valor que você anotou no campo E-mail principal nos detalhes da descoberta.

Etapa 3: pesquisar métodos de ataque e resposta

1. Revise a entrada do framework MITRE ATT&CK para esse tipo de descoberta: Evasão de defesa: implantação forçada da carga de trabalho criada.
2. Verifique as descobertas relacionadas clicando no link em Descobertas relacionadas na linha Descobertas relacionadas na guia Resumo dos detalhes da descoberta.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Defense Evasion: GCS Bucket IP Filtering Modified

O Event Threat Detection examina os registros de auditoria para detectar se a configuração de filtragem de IP foi atualizada em um bucket do Cloud Storage.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Defense Evasion: GCS Bucket IP Filtering Modified, conforme instruído 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:
     • Descrição: informações sobre a detecção
     • Assunto principal: um usuário ou uma conta de serviço que executou uma ação com sucesso
   • Recurso afetado
     • Nome de exibição do recurso: o bucket em que a configuração foi atualizada.
   • Links relacionados, principalmente os seguintes campos:
     • Método MITRE ATTACK: link para a documentação do MITRE ATT&CK.
     • URI do Logging: link para abrir a Análise de registros.

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço ou de usuário no campo Assunto principal. Confirme se o proprietário legítimo realizou a ação.

Defense Evasion: Manually Deleted Certificate Signing Request (CSR)

Alguém excluiu manualmente uma solicitação de assinatura de certificado (CSR, na sigla em inglês). Os CSRs são removidos automaticamente por um controlador de coleta de lixo, mas agentes mal-intencionados podem excluí-los manualmente para evitar a detecção. Se a CSR excluída era de um certificado aprovado e emitido, o usuário potencialmente malicioso agora tem um método de autenticação adicional para acessar o cluster. As permissões associadas ao certificado variam dependendo do assunto incluído, mas podem ser altamente privilegiadas. O Kubernetes não permite a revogação de certificados. Para mais detalhes, consulte a mensagem de registro desse alerta.

1. Analise os registros de auditoria no Cloud Logging e os outros alertas para outros eventos relacionados a essa CSR para determinar se ela foi approved e se a criação dela era uma atividade esperada pelo principal.
2. Determine se há outros sinais de atividade maliciosa do principal nos registros de auditoria no Cloud Logging. Por exemplo:
   • O principal que excluiu a CSR é diferente de quem a criou ou aprovou?
   • O principal tentou solicitar, criar, aprovar ou excluir outras CSRs?
3. Se a aprovação de uma CSR não era esperada ou for considerada maliciosa, o cluster vai exigir uma rotação de credenciais para invalidar o certificado. Consulte as orientações sobre como fazer a rotação das credenciais do cluster.

Defense Evasion: Modify VPC Service Control

Essa descoberta não está disponível para ativações no nível do projeto.

Os registros de auditoria são examinados para detectar alterações nos perímetros do VPC Service Controls que levam a uma redução na proteção oferecida por esse perímetro. Confira alguns exemplos:

• Um projeto é removido de um perímetro
• Uma política de nível de acesso é adicionada a um perímetro atual
• Um ou mais serviços são adicionados à lista de serviços acessíveis

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Defense Evasion: Modify VPC Service Control, conforme instruído em Como verificar descobertas. O painel com os detalhes da descoberta será aberto, exibindo a guia Resumo.

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

   • O que foi detectado, especialmente o seguinte campo:
     • E-mail principal: a conta que realizou a modificação.
   • Recurso afetado, especialmente o seguinte campo:
     • Nome completo do recurso: o nome do perímetro do VPC Service Controls que foi modificado.
   • Links relacionados:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

3. Clique na guia JSON.

4. No JSON, observe os seguintes campos.

   • sourceProperties
     • properties
       • name: o nome do perímetro do VPC Service Controls que foi modificado
       • policyLink: o link para a política de acesso que controla o perímetro
       • delta: as mudanças, REMOVE ou ADD, em um perímetro que reduziu a proteção
       • restricted_resources: os projetos que seguem as restrições desse perímetro. A proteção será reduzida se você remover um projeto
       • restricted_services: os serviços que não podem ser executados pelas restrições desse perímetro. A proteção será reduzida se você remover um serviço restrito
       • allowed_services: os serviços que podem ser executados de acordo com as restrições desse perímetro. A proteção será reduzida se você adicionar um serviço permitido
       • access_levels: os níveis de acesso configurados para permitir o acesso a recursos no perímetro. A proteção será reduzida se você adicionar mais níveis de acesso

Etapa 2: verificar os registros

1. Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
2. Encontre registros de atividades do administrador relacionados às alterações do VPC Service Controls usando estes filtros:
   • protoPayload.methodName:"AccessContextManager.UpdateServicePerimeter"
   • protoPayload.methodName:"AccessContextManager.ReplaceServicePerimeters"

Etapa 3: pesquisar métodos de ataque e resposta

1. Revise a entrada do framework MITRE ATT&CK para esse tipo de descoberta: Evasão de defesa: modifique o processo de autenticação.
2. Verifique as descobertas relacionadas clicando no link em Descobertas relacionadas na linha Descobertas relacionadas na guia Resumo dos detalhes da descoberta.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 4: 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 com o proprietário da política e do perímetro do VPC Service Controls.
• Considere reverter as alterações no perímetro até que a investigação seja concluída.
• Revogue os papéis do Access Context Manager no principal que modificou o perímetro até que a investigação seja concluída.
• Investigar como as proteções reduzidas foram usadas Por exemplo, se a "API BigQuery Data Transfer Service" estiver ativada ou for adicionada como um serviço permitido, verifique quem começou a usar esse serviço e o que ele está transferindo.

Defense Evasion: Potential Kubernetes Pod Masquerading

Alguém implantou um pod com uma convenção de nomenclatura semelhante às cargas de trabalho padrão que o GKE cria para a operação normal do cluster. Essa técnica é chamada de mascaramento. Para mais detalhes, consulte a mensagem de registro desse alerta.

1. Confirme se o pod é legítimo.
2. Determine se há outros sinais de atividade maliciosa do pod ou principal nos registros de auditoria no Cloud Logging.
3. Se o principal não for uma conta de serviço (IAM ou Kubernetes), entre em contato com o proprietário da conta para confirmar se foi essa pessoa que realizou a ação.
4. Se o principal for uma conta de serviço (IAM ou Kubernetes), identifique a origem da ação para determinar a legitimidade.
5. Se o pod não for legítimo, remova-o com as vinculações do controle de acesso baseado em função (RBAC) e as contas de serviço associadas que a carga de trabalho usou e que permitiram a criação dele.

Defense Evasion: Project HTTP Policy Block Disabled

A Detecção de ameaças a eventos examina os registros de auditoria para detectar se a política constraints/storage.secureHttpTransport foi atualizada para desativar o bloqueio de política HTTP.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Defense Evasion: Project HTTP Policy Block Disabled, conforme instruído 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:
     • Descrição: informações sobre a detecção
     • Assunto principal: um usuário ou uma conta de serviço que executou uma ação com sucesso
   • Recurso afetado
     • Nome de exibição do recurso: o projeto/pasta/organização em que a política foi atualizada.
   • Links relacionados, principalmente os seguintes campos:
     • Método MITRE ATTACK: link para a documentação do MITRE ATT&CK.
     • URI do Logging: link para abrir a Análise de registros.

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço ou de usuário no campo Assunto principal. Confirme se o proprietário legítimo realizou a ação para desativar a política constraints/storage.secureHttpTransport.

Defensive Evasion: Static Pod Created

Alguém criou um pod estático no cluster do GKE. Os pods estáticos são executados diretamente no nó e ignoram o servidor da API Kubernetes, o que dificulta o monitoramento e o controle deles. Isso pode ser usado por invasores para evitar a detecção ou manter a persistência.

1. Revise o arquivo de manifesto do pod estático e a finalidade dele. Verifique se ele é legítimo e necessário.
2. Avalie se a funcionalidade do pod estático pode ser alcançada com um pod regular gerenciado pelo servidor da API Kubernetes.
3. Se o pod estático for necessário, verifique se ele segue as práticas recomendadas de segurança e tem privilégios mínimos.
4. Monitore a atividade do pod estático e o impacto dela no cluster.

Discovery: Can get sensitive Kubernetes object check

Uma pessoa mal-intencionada tentou determinar quais objetos confidenciais no GKE eles podem consultar usando o comando kubectl auth can-i get. Especificamente, o ator executou qualquer um dos seguintes comandos:

• kubectl auth can-i get '*'
• kubectl auth can-i get secrets
• kubectl auth can-i get clusterroles/cluster-admin

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Discovery: Can get sensitive Kubernetes object check, conforme direcionado em Como verificar descobertas.

2. No painel Detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:

   • Em O que foi detectado:
     • Avaliações de acesso do Kubernetes: as informações solicitadas para a análise de acesso, com base no recurso SelfSubjectAccessReview do k8s.
     • E-mail principal: a conta que fez a chamada.
   • Em Recurso afetado:
     • Nome de exibição do recurso: o cluster do Kubernetes em que a ação ocorreu.
   • Em Links relacionados:
     • URI do Cloud Logging: link para as entradas do Logging.

Etapa 2: verificar os registros

1. Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.

2. Na página carregada, verifique se há outras ações realizadas pelo principal usando os seguintes filtros:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Substitua:

   • CLUSTER_NAME: o valor que você anotou no campo Nome de exibição do recurso nos detalhes da descoberta.

   • PRINCIPAL_EMAIL: o valor que você anotou no campo E-mail principal nos detalhes da descoberta.

Etapa 3: pesquisar métodos de ataque e resposta

1. Verifique as entradas do framework do MITRE ATT&CK em busca deste tipo de descoberta: Descoberta
2. Confirme a confidencialidade do objeto consultado e determine se há outros sinais de atividade maliciosa pelo principal nos registros.

3. Se a conta que você anotou na linha E-mail principal nos detalhes da descoberta não for uma conta de serviço, entre em contato com o proprietário dela para confirmar se o proprietário legítimo conduziu a ação.

   Se o e-mail principal for uma conta de serviço (IAM ou Kubernetes), identifique a origem da revisão de acesso para determinar a legitimidade.

4. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Evasion: Access from Anonymizing Proxy

O acesso anômalo usando um proxy anônimo é detectado ao analisar os registros de auditoria do Cloud em busca de modificações de serviço do Google Cloud originadas de um endereço IP associado à rede Tor.

Para responder a essas descobertas, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Evasion: Access from Anonymizing Proxy, conforme informado em Como verificar descobertas. O painel com os detalhes da descoberta será aberto, exibindo a guia Resumo.

2. Na guia Resumo do painel de detalhes da descoberta, revise os valores listados nas seguintes seções:

   • O que foi detectado, especialmente os seguintes campos:
     • E-mail principal: a conta que fez as alterações (uma conta potencialmente comprometida).
     • IP: o endereço IP do proxy de onde as mudanças são realizadas
   • Recurso afetado
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

3. Se quiser, clique na guia JSON para visualizar outros campos de descoberta.

Etapa 2: pesquisar métodos de ataque e resposta

1. Analise a entrada do framework MITRE ATT&CK para esse tipo de descoberta: Proxy: multi-hop Proxy.
2. Entre em contato com o proprietário da conta no campo principalEmail. Confirme se a ação foi realizada pelo proprietário legítimo.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Execution: Cryptomining Docker Image

Detecta quando um serviço ou job do Cloud Run é criado ou revisado ao adicionar uma imagem do Docker maliciosa conhecida que pode fazer mineração de criptomoedas.

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

1. Verifique a imagem do contêiner para determinar se isso era esperado.
2. Exclua o contêiner comprometido e substitua-o por um novo.

Execution: GKE launch excessively capable container

Alguém implantou um contêiner com uma ou mais das seguintes capacidades em um cluster do GKE com um contexto de segurança elevado:

• CAP_SYS_MODULE
• CAP_SYS_RAWIO
• CAP_SYS_PTRACE
• CAP_SYS_BOOT
• CAP_DAC_READ_SEARCH
• CAP_NET_ADMIN
• CAP_BPF

Esses recursos já foram usados para escapar de contêineres e precisam ser provisionados com cuidado.

1. Revise o contexto de segurança do contêiner na definição do pod. Identifique todas as capacidades que não são estritamente necessárias para a função.
2. Remova ou reduza recursos excessivos sempre que possível. Use o princípio de privilégio mínimo.

Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments

Alguém criou um pod com comandos ou argumentos geralmente associados a um shell reverso. Os invasores usam shells reversos para expandir ou manter o acesso inicial a um cluster e executar comandos arbitrários. Para mais detalhes, consulte a mensagem de registro deste alerta.

1. Confirme se o pod tem um motivo legítimo para especificar esses comandos e argumentos.
2. Determine se há outros sinais de atividade maliciosa do pod ou principal nos registros de auditoria no Cloud Logging.
3. Se o principal não for uma conta de serviço (IAM ou Kubernetes), entre em contato com o proprietário da conta para confirmar se foi essa pessoa que realizou a ação.
4. Se o principal for uma conta de serviço (IAM ou Kubernetes), identifique a legitimidade do que fez com que a conta de serviço realizasse essa ação.
5. Se o pod não for legítimo, remova-o com as vinculações do controle de acesso baseado em função (RBAC) e as contas de serviço associadas que a carga de trabalho usou e que permitiram a criação dele.

Execution: Suspicious Exec or Attach to a System Pod

Alguém usou os comandos exec ou attach para receber um shell ou executar um comando em um contêiner em execução no namespace kube-system. Esses métodos às vezes são usados para fins legítimos de depuração. No entanto, o kube-system namespace é destinado a objetos do sistema criados pelo Kubernetes, e a execução de comandos ou a criação de shells inesperadas precisa ser analisada. Para mais detalhes, consulte a mensagem de registro desse alerta.

1. Analise os registros de auditoria no Cloud Logging para determinar se essa era a atividade esperada pelo principal.
2. Determine se há outros sinais de atividade maliciosa pelo principal nos registros.

Consulte as orientações sobre o uso do princípio de privilégio mínimo para os papéis do controle de acesso baseado em função (RBAC) e do cluster que permitiram esse acesso.

Execution: Workload triggered in sensitive namespace

Alguém implantou uma carga de trabalho (por exemplo, um pod ou uma implantação) nos namespaces kube-system ou kube-public. Esses namespaces são essenciais para as operações do cluster do GKE, e cargas de trabalho não autorizadas podem comprometer a estabilidade ou a segurança do cluster.

1. Identifique a carga de trabalho implantada e a finalidade dela.
2. Se a carga de trabalho não estiver autorizada, exclua-a e investigue a origem da implantação.

Exfiltration: BigQuery Data Exfiltration

As descobertas retornadas pelo Exfiltration: BigQuery Data Exfiltration contêm uma das duas sub-regras possíveis. Cada sub-regra tem uma gravidade diferente:

• Sub-regra exfil_to_external_table com gravidade = HIGH:
  • Um recurso foi salvo fora da sua organização ou projeto.
• Sub-regra vpc_perimeter_violation com gravidade = LOW:
  • O VPC Service Controls bloqueou uma operação de cópia ou uma tentativa de acessar os recursos do BigQuery.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Exfiltration: BigQuery Data Exfiltration, conforme instruído em Como verificar descobertas.

2. Na guia Resumo do painel de detalhes da descoberta, revise os valores listados nas seguintes seções:

   • O que foi detectado:
     • Gravidade: a gravidade é HIGH para a sub-regra exfil_to_external_table ou LOW para a vpc_perimeter_violation.
     • E-mail principal: a conta usada para exfiltrar os dados.
     • Origens de exfiltração: detalhes sobre as tabelas das quais os dados foram exfiltados.
     • Destinos de exfiltração: detalhes sobre as tabelas em que os dados de exfiltração foram armazenados.
   • Recurso afetado:
     • Nome completo do recurso: o nome completo do recurso do projeto, da pasta ou da organização da qual os dados foram exfiltados.
   • Links relacionados:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

3. Clique na guia Propriedades de origem e revise os campos mostrados, especialmente:

   • detectionCategory:
     • subRuleName: exfil_to_external_table ou vpc_perimeter_violation.
   • evidence:
     • sourceLogId:
       • projectId: o projeto Google Cloud que contém o conjunto de dados de origem do BigQuery.
   • properties
     • dataExfiltrationAttempt
       • jobLink: o link para o job do BigQuery que exfiltrou dados.
       • query: a consulta SQL executada no conjunto de dados do BigQuery.

4. Se quiser, clique na guia JSON para ver uma lista completa das propriedades JSON da descoberta.

Etapa 2: verificar as permissões e configurações

1. No console Google Cloud , acesse a página IAM.

   Acessar IAM

2. Se necessário, selecione o projeto listado no campo projectId no JSON de descoberta.

3. Na página exibida, na caixa Filtro, insira o endereço de e-mail listado em E-mail principal e verifique as permissões atribuídas à conta.

Etapa 3: verificar os registros

1. Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.

2. Encontre registros de atividades do administrador relacionados a jobs do BigQuery usando estes filtros:

   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Etapa 4: pesquisar métodos de ataque e resposta

1. Verifique a entrada do framework do MITRE ATT&CK em busca deste tipo de descoberta: Exfiltração por serviço da Web: exfiltração para o Cloud Storage.
2. Verifique as descobertas relacionadas clicando no link em Descobertas relacionadas na linha Descobertas relacionadas na guia Resumo dos detalhes da descoberta. As descobertas relacionadas são o mesmo tipo de descoberta na mesma instância e rede.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 5: 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 pertence com dados exfiltrado.
• Considere revogar as permissões de userEmail até que a investigação seja concluída.
• Para interromper a exfiltração, adicione políticas do IAM restritivas aos conjuntos de dados do BigQuery afetados (exfiltration.sources e exfiltration.targets).
• Para verificar se há conjuntos de dados de informações sensíveis, use a Proteção de dados confidenciais. Também é possível enviar dados sensíveis de proteção de dados para o Security Command Center. Dependendo da quantidade de informações, os custos da proteção de dados sensíveis podem ser significativos. Siga as práticas recomendadas para manter os custos de proteção de dados sensíveis sob controle.
• Para limitar o acesso à API BigQuery, use o VPC Service Controls.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Exfiltration: BigQuery Data Extraction

A exfiltração de dados pelo BigQuery é detectada ao examinar os registros de auditoria em dois cenários:

• Um recurso é salvo em um bucket do Cloud Storage fora da sua organização.
• Um recurso é salvo em um bucket do Cloud Storage acessível ao público de propriedade da sua organização.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Exfiltration: BigQuery Data Extraction, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.

2. Na guia Resumo do painel de detalhes da descoberta, revise os valores listados nas seguintes seções:

   • O que foi detectado:
     • E-mail principal: a conta usada para exfiltrar os dados.
     • Origens de exfiltração: detalhes sobre as tabelas das quais os dados foram exfiltados.
     • Destinos de exfiltração: detalhes sobre as tabelas em que os dados de exfiltração foram armazenados.
   • Recurso afetado:
     • Nome completo do recurso: o nome do recurso do BigQuery com dados exfiltrados.
     • Nome completo do projeto: o projeto Google Cloud que contém o conjunto de dados do BigQuery de origem.
   • Links relacionados:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

3. No painel de detalhes da descoberta, clique na guia JSON.

4. No JSON, observe os seguintes campos.

   • sourceProperties:
     • evidence:
       • sourceLogId:
       • projectId: o projeto Google Cloud que contém o conjunto de dados de origem do BigQuery.
     • properties:
       • extractionAttempt:
       • jobLink: o link para o job do BigQuery que exfiltrou dados

Etapa 2: verificar as permissões e configurações

1. No console Google Cloud , acesse a página IAM.

   Acessar o IAM

2. Se necessário, selecione o projeto listado no campo projectId no JSON de descoberta (da Etapa 1).

3. Na página exibida, na caixa Filtro, digite o endereço de e-mail listado em E-mail principal (da Etapa 1) e verifique as permissões que estão atribuídas à conta.

Etapa 3: verificar os registros

1. Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
2. Encontre registros de atividades do administrador relacionados a jobs do BigQuery usando estes filtros:
   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Etapa 4: pesquisar métodos de ataque e resposta

1. Verifique a entrada do framework do MITRE ATT&CK em busca deste tipo de descoberta: Exfiltração por serviço da Web: exfiltração para o Cloud Storage.
2. Verifique as descobertas relacionadas clicando no link na linha Descobertas relacionadas na guia Resumo dos detalhes da descoberta. As descobertas relacionadas são o mesmo tipo de descoberta na mesma instância e rede.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 5: 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 pertence com dados exfiltrado.
• Recomendamos que você revogue as permissões do principal listado na linha E-mail principal na guia Resumo dos detalhes da descoberta até que a investigação seja concluída.
• Para interromper a exfiltração, adicione políticas restritivas do IAM aos conjuntos de dados afetados do BigQuery identificados no campo Origens de exfiltração no Resumo dos detalhes da descoberta.
• Para verificar se há conjuntos de dados de informações sensíveis, use a Proteção de dados confidenciais. Também é possível enviar dados sensíveis de proteção de dados para o Security Command Center. Dependendo da quantidade de informações, os custos da proteção de dados sensíveis podem ser significativos. Siga as práticas recomendadas para manter os custos de proteção de dados sensíveis sob controle.
• Para limitar o acesso à API BigQuery, use o VPC Service Controls.
• Se você for o proprietário do bucket, revogue as permissões de acesso público.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Exfiltration: BigQuery Data to Google Drive

A exfiltração de dados do BigQuery é detectada examinando registros de auditoria para o seguinte cenário:

• Um recurso é salvo em uma pasta do Google Drive.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Exfiltration: BigQuery Data to Google Drive, conforme direcionado em Como verificar descobertas.

2. Na guia Resumo do painel de detalhes da descoberta, revise as informações nas seguintes seções:

   • O que foi detectado, incluindo:
     • E-mail principal: a conta usada para exfiltrar os dados.
     • Origens de exfiltração: detalhes sobre a tabela do BigQuery de que os dados foram exfiltados.
     • Metas de exfiltração: detalhes sobre o destino no Google Drive.
   • Recurso afetado, incluindo:
     • Nome completo do recurso: o nome do recurso do BigQuery com dados exfiltrados.
     • Nome completo do projeto: o projeto Google Cloud que contém o conjunto de dados do BigQuery de origem.
   • Links relacionados, incluindo:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

3. Para mais informações, clique na guia JSON.

4. No JSON, observe os seguintes campos.

   • sourceProperties:
     • evidence:
       • sourceLogId:
       • projectId: o projeto Google Cloud que contém o conjunto de dados de origem do BigQuery.
     • properties:
       • extractionAttempt:
       • jobLink: o link para o job do BigQuery que exfiltrou dados;

Etapa 2: verificar as permissões e configurações

1. No console Google Cloud , acesse a página IAM.

   Acessar IAM

2. Se necessário, selecione o projeto listado no campo projectId no JSON de descoberta (da Etapa 1).

3. Na página exibida, na caixa Filtro, digite o endereço de e-mail listado em access.principalEmail (da Etapa 1) e verifique as permissões que estão atribuídas à conta.

Etapa 3: verificar os registros

1. Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
2. Encontre registros de atividades do administrador relacionados a jobs do BigQuery usando estes filtros:
   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Etapa 4: pesquisar métodos de ataque e resposta

1. Verifique a entrada do framework do MITRE ATT&CK em busca deste tipo de descoberta: Exfiltração por serviço da Web: exfiltração para o Cloud Storage.
2. Verifique as descobertas relacionadas clicando no link em Descobertas relacionadas na linha Descobertas relacionadas na guia Resumo dos detalhes da descoberta. As descobertas relacionadas são o mesmo tipo de descoberta na mesma instância e rede.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 5: 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 pertence com dados exfiltrado.
• Considere revogar as permissões do principal no campo access.principalEmail até que a investigação seja concluída.
• Para interromper a exfiltração, adicione políticas do IAM restritivas aos conjuntos de dados do BigQuery afetados (exfiltration.sources).
• Para verificar se há conjuntos de dados de informações sensíveis, use a Proteção de dados confidenciais. Também é possível enviar dados sensíveis de proteção de dados para o Security Command Center. Dependendo da quantidade de informações, os custos da proteção de dados sensíveis podem ser significativos. Siga as práticas recomendadas para manter os custos de proteção de dados sensíveis sob controle.
• Para limitar o acesso à API BigQuery, use o VPC Service Controls.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Exfiltration: Cloud SQL Data Exfiltration

A exfiltração de dados do Cloud SQL é detectada examinando registros de auditoria para dois cenários:

• Dados de instâncias ativas exportados para um bucket do Cloud Storage fora da organização.
• Dados de instâncias ativas exportados para um bucket do Cloud Storage de propriedade da organização e acessível publicamente.

Todos os tipos de instâncias do Cloud SQL têm suporte.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Exfiltration: Cloud SQL Data Exfiltration, 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:
     • E-mail principal: a conta usada para exfiltrar os dados.
     • Origens de exfiltração: detalhes sobre a instância do Cloud SQL com dados exfiltrados.
     • Destinos de exfiltração: detalhes sobre o bucket do Cloud Storage para o qual os dados foram exportados.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome completo do recurso: o nome do recurso do Cloud SQL com dados exfiltrados.
     • Nome completo do projeto: o projeto do Google Cloud que contém os dados de origem do Cloud SQL.
   • Links relacionados, incluindo:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

3. Clique na guia JSON.

4. No JSON da descoberta, observe os seguintes campos:

   • sourceProperties:
     • evidence:
     • sourceLogId:
       • projectId: o projeto Google Cloud que contém a instância de origem do Cloud SQL.
     • properties
     • bucketAccess: se o bucket do Cloud Storage for acessível publicamente ou externo à organização
     • exportScope: a quantidade de dados exportados (por exemplo, toda a instância, um ou mais bancos de dados, uma ou mais tabelas ou um subconjunto especificado por uma consulta).

Etapa 2: verificar as permissões e configurações

1. No console Google Cloud , acesse a página IAM.

   Acessar IAM

2. Se necessário, selecione o projeto da instância listada no campo projectId no JSON de descoberta (da Etapa 1).

3. Na página exibida, na caixa Filtro, insira o endereço de e-mail listado na linha E-mail principal na guia Resumo dos detalhes da descoberta (da Etapa 1). Verifique quais permissões estão atribuídas à conta.

Etapa 3: verificar os registros

1. No console do Google Cloud , acesse o Explorador de registros clicando no link em URI do Cloud Logging (da Etapa 1). A página Explorador de registros inclui todos os registros relacionados à instância relevante do Cloud SQL.

Etapa 4: pesquisar métodos de ataque e resposta

1. Verifique a entrada do framework do MITRE ATT&CK em busca deste tipo de descoberta: Exfiltração por serviço da Web: exfiltração para o Cloud Storage.
2. Clique no link da linha Descobertas relacionadas descrita na Etapa 1 para revisar as descobertas relacionadas. As descobertas relacionadas têm o mesmo tipo de descoberta na mesma instância do Cloud SQL.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 5: 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 pertence com dados exfiltrado.
• Considere revogar as permissões de access.principalEmail até que a investigação seja concluída.
• Para interromper a exfiltração ainda mais, adicione políticas restritivas do IAM às instâncias afetadas do Cloud SQL.
  • MySQL
  • PostgreSQL
  • SQL Server
• Para limitar o acesso e a exportação da API Cloud SQL Admin, use o VPC Service Controls.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Exfiltration: Cloud SQL Over-Privileged Grant

Detecta quando todos os privilégios sobre um banco de dados PostgreSQL (ou todas as funções ou procedimentos em um banco de dados) são concedidos a um ou mais usuários de banco de dados.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Exfiltration: Cloud SQL Over-Privileged Grant, conforme instruído em Como verificar descobertas.

2. Na guia Resumo do painel de detalhes da descoberta, revise as informações nas seguintes seções:

   • O que foi detectado, especialmente os seguintes campos:
     • Nome de exibição do banco de dados: o nome do banco de dados na instância do PostgreSQL do Cloud SQL que foi afetada.
     • Nome de usuário do banco de dados: o usuário do PostgreSQL que concedeu privilégios demais.
     • Consulta do banco de dados: a consulta do PostgreSQL executada que concedeu os privilégios.
     • Beneficiários do banco de dados: os beneficiários dos privilégios excessivos.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome completo do recurso: o nome do recurso da instância do PostgreSQL do Cloud SQL que foi afetado.
     • Nome completo do pai: o nome do recurso da instância do PostgreSQL do Cloud SQL.
     • Nome completo do projeto: o projeto Google Cloud que contém a instância do PostgreSQL do Cloud SQL.
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

3. Para ver o JSON completo da descoberta, clique na guia JSON.

Etapa 2: analisar os privilégios do banco de dados

1. Conecte-se ao banco de dados PostgreSQL.
2. Liste e mostre privilégios de acesso para o seguinte:
   • Bancos de dados. Use o metacomando \l ou \list e verifique quais privilégios são atribuídos ao banco de dados listado em Nome de exibição do banco de dados (na Etapa 1).
   • Funções ou procedimentos. Use o metacomando \df e verifique quais privilégios são atribuídos a funções ou procedimentos no banco de dados listado em Nome de exibição do banco de dados (na Etapa 1).

Etapa 3: verificar os registros

1. No console do Google Cloud , acesse o Explorador de registros clicando no link em URI do Cloud Logging (da Etapa 1). A página Explorador de registros inclui todos os registros relacionados à instância relevante do Cloud SQL.
2. No Explorador de registros, verifique os registros pgaudit do PostgreSQL, que registram consultas executadas no banco de dados, usando os seguintes filtros:
   • protoPayload.request.database="var class="edit">database"

Etapa 4: pesquisar métodos de ataque e resposta

1. Revise a entrada do framework MITRE ATT&CK para esse tipo de descoberta: Exfiltration Over Web Service (Exfiltração sobre o serviço da Web).
2. Para determinar se outras etapas de correção são necessárias, combine seus resultados da investigação com a pesquisa do MITRE.

Etapa 5: 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 com o proprietário da instância com concessões privilegiadas em excesso.
• Considere revogar todas as permissões dos usuários listados em Beneficiários do banco de dados até que a investigação seja concluída.
• Para limitar o acesso ao banco de dados (no Nome de exibição do banco de dados da Etapa 1), revogue permissões desnecessárias dos beneficiários (em Beneficiários do banco de dados da Etapa 1).

Exfiltration: Cloud SQL Restore Backup to External Organization

A exfiltração de dados de um backup do Cloud SQL é detectada por análise de registros de auditoria para determinar se os dados do backup foram restaurados para uma instância do Cloud SQL fora da organização ou projeto. Todos os tipos de backup e instância do Cloud SQL são compatíveis.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Exfiltration: Cloud SQL Restore Backup to External Organization, conforme direcionado em Como verificar descobertas.

2. Na guia Resumo do painel de detalhes da descoberta, revise as informações nas seguintes seções:

   • O que foi detectado, especialmente os seguintes campos:
     • E-mail principal: a conta usada para exfiltrar os dados.
     • Origens de exfiltração: detalhes sobre a instância do Cloud SQL em que o backup foi criado.
     • Destinos de exfiltração: detalhes sobre a instância do Cloud SQL para a qual os dados de backup foram restaurados.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome completo do recurso: o nome do recurso do backup que foi restaurado.
     • Nome completo do projeto: o projeto Google Cloud que contém a instância do Cloud SQL em que o backup foi criado.

3. Links relacionados, principalmente os seguintes campos:

   • URI do Cloud Logging: link para as entradas do Logging.
   • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
   • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

4. Clique na guia JSON.

5. No JSON, observe os seguintes campos.

   • resource:
     • parent_name: o nome do recurso da instância do Cloud SQL em que o backup foi criado;
   • evidence:
     • sourceLogId:
       • projectId: o projeto Google Cloud que contém o conjunto de dados de origem do BigQuery.
   • properties:
     • restoreToExternalInstance:
       • backupId: o ID da execução de backup que foi restaurada;

Etapa 2: verificar as permissões e configurações

1. No console Google Cloud , acesse a página IAM.

   Acessar IAM

2. Se necessário, selecione o projeto da instância listada no campo projectId no JSON de descoberta (da Etapa 1).

3. Na página exibida, na caixa Filtro, digite o endereço de e-mail listado no e-mail principal (da Etapa 1) e verifique as permissões que estão atribuídas à conta.

Etapa 3: verificar os registros

1. No console do Google Cloud , acesse o Explorador de registros clicando no link em URI do Cloud Logging (da Etapa 1). A página Explorador de registros inclui todos os registros relacionados à instância relevante do Cloud SQL.

Etapa 4: pesquisar métodos de ataque e resposta

1. Verifique a entrada do framework do MITRE ATT&CK em busca deste tipo de descoberta: Exfiltração por serviço da Web: exfiltração para o Cloud Storage.
2. Clique no link da linha Descobertas relacionadas para revisar as descobertas relacionadas. Na Etapa 1. As descobertas relacionadas têm o mesmo tipo de descoberta na mesma instância do Cloud SQL.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 5: 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 pertence com dados exfiltrado.
• Considere revogar as permissões que o principal está listado na linha E-mail principal na guia Resumo dos detalhes da descoberta até que a investigação seja concluída.
• Para interromper a exfiltração ainda mais, adicione políticas restritivas do IAM às instâncias afetadas do Cloud SQL.
  • MySQL
  • PostgreSQL
  • SQL Server
• Para limitar o acesso à API Cloud SQL Admin, use o VPC Service Controls.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Impact: Cryptomining Commands

Detecta quando comandos conhecidos de mineração de criptomoedas são transmitidos para jobs do Cloud Run como pontos de entrada que serão executados quando o job for executado.

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

1. Verifique o job, o comando e o contêiner para determinar se isso era esperado.
2. Exclua o job e o contêiner comprometidos.

Impact: Deleted Google Cloud Backup and DR Backup

A detecção de ameaças a eventos examina registros de auditoria para detectar se um backup armazenado em um cofre de backup foi excluído.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Impact: Deleted Google Cloud Backup and DR Backup, conforme instruído 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:
     • Descrição: informações sobre a detecção.
     • Assunto principal: um usuário ou uma conta de serviço que executou uma ação com sucesso.
   • Recurso afetado
     • Nome de exibição do recurso: o projeto em que a frequência de backup foi reduzida.
   • Links relacionados, principalmente os seguintes campos:
     • Método MITRE ATTACK: link para a documentação do MITRE ATT&CK.
     • URI do Logging: link para abrir a Análise de registros.

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço no campo Assunto principal e confirme se foi essa pessoa que realizou a ação.

Impact: Deleted Google Cloud Backup and DR host

A detecção de ameaças a eventos examina registros de auditoria para detectar a exclusão de hosts que executam aplicativos protegidos pelo serviço de backup e DR. Depois que um host é excluído, não é possível fazer backup dos aplicativos associados a ele.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Impact: Deleted Google Cloud Backup and DR host, conforme instruído 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:
     • Nome do aplicativo: o nome de um banco de dados ou VM conectado ao backup e DR
     • Nome do host: o nome de um host conectado ao backup e DR
     • Assunto principal: um usuário que executou uma ação com sucesso
   • Recurso afetado
     • Nome de exibição do recurso: o projeto do qual o host foi excluído.
   • Links relacionados, principalmente os seguintes campos:
     • Método MITRE ATTACK: link para a documentação do MITRE ATT&CK
     • URI do Logging: link para abrir a Análise de registros

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: implementar a resposta

O plano de resposta a seguir pode ser apropriado para esta descoberta. Avalie cuidadosamente as informações coletadas na investigação para determinar a melhor maneira de resolver as descobertas.

1. No projeto em que a ação foi realizada, acesse o console de gerenciamento.
2. Confirme se o host excluído não está mais na lista de hosts de backup e DR.
3. Selecione a opção Adicionar host para adicionar novamente o host excluído.

Impact: Deleted Google Cloud Backup and DR plan association

A Detecção de ameaças a eventos examina os registros de auditoria para detectar se uma associação de plano foi excluída.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Impact: Deleted Google Cloud Backup and DR plan association, conforme instruído 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:
     • Descrição: informações sobre a detecção.
     • Assunto principal: um usuário ou uma conta de serviço que executou uma ação com sucesso.
   • Recurso afetado
     • Nome de exibição do recurso: o projeto em que a frequência de backup foi reduzida.
   • Links relacionados, principalmente os seguintes campos:
     • Método MITRE ATTACK: link para a documentação do MITRE ATT&CK.
     • URI do Logging: link para abrir a Análise de registros.

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço no campo Assunto principal e confirme se foi essa pessoa que realizou a ação.

Impact: Deleted Google Cloud Backup and DR Vault

A detecção de ameaças a eventos examina os registros de auditoria para detectar se o cofre de backup foi excluído.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Impact: Google Cloud Backup and DR reduced backup frequency, conforme instruído 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:
     • Descrição: informações sobre a detecção.
     • Assunto principal: um usuário ou uma conta de serviço que executou uma ação com sucesso.
   • Recurso afetado
     • Nome de exibição do recurso: o projeto em que a frequência de backup foi reduzida.
   • Links relacionados, principalmente os seguintes campos:
     • Método MITRE ATTACK: link para a documentação do MITRE ATT&CK.
     • URI do Logging: link para abrir a Análise de registros.

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço no campo Assunto principal. Confirme se o proprietário legítimo realizou a ação.

Impact: GKE kube-dns modification detected

Alguém modificou a configuração do kube-dns no seu cluster do GKE. O kube-dns do GKE é um componente essencial da rede do cluster, e uma configuração incorreta pode levar a uma violação de segurança.

1. Revise a configuração do kube-dns do cluster para identificar mudanças suspeitas.

Impact: Google Cloud Backup and DR delete policy

Os registros de auditoria são examinados para detectar a exclusão de uma política. Uma política define como um backup é feito e onde ele é armazenado.

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Impact: Google Cloud Backup and DR delete policy, conforme instruído 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:
     • Nome da política: o nome de uma única política, que define a frequência, a programação e o tempo de retenção do backup
     • Assunto principal: um usuário que executou uma ação com sucesso
   • Recurso afetado
     • Nome de exibição do recurso: o projeto do qual a política foi excluída.
   • Links relacionados, principalmente os seguintes campos:
     • Método MITRE ATTACK: link para a documentação do MITRE ATT&CK
     • URI do Logging: link para abrir a Análise de registros.

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: implementar a resposta

O plano de resposta a seguir pode ser apropriado para esta descoberta. Avalie cuidadosamente as informações coletadas na investigação para determinar a melhor maneira de resolver as descobertas. 1. No projeto em que a ação foi realizada, acesse o console de gerenciamento. 2. Na guia App Manager, selecione o aplicativo afetado e analise as configurações de Política aplicadas a ele.

Impact: Google Cloud Backup and DR delete profile

Os registros de auditoria são examinados para detectar a exclusão de um perfil. Um perfil define quais pools de armazenamento são usados para armazenar backups.

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Impact: Google Cloud Backup and DR delete profile, conforme instruído 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:
     • Nome do perfil: especifica o destino de armazenamento para backups de dados de aplicativo e VM.
     • Assunto principal: um usuário que executou uma ação com sucesso
   • Recurso afetado
     • Nome de exibição do recurso: o projeto do qual o perfil foi excluído
   • Links relacionados, principalmente os seguintes campos:
     • Método MITRE ATTACK: link para a documentação do MITRE ATT&CK
     • URI do Logging: link para abrir a Análise de registros

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: implementar a resposta

O plano de resposta a seguir pode ser apropriado para esta descoberta. Avalie cuidadosamente as informações coletadas na investigação para determinar a melhor maneira de resolver as descobertas. 1. No projeto em que a ação foi realizada, acesse o console de gerenciamento. 2. Na guia Planos de backup, selecione Perfis para ver uma lista com todos os perfis. 3. Confira se todos os perfis obrigatórios estão em vigor. 4. Se o perfil excluído foi removido por engano, selecione Criar perfil para definir destinos de armazenamento para seus dispositivos de backup e DR.

Impact: Google Cloud Backup and DR delete template

O Security Command Center examina registros de auditoria para detectar a exclusão anômala de um modelo. Um modelo é uma configuração básica de backups que pode ser aplicada a vários aplicativos.

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Impact: Google Cloud Backup and DR delete template, conforme instruído 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:
     • Nome do modelo: o nome de um conjunto de políticas que definem a frequência, a programação e o tempo de retenção do backup
     • Assunto principal: um usuário que executou uma ação com sucesso
   • Recurso afetado
     • Nome de exibição do recurso: o projeto do qual o modelo foi excluído.
   • Links relacionados, principalmente os seguintes campos:
     • Método MITRE ATTACK: link para a documentação do MITRE ATT&CK
     • URI do Logging: link para abrir a Análise de registros

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: implementar a resposta

O plano de resposta a seguir pode ser apropriado para esta descoberta. Avalie cuidadosamente as informações coletadas na investigação para determinar a melhor maneira de resolver as descobertas.

1. No projeto em que a ação foi realizada, acesse o console de gerenciamento.
2. Na guia App Manager, encontre os aplicativos afetados que não estão mais protegidos e analise as políticas de backup de cada um.
3. Para adicionar novamente um modelo, acesse a guia Planos de backup, selecione Modelos e a opção Criar modelo.

Impact: Google Cloud Backup and DR delete storage pool

Os registros de auditoria são examinados para detectar a exclusão de um pool de armazenamento. Um pool de armazenamento associa um bucket do Cloud Storage ao backup e DR.

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Impact: Google Cloud Backup and DR delete storage pool, conforme instruído 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:
     • Nome do pool de armazenamento: o nome dos buckets de armazenamento em que os backups são armazenados.
     • Assunto principal: um usuário que executou uma ação com sucesso
   • Recurso afetado
     • Nome de exibição do recurso: o projeto do qual o pool de armazenamento foi excluído.
   • Links relacionados, principalmente os seguintes campos:
     • Método MITRE ATTACK: link para a documentação do MITRE ATT&CK
     • URI do Logging: link para abrir a Análise de registros

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: implementar a resposta

O plano de resposta a seguir pode ser apropriado para esta descoberta. Avalie cuidadosamente as informações coletadas na investigação para determinar a melhor maneira de resolver as descobertas. 1. No projeto em que a ação foi realizada, acesse o console de gerenciamento. 2. Na guia "Gerenciar", selecione Pools de armazenamento para ver uma lista de todos os pools de armazenamento. 3. Revise as associações de pools de armazenamento com os dispositivos de backup. 4. Se um dispositivo ativo não tiver um pool de armazenamento associado, selecione Adicionar pool do OnVault para adicionar novamente.

Impact: Google Cloud Backup and DR expire all images

Um usuário potencialmente mal-intencionado solicitou a exclusão de todas as imagens de backup associadas a um aplicativo.

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Impact: Google Cloud Backup and DR expire all images, conforme instruído 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:
     • Nome da política: o nome de uma única política, que define a frequência, a programação e o tempo de retenção do backup
     • Nome do modelo: o nome de um conjunto de políticas que definem a frequência, a programação e o tempo de retenção do backup
     • Nome do perfil: especifica o destino de armazenamento para backups de dados de aplicativo e VM.
     • Assunto principal: um usuário que executou uma ação com sucesso
   • Recurso afetado
     • Nome de exibição do recurso: o projeto do qual as imagens de backup foram excluídas.
   • Links relacionados, principalmente os seguintes campos:
     • Método MITRE ATTACK: link para a documentação do MITRE ATT&CK
     • URI do Logging: link para abrir a Análise de registros.

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: implementar a resposta

O plano de resposta a seguir pode ser apropriado para esta descoberta. Avalie cuidadosamente as informações coletadas na investigação para determinar a melhor maneira de resolver as descobertas. 1. No projeto em que a ação foi realizada, acesse o console de gerenciamento. 2. Navegue até a guia "Monitor" e selecione "Jobs" para conferir o status do job de exclusão de backup. 3. Se um job de exclusão não for autorizado, acesse as permissões do IAM para conferir os usuários com acesso aos dados de backup.

Impact: Google Cloud Backup and DR expire image

Um usuário potencialmente mal-intencionado solicitou a exclusão de uma imagem de backup.

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Inhibit System Recovery: Google Cloud Backup and DR expire image, conforme instruído 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:
     • Nome da política: o nome de uma única política, que define a frequência, a programação e o tempo de retenção do backup
     • Nome do modelo: o nome de um conjunto de políticas que definem a frequência, a programação e o tempo de retenção do backup
     • Nome do perfil: especifica o destino de armazenamento para backups de dados de aplicativo e VM.
     • Assunto principal: um usuário que executou uma ação com sucesso
   • Recurso afetado
     • Nome de exibição do recurso: o projeto do qual a imagem de backup foi excluída.
   • Links relacionados, principalmente os seguintes campos:
     • Método MITRE ATTACK: link para a documentação do MITRE ATT&CK
     • URI do Logging: link para abrir a Análise de registros

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: implementar a resposta

O plano de resposta a seguir pode ser apropriado para esta descoberta. Avalie cuidadosamente as informações coletadas na investigação para determinar a melhor maneira de resolver as descobertas. 1. No projeto em que a ação foi realizada, acesse o console de gerenciamento. 2. Navegue até a guia "Monitor" e selecione "Jobs" para conferir o status do job de exclusão de backup. 3. Se um job de exclusão não for autorizado, acesse as permissões do IAM para conferir os usuários com acesso aos dados de backup.

Impact: Google Cloud Backup and DR reduced backup expiration

A detecção de ameaças a eventos examina os registros de auditoria para detectar se a data de expiração de um backup em um dispositivo do serviço de backup e DR foi reduzida.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Impact: Google Cloud Backup and DR reduced backup expiration, conforme instruído 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:
     • Descrição: informações sobre a detecção
     • Assunto principal: um usuário ou uma conta de serviço que executou uma ação com sucesso
   • Recurso afetado
     • Nome de exibição do recurso: o projeto em que a expiração do backup foi reduzida.
   • Links relacionados, principalmente os seguintes campos:
     • Método MITRE ATTACK: link para a documentação do MITRE ATT&CK.
     • URI do Logging: link para abrir a Análise de registros.

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço no campo Assunto principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: implementar a resposta

O plano de resposta a seguir pode ser apropriado para esta descoberta. Avalie cuidadosamente as informações coletadas na investigação para determinar a melhor maneira de resolver as descobertas.

1. No projeto em que a ação foi realizada, acesse o console de gerenciamento.
2. Na guia App Manager, encontre o aplicativo afetado em que a expiração do backup foi reduzida e verifique se a expiração foi intencional pelo principal.
3. Para iniciar um novo backup do aplicativo, selecione Gerenciar configurações de backup para criar um backup sob demanda ou agendar um novo backup.

Impact: Google Cloud Backup and DR reduced backup frequency

A detecção de ameaças de eventos examina os registros de auditoria para detectar se o plano de backup foi modificado para reduzir a frequência de backup.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Impact: Google Cloud Backup and DR reduced backup frequency, conforme instruído 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:
     • Descrição: informações sobre a detecção
     • Assunto principal: um usuário ou uma conta de serviço que executou uma ação com sucesso
   • Recurso afetado
     • Nome de exibição do recurso: o projeto em que a frequência de backup foi reduzida.
   • Links relacionados, principalmente os seguintes campos:
     • Método MITRE ATTACK: link para a documentação do MITRE ATT&CK.
     • URI do Logging: link para abrir a Análise de registros.

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço no campo Assunto principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: implementar a resposta

O plano de resposta a seguir pode ser apropriado para esta descoberta. Avalie cuidadosamente as informações coletadas na investigação para determinar a melhor maneira de resolver as descobertas.

1. No projeto em que a ação foi realizada, acesse o console de gerenciamento.
2. Na guia App Manager, encontre o aplicativo afetado cuja frequência de backup foi reduzida e verifique se a mudança foi intencional.
3. Para iniciar um novo backup do aplicativo, selecione Gerenciar configurações de backup para criar um backup sob demanda ou agendar um novo backup.

Impact: Google Cloud Backup and DR remove appliance

Os registros de auditoria são examinados para detectar a remoção de um dispositivo de backup e recuperação. Um dispositivo de backup e recuperação é um componente essencial para operações de backup.

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Inhibit System Recovery: Google Cloud Backup and DR remove appliance, conforme instruído 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:
     • Nome do dispositivo: o nome de um banco de dados ou VM conectado ao backup e DR
     • Assunto principal: um usuário que executou uma ação com sucesso
   • Recurso afetado
     • Nome de exibição do recurso: o projeto do qual o dispositivo foi excluído.
   • Links relacionados, principalmente os seguintes campos:
     • Método MITRE ATTACK: link para a documentação do MITRE ATT&CK
     • URI do Logging: link para abrir a Análise de registros

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: implementar a resposta

O plano de resposta a seguir pode ser apropriado para esta descoberta. Avalie cuidadosamente as informações coletadas na investigação para determinar a melhor maneira de resolver as descobertas. 1. No projeto em que a ação foi realizada, acesse o console de gerenciamento. 2. Na guia App Manager, encontre os aplicativos afetados que não estão mais protegidos e analise as políticas de backup de cada um. 3. Para criar um novo dispositivo e aplicar proteções novamente a apps desprotegidos, navegue até "Backup e DR" no console Google Cloud e selecione a opção "Implantar outro dispositivo de backup ou recuperação". 4. No menu Armazenamento, configure cada novo dispositivo com um destino de armazenamento. Após a configuração de um dispositivo, ele aparecerá como uma opção quando você criar um perfil para seus aplicativos.

Impact: Google Cloud Backup and DR remove plan

O Security Command Center examina registros de auditoria para detectar a exclusão anômala de um plano de backup do serviço de backup e DR usado para aplicar políticas de backup a um aplicativo.

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Impact: Google Cloud Backup and DR remove plan, conforme instruído 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:
     • Nome do aplicativo: o nome de um banco de dados ou VM conectado ao backup e DR
     • Nome do perfil: especifica o destino de armazenamento para backups de dados de aplicativo e VM.
     • Nome do modelo: o nome de um conjunto de políticas que definem a frequência, a programação e o tempo de retenção do backup
   • Recurso afetado
     • Nome de exibição do recurso: o projeto do qual o plano foi excluído.
   • Links relacionados, principalmente os seguintes campos:
     • Método MITRE ATTACK: link para a documentação do MITRE ATT&CK
     • URI do Logging: link para abrir a Análise de registros

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: implementar a resposta

O plano de resposta a seguir pode ser apropriado para esta descoberta. Avalie cuidadosamente as informações coletadas na investigação para determinar a melhor maneira de resolver as descobertas.

1. No projeto em que a ação foi realizada, acesse o console de gerenciamento.
2. Na guia App Manager, encontre os aplicativos afetados que não estão mais protegidos e analise as políticas de backup de cada um.

Impact: Suspicious Kubernetes Container Names - Cryptocurrency Mining

Alguém implantou um pod com uma convenção de nomenclatura parecida com a dos mineradores de moedas de criptomoedas comuns. Isso pode ser uma tentativa de um invasor que obteve acesso inicial ao cluster para usar os recursos dele na mineração de criptomoedas. Para mais detalhes, consulte a mensagem de registro desse alerta.

1. Confirme se o pod é legítimo.
2. Determine se há outros sinais de atividade maliciosa do pod ou principal nos registros de auditoria no Cloud Logging.
3. Se o principal não for uma conta de serviço (IAM ou Kubernetes), entre em contato com o proprietário da conta para confirmar se foi essa pessoa que realizou a ação.
4. Se o principal for uma conta de serviço (IAM ou Kubernetes), identifique a origem da ação para determinar a legitimidade.
5. Se o pod não for legítimo, remova-o com as vinculações do controle de acesso baseado em função (RBAC) e as contas de serviço associadas que a carga de trabalho usou e que permitiram a criação dele.

Initial Access: Anonymous GKE resource created from the internet

Detecta quando um agente potencialmente malicioso usou um dos seguintes usuários ou grupos de usuários padrão do Kubernetes para criar um novo recurso do Kubernetes no cluster:

• system:anonymous
• system:authenticated
• system:unauthenticated

Esses usuários e grupos são efetivamente anônimos. Uma vinculação de controle de acesso baseado em papéis (RBAC) no cluster concedeu a esse usuário permissão para criar esses recursos no cluster.

Revise o recurso criado e a vinculação de RBAC associada para garantir que ela seja necessária. Se não for necessário, remova a vinculação. Para mais detalhes, consulte a mensagem de registro dessa descoberta.

Para resolver esse problema, consulte Evitar papéis e grupos padrão.

Initial Access: CloudDB Successful login from Anonymizing Proxy IP

Detecta um login bem-sucedido na instância de banco de dados de um endereço IP de anonimização conhecido. Esses endereços de anonimização são nós do Tor. Isso pode indicar que um invasor conseguiu acesso inicial à sua instância.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Initial Access: CloudDB Successful login from Anonymizing Proxy IP, conforme direcionado em Como verificar descobertas.

2. Na guia Resumo do painel de detalhes da descoberta, revise as informações nas seguintes seções:

   • O que foi detectado, especialmente os seguintes campos:
   • Endereço IP do indicador, o endereço IP de anonimização.
   • Nome de exibição do banco de dados: o nome do banco de dados na instância do PostgreSQL, MySQL ou AlloyDB do Cloud SQL que foi afetada.
   • Nome de usuário do banco de dados: o usuário.
   • Nome completo do projeto: o projeto do Google Cloud que contém a instância do Cloud SQL.

Etapa 2: pesquisar métodos de ataque e resposta

1. Analise a entrada do framework MITRE ATT&CK para esse tipo de descoberta: Acesso inicial.
2. Para determinar se outras etapas de correção são necessárias, combine seus resultados da investigação com a pesquisa do MITRE.

Etapa 3: 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.

• Analise os usuários autorizados a se conectar ao banco de dados.

  • Para o PostgreSQL, consulte Criar e gerenciar usuários
  • Para o MySQL, consulte Gerenciar usuários com a autenticação integrada

• Considere mudar a senha do usuário.

  • Para PostgreSQL, consulte Definir a senha do usuário padrão

  • Para o MySQL, consulte Definir a senha do usuário padrão

  • Atualize as credenciais dos clientes que se conectam à instância do Cloud SQL.

Initial Access: Database Superuser Writes to User Tables

Detecta quando a conta de superusuário do banco de dados do Cloud SQL (postgres para PostgreSQL e root para MySQL) grava em tabelas de usuários. O superusuário (uma função com acesso muito amplo) geralmente não deve ser usado para gravar em tabelas de usuários. Uma conta de usuário com acesso mais limitado deve ser usada para atividades diárias normais. Quando um superusuário grava em uma tabela de usuários, isso pode indicar que um invasor ampliou os privilégios ou comprometeu o usuário padrão do banco de dados e está modificando dados. Também pode indicar práticas normais, mas inseguras.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Initial Access: Database Superuser Writes to User Tables, conforme direcionado em Como verificar descobertas.

2. Na guia Resumo do painel de detalhes da descoberta, revise as informações nas seguintes seções:

   • O que foi detectado, especialmente os seguintes campos:
     • Nome de exibição do banco de dados: o nome do banco de dados na instância do PostgreSQL ou MySQL do Cloud SQL que foi afetada.
     • Nome de usuário do banco de dados: o superusuário.
     • Consulta de banco de dados: a consulta SQL executada ao gravar em tabelas de usuários.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome completo do recurso: o nome do recurso da instância do Cloud SQL que foi afetada.
     • Nome completo do pai: o nome do recurso da instância do Cloud SQL.
     • Nome completo do projeto: o projeto Google Cloud que contém a instância do Cloud SQL.
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

3. Para ver o JSON completo da descoberta, clique na guia JSON.

Etapa 2: verificar os registros

1. No console Google Cloud , acesse o Explorador de registros clicando no link em cloudLoggingQueryURI (da Etapa 1). A página Explorador de registros inclui todos os registros relacionados à instância relevante do Cloud SQL.
2. Verifique os registros pgaudit do PostgreSQL ou os registros de auditoria do Cloud SQL para MySQL, que contêm as consultas executadas pelo superusuário, usando os seguintes filtros:
   • protoPayload.request.user="SUPERUSER"

Etapa 3: pesquisar métodos de ataque e resposta

1. Revise a entrada do framework MITRE ATT&CK para esse tipo de descoberta: Exfiltration Over Web Service (Exfiltração sobre o serviço da Web).
2. Para determinar se outras etapas de correção são necessárias, combine seus resultados da investigação com a pesquisa do MITRE.

Etapa 4: 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.

• Analise os usuários autorizados a se conectar ao banco de dados.

  • Para o PostgreSQL, consulte Criar e gerenciar usuários
  • Para o MySQL, consulte Gerenciar usuários com a autenticação integrada

• Considere mudar a senha do superusuário.

  • Para PostgreSQL, consulte Definir a senha do usuário padrão
  • Para o MySQL, consulte Definir a senha do usuário padrão

• Considere criar um usuário novo com acesso limitado para os diferentes tipos de consultas usadas na instância.

  • Conceda ao novo usuário apenas as permissões necessárias para executar as consultas.

    • Para PostgreSQL, consulte Grant (comando).
    • Para o MySQL, consulte Controle de acesso e gerenciamento de contas

  • Atualize as credenciais dos clientes que se conectam à instância do Cloud SQL.

Initial Access: Dormant Service Account Action

Detecta eventos em que uma conta de serviço gerenciada pelo usuário inativa acionou uma ação. Nesse contexto, uma conta de serviço é considerada inativa se estiver inativa por mais de 180 dias.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Initial Access: Dormant Service Account Action, conforme instruído em Como verificar descobertas.

2. Nos detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:

   Em O que foi detectado:

   • E-mail principal: a conta de serviço inativa que realizou a ação
   • Nome do serviço: o nome da API do serviço do Google Cloud acessado pela conta de serviço
   • Nome do método: o método que foi chamado

Etapa 2: pesquisar métodos de ataque e resposta

1. Use as ferramentas da conta de serviço, como o Activity Analyzer, para investigar a atividade da conta de serviço inativa.
2. Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: 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 com o proprietário do projeto em que a ação foi realizada.
• Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os aplicativos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os aplicativos afetados e trabalhar com os proprietários do aplicativo para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do suporte do Google Cloud .
• Para limitar quem pode criar contas de serviço, use o serviço de Política da organização.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Initial Access: Dormant Service Account Activity in AI Service

Detecta eventos em que uma conta serviço gerenciado pelo usuário inativa acionou uma ação em um serviço de IA. Nesse contexto, uma conta de serviço é considerada inativa se estiver inativa por mais de 180 dias.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Initial Access: Dormant Service Account Activity in AI Service, conforme instruído em Como verificar descobertas.

2. Nos detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:

   Em O que foi detectado:

   • E-mail principal: a conta de serviço inativa que realizou a ação
   • Nome do método: o método que foi chamado
   • Recursos de IA: os recursos de IA potencialmente afetados, como os recursos da Vertex AI e o modelo de IA.

Etapa 2: pesquisar métodos de ataque e resposta

1. Use as ferramentas da conta de serviço, como o Activity Analyzer, para investigar a atividade da conta de serviço inativa.
2. Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: 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 com o proprietário do projeto em que a ação foi realizada.
• Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os aplicativos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os aplicativos afetados e trabalhar com os proprietários do aplicativo para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do Cloud Customer Care.
• Para limitar quem pode criar contas de serviço, use o serviço de Política da organização.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Initial Access: Dormant Service Account Key Created

Detecta eventos em que ocorre a criação de chave em uma conta de serviço gerenciada pelo usuário inativa. Nesse contexto, uma conta de serviço é considerada inativa se estiver inativa por mais de 180 dias.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Initial Access: Dormant Service Account Key Created, conforme instruído em Como verificar descobertas.

2. Nos detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:

   Em O que foi detectado:

   • E-mail principal: o usuário que criou a chave da conta de serviço

   Em Recurso afetado:

   • Nome de exibição do recurso: a chave recém-criada da conta de serviço inativa
   • Nome completo do projeto: o projeto em que está a conta de serviço inativa

Etapa 2: pesquisar métodos de ataque e resposta

1. Use as ferramentas da conta de serviço, como o Activity Analyzer, para investigar a atividade da conta de serviço inativa.
2. Entre em contato com o proprietário do campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: 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 com o proprietário do projeto em que a ação foi realizada.
• Remova o acesso do proprietário do E-mail principal se ele estiver comprometido.
• Invalide a chave recém-criada da conta de serviço na página Contas de serviço.
• Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os aplicativos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os aplicativos afetados e trabalhar com os proprietários do aplicativo para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do Cloud Customer Care.
• Para limitar quem pode criar contas de serviço, use o serviço de Política da organização.
• Para identificar e corrigir papéis com permissões em excesso, use o Recomendador do IAM.

Initial Access: Excessive Permission Denied Actions

Detecta eventos em que um principal aciona repetidamente erros de permissão negada em múltiplos métodos e serviços.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Initial Access: Excessive Permission Denied Actions, conforme instruído em Como verificar descobertas.

2. Nos detalhes de descoberta, na guia Resumo, observe os valores dos seguintes campos.

   Em O que foi detectado:

   • E-mail principal: o principal que acionou vários erros de permissão negada
   • Nome do serviço: o nome da API do serviço do Google Cloud em que ocorreu o último erro de permissão negada.
   • Nome do método: o método chamado quando o último erro de permissão negada ocorre.

3. Nos detalhes da descoberta, na guia Propriedades de origem, anote os valores dos seguintes campos no JSON:

   • properties.failedActions: a permissão negou erros que ocorreram. Para cada entrada, os detalhes incluem o nome do serviço, o nome do método, o número de tentativas com falha e a hora em que o erro ocorreu pela última vez. São exibidas no máximo 10 entradas.

Etapa 2: verificar os registros

1. No console Google Cloud , acesse o Explorador de registros clicando no link em URI do Cloud Logging.
2. Na barra de ferramentas do console Google Cloud , selecione seu projeto.

3. Na página carregada, encontre os registros relacionados usando o seguinte filtro:

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
   • protoPayload.status.code=7

   Substitua PRINCIPAL_EMAIL pelo valor que você anotou no campo E-mail do principal nos detalhes da descoberta.

Etapa 3: pesquisar métodos de ataque e resposta

1. Verifique a entrada do framework do MITRE ATT&CK em busca deste tipo de descoberta: Contas válidas: contas do Cloud.
2. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 4: 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 com o proprietário da conta no campo E-mail do principal. Confirme se o proprietário legítimo realizou a ação.
• Exclua recursos do projeto criados por essa conta, como instâncias desconhecidas do Compute Engine, snapshots, contas de serviço e usuários do IAM etc.
• Entre em contato com o proprietário do projeto com a conta e possivelmente exclua ou desative a conta.

Initial Access: GKE NodePort service created

Alguém criou um serviço NodePort. Os serviços NodePort expõem pods diretamente no endereço IP e na porta estática de um nó, o que torna os pods acessíveis de fora do cluster. Isso pode introduzir um risco significativo à segurança, porque permite que um invasor explore vulnerabilidades no serviço exposto para acessar o cluster ou dados sensíveis.

1. Analise a configuração do serviço para determinar a finalidade dele.
2. Considere restringir as políticas de rede para proteger o serviço.

Initial Access: GKE resource modified anonymously from the internet

Detecta quando um agente potencialmente malicioso usou um dos seguintes usuários ou grupos de usuários padrão do Kubernetes para modificar um recurso do Kubernetes no cluster:

• system:anonymous
• system:authenticated
• system:unauthenticated

Esses usuários e grupos são efetivamente anônimos. Uma vinculação de controle de acesso baseado em função (RBAC) no cluster concedeu a esse usuário permissão para modificar esses recursos no cluster.

Revise o recurso modificado e a vinculação de RBAC associada para garantir que ela seja necessária. Se não for necessário, remova a vinculação. Para mais detalhes, consulte a mensagem de registro dessa descoberta.

Para resolver esse problema, consulte Evitar papéis e grupos padrão.

Initial Access: Leaked Service Account Key Used

Detecta eventos em que uma chave de conta de serviço com vazamento é usada para autenticar a ação. Nesse contexto, uma chave da conta de serviço com vazamento foi publicada na Internet pública. Por exemplo, as chaves da conta de serviço geralmente são postadas por engano no repositório público do GitHub.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Initial Access: Leaked Service Account Key Used, conforme instruído em Como verificar descobertas.

2. Nos detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:

   Em O que foi detectado:

   • E-mail principal: a conta de serviço usada nesta ação
   • Nome do serviço: o nome da API do serviço do Google Cloud acessado pela conta de serviço
   • Nome do método: o nome do método da ação
   • Nome da chave da conta de serviço: a chave da conta de serviço com vazamento usada para autenticar a ação
   • Descrição: o que foi detectado, incluindo o local na Internet pública onde a chave da conta de serviço pode ser encontrada

   Em Recurso afetado:

   • Nome de exibição do recurso: o recurso envolvido na ação.

Etapa 2: verificar os registros

1. No console Google Cloud , acesse o Explorador de registros clicando no link em URI do Cloud Logging.
2. Na barra de ferramentas do console Google Cloud , selecione seu projeto ou organização.

3. Na página carregada, encontre os registros relacionados usando o seguinte filtro:

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
   • protoPayload.authenticationInfo.serviceAccountKeyName="SERVICE_ACCOUNT_KEY_NAME"

   Substitua PRINCIPAL_EMAIL pelo valor que você anotou no campo E-mail do principal nos detalhes da descoberta. Substitua SERVICE_ACCOUNT_KEY_NAME pelo valor que você anotou no campo Nome da chave da conta de serviço nos detalhes da descoberta.

Etapa 3: 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.

• Revogue a chave da conta de serviço imediatamente na página Contas de serviço.
• Remova a página da Web ou o repositório do GitHub em que a chave da conta de serviço foi postada.
• Considere excluir a conta de serviço comprometida.
• Alterne e exclua todas as chaves de acesso da conta de serviço do projeto potencialmente comprometido. Após a exclusão, os aplicativos que usam a conta de serviço para autenticação perdem o acesso. Antes de excluir, a equipe de segurança precisa identificar todos os aplicativos afetados e trabalhar com os proprietários do aplicativo para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do Cloud Customer Care.

Initial Access: Log4j Compromise Attempt

Essa descoberta é gerada quando buscas do Java Naming e Directory Interface (JNDI) em cabeçalhos ou parâmetros de URL são detectadas. Essas pesquisas podem indicar tentativas na exploração do Log4Shell. Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Initial Access: Log4j Compromise Attempt, conforme direcionado em Como verificar detalhes da descoberta. 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
   • Recurso afetado
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.
   • Na visualização detalhada da descoberta, clique na guia JSON.

   • No JSON, observe os seguintes campos.

   • properties

     • loadBalancerName: o nome do balanceador de carga que recebeu a pesquisa JNDI
     • requestUrl: o URL da solicitação HTTP. Se presente, contém uma busca JNDI.
     • requestUserAgent: o user agent que enviou a solicitação HTTP. Se presente, contém uma busca JNDI.
     • refererUrl: o URL da página que enviou a solicitação HTTP. Se presente, contém uma busca JNDI.

Etapa 2: verificar os registros

1. No console do Google Cloud , acesse o Explorador de registros clicando no link no campo URI do Cloud Logging da etapa 1.

2. Na página carregada, verifique os campos httpRequest para tokens de string, como ${jndi:ldap://, que podem indicar possíveis tentativas de exploração.

   Consulte CVE-2021-44228: como detectar a exploração do Log4Shell na documentação do Logging para ver strings de exemplo e pesquisar um exemplo de consulta.

Etapa 3: pesquisar métodos de ataque e resposta

1. Analise a entrada do framework da MITRE ATT&CK para esse tipo de descoberta: Explorar aplicativo voltado para o público.
2. Verifique as descobertas relacionadas clicando no link em Descobertas relacionadas na linha Descobertas relacionadas na guia Resumo dos detalhes da descoberta. As descobertas relacionadas são o mesmo tipo de descoberta e a mesma instância e rede.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 4: 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.

• Faça upgrade para a versão mais recente do Log4j2.
• Siga as recomendações doGoogle Cloudpara investigar e responder à vulnerabilidade "Apache Log4j 2".
• Implemente as técnicas recomendadas de mitigação nas vulnerabilidades de segurança do Apache Log4j.
• Se você usa o Google Cloud Armor, implante o cve-canary rule em uma política de segurança nova ou existente do Google Cloud Armor. Saiba mais em Regra do WAF do Google Cloud Armor para ajudar a mitigar a vulnerabilidade do Apache Log4j.

Initial Access: Successful API call made from a TOR proxy IP

Uma chamada de API bem-sucedida foi feita para seu cluster do GKE de um endereço IP associado à rede Tor. O Tor oferece anonimato, que os invasores costumam usar para ocultar a identidade.

1. Investigue a natureza da chamada de API e os recursos acessados.
2. Revise suas políticas de rede e regras de firewall para bloquear o acesso de endereços IP de proxy do Tor.

Lateral Movement: Modified Boot Disk Attached to Instance

Os registros de auditoria são examinados para detectar movimentos suspeitos de disco entre recursos de instâncias do Compute Engine. Um disco de inicialização potencialmente modificado foi anexado ao seu Compute Engine.

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Lateral Movement: Modify Boot Disk Attaching to Instance, conforme instruído em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.

2. Na guia Resumo, observe os valores dos seguintes campos:

   Em O que foi detectado:

   • E-mail principal: a conta de serviço que realizou a ação
   • Nome do serviço: o nome da API do serviço Google Cloud acessado pela conta de serviço
   • Nome do método: o método que foi chamado

Etapa 2: pesquisar métodos de ataque e resposta

1. Use as ferramentas da conta de serviço, como o Activity Analyzer, para investigar a atividade da conta de serviço associada.
2. Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: 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 com o proprietário do projeto em que a ação foi realizada.
• Considere usar a Inicialização segura nas instâncias de VM do Compute Engine.
• Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os aplicativos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os aplicativos afetados e trabalhar com os proprietários do aplicativo para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do suporte do Google Cloud .

Leaked credentials

Essa descoberta não está disponível para ativações no nível do projeto.

Essa descoberta é gerada quando as credenciais da conta de serviço Google Cloud são vazadas acidentalmente on-line ou ficam comprometidas. Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta account_has_leaked_credentials, conforme direcionado em Como verificar detalhes da descoberta. 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
• Recurso afetado

1. Clique na guia Propriedades de origem e anote estes campos:

   • Compromised_account: a conta de serviço possivelmente comprometida;
   • Project_identifier: o projeto que contém as credenciais de conta possivelmente vazadas;
   • URL: o link para o repositório do GitHub.

2. Para ver o JSON completo da descoberta, clique na guia JSON.

Etapa 2: verificar as permissões do projeto e da conta de serviço

1. No console Google Cloud , acesse a página IAM.

   Acessar IAM

2. Se necessário, selecione o projeto listado em Project_identifier.

3. Na página exibida, na caixa Filtro, insira o nome da conta listado em Compromised_account e verifique as permissões atribuídas.

4. No console Google Cloud , acesse a página Contas de serviço.

   Acesse Contas de serviço

5. Na página exibida, na caixa Filtro, insira o nome da conta de serviço comprometida e verifique as chaves da conta de serviço e as datas de criação da chave.

Etapa 3: verificar os registros

1. No console Google Cloud , acesse o Explorador de registros.

   Acessar o Explorador de registros

2. Na barra de ferramentas do console Google Cloud , selecione seu projeto.

3. Na página carregada, verifique os registros em busca de atividades em recursos novos ou atualizados do IAM usando estes filtros:

   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • resource.type="gce_instance" AND log_name="projects/Project_identifier/logs/cloudaudit.googleapis.com%2Factivity"
   • protoPayload.methodName="InsertProjectOwnershipInvite"
   • protoPayload.authenticationInfo.principalEmail="Compromised_account"

Etapa 4: pesquisar métodos de ataque e resposta

1. Verifique a entrada do framework do MITRE ATT&CK em busca deste tipo de descoberta: Contas válidas: contas do Cloud.
2. Verifique as descobertas relacionadas clicando no link em relatedFindingURI. As descobertas relacionadas são o mesmo tipo de descoberta e a mesma instância e rede.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 5: 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 com a pessoa a quem o projeto com as credenciais vazadas pertence.
• Considere excluir a conta de serviço comprometida, bem como rotacionar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os recursos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os recursos afetados e trabalhar com aqueles que detém recursos para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do suporte do Google Cloud .
• Para limitar quem pode criar contas de serviço, use o serviço de Política da organização.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.
• Abra o link URL e exclua as credenciais vazadas. Colete mais informações sobre a conta comprometida e entre em contato com a pessoa a quem a conta pertence.

Malware

O malware é detectado examinando os Registros de fluxo da VPC e os registros do Cloud DNS em busca de conexões com domínios de comando e controle e endereços IP conhecidos. Atualmente, o Event Threat Detection oferece detecção geral de malware (Malware: Bad IP e Malware: Bad Domain) e detectores especialmente para malware relacionado ao Log4j (Log4j Malware: Bad IP e Log4j Malware: Bad Domain).

As etapas a seguir descrevem como investigar e responder a descobertas baseadas em IP. As etapas de remediação são semelhantes às descobertas baseadas em domínio.

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta de malware relevante. As etapas a seguir usam a descoberta Malware: Bad IP, conforme indicado em Como revisar 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:
     • Domínio indicador: para descobertas Bad domain, o domínio que acionou a descoberta.
     • IP do indicador: para as descobertas de Bad IP, o endereço IP que acionou a descoberta.
     • IP de origem: para descobertas de Bad IP, um comando de malware conhecido e um endereço IP de controle.
     • Porta de origem: para descobertas de Bad IP, a porta de origem da conexão.
     • IP de destino: para descobertas de Bad IP, o endereço IP de destino do malware.
     • Porta de destino: para descobertas de Bad IP, a porta de destino da conexão.
     • Protocolo: para descobertas de Bad IP, o número do protocolo IANA associado à conexão.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome completo do recurso: o nome completo do recurso da instância do Compute Engine afetado.
     • Nome completo do projeto: o nome completo do recurso do projeto que contém a descoberta.
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.
     • Indicador do VirusTotal: link para a página de análise do VirusTotal.
     • Flow Analyzer: link para o recurso Flow Analyzer do Network Intelligence Center. Esse campo só aparece quando os registros de fluxo da VPC estão ativados.

   1. Clique na guia JSON e observe o seguinte campo:

      • evidence:
      • sourceLogId:
        • projectID: o ID do projeto em que o problema foi detectado.
      • properties:
      • InstanceDetails: o endereço do recurso da instância do Compute Engine.

Etapa 2: verificar as permissões e configurações

1. No console Google Cloud , acesse a página Painel.

   Ir para o Painel

2. Selecione o projeto especificado na linha Nome completo do projeto na guia Resumo.

3. Acesse o card Recursos e clique em Compute Engine.

4. Clique na instância de VM que corresponde ao nome e à zona em Nome completo do recurso. Verifique os detalhes da instância, incluindo as configurações de rede e acesso.

5. No painel de navegação, clique em Rede VPC e em Firewall. Remova ou desative regras de firewall excessivamente permissivas.

Etapa 3: verificar os registros

1. Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.

2. Na página carregada, encontre os registros de fluxo de VPC relacionados ao endereço IP no IP de origem usando este filtro

   • logName="projects/projectId/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="SOURCE_IP" OR jsonPayload.connection.dest_ip="destIP")

     Substitua:

     • PROJECT_ID pelo projeto listado em projectId.
     • SOURCE_IP pelo endereço IP listado na linha IP de origem na guia Resumo dos detalhes da descoberta.

Etapa 4: verificar o Flow Analyzer

É necessário ativar os registros de fluxo da VPC para realizar o processo a seguir.

1. Confirme se você fez upgrade do bucket de registros para usar a Análise de dados de registros. Para instruções, consulte Fazer upgrade de um bucket para usar a Análise de dados de registros. Não há custo adicional para fazer upgrade.

2. No console Google Cloud , acesse a página Analisador de fluxos:

   Acessar o Flow Analyzer

   Também é possível acessar o Flow Analyzer pelo link URL do Flow Analyzer na seção Links relacionados da guia Resumo no painel Detalhes da descoberta.

3. Para investigar mais informações sobre a descoberta do Event Threat Detection, use o seletor de período na barra de ações para mudar o período. O período precisa refletir quando a descoberta foi informada pela primeira vez. Por exemplo, se a descoberta foi informada nas últimas duas horas, defina o período como Últimas 6 horas. Isso garante que o período no analisador de fluxo inclua o momento em que a descoberta foi informada.

4. Filtre o Flow Analyzer para mostrar os resultados adequados do endereço IP associado à descoberta de IP malicioso:

   1. No menu Filtro da linha Origem da seção Consulta, selecione IP.

   2. No campo Valor, insira o endereço IP associado à descoberta e clique em Executar nova consulta.

      Se o Analisador de fluxo não mostrar resultados para o endereço IP, limpe o filtro da linha Origem e execute a consulta novamente com o mesmo filtro na linha Destino.

5. Analise os resultados. Para mais informações sobre um fluxo específico, clique em Detalhes na tabela Todos os fluxos de dados para abrir o painel Detalhes do fluxo.

Etapa 5: pesquisar métodos de ataque e resposta

1. Analise as entradas do framework do MITRE ATT&CK em busca deste tipo de descoberta: Resolução dinâmica e Comando e controle.
2. Verifique as descobertas relacionadas clicando no link em Descobertas relacionadas na linha Descobertas relacionadas na guia Resumo dos detalhes da descoberta. As descobertas relacionadas são o mesmo tipo de descoberta e a mesma instância e rede.
3. Verifique os URLs e domínios sinalizados no VirusTotal clicando no link no indicador do VirusTotal. O VirusTotal é um serviço pertencente à Alphabet que fornece contexto sobre arquivos, URLs, domínios e endereços IP potencialmente maliciosos.
4. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 6: 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 malware pertence.
• Investigue a instância possivelmente comprometida e remova qualquer malware descoberto. Para ajudar na detecção e remoção, use uma solução de detecção e resposta de endpoints.
• Para rastrear atividades e vulnerabilidades que permitiram a inserção de malware, verifique os registros de auditoria e os syslogs associados à instância comprometida.
• Se necessário, interrompa a instância comprometida e substitua-a por uma nova instância.
• Bloqueie os endereços IP maliciosos atualizando regras de firewall ou usando o Google Cloud Armor. Ative o Google Cloud Armor na página Serviços integrados do Security Command Center. Dependendo do volume de dados, os custos do Google Cloud Armor podem ser significativos. Consulte o guia de preços do Google Cloud Armor para mais informações.
• Para controlar o acesso e o uso de imagens de VM, use a política VM protegida e Imagens confiáveis de IAM.

Malware: Cryptomining Bad IP

O malware é detectado examinando os Registros de fluxo da VPC e os registros do Cloud DNS em busca de conexões com domínios de comando e controle e endereços IP conhecidos. Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Malware: Cryptomining Bad IP, 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:
     • IP de origem: o endereço IP de criptomineração suspeito.
     • Porta de origem: a porta de origem da conexão, se disponível.
     • IP de destino: é o endereço IP de destino.
     • Porta de destino: a porta de destino da conexão, se disponível.
     • Protocolo: o protocolo IANA associado à conexão.
   • Recurso afetado
   • Links relacionados, incluindo os seguintes campos:
     • URI do Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.
     • Flow Analyzer: link para o recurso Flow Analyzer do Network Intelligence Center. Esse campo só aparece quando os registros de fluxo da VPC estão ativados.

3. Na visualização detalhada da descoberta, clique na guia Propriedades de origem.

4. Abra Propriedades e anote os valores de projeto e instância no seguinte campo:

   • instanceDetails: anote o ID do projeto e o nome da instância do Compute Engine. O ID do projeto e o nome da instância aparecem conforme mostrado neste exemplo:

     /projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME

5. Para ver o JSON completo da descoberta, clique na guia JSON.

Etapa 2: verificar as permissões e configurações

1. No console Google Cloud , acesse a página Painel.

   Ir para o Painel

2. Selecione o projeto especificado em properties_project_id.

3. Acesse o card Recursos e clique em Compute Engine.

4. Clique na instância de VM correspondente a properties_sourceInstance. Investigue a instância possivelmente comprometida em busca de malware.

5. No painel de navegação, clique em Rede VPC e em Firewall. Remova ou desative regras de firewall excessivamente permissivas.

Etapa 3: verificar os registros

1. No console Google Cloud , acesse o Explorador de registros.

   Acessar o Explorador de registros

2. Na barra de ferramentas do console Google Cloud , selecione seu projeto.

3. Na página carregada, localize os Registros de fluxo da VPC relacionados a Properties_ip_0 usando este filtro:

   • logName="projects/properties_project_id/logs/compute.googleapis.com%2Fvpc_flows"
   • (jsonPayload.connection.src_ip="Properties_ip_0" OR jsonPayload.connection.dest_ip="Properties_ip_0")

Etapa 4: pesquisar métodos de ataque e resposta

1. Verifique as entradas do framework do MITRE ATT&CK em busca deste tipo de descoberta: Resource Hijacking.
2. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 5: 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 malware pertence.
• Investigue a instância possivelmente comprometida e remova qualquer malware descoberto. Para ajudar na detecção e remoção, use uma solução de detecção e resposta de endpoints.
• Se necessário, interrompa a instância comprometida e substitua-a por uma nova instância.
• Bloqueie os endereços IP maliciosos atualizando regras de firewall ou usando o Google Cloud Armor. Ative o Google Cloud Armor na página Serviços integrados do Security Command Center. Dependendo do volume de dados, os custos do Google Cloud Armor podem ser significativos. Consulte o guia de preços do Google Cloud Armor para mais informações.

Persistence: GKE Webhook Configuration Detected

Uma configuração de webhook foi detectada no seu cluster do GKE. Os webhooks podem interceptar e modificar solicitações da API Kubernetes, o que potencialmente permite que invasores permaneçam no cluster ou manipulem recursos.

1. Identifique a finalidade e a origem da configuração do webhook. Verifique se ele é de uma fonte confiável e tem uma finalidade legítima.
2. Revise a configuração do webhook para entender o escopo e os tipos de solicitações que ele intercepta.
3. Monitore a atividade do webhook em busca de ações suspeitas ou não autorizadas.
4. Se o webhook não for necessário ou se o comportamento dele for preocupante, considere remover ou desativar.

Persistence: IAM Anomalous Grant

Os registros de auditoria são examinados para detectar a adição de concessões de papel do IAM (IAM) que podem ser consideradas suspeitas.

Confira a seguir exemplos de concessões anômalas:

• Convidar um usuário externo, como gmail.com, como proprietário do projeto no console Google Cloud
• Uma conta de serviço que concede permissões confidenciais;
• um papel personalizado que concede permissões confidenciais;
• Uma conta de serviço adicionada de fora da organização ou do projeto

A descoberta de IAM Anomalous Grant é exclusiva porque inclui subregras que fornecem informações mais específicas sobre cada instância dessa descoberta. A classificação de gravidade dessa descoberta depende da subregra. Cada subregra pode exigir uma resposta diferente.

A lista a seguir mostra todas as subregras possíveis e as gravidades delas:

• external_service_account_added_to_policy:
  • HIGH, se um papel altamente confidencial tiver sido concedido ou um papel de confidencialidade média for concedido no nível da organização. Para mais informações, consulte Papéis altamente confidenciais.
  • MEDIUM, se um papel de confidencialidade média for concedido. Para mais informações, consulte Papéis de confidencialidade média.
• external_member_invited_to_policy: HIGH
• external_member_added_to_policy:
  • HIGH, se um papel altamente confidencial tiver sido concedido ou um papel de confidencialidade média for concedido no nível da organização. Para mais informações, consulte Papéis altamente confidenciais.
  • MEDIUM, se um papel de confidencialidade média for concedido. Para mais informações, consulte Papéis de confidencialidade média.
• custom_role_given_sensitive_permissions: MEDIUM
• service_account_granted_sensitive_role_to_member: HIGH
• policy_modified_by_default_compute_service_account: HIGH

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Persistence: IAM Anomalous Grant 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:
     • E-mail principal: endereço de e-mail do usuário ou da conta de serviço que atribuiu o papel.

   • Recurso afetado

   • Links relacionados, principalmente os seguintes campos:

     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.
     • Indicador do VirusTotal: link para a página de análise do VirusTotal.

3. Clique na guia JSON. O JSON completo da descoberta será exibido.

4. No JSON da descoberta, observe os seguintes campos:

   • detectionCategory:
     • subRuleName: informações mais específicas sobre o tipo de concessão anômala que ocorreu. A subregra determina a classificação de gravidade dessa descoberta.
   • evidence:
     • sourceLogId:
     • projectId: o ID do projeto que contém a descoberta.
   • properties:
     • sensitiveRoleGrant:
       • bindingDeltas:
       • Action: a ação tomada pelo usuário.
       • Role: o papel atribuído ao usuário.
       • member: o endereço de e-mail do usuário que recebeu o papel.

Etapa 2: verificar os registros

1. Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
2. Na página carregada, procure recursos novos ou atualizados do IAM usando estes filtros:
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"

Etapa 3: pesquisar métodos de ataque e resposta

1. Verifique as entradas do framework do MITRE ATT&CK em busca deste tipo de descoberta: Contas válidas: contas do Cloud.
2. Verifique as descobertas relacionadas clicando no link na linha Descobertas relacionadas na guia Resumo dos detalhes da descoberta. As descobertas relacionadas são o mesmo tipo de descoberta e a mesma instância e rede.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 4: 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 a conta violada pertence.
• Exclua a conta de serviço violada e rotacione e exclua todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os recursos que usam a conta de serviço para autenticação perdem o acesso.
• Exclua recursos do projeto criados por contas não autorizadas, como instâncias desconhecidas do Compute Engine, snapshots, contas de serviço e usuários do IAM.
• Para restringir a adição de usuários do gmail.com, use a Política da organização.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Persistence: New AI API Method

Atividade de administrador anômala para serviços de IA por um ator potencialmente malicioso foi detectada em uma organização, pasta ou projeto. A atividade anômala pode ser:

• Nova atividade de um principal em uma organização, pasta ou projeto
• Atividades que não ocorrem há algum tempo, realizadas por um principal em uma organização, pasta ou projeto

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Persistence: New AI API Method, conforme instruído em Como verificar descobertas.

2. Nos detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:

   • Em O que foi detectado:
     • E-mail do principal: a conta que fez a chamada
     • Nome do método: o método que foi chamado
     • Recursos de IA: os recursos de IA potencialmente afetados, como os recursos da Vertex AI e o modelo de IA.
   • Em Recurso afetado:
     • Nome de exibição do recurso: o nome do recurso afetado, que pode ser igual ao nome da organização, da pasta ou do projeto
     • Caminho do recurso: é o local na hierarquia de recursos em que a atividade ocorreu

Etapa 2: pesquisar métodos de ataque e resposta

1. Verifique as entradas do framework do MITRE ATT&CK em busca deste tipo de descoberta: Persistência.
2. Investigue se a ação foi garantida na organização, na pasta ou no projeto e se a ação foi realizada pelo proprietário legítimo da conta. A organização, a pasta ou o projeto é exibido no campo Caminho do recurso, e a conta é exibida na linha E-mail principal.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Persistence: New API Method

Atividade do administrador anômala por um ator potencialmente malicioso foi detectada em uma organização, pasta ou projeto. A atividade anômala pode ser:

• Nova atividade de um principal em uma organização, pasta ou projeto
• Atividades que não ocorrem há algum tempo por um diretor em uma organização, pasta ou projeto

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Persistence: New API Method, conforme instruído em Como verificar descobertas.

2. Nos detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:

   • Em O que foi detectado:
     • E-mail do principal: a conta que fez a chamada
     • Nome do serviço: o nome da API do serviço do Google Cloud usado na ação
     • Nome do método: o método que foi chamado
   • Em Recurso afetado:
     • Nome de exibição do recurso: o nome do recurso afetado, que pode ser igual ao nome da organização, da pasta ou do projeto
     • Caminho do recurso: é o local na hierarquia de recursos em que a atividade ocorreu

Etapa 2: pesquisar métodos de ataque e resposta

1. Verifique as entradas do framework do MITRE ATT&CK em busca deste tipo de descoberta: Persistência.
2. Investigue se a ação foi garantida na organização, na pasta ou no projeto e se a ação foi realizada pelo proprietário legítimo da conta. A organização, a pasta ou o projeto é exibido na linha Caminho do recurso, e a conta é exibida na linha E-mail do principal.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Persistence: New Geography

Essa descoberta não está disponível para ativações no nível do projeto.

Um usuário ou conta de serviço do IAM está acessando Google Cloud de um local anômalo, com base na geolocalização do endereço IP solicitante.

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Persistence: New Geography, conforme direcionado em Como verificar detalhes da descoberta anteriormente nesta página. 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:
  • E-mail principal: a conta do usuário que pode estar comprometida.
• Recurso afetado, especialmente os seguintes campos:
  • Nome completo do projeto: contém a conta de usuário potencialmente comprometida.
• Links relacionados, principalmente os seguintes campos:
  • URI do Cloud Logging: link para as entradas do Logging.
  • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
  • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

1. Na visualização detalhada da descoberta, clique na guia JSON.

2. No JSON, observe os seguintes campos sourceProperties:

   • affectedResources:
     • gcpResourceName: o recurso afetado;
   • evidence:
     • sourceLogId:
     • projectId: o ID do projeto que contém a descoberta.
   • properties:
     • anomalousLocation:
     • anomalousLocation: o local atual estimado do usuário.
     • callerIp: o endereço IP externo.
     • notSeenInLast: o período usado para estabelecer um valor de referência para o comportamento normal.
     • typicalGeolocations: os locais onde o usuário geralmente acessa recursos doGoogle Cloud .

Etapa 2: verificar as permissões do projeto e da conta

1. No console Google Cloud , acesse a página IAM.

   Acessar IAM

2. Se necessário, selecione o projeto listado no campo projectID no JSON de descoberta.

3. Na página exibida, na caixa Filtro, insira o nome da conta listado em E-mail principal e verifique os papéis concedidos.

Etapa 3: verificar os registros

1. Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
2. Se necessário, selecione o projeto.
3. Na página carregada, verifique os registros em busca de atividades em recursos novos ou atualizados do IAM usando estes filtros:
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Etapa 4: pesquisar métodos de ataque e resposta

1. Verifique a entrada do framework do MITRE ATT&CK em busca deste tipo de descoberta: Contas válidas: contas do Cloud.
2. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 5: 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 a conta violada pertence.
• Confira os campos anomalousLocation, typicalGeolocations e notSeenInLast para verificar se o acesso está anormal e se a conta foi comprometida.
• Exclua recursos do projeto criados por contas não autorizadas, como instâncias desconhecidas do Compute Engine, snapshots, contas de serviço e usuários do IAM.
• Para restringir a criação de novos recursos a regiões específicas, consulte Como restringir locais de recursos.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Persistence: New Geography for AI Service

Essa descoberta não está disponível para ativações no nível do projeto.

Um usuário ou conta de serviço do IAM está acessando os serviços de IA do Google Cloud em um local anômalo, com base na geolocalização do endereço IP solicitante.

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Persistence: New Geography for AI Service, conforme direcionado em Como verificar detalhes da descoberta anteriormente nesta página. 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:
  • E-mail principal: a conta do usuário que pode estar comprometida.
  • Recursos de IA: os recursos de IA potencialmente afetados, como os recursos da Vertex AI e o modelo de IA.
• Recurso afetado, especialmente os seguintes campos:
  • Nome completo do projeto: contém a conta de usuário potencialmente comprometida.
• Links relacionados, principalmente os seguintes campos:
  • URI do Cloud Logging: link para as entradas do Logging.
  • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
  • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

1. Na visualização detalhada da descoberta, clique na guia JSON.

2. No JSON, observe os seguintes campos sourceProperties:

   • affectedResources:
     • gcpResourceName: o recurso afetado;
   • evidence:
     • sourceLogId:
     • projectId: o ID do projeto que contém a descoberta.
   • properties:
     • anomalousLocation:
     • anomalousLocation: o local atual estimado do usuário.
     • callerIp: o endereço IP externo.
     • notSeenInLast: o período usado para estabelecer um valor de referência para o comportamento normal.
     • typicalGeolocations: os locais onde o usuário geralmente acessa recursos doGoogle Cloud .
   • aiModel:
     • name: a IA afetada Model
   • vertexAi:
     • datasets: os conjuntos de dados afetados da Vertex AI
     • pipelines: os pipelines de treinamento da Vertex AI afetados

Etapa 2: verificar as permissões do projeto e da conta

1. No console Google Cloud , acesse a página IAM.

   Acessar IAM

2. Se necessário, selecione o projeto listado no campo projectID no JSON de descoberta.

3. Na página exibida, na caixa Filtro, insira o nome da conta listado em E-mail principal e verifique os papéis concedidos.

Etapa 3: verificar os registros

1. Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
2. Se necessário, selecione o projeto.
3. Na página carregada, verifique os registros em busca de atividades em recursos novos ou atualizados do IAM usando estes filtros:
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Etapa 4: pesquisar métodos de ataque e resposta

1. Verifique a entrada do framework do MITRE ATT&CK em busca deste tipo de descoberta: Contas válidas: contas do Cloud.
2. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 5: 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 a conta violada pertence.
• Confira os campos anomalousLocation, typicalGeolocations e notSeenInLast para verificar se o acesso está anormal e se a conta foi comprometida.
• Exclua recursos do projeto criados por contas não autorizadas, como instâncias desconhecidas do Compute Engine, snapshots, contas de serviço e usuários do IAM.
• Para restringir a criação de novos recursos a regiões específicas, consulte Como restringir locais de recursos.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Persistence: New User Agent

Essa descoberta não está disponível para ativações no nível do projeto.

Uma conta de serviço do IAM está acessando Google Cloud usando software suspeito, conforme indicado por um user agent anômalo.

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Persistence: New User Agent, conforme direcionado em Como verificar detalhes da descoberta anteriormente nesta página. 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:
     • E-mail principal: a conta de serviço possivelmente comprometida.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome completo do projeto: o projeto que contém a conta de serviço potencialmente comprometida.
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.
   1. Na visualização detalhada da descoberta, clique na guia JSON.
   2. No JSON, observe os seguintes campos.
   • projectId: o projeto que contém a conta de serviço possivelmente comprometida.
   • callerUserAgent: o user agent anômalo.
   • anomalousSoftwareClassification: o tipo de software.
   • notSeenInLast: o período usado para estabelecer um valor de referência para o comportamento normal.

Etapa 2: verificar as permissões do projeto e da conta

1. No console Google Cloud , acesse a página IAM.

   Acessar IAM

2. Se necessário, selecione o projeto listado em projectId.

3. Na página exibida, na caixa Filtro, insira o nome da conta listado na linha E-mail principal na guia Resumo dos detalhes da descoberta e verifique os papéis concedidos.

4. No console Google Cloud , acesse a página Contas de serviço.

   Acesse Contas de serviço

5. Na página exibida, na caixa Filtro, insira o nome da conta listado na linha E-mail principal na guia Resumo dos detalhes da descoberta.

6. Verifique as chaves e as datas de criação das chaves da conta de serviço.

Etapa 3: verificar os registros

1. Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
2. Se necessário, selecione o projeto.
3. Na página carregada, verifique os registros em busca de atividades em recursos novos ou atualizados do IAM usando estes filtros:
   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Etapa 4: pesquisar métodos de ataque e resposta

1. Verifique a entrada do framework do MITRE ATT&CK em busca deste tipo de descoberta: Contas válidas: contas do Cloud.
2. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 5: 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 a conta violada pertence.
• Confira os campos anomalousSoftwareClassification, callerUserAgent e behaviorPeriod para verificar se o acesso está anormal e se a conta foi comprometida.
• Exclua recursos do projeto criados por contas não autorizadas, como instâncias desconhecidas do Compute Engine, snapshots, contas de serviço e usuários do IAM.
• Para restringir a criação de novos recursos a regiões específicas, consulte Como restringir locais de recursos.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Persistence: Service Account Created in sensitive namespace

Alguém criou uma conta de serviço em um namespace sensível. Os namespaces kube-system e kube-public são essenciais para as operações do cluster do GKE, e contas de serviço não autorizadas podem comprometer a estabilidade e a segurança do cluster. 1. Se a conta de serviço não estiver autorizada, exclua-a e investigue o método de criação.

Persistence: Unmanaged Account Granted Sensitive Role

Detecta eventos em que uma função sensível é concedida a uma conta não gerenciada. As contas não gerenciadas não podem ser controladas por administradores de sistema. Por exemplo, quando o funcionário correspondente saiu da empresa, o administrador não pode excluir a conta. Portanto, conceder papéis sensíveis a contas não gerenciadas cria um possível risco de segurança para a organização.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Persistence: Unmanaged Account Granted Sensitive Role, conforme instruído em Como verificar descobertas.

2. Nos detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:

   Em O que foi detectado:

   • E-mail principal: o usuário que realizou a ação de concessão
   • Concessões de acesso inadequadas.Nome principal: a conta não gerenciada que recebe a concessão
   • Papel concedido pelas concessões de acesso inadequado: o papel sensível concedido

Etapa 2: pesquisar métodos de ataque e resposta

1. Entre em contato com o proprietário do campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.
2. Verifique com o proprietário do campo Concessões de acesso ofensivas.Nome principal e entenda a origem da conta não gerenciada.

Etapa 3: verificar os registros

1. Na guia Resumo do painel de detalhes da descoberta, em Links relacionados, clique no link URI do Cloud Logging para abrir a Análise de registros.

Etapa 4: 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 com o proprietário do projeto em que a ação foi realizada.
• Remova o acesso do proprietário do E-mail principal se ele estiver comprometido.
• Remova a função sensível recém-concedida da conta não gerenciada.
• Considere converter a conta não gerenciada em uma conta gerenciada usando a ferramenta de transferência e coloque essa conta sob o controle dos administradores de sistema.

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

Detecta quando a conta de superusuário do banco de dados AlloyDB para PostgreSQL (postgres) grava em tabelas de usuários. O superusuário (uma função com acesso muito amplo) geralmente não deve ser usado para gravar em tabelas de usuários. Uma conta de usuário com acesso mais limitado deve ser usada para atividades diárias normais. Quando um superusuário grava em uma tabela de usuários, isso pode indicar que um invasor ampliou os privilégios ou comprometeu o usuário padrão do banco de dados e está modificando dados. Também pode indicar práticas normais, mas não seguras.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Privilege Escalation: AlloyDB Database Superuser Writes to User Tables, conforme direcionado em Como verificar descobertas.

2. Na guia Resumo do painel de detalhes da descoberta, revise as informações nas seguintes seções:

   • O que foi detectado, especialmente os seguintes campos:
     • Nome de exibição do banco de dados: o nome do banco de dados na instância do AlloyDB para PostgreSQL que foi afetada.
     • Nome de usuário do banco de dados: o superusuário.
     • Consulta de banco de dados: a consulta SQL executada ao gravar em tabelas de usuários.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome completo do recurso: o nome do recurso da instância do AlloyDB para PostgreSQL que foi afetada.
     • Nome completo do pai: o nome do recurso da instância do AlloyDB para PostgreSQL.
     • Nome completo do projeto: o projeto Google Cloud que contém a instância do AlloyDB para PostgreSQL.
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.

3. Para ver o JSON completo da descoberta, clique na guia JSON.

Etapa 2: verificar os registros

1. No console Google Cloud , acesse o Explorador de registros clicando no link em cloudLoggingQueryURI (da Etapa 1). A página Explorador de registros inclui todos os registros relacionados à instância relevante do AlloyDB para PostgreSQL.
2. Verifique os registros pgaudit do PostgreSQL, que contêm as consultas executadas pelo superusuário, usando os seguintes filtros:
   • protoPayload.request.user="postgres"

Etapa 3: pesquisar métodos de ataque e resposta

1. Revise a entrada do framework MITRE ATT&CK para esse tipo de descoberta: Exfiltration Over Web Service (Exfiltração sobre o serviço da Web).
2. Para determinar se outras etapas de correção são necessárias, combine seus resultados da investigação com a pesquisa do MITRE.

Etapa 4: 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.

• Revise os usuários que podem se conectar ao banco de dados.
• Considere mudar a senha do superusuário.
• Considere criar um novo usuário com acesso limitado para os diferentes tipos de consultas usadas na instância.
  • Conceda ao novo usuário apenas as permissões necessárias para executar as consultas.
  • Atualize as credenciais dos clientes que se conectam à instância do AlloyDB para PostgreSQL.

Privilege Escalation: AlloyDB Over-Privileged Grant

Detecta quando todos os privilégios sobre um banco de dados do AlloyDB para PostgreSQL (ou todas as funções ou procedimentos em um banco de dados) são concedidos a um ou mais usuários de banco de dados.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Privilege Escalation: AlloyDB Over-Privileged Grant, conforme instruído em Como verificar descobertas.

2. Na guia Resumo do painel de detalhes da descoberta, revise as informações nas seguintes seções:

   • O que foi detectado, especialmente os seguintes campos:
     • Nome de exibição do banco de dados: o nome do banco de dados na instância do AlloyDB para PostgreSQL que foi afetada.
     • Nome de usuário do banco de dados: o usuário do PostgreSQL que concedeu privilégios demais.
     • Consulta do banco de dados: a consulta do PostgreSQL executada que concedeu os privilégios.
     • Beneficiários do banco de dados: os beneficiários dos privilégios excessivos.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome completo do recurso: o nome do recurso da instância do AlloyDB para PostgreSQL que foi afetada.
     • Nome completo do pai: o nome do recurso da instância do AlloyDB para PostgreSQL.
     • Nome completo do projeto: o projeto Google Cloud que contém a instância do AlloyDB para PostgreSQL.
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.

3. Para ver o JSON completo da descoberta, clique na guia JSON.

Etapa 2: analisar os privilégios do banco de dados

1. Conecte-se à instância do AlloyDB para PostgreSQL.
2. Liste e mostre privilégios de acesso para o seguinte:
   • Bancos de dados. Use o metacomando \l ou \list e verifique quais privilégios são atribuídos ao banco de dados listado em Nome de exibição do banco de dados (na Etapa 1).
   • Funções ou procedimentos. Use o metacomando \df e verifique quais privilégios são atribuídos a funções ou procedimentos no banco de dados listado em Nome de exibição do banco de dados (na Etapa 1).

Etapa 3: verificar os registros

1. No console do Google Cloud , acesse o Explorador de registros clicando no link em URI do Cloud Logging (da Etapa 1). A página Explorador de registros inclui todos os registros relacionados à instância relevante do Cloud SQL.
2. No Explorador de registros, verifique os registros pgaudit do PostgreSQL, que registram consultas executadas no banco de dados, usando os seguintes filtros:
   • protoPayload.request.database="var class="edit">database"

Etapa 4: pesquisar métodos de ataque e resposta

1. Revise a entrada do framework MITRE ATT&CK para esse tipo de descoberta: Exfiltration Over Web Service (Exfiltração sobre o serviço da Web).
2. Para determinar se outras etapas de correção são necessárias, combine seus resultados da investigação com a pesquisa do MITRE.

Etapa 5: 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 com o proprietário da instância com concessões privilegiadas em excesso.
• Considere revogar todas as permissões dos usuários listados em Beneficiários do banco de dados até que a investigação seja concluída.
• Para limitar o acesso ao banco de dados (no Nome de exibição do banco de dados da Etapa 1), revogue permissões desnecessárias dos beneficiários (em Beneficiários do banco de dados da Etapa 1).

Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity

O Anomalous Impersonation of Service Account é detectado examinando os registros de auditoria de atividades do administrador para ver se ocorreu uma anomalia em uma solicitação de representação da conta de serviço.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity, conforme instruído 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:
     • E-mail principal: a conta de serviço final da solicitação de representação usada para acessar Google Cloud.
     • Nome do serviço: o nome da API do serviço Google Cloud envolvido na solicitação de representação.
     • Nome do método: o método que foi chamado.
     • Informações de delegação da conta de serviço: detalhes das contas de serviço da cadeia de delegação, o principal na parte inferior da lista é o autor da chamada da solicitação de representação.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome completo do recurso: o nome do cluster.
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

Etapa 2: pesquisar métodos de ataque e resposta

1. Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.
2. Investigue os principais da cadeia de delegação para verificar se a solicitação é anormal e se alguma conta foi comprometida.
3. Entre em contato com o proprietário do autor da chamada da representação da lista de informações de delegação da conta de serviço. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: 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 com o proprietário do projeto em que a ação foi realizada.
• Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os recursos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os recursos afetados e trabalhar com aqueles que detém recursos para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do suporte do Google Cloud .
• Para limitar quem pode criar contas de serviço, use o Serviço de políticas da organização.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Privilege Escalation: Anomalous Impersonation of Service Account for AI Admin Activity

O Anomalous Impersonation of Service Account é detectado quando os registros de auditoria de atividade do administrador de um serviço de IA mostram que ocorreu uma anomalia em uma solicitação de representação da conta de serviço.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Privilege Escalation: Anomalous Impersonation of Service Account for AI Admin Activity, conforme instruído 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:
     • E-mail principal: a conta de serviço final da solicitação de representação usada para acessar Google Cloud.
     • Nome do método: o método que foi chamado.
     • Informações de delegação da conta de serviço: detalhes das contas de serviço na cadeia de delegação. O principal na parte de baixo da lista é o autor da chamada da solicitação de representação.
     • Recursos de IA: os recursos de IA potencialmente afetados, como os recursos da Vertex AI e o modelo de IA.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome completo do recurso: o nome do cluster.
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

Etapa 2: pesquisar métodos de ataque e resposta

1. Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.
2. Investigue os principais da cadeia de delegação para verificar se a solicitação é anormal e se alguma conta foi comprometida.
3. Entre em contato com o proprietário do autor da chamada da representação da lista de informações de delegação da conta de serviço. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: 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 com o proprietário do projeto em que a ação foi realizada.
• Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os recursos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os recursos afetados e trabalhar com aqueles que detém recursos para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do Cloud Customer Care.
• Para limitar quem pode criar contas de serviço, use o Serviço de políticas da organização.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity

O Anomalous Multistep Service Account Delegation é detectado examinando os registros de auditoria de atividades do administrador para ver se ocorreu uma anomalia em uma solicitação de representação da conta de serviço.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity, conforme instruído 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:
     • E-mail principal: a conta de serviço final da solicitação de representação usada para acessar Google Cloud.
     • Nome do serviço: o nome da API do serviço Google Cloud envolvido na solicitação de representação.
     • Nome do método: o método que foi chamado.
     • Informações de delegação da conta de serviço: detalhes das contas de serviço da cadeia de delegação, o principal na parte inferior da lista é o autor da chamada da solicitação de representação.
   • Recurso afetado
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

Etapa 2: pesquisar métodos de ataque e resposta

1. Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.
2. Investigue os principais da cadeia de delegação para verificar se a solicitação é anormal e se alguma conta foi comprometida.
3. Entre em contato com o proprietário do autor da chamada da representação da lista de informações de delegação da conta de serviço. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: 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 com o proprietário do projeto em que a ação foi realizada.
• Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os recursos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os recursos afetados e trabalhar com aqueles que detém recursos para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do suporte do Google Cloud .
• Para limitar quem pode criar contas de serviço, use o Serviço de políticas da organização.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for AI Admin Activity

O Anomalous Multistep Service Account Delegation é detectado quando os registros de auditoria de atividade do administrador de um serviço de IA mostram que ocorreu uma anomalia em uma solicitação de representação de conta de serviço.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Privilege Escalation: Anomalous Multistep Service Account Delegation for AI Admin Activity, conforme instruído 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:
     • E-mail principal: a conta de serviço final da solicitação de representação usada para acessar Google Cloud.
     • Nome do método: o método que foi chamado.
     • Informações de delegação da conta de serviço: detalhes das contas de serviço na cadeia de delegação. O principal na parte de baixo da lista é o autor da chamada da solicitação de representação.
     • Recursos de IA: os recursos de IA potencialmente afetados, como os recursos da Vertex AI e o modelo de IA.
   • Recurso afetado
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

Etapa 2: pesquisar métodos de ataque e resposta

1. Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.
2. Investigue os principais da cadeia de delegação para verificar se a solicitação é anormal e se alguma conta foi comprometida.
3. Entre em contato com o proprietário do autor da chamada da representação da lista de informações de delegação da conta de serviço. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: 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 com o proprietário do projeto em que a ação foi realizada.
• Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os recursos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os recursos afetados e trabalhar com aqueles que detém recursos para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do Cloud Customer Care.
• Para limitar quem pode criar contas de serviço, use o Serviço de políticas da organização.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for AI Data Access

O Anomalous Multistep Service Account Delegation é detectado quando os registros de auditoria de atividade do administrador de um serviço de IA mostram que ocorreu uma anomalia em uma solicitação de representação de conta de serviço.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Privilege Escalation: Anomalous Multistep Service Account Delegation for AI Data Access, conforme instruído 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:
     • E-mail principal: a conta de serviço final da solicitação de representação usada para acessar Google Cloud
     • Nome do método: o método que foi chamado
     • Informações de delegação da conta de serviço: detalhes das contas de serviço na cadeia de delegação. O principal na parte de baixo da lista é o autor da chamada da solicitação de representação.
     • Recursos de IA: os recursos de IA potencialmente afetados, como os recursos da Vertex AI e o modelo de IA.
   • Recurso afetado
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

Etapa 2: pesquisar métodos de ataque e resposta

1. Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.
2. Investigue os principais da cadeia de delegação para verificar se a solicitação é anormal e se alguma conta foi comprometida.
3. Entre em contato com o proprietário do autor da chamada da representação da lista de informações de delegação da conta de serviço. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: 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 com o proprietário do projeto em que a ação foi realizada.
• Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os recursos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os recursos afetados e trabalhar com aqueles que detém recursos para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do Cloud Customer Care.
• Para limitar quem pode criar contas de serviço, use o Serviço de políticas da organização.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access

O Anomalous Multistep Service Account Delegation é detectado examinando os registros de auditoria de acesso a dados para ver se ocorreu uma anomalia em uma solicitação de representação de conta de serviço.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access, conforme instruído 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:
     • E-mail principal: a conta de serviço final da solicitação de representação usada para acessar Google Cloud
     • Nome do serviço: o nome da API do serviço Google Cloud envolvido na solicitação de representação
     • Nome do método: o método que foi chamado
     • Informações de delegação da conta de serviço: detalhes das contas de serviço da cadeia de delegação, o principal na parte inferior da lista é o autor da chamada da solicitação de representação.
   • Recurso afetado
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

Etapa 2: pesquisar métodos de ataque e resposta

1. Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.
2. Investigue os principais da cadeia de delegação para verificar se a solicitação é anormal e se alguma conta foi comprometida.
3. Entre em contato com o proprietário do autor da chamada da representação da lista de informações de delegação da conta de serviço. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: 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 com o proprietário do projeto em que a ação foi realizada.
• Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os recursos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os recursos afetados e trabalhar com aqueles que detém recursos para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do suporte do Google Cloud .
• Para limitar quem pode criar contas de serviço, use o Serviço de políticas da organização.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity

O Anomalous Service Account Impersonator é detectado examinando os registros de auditoria de atividades do administrador para ver se ocorreu uma anomalia em uma solicitação de representação da conta de serviço.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity, conforme instruído 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:

     • E-mail principal: a conta de serviço final da solicitação de representação usada para acessar o Google Cloud
     • Nome do serviço: o nome da API do serviço do Google Cloud envolvido na solicitação de representação
     • Nome do método: o método que foi chamado
     • Informações de delegação da conta de serviço: detalhes das contas de serviço da cadeia de delegação, o principal na parte inferior da lista é o autor da chamada da solicitação de representação.

   • Recurso afetado

   • Links relacionados, principalmente os seguintes campos:

     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

Etapa 2: pesquisar métodos de ataque e resposta

1. Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.
2. Investigue os principais da cadeia de delegação para verificar se a solicitação é anormal e se alguma conta foi comprometida.
3. Entre em contato com o proprietário do autor da chamada da representação da lista de informações de delegação da conta de serviço. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: 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 com o proprietário do projeto em que a ação foi realizada.
• Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os recursos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os recursos afetados e trabalhar com aqueles que detém recursos para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do suporte do Google Cloud .
• Para limitar quem pode criar contas de serviço, use o Serviço de políticas da organização.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Privilege Escalation: Anomalous Service Account Impersonator for AI Admin Activity

O Anomalous Service Account Impersonator é detectado quando os registros de auditoria de atividade do administrador de um serviço de IA mostram que ocorreu uma anomalia em uma solicitação de representação da conta de serviço.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Privilege Escalation: Anomalous Service Account Impersonator for AI Admin Activity, conforme instruído 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:
     • E-mail principal: a conta de serviço final da solicitação de representação usada para acessar Google Cloud
     • Nome do método: o método que foi chamado
     • Informações de delegação da conta de serviço: detalhes das contas de serviço na cadeia de delegação. O principal na parte de baixo da lista é o autor da chamada da solicitação de representação.
     • Recursos de IA: os recursos de IA potencialmente afetados, como os recursos da Vertex AI e o modelo de IA.
   • Recurso afetado
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

Etapa 2: pesquisar métodos de ataque e resposta

1. Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.
2. Investigue os principais da cadeia de delegação para verificar se a solicitação é anormal e se alguma conta foi comprometida.
3. Entre em contato com o proprietário do autor da chamada da representação da lista de informações de delegação da conta de serviço. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: 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 com o proprietário do projeto em que a ação foi realizada.
• Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os recursos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os recursos afetados e trabalhar com aqueles que detém recursos para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do Cloud Customer Care.
• Para limitar quem pode criar contas de serviço, use o Serviço de políticas da organização.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Privilege Escalation: Anomalous Service Account Impersonator for AI Data Access

O Anomalous Service Account Impersonator é detectado quando os registros de auditoria de atividade do administrador de um serviço de IA mostram que ocorreu uma anomalia em uma solicitação de representação da conta de serviço.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Privilege Escalation: Anomalous Service Account Impersonator for AI Data Access, conforme instruído em Como verificar descobertas.

2. Nos detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:

   Em O que foi detectado:

   • E-mail principal: a conta de serviço final da solicitação de representação usada para acessar Google Cloud
   • Nome do método: o método que foi chamado
   • Informações de delegação da conta de serviço: detalhes das contas de serviço na cadeia de delegação. O principal na parte de baixo da lista é o autor da chamada da solicitação de representação.
   • Recursos de IA: os recursos de IA potencialmente afetados, como os recursos da Vertex AI e o modelo de IA.

Etapa 2: pesquisar métodos de ataque e resposta

1. Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.
2. Investigue os principais da cadeia de delegação para verificar se a solicitação é anormal e se alguma conta foi comprometida.
3. Entre em contato com o proprietário do autor da chamada da representação da lista de informações de delegação da conta de serviço. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: 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 com o proprietário do projeto em que a ação foi realizada.
• Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os recursos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os recursos afetados e trabalhar com aqueles que detém recursos para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do Cloud Customer Care.
• Para limitar quem pode criar contas de serviço, use o Serviço de políticas da organização.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Privilege Escalation: Anomalous Service Account Impersonator for Data Access

O Anomalous Service Account Impersonator é detectado examinando os registros de auditoria de acesso a dados para ver se ocorreu uma anomalia em uma solicitação de representação de conta de serviço.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Privilege Escalation: Anomalous Service Account Impersonator for Data Access, conforme instruído em Como verificar descobertas.

2. Nos detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:

   Em O que foi detectado:

   • E-mail principal: a conta de serviço final da solicitação de representação usada para acessar o Google Cloud
   • Nome do serviço: o nome da API do serviço do Google Cloud envolvido na solicitação de representação
   • Nome do método: o método que foi chamado
   • Informações de delegação da conta de serviço: detalhes das contas de serviço da cadeia de delegação, o principal na parte inferior da lista é o autor da chamada da solicitação de representação.

Etapa 2: pesquisar métodos de ataque e resposta

1. Entre em contato com o proprietário da conta de serviço no campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.
2. Investigue os principais da cadeia de delegação para verificar se a solicitação é anormal e se alguma conta foi comprometida.
3. Entre em contato com o proprietário do autor da chamada da representação da lista de informações de delegação da conta de serviço. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: 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 com o proprietário do projeto em que a ação foi realizada.
• Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os recursos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os recursos afetados e trabalhar com aqueles que detém recursos para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do suporte do Google Cloud .
• Para limitar quem pode criar contas de serviço, use o Serviço de políticas da organização.
• Para identificar e corrigir papéis excessivamente permissivos, use o Recomendador do IAM.

Privilege Escalation: Changes to sensitive Kubernetes RBAC objects

Para escalonar o privilégio, um usuário possivelmente malicioso tentou modificar um objeto de controle de acesso baseado em papéis (RBAC) ClusterRole, RoleBinding ou ClusterRoleBinding do papel sensível cluster-admin usando uma solicitação PUT ou PATCH.

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Privilege Escalation: Changes to sensitive Kubernetes RBAC objects, 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:
     • E-mail principal: a conta que fez a chamada.
     • Nome do método: o método que foi chamado.
     • Vinculações do Kubernetes: a vinculação confidencial do Kubernetes ou ClusterRoleBinding que foi modificada.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome de exibição do recurso: o cluster do Kubernetes em que a ação ocorreu.
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

3. Na seção O que foi detectado, clique no nome da vinculação na linha Vinculações do Kubernetes. Os detalhes da vinculação são exibidos.

4. Na vinculação exibida, observe os detalhes dela.

Etapa 2: verificar os registros

1. Na guia Resumo dos detalhes da descoberta no console do Google Cloud , acesse o Explorador de registros clicando no link no campo URI do Cloud Logging.

2. Se o valor em Nome do método for um método PATCH, verifique o corpo da solicitação para ver quais propriedades foram modificadas.

   Nas chamadas update (PUT), todo o objeto é enviado na solicitação para que as alterações não sejam tão claras.

3. Verifique se há outras ações realizadas pelo principal usando os seguintes filtros:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Substitua:

   • CLUSTER_NAME: o valor que você anotou no campo Nome de exibição do recurso nos detalhes da descoberta.

   • PRINCIPAL_EMAIL: o valor que você anotou no campo E-mail principal nos detalhes da descoberta.

Etapa 3: pesquisar métodos de ataque e resposta

1. Revise as entradas do framework MITRE ATT&CK para esse tipo de descoberta: Escalonamento de privilégios
2. Confirme se o objeto é sensível e se a modificação foi justificada.
3. Nas vinculações, verifique o assunto e investigue se o assunto precisa do papel ao qual ele está vinculado.
4. Determine se há outros sinais de atividade maliciosa pelo principal nos registros.

5. Se o e-mail principal não for uma conta de serviço, entre em contato com o proprietário da conta para confirmar se o proprietário legítimo realizou a ação.

   Se o e-mail principal for uma conta de serviço (IAM ou Kubernetes), identifique a origem da modificação para determinar a legitimidade.

6. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Privilege Escalation: ClusterRole with Privileged Verbs

Alguém criou um objeto ClusterRole do RBAC que contém os verbos bind, escalate ou impersonate. Um sujeito vinculado a uma função com esses verbos pode se passar por outros usuários com privilégios mais altos, se vincular a outros objetos Role ou ClusterRole que contêm permissões adicionais ou modificar as próprias permissões de ClusterRole. Isso pode fazer com que esses indivíduos recebam privilégios de cluster-admin. Para mais detalhes, consulte a mensagem de registro deste alerta.

1. Revise o ClusterRole e o ClusterRoleBindings associado para verificar se os sujeitos realmente precisam dessas permissões.
2. Se possível, evite criar papéis com os verbos bind, escalate ou impersonate.
3. Determine se há outros sinais de atividade maliciosa do principal nos registros de auditoria no Cloud Logging.
4. Ao atribuir permissões em um papel do controle de acesso baseado em função (RBAC), use o princípio de privilégio mínimo e conceda o mínimo de permissões necessárias para executar uma tarefa. O uso do princípio de privilégio mínimo reduz o potencial de escalonamento de privilégios se o cluster estiver comprometido, além de reduzir a probabilidade de que o acesso excessivo resulte em um incidente de segurança.

Privilege Escalation: ClusterRoleBinding to Privileged Role

Alguém criou uma ClusterRoleBinding do RBAC que faz referência à ClusterRole system:controller:clusterrole-aggregation-controller padrão. Esse ClusterRole padrão tem o verbo escalate, que permite aos sujeitos modificar os privilégios das próprias funções, o que permite o escalonamento de privilégios. Para mais detalhes, consulte a mensagem de registro desse alerta.

1. Revise qualquer ClusterRoleBinding que faça referência ao system:controller:clusterrole-aggregation-controller ClusterRole.
2. Revise as modificações no system:controller:clusterrole-aggregation-controller ClusterRole.
3. Determine se há outros sinais de atividade maliciosa do principal que criou o ClusterRoleBinding nos registros de auditoria no Cloud Logging.

Privilege Escalation: Create Kubernetes CSR for master cert

Para escalonar o privilégio, um usuário possivelmente mal-intencionado criou uma solicitação de assinatura de certificado (CSR), que concede acesso ao cluster-admin do mestre do Kubernetes.

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Privilege Escalation: Create Kubernetes CSR for master cert, 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:
     • E-mail principal: a conta que fez a chamada.
     • Nome do método: o método que foi chamado.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome de exibição do recurso: o cluster do Kubernetes em que a ação ocorreu.
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

Etapa 2: verificar os registros

1. Na guia Resumo dos detalhes da descoberta no console do Google Cloud , acesse o Explorador de registros clicando no link no campo URI do Cloud Logging.
2. Verifique o valor no campo protoPayload.resourceName para identificar a solicitação de assinatura de certificado específica.

3. Verifique se há outras ações realizadas pelo principal usando os seguintes filtros:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Substitua:

   • CLUSTER_NAME: o valor que você anotou no campo Nome de exibição do recurso nos detalhes da descoberta.

   • PRINCIPAL_EMAIL: o valor que você anotou no campo E-mail principal nos detalhes da descoberta.

Etapa 3: pesquisar métodos de ataque e resposta

1. Revise as entradas do framework MITRE ATT&CK para esse tipo de descoberta: Escalonamento de privilégios.
2. Investigue se a permissão de acesso ao cluster-admin é garantida.

3. Se o e-mail principal não for uma conta de serviço, entre em contato com o proprietário da conta para confirmar se o proprietário legítimo realizou a ação.

   Se o e-mail principal for uma conta de serviço (IAM ou Kubernetes), identifique a origem da ação para determinar a legitimidade.

4. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Privilege Escalation: Creation of sensitive Kubernetes bindings

Para escalonar o privilégio, um usuário possivelmente mal-intencionado tentou criar um novo objeto RoleBinding ou ClusterRoleBinding para o papel cluster-admin.

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Privilege Escalation: Creation of sensitive Kubernetes bindings, 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:
     • E-mail principal: a conta que fez a chamada.
     • Vinculações do Kubernetes: a vinculação confidencial do Kubernetes ou ClusterRoleBinding que foi criada.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome de exibição do recurso: o cluster do Kubernetes em que a ação ocorreu.
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

Etapa 2: verificar os registros

1. Na guia Resumo dos detalhes da descoberta no console do Google Cloud , acesse o Explorador de registros clicando no link no campo URI do Cloud Logging.

2. Verifique se há outras ações realizadas pelo principal usando os seguintes filtros:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Substitua:

   • CLUSTER_NAME: o valor que você anotou no campo Nome de exibição do recurso nos detalhes da descoberta.

   • PRINCIPAL_EMAIL: o valor que você anotou no campo E-mail principal nos detalhes da descoberta.

Etapa 3: pesquisar métodos de ataque e resposta

1. Revise as entradas do framework MITRE ATT&CK para esse tipo de descoberta: Escalonamento de privilégios.
2. Confirme a sensibilidade da vinculação criada e se os papéis são necessários para os sujeitos.
3. Nas vinculações, verifique o assunto e investigue se o assunto precisa do papel ao qual ele está vinculado.
4. Determine se há outros sinais de atividade maliciosa pelo principal nos registros.

5. Se o e-mail principal não for uma conta de serviço, entre em contato com o proprietário da conta para confirmar se o proprietário legítimo realizou a ação.

   Se o e-mail principal for uma conta de serviço (IAM ou Kubernetes), identifique a origem da ação para determinar a legitimidade.

6. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Privilege Escalation: Default Compute Engine Service Account SetIAMPolicy

Detecta quando a conta de serviço padrão do Compute Engine é usada para definir a política do IAM de um serviço do Cloud Run. Essa é uma possível ação pós-exploração quando um token do Compute Engine é comprometido por um serviço sem servidor.

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

1. Analise os registros de auditoria no Cloud Logging para determinar se essa era a atividade esperada pelo principal.
2. Determine se há outros sinais de atividade maliciosa pelo principal nos registros.

Privilege Escalation: Dormant Service Account Granted Sensitive Role

Detecta eventos em que um papel confidencial do IAM é concedido a uma conta de serviço gerenciada pelo usuário inativa. Nesse contexto, uma conta de serviço é considerada inativa se estiver inativa por mais de 180 dias.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Privilege Escalation: Dormant Service Account Granted Sensitive Role, conforme instruído em Como verificar descobertas.

2. Nos detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:

   Em O que foi detectado:

   • E-mail principal: o usuário que realizou a ação de concessão
   • Nome principal das concessões de acesso inadequado: a conta de serviço inativa que recebeu o papel sensível
   • Papel concedido pelas concessões de acesso inadequado: o papel confidencial do IAM que foi atribuído

   Em Recurso afetado:

   • Nome de exibição do recurso: organização, pasta ou projeto em que o papel confidencial do IAM foi concedido à conta de serviço inativa.

Etapa 2: pesquisar métodos de ataque e resposta

1. Use as ferramentas da conta de serviço, como o Activity Analyzer, para investigar a atividade da conta de serviço inativa.
2. Entre em contato com o proprietário do campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: verificar os registros

1. Na guia Resumo do painel de detalhes da descoberta, em Links relacionados, clique no link URI do Cloud Logging para abrir a Análise de registros.

Etapa 4: 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 com o proprietário do projeto em que a ação foi realizada.
• Remova o acesso do proprietário do E-mail principal se ele estiver comprometido.
• Remova o papel confidencial do IAM recém-atribuído da conta de serviço inativa.
• Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os recursos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os recursos afetados e trabalhar com aqueles que detém recursos para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do Cloud Customer Care.
• Para limitar quem pode criar contas de serviço, use o serviço de Política da organização.
• Para identificar e corrigir papéis com permissões em excesso, use o Recomendador do IAM.

Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access

Alguém criou uma vinculação do RBAC que faz referência a um dos seguintes usuários ou grupos:

• system:anonymous
• system:authenticated
• system:unauthenticated

Esses usuários e grupos são efetivamente anônimos e devem ser evitados ao criar vinculações de papéis ou de funções de cluster para qualquer papel do RBAC. Verifique se a vinculação é necessária. Se não for necessário, remova a vinculação. Para mais detalhes, consulte a mensagem de registro dessa descoberta.

1. Revise as vinculações criadas que concederam permissões para o usuário system:anonymous, system:unauthenticated group ou system:authenticated.
2. Determine se há outros sinais de atividade maliciosa do principal nos registros de auditoria no Cloud Logging.

Se houver sinais de atividade maliciosa, consulte as orientações sobre como investigar e remover as vinculações que permitiram esse acesso.

Privilege Escalation: External Member Added To Privileged Group

Essa descoberta não está disponível para ativações no nível do projeto.

Detecta quando um membro externo é adicionado a um Grupo do Google privilegiado (um grupo com papéis ou permissões confidenciais). Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Privilege Escalation: External Member Added To Privileged Group, 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:
     • E-mail do principal: a conta que fez as mudanças.
   • Recurso afetado
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

3. No painel de detalhes, clique na guia JSON.

4. No JSON, observe os seguintes campos.

   • groupName: o Grupo do Google em que as alterações foram feitas;
   • externalMember: o membro externo recém-adicionado;
   • sensitiveRoles: as funções confidenciais associadas a este grupo;

Etapa 2: analisar os participantes do grupo

1. Acesse Grupos do Google.

   Acesse Grupos do Google

2. Clique no nome do grupo que você quer analisar.

3. No menu de navegação, clique em Participantes.

4. Se o membro externo recém-adicionado não estiver neste grupo, clique na caixa de seleção ao lado do nome do membro e, em seguida, selecione remove_circle_outline Remover membro ou not_interested Banir membro.

   Para remover participantes, você precisa ser um administrador do Google Workspace ou ter atribuído a função Proprietário ou Administrador no Grupo do Google. Para mais informações, consulte Atribuir funções aos participantes de um grupo.

Etapa 3: verificar os registros

1. Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.

2. Se necessário, selecione o projeto.

3. Na página carregada, verifique os registros de alterações na associação do Grupo do Google usando os seguintes filtros:

   • protoPayload.methodName="google.apps.cloudidentity.groups.v1.MembershipsService.UpdateMembership"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Etapa 4: pesquisar métodos de ataque e resposta

1. Analise a entrada do framework do MITRE ATT&CK para esse tipo de descoberta: Contas válidas.
2. Para determinar se outras etapas de remediação são necessárias, combine seus resultados da investigação com a pesquisa do MITRE.

Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials

Para escalonar o privilégio, um ator potencialmente nocivo consultou uma solicitação de assinatura de certificado (CSR), com o comando kubectl, usando credenciais de inicialização comprometida.

Veja a seguir um exemplo de comando que essa regra detecta:

kubectl --client-certificate kubelet.crt --client-key kubelet.key --server YOUR_SERVER get csr CSR_NAME

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials, 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:
     • E-mail principal: a conta que fez a chamada.
     • Nome do método: o método que foi chamado.
   • Em Recurso afetado:
     • Nome de exibição do recurso: o cluster do Kubernetes em que a ação ocorreu.
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

Etapa 2: verificar os registros

Se o nome do método, que você anotou no campo Nome do método nos detalhes da descoberta, for um método GET, faça o seguinte:

1. Na guia Resumo dos detalhes da descoberta no console do Google Cloud , acesse o Explorador de registros clicando no link no campo URI do Cloud Logging.
2. Verifique o valor no campo protoPayload.resourceName para identificar a solicitação de assinatura de certificado específica.

Etapa 3: pesquisar métodos de ataque e resposta

1. Revise as entradas do framework MITRE ATT&CK para esse tipo de descoberta: Escalonamento de privilégios.
2. Se a CSR específica estiver disponível na entrada de registro, investigue a confidencialidade do certificado e se a ação foi garantida.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Privilege Escalation: Impersonation Role Granted for Dormant Service Account

Detecta eventos em que é concedido a um principal um papel de representação que permite que ele represente uma conta de serviço gerenciada pelo usuário inativa. Nessa descoberta, a conta de serviço inativa é o recurso afetado, e ela é considerada inativa depois de ficar nesse estado por mais de 180 dias.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Privilege Escalation: Impersonation Role Granted for Dormant Service Account, conforme instruído em Como verificar descobertas.

2. Nos detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:

   Em O que foi detectado:

   • E-mail principal: o usuário que realizou a ação de concessão
   • Nome principal das concessões de acesso inadequado: o principal que recebeu o papel de representação

   Em Recurso afetado:

   • Nome de exibição do recurso: a conta de serviço inativa como um recurso
   • Nome completo do projeto: o projeto em que está a conta de serviço inativa

Etapa 2: pesquisar métodos de ataque e resposta

1. Use as ferramentas da conta de serviço, como o Activity Analyzer, para investigar a atividade da conta de serviço inativa.
2. Entre em contato com o proprietário do campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: verificar os registros

1. Na guia Resumo do painel de detalhes da descoberta, em Links relacionados, clique no link URI do Cloud Logging para abrir a Análise de registros.

Etapa 4: 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 com o proprietário do projeto em que a ação foi realizada.
• Remova o acesso do proprietário do E-mail principal se ele estiver comprometido.
• Remova o papel de representação concedido recentemente do membro de destino.
• Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os aplicativos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, sua equipe de segurança precisa identificar todos os aplicativos afetados e trabalhar com os proprietários do aplicativo para garantir a continuidade de negócios.
• Trabalhe com sua equipe de segurança para identificar recursos desconhecidos, inclusive instâncias do Compute Engine, snapshots, contas de serviço e usuários do IAM. Excluir recursos não criados com contas autorizadas.
• Responda às notificações do Cloud Customer Care.
• Para limitar quem pode criar contas de serviço, use o serviço de Política da organização.
• Para identificar e corrigir papéis com permissões em excesso, use o Recomendador do IAM.

Privilege Escalation: Launch of privileged Kubernetes container

Uma pessoa possivelmente maliciosa criou um pod com contêineres privilegiados ou contêineres com recursos de escalonamento de privilégios.

Um contêiner privilegiado tem o campo privileged definido como true. Um contêiner com recursos de escalonamento de privilégios tem o campo allowPrivilegeEscalation definido como true. Para mais informações, consulte a referência da API SecurityContext v1 core na documentação do Kubernetes.

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Privilege Escalation: Launch of privileged Kubernetes 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:
     • E-mail principal: a conta que fez a chamada.
     • Pods do Kubernetes: o pod recém-criado com contêineres privilegiados.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome de exibição do recurso: o cluster do Kubernetes em que a ação ocorreu.
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.

3. Na guia JSON, observe os valores dos campos de descoberta:

   • findings.kubernetes.pods[].: o contêiner privilegiado ativado no pod.

Etapa 2: verificar os registros

1. Na guia Resumo dos detalhes da descoberta no console do Google Cloud , acesse o Explorador de registros clicando no link no campo URI do Cloud Logging.

2. Verifique se há outras ações realizadas pelo principal usando os seguintes filtros:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Substitua:

   • CLUSTER_NAME: o valor que você anotou no campo Nome de exibição do recurso nos detalhes da descoberta.

   • PRINCIPAL_EMAIL: o valor que você anotou no campo E-mail principal nos detalhes da descoberta.

Etapa 3: pesquisar métodos de ataque e resposta

1. Revise as entradas do framework MITRE ATT&CK para esse tipo de descoberta: Escalonamento de privilégios.
2. Confirme se o contêiner criado requer acesso a recursos do host e recursos do kernel.
3. Determine se há outros sinais de atividade maliciosa pelo principal nos registros.

4. Se o e-mail principal não for uma conta de serviço, entre em contato com o proprietário dela para confirmar se foi essa pessoa que realizou a ação.

   Se o e-mail principal for uma conta de serviço (IAM ou Kubernetes), identifique a origem da ação para determinar a legitimidade.

5. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Privilege Escalation: Privileged Group Opened To Public

Essa descoberta não está disponível para ativações no nível do projeto.

Detecta quando um Grupo do Google privilegiado (um grupo com papéis ou permissões confidenciais) é alterado para ser acessível ao público geral. Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Privilege Escalation: Privileged Group Opened To Public, 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:
     • E-mail principal: a conta que fez as alterações, que pode estar comprometida.
   • Recurso afetado
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.
   1. Clique na guia JSON.
   2. No JSON, observe os seguintes campos.
   • groupName: o Grupo do Google em que as alterações foram feitas;
   • sensitiveRoles: as funções confidenciais associadas a este grupo;
   • whoCanJoin: a configuração de participação do grupo;

Etapa 2: conferir as configurações de acesso do grupo

1. Acesse o Admin Console do Grupos do Google. É necessário ser um administrador do Google Workspace para fazer login no console.

   Acessar o Admin Console

2. No painel de navegação, clique em Diretório e selecione Grupos.

3. Clique no nome do grupo que você quer analisar.

4. Clique em Configurações de acesso e, em Quem pode participar do grupo, verifique a configuração de participação do grupo.

5. No menu suspenso, se necessário, altere a configuração de participação.

Etapa 3: verificar os registros

1. Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.

2. Se necessário, selecione o projeto.

3. Na página carregada, verifique os registros de alterações nas configurações do Grupo do Google usando os seguintes filtros:

   • protoPayload.methodName="google.admin.AdminService.changeGroupSetting"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Etapa 4: pesquisar métodos de ataque e resposta

1. Analise a entrada do framework do MITRE ATT&CK para esse tipo de descoberta: Contas válidas.
2. Para determinar se outras etapas de remediação são necessárias, combine seus resultados da investigação com a pesquisa do MITRE.

Privilege Escalation: Sensitive Role Granted To Hybrid Group

Detecta quando papéis ou permissões confidenciais são concedidos a um Grupo do Google com membros externos. Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Privilege Escalation: Sensitive Role Granted To Hybrid Group, 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:
     • E-mail principal: a conta que fez as alterações, que pode estar comprometida.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome completo do recurso: o recurso em que o novo papel foi concedido.
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.
   1. Clique na guia JSON.
   2. No JSON, observe os seguintes campos.
   • groupName: o Grupo do Google em que as alterações foram feitas;
   • bindingDeltas: os papéis confidenciais que foram concedidos recentemente a este grupo.

Etapa 2: revisar as permissões do grupo

1. Acesse a página IAM no console Google Cloud .

   Acessar IAM

2. No campo Filtro, digite o nome da conta listado em groupName.

3. Analise os papéis confidenciais concedidos ao grupo.

4. Se o papel sensível recém-adicionado não for necessário, revogue o papel.

   Você precisa de permissões específicas para gerenciar papéis na sua organização ou projeto. Para mais informações, consulte Permissões necessárias.

Etapa 3: verificar os registros

1. Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.

2. Se necessário, selecione o projeto.

3. Na página carregada, verifique os registros de alterações nas configurações do Grupo do Google usando os seguintes filtros:

   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Etapa 4: pesquisar métodos de ataque e resposta

1. Analise a entrada do framework do MITRE ATT&CK para esse tipo de descoberta: Contas válidas.
2. Para determinar se outras etapas de remediação são necessárias, combine seus resultados da investigação com a pesquisa do MITRE.

Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape

Alguém implantou um pod com uma convenção de nomenclatura semelhante a ferramentas comuns usadas para escapes de contêiner ou para executar outros ataques no cluster. Para mais detalhes, consulte a mensagem de registro desse alerta.

1. Confirme se o pod é legítimo.
2. Determine se há outros sinais de atividade maliciosa do pod ou principal nos registros de auditoria no Cloud Logging.
3. Se o principal não for uma conta de serviço (IAM ou Kubernetes), entre em contato com o proprietário da conta para confirmar se foi essa pessoa que realizou a ação.
4. Se o principal for uma conta de serviço (IAM ou Kubernetes), identifique a origem da ação para determinar a legitimidade.
5. Se o pod não for legítimo, remova-o com as vinculações do controle de acesso baseado em função (RBAC) e as contas de serviço associadas que a carga de trabalho usou e que permitiram a criação dele.

Privilege Escalation: Workload Created with a Sensitive Host Path Mount

Alguém criou uma carga de trabalho que contém uma montagem de volume hostPath para um caminho sensível no sistema de arquivos do nó host. O acesso a esses caminhos no sistema de arquivos do host pode ser usado para acessar informações privilegiadas ou sensíveis no nó e para escapar do contêiner. Se possível, não permita volumes hostPath no cluster. Para mais detalhes, consulte a mensagem de registro desse alerta.

1. Analise a carga de trabalho para determinar se esse volume de hostPath é necessário para a funcionalidade pretendida. Se sim, verifique se o caminho está no diretório mais específico possível. Por exemplo, /etc/myapp/myfiles em vez de / ou /etc.
2. Determine se há outros sinais de atividade maliciosa relacionados a essa carga de trabalho nos registros de auditoria no Cloud Logging.

Para bloquear montagens de volume de hostPath no cluster, consulte orientações sobre como aplicar os padrões de segurança do pod.

Privilege Escalation: Workload with shareProcessNamespace enabled

Alguém implantou uma carga de trabalho com a opção shareProcessNamespace definida como true, permitindo que todos os contêineres compartilhem o mesmo namespace de processo do Linux. Isso pode permitir que um contêiner não confiável ou comprometido aumente privilégios acessando e controlando variáveis de ambiente, memória e outros dados sensíveis de processos executados em outros contêineres. Algumas cargas de trabalho podem exigir essa funcionalidade para operar por motivos legítimos, como contêineres sidecar de processamento de registros ou contêineres de depuração. Para mais detalhes, consulte a mensagem de registro desse alerta.

1. Confirme se a carga de trabalho realmente exige acesso de todos os contêineres na carga de trabalho a um namespace de processo compartilhado.
2. Verifique se há outros sinais de atividade maliciosa do principal nos registros de auditoria no Cloud Logging.
3. Se o principal não for uma conta de serviço (IAM ou Kubernetes), entre em contato com o proprietário da conta para confirmar se foi essa pessoa que realizou a ação.
4. Se o principal for uma conta de serviço (IAM ou Kubernetes), identifique a legitimidade do que fez com que a conta de serviço realizasse essa ação.

Service account self-investigation

Uma credencial de conta de serviço está sendo usada para investigar os papéis e as permissões associados a essa mesma conta de serviço. Essa descoberta indica que as credenciais da conta de serviço podem estar comprometidas e que é necessário tomar uma medida imediata.

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Discovery: Service Account Self-Investigation, conforme direcionado em Como verificar detalhes da descoberta anteriormente nesta página. 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:
     • Gravidade: o nível de risco atribuído à descoberta. A gravidade será HIGH se a chamada de API que acionou essa descoberta não tiver sido autorizada. A conta de serviço não tem permissão para consultar as próprias permissões do IAM com a API projects.getIamPolicy.
     • E-mail principal: a conta de serviço possivelmente comprometida.
     • IP do autor da chamada: o endereço IP interno ou externo
   • Recurso afetado, especialmente os seguintes campos:
     • Nome completo do recurso:
     • Nome completo do projeto: o projeto que contém as credenciais da conta que podem ter vazado.
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para as entradas do Logging.
     • Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
     • Descobertas relacionadas: links para quaisquer descobertas relacionadas.
   1. Para ver o JSON completo da descoberta, clique na guia JSON.

Etapa 2: verificar as permissões do projeto e da conta de serviço

1. No console Google Cloud , acesse a página IAM.

   Acessar IAM

2. Se necessário, selecione o projeto listado no campo projectID do JSON de descoberta.

3. Na página exibida, na caixa Filtro, insira o nome da conta listado em E-mail de principal e verifique as permissões atribuídas.

4. No console Google Cloud , acesse a página Contas de serviço.

   Acesse Contas de serviço

5. Na página exibida, na caixa Filtro, insira o nome da conta de serviço comprometida e verifique as chaves da conta de serviço e as datas de criação da chave.

Etapa 3: verificar os registros

1. Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
2. Se necessário, selecione o projeto.
3. Na página carregada, verifique os registros em busca de atividades em recursos novos ou atualizados do IAM usando estes filtros:
   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Etapa 4: pesquisar métodos de ataque e resposta

1. Verifique a entrada do framework do MITRE ATT&CK em busca deste tipo de descoberta: Descoberta de grupos de permissões: grupos de nuvem.
2. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 5: 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 a conta violada pertence.
• Exclua a conta de serviço violada e rotacione e exclua todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os recursos que usam a conta de serviço para autenticação perdem o acesso.
• Exclua os recursos do projeto criados pela conta comprometida, como instâncias desconhecidas do Compute Engine, snapshots, contas de serviço e usuários do IAM.

Detecções de metadados do administrador do Compute Engine

Persistence: GCE Admin Added SSH Key

Persistence: GCE Admin Added Startup Script

Detecções dos registros do Google Workspace

Se você compartilhar seus registros do Google Workspace com o Cloud Logging, a detecção de ameaças a eventos gerará descobertas para várias ameaças do Google Workspace. Como os registros do Google Workspace estão no nível da organização, o Event Threat Detection só consegue verificá-los se o Security Command Center for ativado no nível da organização.

O Event Threat Detection enriquece eventos de registro e grava descobertas no Security Command Center. A tabela a seguir contém ameaças do Google Workspace, as entradas relevantes do MITRE ATT&CK framework e detalhes sobre os eventos que acionam as descobertas. Também é possível verificar os registros usando filtros específicos e combinar todas as informações para responder às ameaças do Google Workspace.

Initial Access: Disabled Password Leak

Essa descoberta não fica disponível se o Security Command Center for ativado no nível do projeto.

Initial Access: Suspicious Login Blocked

Essa descoberta não fica disponível se o Security Command Center for ativado no nível do projeto.

Initial Access: Account Disabled Hijacked

Essa descoberta não fica disponível se o Security Command Center for ativado no nível do projeto.

Impair Defenses: Two Step Verification Disabled

Essa descoberta não fica disponível se o Security Command Center for ativado no nível do projeto.

Initial Access: Government Based Attack

Essa descoberta não fica disponível se o Security Command Center for ativado no nível do projeto.

Persistence: SSO Enablement Toggle

Essa descoberta não fica disponível se o Security Command Center for ativado no nível do projeto.

Persistence: SSO Settings Changed

Essa descoberta não fica disponível se o Security Command Center for ativado no nível do projeto.

Impair Defenses: Strong Authentication Disabled

Essa descoberta não fica disponível se o Security Command Center for ativado no nível do projeto.

Responder a ameaças ao Google Workspace

As descobertas do Google Workspace só ficam disponíveis para ativações no nível da organização do Security Command Center. Não é possível verificar os registros do Google Workspace em ativações no nível do projeto.

Se você é um administrador do Google Workspace, use as ferramentas de segurança do serviço para resolver essas ameaças:

• Central de alertas do Google Workspace
• Central de segurança do Google Workspace

As ferramentas incluem alertas, um painel de segurança, recomendações de segurança e podem ajudar você a investigar e corrigir ameaças.

Se você não for um administrador do Google Workspace, faça o seguinte:

• Se você ainda tiver acesso à sua conta, altere ou redefina a senha e ative a verificação em duas etapas.
• Entre em contato com o administrador do Google Workspace ou com a equipe da empresa que gerencia sua conta do Google Workspace. Use essas descobertas como uma indicação de que uma conta pode estar comprometida.

Detecções de ameaças do Cloud IDS

Cloud IDS: THREAT_ID

As descobertas do Cloud IDS são geradas pelo Cloud IDS, que é um serviço de segurança que monitora o tráfego de entrada e saída dos recursos doGoogle Cloud em busca de ameaças. Quando o Cloud IDS detecta uma ameaça, ele envia informações sobre ela, como endereço IP de origem, endereço de destino e número da porta, para a detecção de ameaças a eventos, que gera uma descoberta de ameaça.

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Cloud IDS: THREAT_ID, conforme instruído em Como verificar descobertas.

2. Nos detalhes da descoberta, na guia Resumo, revise os valores listados nas seguintes seções:

   • O que foi detectado, especialmente os seguintes campos:
     • Protocolo: o protocolo de rede usado
     • Horário do evento: quando o evento ocorreu
     • Descrição: mais informações sobre a descoberta
     • Gravidade: gravidade do alerta
     • IP de destino: o IP de destino do tráfego de rede
     • Porta de destino: a porta de destino do tráfego de rede
     • IP de origem: o IP de origem do tráfego de rede
     • Porta de origem: a porta de origem do tráfego de rede
   • Recurso afetado, especialmente os seguintes campos:
     • Nome completo do recurso: o projeto que contém a rede com a ameaça
   • Links relacionados, principalmente os seguintes campos:
     • URI do Cloud Logging: link para entradas do Cloud IDS Logging. Essas entradas têm as informações necessárias para pesquisar o Armazenamento de ameaças da Palo Alto Networks
   • Detecção de serviço
     • Categoria da descoberta: o nome da ameaça do Cloud IDS

3. Para ver o JSON completo da descoberta, clique na guia JSON.

Etapa 2: procurar métodos de ataque e resposta

Depois de analisar os detalhes da descoberta, consulte a documentação do Cloud IDS sobre como investigar alertas de ameaças para determinar uma resposta apropriada.

Para mais informações sobre o evento detectado na entrada de registro original, clique no link no campo URI do Cloud Logging nos detalhes da descoberta.

Respostas do Container Threat Detection

Para saber mais sobre o Container Threat Detection, consulte Como o Container Threat Detection funciona.

Added Binary Executed

Um binário que não fazia parte da imagem do contêiner original foi executado. Os invasores geralmente instalam ferramentas de exploração e malware após o comprometimento inicial. Garantir que os contêineres sejam imutáveis é uma prática recomendada importante. Essa é uma descoberta de baixa gravidade porque sua organização pode não estar seguindo essa prática recomendada. Há descobertas Execution: Added Malicious Binary Executed correspondentes quando o hash do binário é um indicador de comprometimento (IoC) conhecido. Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Added Binary Executed, 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 adicionado.
     • Argumentos: os argumentos fornecidos ao invocar o binário adicionado.
   • 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.
   • Links relacionados, principalmente os seguintes campos:
     • Indicador do VirusTotal: link para a página de análise do VirusTotal.

3. Clique no JSON e observe os seguintes campos:

   • resource:
     • project_display_name: o nome do projeto que contém o cluster.
   • 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.

4. 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 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 o Explorador de registros.

   Acessar o Explorador 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 adicionado executando:

     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:

     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. Verifique as entradas do framework do MITRE ATT&CK em busca deste tipo de descoberta: Transferência de ferramentas de entrada, API nativa.
2. Verifique o valor de hash SHA-256 do binário sinalizado como malicioso no VirusTotal clicando no link no indicador do VirusTotal. O VirusTotal é um serviço pertencente à Alphabet que fornece contexto sobre arquivos, URLs, domínios e endereços IP potencialmente maliciosos.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE e a análise do VirusTotal.

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.

• Se o binário deveria ter sido incluído no contêiner, recrie a imagem do contêiner com o binário incluído. Assim, o contêiner pode ser imutável.
• Caso contrário, entre em contato com 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.

Added Library Loaded

Uma biblioteca que não fazia parte da imagem do contêiner original foi carregada. Os invasores podem carregar bibliotecas maliciosas em programas existentes para ignorar as proteções de execução de código e ocultar o código malicioso. Garantir que os contêineres sejam imutáveis é uma prática recomendada importante. Essa é uma descoberta de baixa gravidade porque sua organização pode não estar seguindo essa prática recomendada. Há descobertas Execution: Added Malicious Library Loaded correspondentes quando o hash do binário é um indicador de comprometimento (IoC) conhecido. Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Added Library Loaded, 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 completo do binário do processo que carregou a biblioteca.
     • Bibliotecas: detalhes sobre a biblioteca adicionada.
     • Argumentos: os argumentos fornecidos ao invocar o binário do processo.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome completo do recurso: o nome completo do recurso do cluster.
   • Links relacionados, principalmente os seguintes campos:
     • Indicador do VirusTotal: link para a página de análise do VirusTotal.

3. Clique na guia JSON e observe os seguintes campos:

   • resource:
     • project_display_name: o nome do projeto que contém o recurso.
   • 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 executada.
     • VM_Instance_Name: o nome do nó do GKE em que o pod foi executado.

4. 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 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 em resource.name. 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 o Explorador de registros.

   Acessar o Explorador 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 resource.project_display_name
   

   Para clusters regionais:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Recupere a biblioteca adicionada executando:

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Substitua local_file por um caminho de arquivo local para armazenar a biblioteca adicionada.

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

     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. Verifique as entradas do framework do MITRE ATT&CK em busca deste tipo de descoberta: Transferência de ferramentas de entrada, Módulos compartilhados.
2. Verifique o valor de hash SHA-256 do binário sinalizado como malicioso no VirusTotal clicando no link no indicador do VirusTotal. O VirusTotal é um serviço pertencente à Alphabet que fornece contexto sobre arquivos, URLs, domínios e endereços IP potencialmente maliciosos.
3. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE e a análise do VirusTotal.

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.

• Se a biblioteca deveria ter sido incluída no contêiner, recrie a imagem do contêiner com a biblioteca incluída. Assim, o contêiner pode ser imutável.
• Caso contrário, entre em contato com 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.

Command and Control: Steganography Tool Detected

Um processo foi detectado usando ferramentas de esteganografia comumente encontradas em distribuições do tipo Unix para ocultar a comunicação. Esse comportamento sugere uma tentativa de ocultar o tráfego de comando e controle (C2) ou dados sensíveis em mensagens digitais aparentemente inofensivas trocadas com uma entidade externa. Os adversários costumam usar esteganografia para evitar o monitoramento de rede e tornar a atividade maliciosa menos evidente. A presença dessas ferramentas sugere uma tentativa deliberada de ofuscar a transferência de dados ilícita. Esse comportamento pode levar a mais comprometimento ou exfiltração de informações sensíveis. Identificar o conteúdo oculto é essencial para avaliar com precisão os riscos envolvidos.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Command and Control: Steganography Tool Detected, 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 o Explorador 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: Ofuscação de dados: esteganografia.
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.

Credential Access: Find Google Cloud Credentials

Um processo foi detectado pesquisando credenciais Google Cloud . Esse comportamento sugere uma tentativa de localizar e extrair segredos armazenados que poderiam ser usados para escalar privilégios, acessar recursos restritos ou se mover lateralmente no ambiente. Os invasores costumam procurar credenciais para ter acesso não autorizado a recursos da nuvem e aumentar privilégios ou executar comportamentos maliciosos.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Credential Access: Find Google Cloud Credentials, 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 o Explorador 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. 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: Credenciais não seguras: chaves particulares.
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.

Credential Access: GPG Key Reconnaissance

Um processo foi detectado pesquisando chaves GPG. Esse comportamento sugere uma tentativa de localizar e extrair chaves de segurança armazenadas usadas para criptografar e descriptografar documentos, além de autenticar documentos com assinaturas digitais. Os invasores usam chaves de segurança para obter acesso não autorizado a informações e sistemas críticos, o que torna essa detecção de alta gravidade e exige investigação imediata.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Credential Access: GPG Key Reconnaissance, 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 o Explorador 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. 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: Credenciais não seguras: chaves particulares.
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.

Credential Access: Search Private Keys or Passwords

Um processo foi detectado pesquisando chaves privadas, credenciais ou outras informações de autenticação sensíveis no contêiner. Esse comportamento sugere uma tentativa de localizar e extrair segredos armazenados que poderiam ser usados para escalar privilégios, acessar recursos restritos ou se mover lateralmente no ambiente. Os invasores costumam procurar chaves SSH, tokens de API ou credenciais de banco de dados para conseguir acesso não autorizado a sistemas críticos. Por isso, essa é uma detecção de alta gravidade que exige investigação imediata.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Credential Access: Search Private Keys or Passwords, 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 o Explorador 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. Verifique as entradas do framework do MITRE ATT&CK em busca deste tipo de descoberta: Credenciais não seguras: credenciais em arquivos.
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.

Defense Evasion: Base64 ELF File Command Line

Um processo foi executado com um argumento que é um arquivo ELF (formato executável e vinculável). Se uma execução de arquivo ELF codificado for detectada, isso significa que um invasor está tentando codificar dados binários para transferência para linhas de comando somente ASCII. Os invasores podem usar essa técnica para evitar a detecção e executar código malicioso incorporado em um arquivo ELF.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Defense Evasion: Base64 ELF File Command Line, 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 o Explorador 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.