Investigar e responder a ameaças

Este tópico oferece orientações informais para ajudar você a investigar e responder a ameaças e usar 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 gerenciamento de identidade e acesso (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 ao combinar eventos nos fluxos de registro do Cloud Logging com indicadores conhecidos de comprometimento (IoC, na sigla em inglês). Os IoCs, desenvolvidos por fontes internas de segurança do Google, identificam possíveis vulnerabilidades e ataques. A detecção de ameaças a eventos também detecta ameaças identificando táticas, técnicas e procedimentos no fluxo de registro e detectando desvios do comportamento passado de sua organização ou projeto. Se você ativar nível Premium do Security Command Center para organizações, detecção de ameaças a eventos também pode 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 dos 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 console do Google Cloud, 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 projeto, a pasta ou a organização do Google Cloud.

   

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.

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.

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 endereços IP de proxy anônimos, como endereços IP de 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.

Defense Evasion: Breakglass Workload Deployment Created

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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. EmResumo guia dos detalhes da descoberta no console do Google Cloud, acesseExplorador de registros clicando no link URI do Cloud Logging campo
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

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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. EmResumo guia dos detalhes da descoberta no console do Google Cloud, acesseExplorador de registros clicando no link URI do Cloud Logging campo
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: Manually Deleted Certificate Signing Request (CSR)

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Alguém excluiu manualmente uma solicitação de assinatura de certificado (CSR, na sigla em inglês). CSRs são removidos automaticamente por um controlador de coleta de lixo, mas usuários maliciosos pode excluí-los manualmente para evitar detecção. Se a CSR excluída for de um aprovado e emitido, o usuário potencialmente malicioso agora tem método de autenticação extra para acessar o cluster. As permissões associados ao certificado variam de acordo com o assunto incluído, mas pode ser altamente privilegiado. O Kubernetes não aceita certificados revogação. 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 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 for 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

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Alguém implantou um pod com uma convenção de nomenclatura semelhante às cargas de trabalho padrão criadas pelo GKE para a operação normal do cluster. Essa técnica é chamada mascaramento. Para mais detalhes, veja 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 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 o proprietário legítimo realizou a ação.
4. Se o principal for uma conta de serviço (IAM ou Kubernetes), identificar a origem da ação para determinar a legitimidade dela.
5. Se o pod não for legítimo, remova-o com qualquer RBAC associado. e contas de serviço que a carga de trabalho usou e que permitiram criação.

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:
     • Revisões de acesso ao Kubernetes: as informações de análise de acesso solicitadas, com base na SelfSubjectAccessReview 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. Revise as entradas do framework MITRE ATT&CK para este 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.

Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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

1. Confirme se o pod tem um motivo legítimo para especificar estes comandos e argumentos.
2. Determine se há outros sinais de atividade maliciosa do pod ou principal nos registros de auditoria do Cloud Logging.
3. Se o principal não for uma conta de serviço (IAM ou Kubernetes), entrar em contato com o proprietário da conta para confirmar se ele é legítimo. realizou a ação.
4. Se o principal for uma conta de serviço (IAM ou Kubernetes), identificar 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 qualquer RBAC associado. e contas de serviço que a carga de trabalho usou e que permitiram criação.

Execution: Suspicious Exec or Attach to a System Pod

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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ão usado para fins de depuração legítimos. No entanto, o kube-system namespace é destinado a objetos do sistema criados pelo Kubernetes e a execução do comando ou a criação do shell devem ser revisadas. Para mais detalhes, consulte a mensagem de registro do 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 RBAC e do cluster que permitiram esse acesso.

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.
     • Chronicle: link para o Google SecOps.

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 do 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: investigar no Google Security Operations

Use as Operações de segurança do Google para investigar isso. descoberta. O Google SecOps é um serviço do Google Cloud que permite investigar ameaças e passar por entidades relacionadas em uma na linha do tempo. O Google SecOps enriquece os dados das descobertas, permitindo que você identifique indicadores de interesse e simplifique as investigações.

Só é possível usar o Google SecOps se você ativar o Security Command Center no nível da organização.

1. Acesse a página Descobertas do Security Command Center no Console do Google Cloud.

   Acesse Descobertas

2. No painel Filtros rápidos, role para baixo até Nome de exibição da origem.

3. Na seção Nome de exibição da origem, selecione Detecção de ameaças do evento.

   A tabela é preenchida com as descobertas do Event Threat Detection.

4. Na tabela, em categoria, clique em uma descoberta Exfiltration: BigQuery Data Exfiltration. O painel de detalhes da descoberta será aberto.

5. Na seção Links relacionados do painel de detalhes da descoberta, clique em Investigar no Chronicle.

6. Siga as instruções na interface do usuário guiada do Google SecOps.

Use os seguintes guias para realizar investigações no Google SecOps:

• Investigar um usuário
• Investigar um recurso

Etapa 3: verificar permissões e configurações

1. No console do Google Cloud, abra 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 4: 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 5: 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 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 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 do 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 do 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 do Google Cloud, abra 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 do 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 do 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 do Google Cloud, abra 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 do 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 do Google Cloud, abra 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 no 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 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 do 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 do 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 do Google Cloud, abra 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 no 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.

Exfiltration: Cloud SQL Over-Privileged Grant

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

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 do 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 no 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 (em Nome de exibição do banco de dados de Etapa 1, revogar desnecessário permissões dos beneficiários (de beneficiários do banco de dados de Etapa 1.

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 do usuário. O superusuário (um papel 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 conteúdo normal, práticas não seguras.

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 durante a gravação em tabelas do usuário.
   • 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 do Cloud SQL instância.
     • Nome completo do projeto: o projeto do 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 do 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 se há registros de auditoria do PostgreSQL pgaudit ou 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.

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

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

• Recomendamos que você altere a senha do superusuário.

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

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

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

    • Para o PostgreSQL, consulte Conceder (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: Anonymous GKE resource created from the internet

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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 função (RBAC, na sigla em inglês) no cluster concedeu a permissão do usuário para criar esses recursos no cluster.

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

Para minimizar esse problema, consulte Evite papéis e grupos padrão.

Initial Access: GKE resource modified anonymously from the internet

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Detecta quando um usuário potencialmente malicioso usa uma das seguintes opções do Kubernetes usuários ou grupos de usuários padrão 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 permissão do usuário para modificar esses recursos no cluster.

Revise o recurso modificado e a vinculação do RBAC associada para garantir que 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.

Para resolver esse problema, consulte Evitar grupos e funções padrão.

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 do 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, a equipe de segurança precisa identificar todos os aplicativos afetados e trabalhar com os proprietários do aplicativo para garantir a continuidade dos 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 a 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 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, a equipe de segurança precisa identificar todos os aplicativos afetados e trabalhar com os proprietários do aplicativo para garantir a continuidade dos 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: 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 que foi 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 do Google Cloud, acesse a Análise de registros clicando no link no URI do Cloud Logging.
2. Na barra de ferramentas do console do Google Cloud, selecione o projeto ou a 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 dos 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: 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 do Google Cloud, acesse a Análise de registros clicando no link no URI do Cloud Logging.
2. Na barra de ferramentas do console do Google Cloud, selecione o 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.

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.
     • Chronicle: link para o Google SecOps.

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: investigar no Google Security Operations

Use as Operações de segurança do Google para investigar isso. descoberta. O Google SecOps é um serviço do Google Cloud que permite investigar ameaças e alternar entre entidades relacionadas em uma linha do tempo fácil de usar. O Google SecOps enriquece os dados das descobertas, permitindo que você identifique indicadores de interesse e simplifique as investigações.

Só é possível usar o Google SecOps se você ativar o Security Command Center no nível da organização.

1. Acesse a página Descobertas do Security Command Center no Console do Google Cloud.

   Acesse Descobertas

2. No painel Filtros rápidos, role para baixo até Nome de exibição da origem.

3. Na seção Nome de exibição da origem, selecione Detecção de ameaças do evento.

   Uma tabela será preenchida com as descobertas para o tipo de origem selecionado.

4. Na tabela, em categoria, clique em uma descoberta Brute Force: SSH. O painel de detalhes da descoberta será aberto.

5. Na seção Links relacionados do painel de detalhes da descoberta, clique em Investigar no Chronicle.

6. Siga as instruções na interface do usuário guiada do Google SecOps.

Use os guias a seguir para realizar investigações no Google SecOps:

• Investigar um usuário
• Investigar um endereço IP
• Investigar um recurso

Etapa 3: verificar permissões e configurações

1. No console do 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 4: verificar os registros

1. No console do Google Cloud, acesse a Análise de registros clicando no link no 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 5: 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 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 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: 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 Credential Access: 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 Remover membro ou 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.

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

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Alguém tentou aprovar manualmente uma solicitação de assinatura de certificado (CSR), mas a ação falhou. Criar um certificado para autenticação de cluster é uma prática para os invasores criarem acesso persistente a um cluster comprometido. O as permissões associadas ao certificado variam de acordo com o assunto incluído, mas pode ser altamente privilegiado. Para mais detalhes, consulte a mensagem de registro para este 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 a ela são atividades esperadas pelo principal.
2. Determinar se há outros sinais de atividade maliciosa da principal nos registros de auditoria do 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 for 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)

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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. Revise os registros de auditoria no Cloud Logging e alertas adicionais para outros CSR eventos relacionados para determinar se as ações relacionadas ao CSR são atividades esperadas o 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?
   • O CSR especificou um signatário integrado, mas precisou ser manualmente foi aprovada porque não atendeu aos critérios do signatário?
   • O principal tentou solicitar, criar, aprovar ou excluir outros CSRs?
3. Se uma aprovação de CSR não for esperada ou for considerada maliciosa, o cluster 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: 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 Credential Access: 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.

Credential Access: Secrets Accessed in Kubernetes Namespace

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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

Credential Access: 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 Credential Access: 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 do 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 no seu 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.

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.

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 do Google Cloud, abra a página Painel.

   Ir para o Painel

2. Selecione o projeto especificado 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 do 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.

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.

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 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 do Google Cloud para investigar e responder à vulnerabilidade "Apache Log4j 2".
• Implemente as técnicas recomendadas de mitigação nas vulnerabilidades de segurança 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. Para mais informações, consulte Regra WAF do Google Cloud Armor para ajudar a mitigar a vulnerabilidade do Apache Log4j.

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 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.
• Seguir as recomendações do Google Cloud para investigar e responder ao "Apache Log4j 2" vulnerabilidade.
• Implemente as técnicas recomendadas de mitigação nas vulnerabilidades de segurança 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. Para mais informações, consulte Regra WAF do Google Cloud Armor para ajudar a mitigar a vulnerabilidade do Apache Log4j.

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 do 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 do Google Cloud, abra 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 do 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 do 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.

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 dos 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 a 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.
     • Chronicle: link para o Google SecOps.
     • Indicador do VirusTotal: link para a página de análise do VirusTotal.

   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: investigar no Google Security Operations

Use as Operações de segurança do Google para investigar isso. descoberta. O Google SecOps é um serviço do Google Cloud que permite investigar ameaças e alternar entre entidades relacionadas em uma linha do tempo fácil de usar. O Google SecOps enriquece os dados das descobertas, permitindo que você identifique indicadores de interesse e simplificar as investigações.

Só é possível usar o Google SecOps se você ativar o Security Command Center no nível da organização.

1. Acesse a página Descobertas do Security Command Center no Console do Google Cloud.

   Acesse Descobertas

2. No painel Filtros rápidos, role para baixo até Nome de exibição da origem.

3. Na seção Nome de exibição da origem, selecione Detecção de ameaças do evento.

   Uma tabela será preenchida com as descobertas para o tipo de origem selecionado.

4. Na tabela, em categoria, clique na descoberta Malware: Bad IP. O painel de detalhes para a descoberta será aberto.

5. Na seção Links relacionados do painel de detalhes da descoberta, clique em Investigar no Chronicle.

6. Siga as instruções na interface do usuário guiada do Google SecOps.

Use os guias a seguir para realizar investigações no Google SecOps:

• Investigar um endereço IP
• Investigar um recurso

Etapa 3: verificar permissões e configurações

1. No Console do Google Cloud, abra 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 4: 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 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: Outgoing DoS

O Event Threat Detection detecta o potencial uso de uma instância para iniciar um ataque de negação de serviço (DoS, na sigla em inglês) analisando os Registros de fluxo da VPC. Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Malware: Outgoing DoS 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
     • IP de origem: é o endereço IP de origem da atividade do DoS.
     • Porta de origem: a porta de origem da conexão.
     • IP de destino: é o endereço IP de destino da atividade do DoS.
     • Porta de destino: a porta de destino da conexã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.
   1. Na visualização detalhada da descoberta, clique na guia JSON.
   2. No JSON, observe os seguintes campos.
   • sourceInstanceDetails: a instância de VM do Compute Engine afetada;

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

1. No Console do Google Cloud, abra a página Painel.

   Ir para o Painel

2. Selecione o projeto especificado em sourceInstanceDetails.

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

4. Clique na instância de VM que corresponde ao nome da instância e à zona em sourceInstanceDetails. 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 em srcIP usando este filtro:

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

     Substitua:

     • PROJECT_ID pelo ID do projeto em que o problema foi encontrado.
     • SOURCE_IP pelo endereço IP que está listado no campo srcIP no JSON de descoberta.
     • DESTINATION_IP pelo endereço IP que está listado no campo destIp no JSON de descoberta.

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: Negação de serviço da rede.
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 com tráfego de saída de DoS 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.

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 do 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.
     • Chronicle: link para o Google SecOps.

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: investigar no Google Security Operations

Use as Operações de segurança do Google para investigar essa descoberta. O Google SecOps é um serviço do Google Cloud que permite investigar ameaças e passar por entidades relacionadas em um na linha do tempo. O Google SecOps enriquece os dados das descobertas, permitindo que você identifique indicadores de interesse e simplificar as investigações.

Não será possível investigar as descobertas do Security Command Center no Chronicle se você o ativar no nível do projeto.

1. Acesse a página Descobertas do Security Command Center no Console do Google Cloud.

   Acesse Descobertas

2. No painel Filtros rápidos, role para baixo até Nome de exibição da origem.

3. Na seção Nome de exibição da origem, selecione Detecção de ameaças do evento.

   Uma tabela será preenchida com as descobertas para o tipo de origem selecionado.

4. Na tabela, em categoria, clique em uma descoberta Persistence: IAM Anomalous Grant. O painel de detalhes para a descoberta será aberto.

5. Na seção Links relacionados do painel de detalhes da descoberta, clique em Investigar no Chronicle.

6. Siga as instruções na interface do usuário guiada do Google SecOps.

Use os seguintes guias para realizar investigações no Google SecOps:

• Investigar um usuário
• Investigar um recurso

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, 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 4: 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 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 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: 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 Persistence: 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
   • Concessões de acesso ofensivos.Nome principal: a 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 continuar, a equipe de segurança precisa identificar todos os e trabalhar com proprietários de aplicativos para garantir a continuidade dos 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.

Persistence: Unmanaged Account Granted Sensitive Role

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Detecta eventos em que um papel confidencial é concedido a uma conta não gerenciada Contas não gerenciadas não podem ser controladas pelos administradores de sistema. Por exemplo, quando funcionário correspondente saiu da empresa, o administrador não poderá excluir a conta. Portanto, conceder funções 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 ofensivo.Nome principal: a conta não gerenciada que recebe a concessão
   • Concessões de acesso inadequado: o papel confidencial 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 Offending access grants.Principal name 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.
• Converta a conta não gerenciada em gerenciada usando a ferramenta de transferência e transfira o controle dela para os administradores do sistema.

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 o 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 os recursos do Google Cloud.

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

1. No console do Google Cloud, abra 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 o 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 do Google Cloud, abra 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 do 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.

Privilege Escalation: Changes to sensitive Kubernetes RBAC objects

Para escalonar o privilégio, um usuário possivelmente mal-intencionado tentou modificar um objeto de controle de acesso baseado em papel (RBAC, na sigla em inglês) 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. EmResumo guia dos detalhes da descoberta no console do Google Cloud, acesseExplorador de registros clicando no link URI do Cloud Logging campo

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 este 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 um conta de serviço, entre em contato com o proprietário dela 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: 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) mestre do Kubernetes, que concede acesso ao cluster-admin.

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. EmResumo guia dos detalhes da descoberta no console do Google Cloud, acesseExplorador de registros clicando no link URI do Cloud Logging campo
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. EmResumo guia dos detalhes da descoberta no console do Google Cloud, acesseExplorador de registros clicando no link URI do Cloud Logging campo

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: Effectively Anonymous Users Granted GKE Cluster Access

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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. Analise o vinculam para garantir que sejam necessários. Se não for necessário, remova a vinculação. Para mais detalhes, consulte a mensagem de registro para essa descoberta.

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

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

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. EmResumo guia dos detalhes da descoberta no console do Google Cloud, acesseExplorador de registros clicando no link URI do Cloud Logging campo
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: 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. EmResumo guia dos detalhes da descoberta no console do Google Cloud, acesseExplorador de registros clicando no link URI do Cloud Logging campo

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 um serviço conta, entre em contato com o proprietário dela para confirmar se o proprietário conduziu 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: 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
   • Concessões de acesso ofensivo. Nome principal: a conta de serviço inativa que recebeu o papel confidencial.
   • 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 dos 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: Anomalous Impersonation of Service Account for Admin Activity

A falsificação de identidade anômala da conta de serviço é detectada por análise dos registros de auditoria de atividade do administrador para ver se ocorreu alguma 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 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, 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 do 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 dos 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 a 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 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 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 do 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 dos 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 a 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 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 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 do 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 dos 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 a 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 do 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 dos 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 a 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 Data Access

O falsificador de identidade anômalo de conta de serviço é detectado por análise dos registros de auditoria de acesso aos dados para ver se ocorreu alguma 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 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 do 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 dos 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 a 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: ClusterRole with Privileged Verbs

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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 ClusterRole. Isso pode fazer com que esses indivíduos ganhem Privilégios 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 funções que envolvam bind, escalate ou verbos impersonate.
3. Determinar se há outros sinais de atividade maliciosa da principal nos registros de auditoria do Cloud Logging.
4. Ao atribuir permissões em uma função do RBAC, use o princípio do mínimo privilégio e conceda as permissões mínimas necessárias para executar uma tarefa. Usando o princípio de privilégio mínimo reduz o potencial de privilégio caso seu cluster esteja comprometido e reduz a probabilidade de que o acesso excessivo resulta em um incidente de segurança.

Privilege Escalation: ClusterRoleBinding to Privileged Role

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Alguém criou um RBAC ClusterRoleBinding que referencia a system:controller:clusterrole-aggregation-controller: ClusterRole. Isso o padrão ClusterRole tem o verbo escalate, que permite que os sujeitos modifiquem 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. Analise todos os ClusterRoleBinding que fazem referência ao ClusterRole system:controller:clusterrole-aggregation-controller.
2. Analise as modificações no system:controller:clusterrole-aggregation-controller ClusterRole.
3. Determinar se há outros sinais de atividade maliciosa da principal que criou o ClusterRoleBinding nos registros de auditoria em o Cloud Logging.

Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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, veja 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 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 o proprietário legítimo realizou a ação.
4. Se o principal for uma conta de serviço (IAM ou Kubernetes), identificar a origem da ação para determinar a legitimidade dela.
5. Se o pod não for legítimo, remova-o com as vinculações do 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

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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. Acesso a esses caminhos no host do sistema de arquivos pode ser usado para acessar informações privilegiadas ou confidenciais no nó e para escapes de contêiner. Se possível, não permita volumes hostPath no cluster. Para mais detalhes, consulte a mensagem de registro desse alerta.

1. Revise a carga de trabalho para determinar se este 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 hostPath no cluster, consulte as orientações sobre como aplicar os padrões de segurança de pods.

Privilege Escalation: Workload with shareProcessNamespace enabled

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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 através do acesso e controle de variáveis de ambiente, memória e outros dados sensíveis de processos executados em outros contêineres. Algumas cargas de trabalho podem exigir que essa funcionalidade funcione por motivos legítimos, como contêineres de sidecar de processamento de registros ou contêineres de depuração. Para mais detalhes, consulte o registro para este alerta.

1. Confirme se a carga de trabalho realmente exige acesso a um processo compartilhado namespace para todos os contêineres na carga de trabalho.
2. Verifique se há outros sinais de atividade maliciosa do diretor na os 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), identificar 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 do Google Cloud, abra 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 do 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.

Inhibit System Recovery: 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 Inhibit System Recovery: Deleted Google Cloud Backup and DR host, conforme detalhado 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 do 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.

Inhibit System Recovery: 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 e DR do serviço usado para aplicar políticas de backup a um aplicativo.

Etapa 1: verificar os detalhes da descoberta

1. Abra o Inhibit System Recovery: Google Cloud Backup and DR remove plan descoberta, conforme detalhado em Como analisar 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 do 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.

Inhibit System Recovery: Google Cloud Backup and DR delete template

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

Etapa 1: verificar os detalhes da descoberta

1. Abra o Inhibit System Recovery: Google Cloud Backup and DR delete template descoberta, conforme detalhado em Como analisar 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 do 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, em seguida, selecione a opção Criar modelo.

Inhibit System Recovery: 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 o Inhibit System Recovery: Google Cloud Backup and DR delete policy descoberta, conforme detalhado em Como analisar 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 o backup. frequência, programação e tempo de retenção
     • 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.

Inhibit System Recovery: 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 Inhibit System Recovery: 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.

Inhibit System Recovery: 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 Inhibit System Recovery: 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 em que 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.

Data Destruction: 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 em que 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.

Data Destruction: 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 Inhibit System Recovery: 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.

Data Destruction: 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 do 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 reduced backup expiration

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

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 detalhado em Como verificar descobertas. O O painel de detalhes da descoberta abre a 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 conta de serviço que foi executou uma ação
   • 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 Gerenciador de apps, encontre o aplicativo afetado para o qual a expiração foi reduzida e verifique se ela era prevista pelo principal.
3. Para iniciar um novo backup do aplicativo, selecione Gerenciar configurações de backup para criar um backup sob demanda ou programar um novo backup.

Impact: Google Cloud Backup and DR reduced backup frequency

A detecção de ameaças a 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 detalhado 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 conta de serviço que foi executou uma ação
   • Recurso afetado
     • Nome de exibição do recurso: o projeto em que a frequência de backup foi reduzido.
   • 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 Gerenciador de apps, encontre o aplicativo afetado para o qual frequência foi reduzida e verificar se a mudança foi pretendida principal.
3. Para iniciar um novo backup do aplicativo, selecione Gerenciar configurações de backup para criar um backup sob demanda ou para agendar um novo backup.

Impact: Suspicious Kubernetes Container Names - Coin Mining

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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

1. Confirme se o pod é legítimo.
2. Determine se há outros sinais de atividade maliciosa do pod ou 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 o proprietário legítimo realizou a ação.
4. Se o principal for uma conta de serviço (IAM ou Kubernetes), identificar a origem da ação para determinar a legitimidade dela.
5. Se o pod não for legítimo, remova-o com as vinculações do RBAC e as contas de serviço associadas que a carga de trabalho usou e que permitiram a criação dele.

Lateral Movement: Modified Boot Disk Attached to Instance

Os registros de auditoria são examinados para detectar movimentos suspeitos de disco entre os recursos da instância do Compute Engine. Um disco de inicialização potencialmente modificado foi anexado ao 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 de campos a seguir.

   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 do Google Cloud que foi 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 a conta de serviço ferramentas, como Atividade Analisador, 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 do 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 Inicialização segura para o 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, a equipe de segurança precisa identificar todos os aplicativos afetados e trabalhar com os proprietários do aplicativo para garantir a continuidade dos 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 a notificações do suporte do Google Cloud.

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 no 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 do AlloyDB para PostgreSQL que foi afetada.
     • Nome completo do pai: o nome do recurso do AlloyDB para PostgreSQL instância.
     • Nome completo do projeto: o projeto do 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 no 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: AlloyDB Database Superuser Writes to User Tables

Detecta quando a conta de superusuário do banco de dados do AlloyDB para PostgreSQL (postgres) gravações nas tabelas do usuário. O superusuário (um papel 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 normais diárias. Quando um superusuário grava em uma tabela de usuário, 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. Ele 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 no 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 durante a gravação em tabelas do usuário.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome completo do recurso: o nome do recurso do AlloyDB para PostgreSQL que foi afetada.
     • Nome completo do pai: o nome do recurso do AlloyDB para PostgreSQL instância.
     • Nome completo do projeto: o projeto do 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 do Google Cloud, acesse o Explorador de registros clicando no link em cloudLoggingQueryURI (da Etapa 1). A página Análise de registros inclui todos os registros relacionados ao Instância do AlloyDB para PostgreSQL.
2. Verifique os registros de pgaudit do PostgreSQL, que contêm as consultas executado 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.

• Verifique os usuários com permissão para se conectar ao banco de dados.
• Altere 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

Detecções de metadados do administrador do Compute Engine

Persistence: GCE Admin Added SSH Key

Descrição	Ações
A chave de metadados da instância do Compute Engine ssh-keys foi alterada em uma instância estabelecida.	A chave de metadados da instância do Compute Engine ssh-keys foi modificada em uma instância criada há mais de sete dias. Verifique se a alteração foi feita intencionalmente por um membro ou se foi implementada por um invasor para introduzir um novo acesso à sua organização.	Verifique os registros usando os seguintes filtros: protopayload.resource.labels.instance_id=INSTANCE_ID protoPayload.serviceName="compute.googleapis.com" (protoPayload.metadata.instanceMetaData.addedMetadataKey : "ssh-keys" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "ssh-keys" ) logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Substitua: INSTANCE_ID: a gceInstanceId listada na descoberta ORGANIZATION_ID: o ID da organização
		Eventos de pesquisa que acionam essa descoberta: MITRE: https://attack.mitre.org/techniques/T1098/004/

Persistence: GCE Admin Added Startup Script

Descrição	Ações
A chave de metadados da instância do Compute Engine startup-script ou startup-script-url foi alterada em uma instância estabelecida.	A chave de metadados da instância do Compute Engine startup-script ou startup-script-url foi modificada em uma instância criada há mais de sete dias. Verifique se a alteração foi feita intencionalmente por um membro ou se foi implementada por um invasor para introduzir um novo acesso à sua organização.	Verifique os registros usando os seguintes filtros: protopayload.resource.labels.instance_id=INSTANCE_ID protoPayload.serviceName="compute.googleapis.com" ((protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script" ) OR (protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script-url" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script-url" )) logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Substitua: INSTANCE_ID: a gceInstanceId listada na descoberta ORGANIZATION_ID: o ID da organização
		Eventos de pesquisa que acionam essa descoberta: MITRE: https://attack.mitre.org/techniques/T1098/004/

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.

Descrição	Ações
A conta de um membro foi desativada porque foi detectado um vazamento de senha.	Redefina as senhas das contas afetadas e aconselhe os membros a usar senhas fortes e exclusivas para contas corporativas.	Verifique os registros usando os seguintes filtros: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access SubstituaORGANIZATION_ID pelo ID da organização.
		Eventos de pesquisa que acionam essa descoberta: MITRE: https://attack.mitre.org/techniques/T1078/ Detalhes do evento no espaço de trabalho: https://developers.google.com/admin-sdk/reports/v1/Apêndice/activity/login#account_disabled_password_leak

Initial Access: Suspicious Login Blocked

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

Descrição	Ações
Um login suspeito na conta de um participante foi detectado e bloqueado.	Essa conta pode ser segmentada por adversários. Verifique se a conta de usuário segue as diretrizes de segurança da sua organização para senhas fortes e autenticação multifator.	Verifique os registros usando os seguintes filtros: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access SubstituaORGANIZATION_ID pelo ID da organização.
		Eventos de pesquisa que acionam essa descoberta: MITRE: https://attack.mitre.org/techniques/T1078/ Detalhes do evento do espaço de trabalho: https://developers.google.com/admin-sdk/reports/v1/Apêndice/activity/login#suspicious_login

Initial Access: Account Disabled Hijacked

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

Descrição	Ações
A conta de um membro foi suspensa devido a atividade suspeita.	Esta conta foi invadida. Redefina a senha da conta e incentive os usuários a criar senhas fortes e exclusivas para contas corporativas.	Verifique os registros usando os seguintes filtros: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access SubstituaORGANIZATION_ID pelo ID da organização.
		Eventos de pesquisa que acionam essa descoberta: MITRE: https://attack.mitre.org/techniques/T1078/ Detalhes do evento do espaço de trabalho: https://developers.google.com/admin-sdk/reports/v1/Apêndice/activity/login#account_disabled_hacked

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.

Descrição	Ações
Um membro desativou a verificação em duas etapas.	Verifique se o usuário pretendia desativar a verificação em duas etapas. Se sua organização exigir a verificação em duas etapas, verifique se o usuário o ativou imediatamente.	Verifique os registros usando os seguintes filtros: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access SubstituaORGANIZATION_ID pelo ID da organização.
		Eventos de pesquisa que acionam essa descoberta: MITRE: https://attack.mitre.org/techniques/T1562/ Detalhes do evento do espaço de trabalho: https://developers.google.com/admin-sdk/reports/v1/Apêndice/activity/login#2sv_disable

Initial Access: Government Based Attack

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

Descrição	Ações
Os invasores apoiados pelo governo podem ter tentado comprometer uma conta de membro ou um computador.	Essa conta pode ser segmentada por adversários. Verifique se a conta de usuário segue as diretrizes de segurança da sua organização para senhas fortes e autenticação multifator.	Verifique os registros usando os seguintes filtros: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access SubstituaORGANIZATION_ID pelo ID da organização.
		Eventos de pesquisa que acionam essa descoberta: MITRE: https://attack.mitre.org/techniques/T1078/ Detalhes do evento no espaço de trabalho: https://developers.google.com/admin-sdk/reports/v1/Apêndice/activity/login#gov_attack_warning

Persistence: SSO Enablement Toggle

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

Descrição	Ações
A configuração Ativar SSO (logon único) na conta de administrador foi desativada.	As configurações de SSO da sua organização foram alteradas. Verifique se a alteração foi feita intencionalmente por um membro ou se foi implementada por um invasor para introduzir um novo acesso à sua organização.	Verifique os registros usando os seguintes filtros: protopayload.resource.labels.service="admin.googleapis.com" protopayload.metadata.event.parameter.value=DOMAIN_NAME logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Substitua: DOMAIN_NAME: a domainName listada na descoberta ORGANIZATION_ID: o ID da organização
		Eventos de pesquisa que acionam essa descoberta: MITRE: https://attack.mitre.org/techniques/T1098/ Detalhes do evento do espaço de trabalho: https://developers.google.com/admin-sdk/reports/v1/Apêndice/activity/admin-domain-settings#TOGGLE_SSO_ENABLED

Persistence: SSO Settings Changed

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

Descrição	Ações
As configurações de SSO da conta de administrador foram alteradas.	As configurações de SSO da sua organização foram alteradas. Verifique se a alteração foi feita intencionalmente por um membro ou se foi implementada por um invasor para introduzir um novo acesso à sua organização.	Verifique os registros usando os seguintes filtros: protopayload.resource.labels.service="admin.googleapis.com" protopayload.metadata.event.parameter.value=DOMAIN_NAME logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Substitua: DOMAIN_NAME: a domainName listada na descoberta ORGANIZATION_ID: o ID da organização
		Eventos de pesquisa que acionam essa descoberta: MITRE: https://attack.mitre.org/techniques/T1098/ Detalhes do evento do espaço de trabalho: https://developers.google.com/admin-sdk/reports/v1/Apêndice/activity/admin-domain-settings#CHANGE_SSO_SETTINGS

Impair Defenses: Strong Authentication Disabled

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

Descrição	Ações
A verificação em duas etapas foi desativada para a organização.	A verificação em duas etapas não é mais necessária para sua organização. Descubra se essa foi uma mudança intencional de política por um administrador ou se essa é uma tentativa de um adversário para facilitar a invasão de contas.	Verifique os registros usando os seguintes filtros: protopayload.resource.labels.service="admin.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity SubstituaORGANIZATION_ID pelo ID da organização.
		Eventos de pesquisa que acionam essa descoberta: MITRE: https://attack.mitre.org/techniques/T1562/ Detalhes do evento do espaço de trabalho: https://developers.google.com/admin-sdk/reports/v1/Apêndice/activity/admin-security-settings#PTFORCE_STRONG_AUTHENTICATION

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

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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 do Google 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 emite 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 atacantes costumam instalar ferramentas de exploração e malware após o comprometimento inicial. Garantir que seus 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.

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 horário semelhante para esse contêiner. Descobertas relacionadas podem indicar que essa atividade foi maliciosa, em vez de uma falha ao seguir as práticas recomendadas.

Etapa 2: verificar o cluster e o nó

1. No Console do Google Cloud, acesse a página de 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 do 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 do 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 console do Google Cloud

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

• Se o binário deveria ser incluído no contêiner, recrie a imagem dele com o binário incluído. Dessa forma, o contêiner pode ser imutável.
• Caso contrário, entre em contato com o proprietário do projeto com o contêiner comprometido.
• 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. Existem descobertas de Execution: Added Malicious Library Loaded correspondentes quando o hash do binário é um indicador conhecido de comprometimento (IoC). 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.

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 horário semelhante para esse contêiner. Descobertas relacionadas podem indicar que essa atividade foi maliciosa, em vez de uma falha ao seguir as práticas recomendadas.

Etapa 2: verificar o cluster e o nó

1. No Console do Google Cloud, acesse a página de 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 do 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 do 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 console do Google Cloud

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. Revise as entradas do framework MITRE ATT&CK para este tipo de descoberta: Ingress Tool Transfer Módulos compartilhados.
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.

• Se a biblioteca foi incluída no contêiner, recrie a imagem do contêiner com a biblioteca incluída. Dessa forma, o contêiner pode ser imutável.
• Caso contrário, entre em contato com o proprietário do projeto com o contêiner comprometido.
• Interrompa ou exclua o contêiner comprometido e substitua-o por um novo contêiner.

Execution: Added Malicious Binary Executed

Um binário malicioso que não fazia parte da imagem do contêiner original foi executada. Os invasores geralmente instalam ferramentas de exploração e malware após o comprometimento inicial. Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Execution: Added Malicious 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.
     • Contêineres: o nome do contêiner afetado.
     • URI de contêineres: o nome da imagem do contêiner que está sendo implantada.
   • 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 na guia JSON e observe os seguintes campos:

   • sourceProperties:
     • VM_Instance_Name: o nome do nó do GKE em que o pod foi executado.

Etapa 2: verificar o cluster e o nó

1. No Console do Google Cloud, acesse a página de 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 do 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 do 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 console do Google Cloud

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. Extraia o binário malicioso adicionado:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

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

6. Conecte-se ao ambiente do contêiner:

     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. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.
3. Verifique o valor do 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.

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.

Execution: Added Malicious Library Loaded

Uma biblioteca maliciosa 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. Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Execution: Added Malicious 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.
     • Contêineres: o nome do contêiner afetado.
     • URI de contêineres: o nome da imagem do contêiner que está sendo implantada.
   • 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:

   • sourceProperties:
     • VM_Instance_Name: o nome do nó do GKE em que o pod foi executado.

Etapa 2: verificar o cluster e o nó

1. No Console do Google Cloud, acesse a página de 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 do 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 do 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 console do Google Cloud

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 maliciosa adicionada:

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Substitua local_file por um caminho local para armazenar o elemento malicioso adicionado. biblioteca.

6. Conecte-se ao ambiente do contêiner:

     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 este tipo de descoberta: Ingress Tool Transfer Módulos compartilhados.
2. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.
3. Verifique o valor de hash SHA-256 da biblioteca sinalizada como maliciosa em VirusTotal por clicando no link no indicador VirusTotal. O VirusTotal é um serviço pertencente à Alphabet que fornece contexto sobre arquivos, URLs, domínios e endereços IP potencialmente maliciosos.

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.

Execution: Built in Malicious Binary Executed

Um binário que foi executado, com o binário:

• Incluído na imagem do contêiner original.
• Identificado como malicioso com base na inteligência contra ameaças.

O atacante tem controle sobre o repositório de imagens de contêiner ou o pipeline de criação, em que o binário malicioso é injetado na imagem do contêiner. Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Execution: Built in Malicious 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 integrado.
     • Argumentos: os argumentos fornecidos ao invocar o binário integrado.
     • Contêineres: o nome do contêiner afetado.
     • URI de contêineres: o nome da imagem do contêiner que está sendo implantada.
   • 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:

   • sourceProperties:
     • VM_Instance_Name: o nome do nó do GKE em que o pod foi executado.

Etapa 2: verificar o cluster e o nó

1. No Console do Google Cloud, acesse a página de 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 do 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 do 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 console do Google Cloud

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 malicioso integrado:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Substitua local_file por um caminho local para armazenar o binário malicioso criado.

6. Conecte-se ao ambiente do contêiner:

     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 este tipo de descoberta: Ingress Tool Transfer API nativa.
2. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.
3. Verifique o valor do 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.

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.

Execution: Malicious Python executed

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Um modelo de aprendizado de máquina identificou o código Python executado como malicioso. Os invasores podem usar o Python para transferir ferramentas e executar comandos sem binários. Garantir que seus contêineres sejam imutáveis é uma prática recomendada importante. O uso de scripts para transferir ferramentas pode imitar a técnica do invasor de transferência de ferramentas de entrada e resultar em detecções indesejadas.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Execution: Malicious Python 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: detalhes sobre o interpretador que invocou o script.
     • Script: caminho absoluto do nome do script no disco. este só aparece para scripts gravados em disco, não para literal execução de script, por exemplo, python3 -c.
     • Argumentos: os argumentos fornecidos ao invocar o script.
   • 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 projeto.

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

4. No JSON, observe os seguintes campos.

   • finding:
     • processes:
     • script:
       • contents: conteúdo do script executado, que pode estar truncado para por motivos de desempenho. isso pode ajudar na investigação
       • sha256: o hash SHA-256 de script.contents
   • 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.

5. Identifique outras descobertas que ocorreram em um horário semelhante para esse contêiner. Por exemplo, se o script descartar um binário, verifique se há descobertas relacionadas a ele.

Etapa 2: verificar o cluster e o nó

1. No Console do Google Cloud, acesse a página de 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 do 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 em resource.name e no namespace de 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 do 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. No Console do Google Cloud, acesse a página de clusters do Kubernetes.

   Acesse Clusters do Kubernetes

2. Clique no nome do cluster mostrado em resource.labels.cluster_name.

3. Na página Clusters, clique em Conectar e em Executar no Cloud Shell.

   O Cloud Shell inicia e adiciona comandos para o cluster no terminal.

4. Pressione Enter e, se a caixa de diálogo Autorizar o Cloud Shell aparecer, Clique em Autorizar.

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. Verifique as entradas do framework do MITRE ATT&CK em busca deste tipo de descoberta: Intérprete de comandos e scripts e Transferência de ferramentas de entrada.
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.

• Se o Python estava fazendo as alterações pretendidas no contêiner, recrie a imagem dele para que nenhuma delas seja necessária. Dessa forma, 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.

Execution: Modified Malicious Binary Executed

Um binário que foi executado com o binário:

• Incluído na imagem do contêiner original.
• Modificado durante o ambiente de execução do contêiner.
• Identificadas como maliciosas com base em informações de ameaças.

Os invasores geralmente instalam ferramentas de exploração e malware após o comprometimento inicial. Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Execution: Modified Malicious 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 modificado.
     • Argumentos: os argumentos fornecidos ao invocar o binário modificado.
     • Contêineres: o nome do contêiner afetado.
     • URI de contêineres: o nome da imagem do contêiner que está sendo implantada.
   • 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:

   • sourceProperties:
     • VM_Instance_Name: o nome do nó do GKE em que o pod foi executado.

Etapa 2: verificar o cluster e o nó

1. No Console do Google Cloud, acesse a página de 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 do 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 do 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 console do Google Cloud

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 malicioso modificado:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Substitua local_file por um caminho local para armazenar o binário malicioso modificado.

6. Conecte-se ao ambiente do contêiner:

     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. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.
3. Verifique o valor do 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.

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.

Execution: Modified Malicious Library Loaded

Uma biblioteca que foi carregada, com a biblioteca:

• Incluído na imagem do contêiner original.
• Modificado durante o ambiente de execução do contêiner.
• Identificado como malicioso com base na inteligência contra ameaças.

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. Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Execution: Modified Malicious 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 modificada.
     • Argumentos: os argumentos fornecidos ao invocar o binário do processo.
     • Contêineres: o nome do contêiner afetado.
     • URI de contêineres: o nome da imagem do contêiner que está sendo implantada.
   • 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:

   • sourceProperties:
     • VM_Instance_Name: o nome do nó do GKE em que o pod foi executado.

Etapa 2: verificar o cluster e o nó

1. No Console do Google Cloud, acesse a página de 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 do 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 do 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 console do Google Cloud

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. Extraia a biblioteca maliciosa modificada:

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Substitua local_file por um caminho local para armazenar a biblioteca maliciosa modificada.

6. Conecte-se ao ambiente do contêiner:

     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. Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.
3. Verifique o valor de hash SHA-256 da biblioteca sinalizada como maliciosa em VirusTotal por clicando no link no indicador VirusTotal. O VirusTotal é um serviço pertencente à Alphabet que fornece contexto sobre arquivos, URLs, domínios e endereços IP potencialmente maliciosos.

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.

Malicious Script Executed

Um modelo de machine learning identificou o código Bash executado como malicioso. Os invasores podem usar o Bash para transferir ferramentas e executar comandos sem binários. Garantir que os contêineres sejam imutáveis é uma prática recomendada importante. O uso de scripts para transferir ferramentas pode imitar a técnica do invasor de transferência de ferramentas de entrada e resultar em detecções indesejadas.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Malicious Script 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: detalhes sobre o interpretador que invocou o script.
     • Script: caminho absoluto do nome do script no disco. Esse atributo só aparece para scripts gravados em disco, não para execução de scripts literais, por exemplo, bash -c
     • Argumentos: os argumentos fornecidos ao invocar o script.
   • 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 projeto.

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

4. No JSON, observe os seguintes campos.

   • finding:
     • processes:
     • script:
       • contents: conteúdo do script executado, que pode estar truncado para por motivos de desempenho. isso pode ajudar na investigação
       • sha256: o hash SHA-256 de script.contents
   • 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.

5. Identifique outras descobertas que ocorreram em um horário semelhante para esse contêiner. Por exemplo, se o script descartar um binário, verifique se há descobertas relacionadas a ele.

Etapa 2: verificar o cluster e o nó

1. No Console do Google Cloud, acesse a página de 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 do 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 em resource.name e no namespace de 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 do 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. No Console do Google Cloud, acesse a página de clusters do Kubernetes.

   Acesse Clusters do Kubernetes

2. Clique no nome do cluster mostrado em resource.labels.cluster_name.

3. Na página Clusters, clique em Conectar e em Executar no Cloud Shell.

   O Cloud Shell inicia e adiciona comandos para o cluster no terminal.

4. Pressione Enter e, se a caixa de diálogo Autorizar o Cloud Shell for exibida, clique em Autorizar.

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 do MITRE ATT&CK para esse tipo de descoberta: Intérprete de comandos e scripts, Transferência de ferramentas de entrada.
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.

• Se o script estava fazendo as mudanças pretendidas no contêiner, recrie a imagem do contêiner para que nenhuma delas seja necessária. Dessa forma, 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.

Malicious URL Observed

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

O Container Threat Detection observou um URL malicioso na lista de argumentos de um processo executável. Os invasores podem carregar malware ou bibliotecas maliciosas por URLs maliciosos.

Para responder a essa descoberta, siga as etapas abaixo.

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Malicious URL Observed 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:
     • URI: o URI malicioso observado.
     • Binário adicionado: o caminho completo do binário do processo que recebeu os argumentos que contêm o URL malicioso.
     • Argumentos: os argumentos fornecidos ao invocar o binário do processo.
     • Variáveis de ambiente: as variáveis de ambiente que estavam em vigor quando o binário do processo foi invocado.
     • Contêineres: o nome do contêiner.
     • Pods do Kubernetes: o nome e o namespace do pod.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome de exibição do recurso: o nome do recurso afetado.
     • Nome completo do recurso: o nome completo do recurso do cluster. O nome completo do recurso inclui as seguintes informações:
       • O projeto que contém o cluster: projects/PROJECT_ID
       • O local em que o cluster está: zone/ZONE ou locations/LOCATION
       • projects/CLUSTER_NAME: o nome do cluster.

3. Na guia JSON, no atributo sourceProperties, observe o valor da propriedade VM_Instance_Name.

Etapa 2: verificar o cluster e o nó

1. No Console do Google Cloud, acesse a página de clusters do Kubernetes.

   Acesse Clusters do Kubernetes

2. Na barra de ferramentas do console do Google Cloud, selecione o projeto que aparece em Nome completo do recurso (resource.name), se necessário. O nome do projeto aparece depois de /projects/ no nome completo do recurso.

3. Clique no nome do cluster que você anotou em Nome de exibição do recurso (resource.display_name) do resumo da descoberta. A página Clusters será aberta.

4. Na página Seção de metadados, na página de detalhes do **Cluster, veja todas as informações definidas pelo usuário que podem ser úteis para resolver a ameaça, como informações que identificam o proprietário do cluster.

5. Clique na guia Nós.

6. Nos nós listados, selecione o nó que corresponde ao valor de VM_Instance_Name que você anotou no JSON de descoberta anteriormente.

7. Na guia Detalhes da páginaDetalhes do nó na seção Anotações, anote o valor da anotação container.googleapis.com/instance_id.

Etapa 3: verificar o pod

1. No console do 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 que você anotou no Nome completo do recurso (resource.name) do cluster no resumo de descobertas, se necessário.

3. Clique em Mostrar cargas de trabalho do sistema.

4. Filtre a lista de cargas de trabalho pelo nome do cluster que você anotou em Nome completo do recurso (resource.name ) do resumo da descoberta e, se necessário, o conjunto Namespace (kubernetes.pods.ns ) que você anotou.

5. Clique no nome da carga de trabalho correspondente ao valor da propriedade VM_Instance_Name anotado anteriormente no JSON de descoberta. A página Detalhes do pod é aberta.

6. Na página Detalhes do pod, veja todas as informações sobre o pod que possam ajudar a resolver a ameaça.

Etapa 4: verificar os registros

1. No Console do 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 que aparece em Nome completo do recurso (resource.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 pod para seu pod (kubernetes.pods.name) usando o seguinte filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="PROJECT_ID"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • resource.labels.namespace_name="NAMESPACE_NAME"
      • resource.labels.pod_name="POD_NAME"
   2. Encontre os registros de auditoria do cluster usando este filtro:
      • logName="projects/PROJECT_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="PROJECT_ID"
      • resource.labels.location="LOCATION_OR_ZONE"
      • resource.labels.cluster_name="CLUSTER_NAME/var>"
      • 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. No Console do Google Cloud, acesse a página de clusters do Kubernetes.

   Acesse Clusters do Kubernetes

2. Clique no nome do cluster mostrado em resource.labels.cluster_name.

3. Na página Clusters, clique em Conectar e em Executar no Cloud Shell.

   O Cloud Shell inicia e adiciona comandos para o cluster no terminal.

4. Pressione Enter e, se a caixa de diálogo Autorizar o Cloud Shell for exibida, clique em Autorizar.

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
   

   Substitua CONTAINER_NAME pelo nome do contêiner que você anotou no resumo da descoberta anteriormente.

   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 o Status do site na Navegação segura para ver detalhes sobre o motivo da classificação do URL como malicioso.
2. Revise as entradas do framework MITRE ATT&CK para esse tipo de descoberta: Transferência de ferramenta de entrada.
3. 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.

Reverse Shell

Um processo começou com o redirecionamento de stream para um soquete conectado remotamente. A geração de um shell conectado à rede pode permitir que um invasor execute ações arbitrárias após um comprometimento inicial limitado. Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Reverse Shell, 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 processo iniciado pelo redirecionamento do stream para um soquete remoto.
     • 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.
     • Nome completo do projeto:
   • Na visualização detalhada da descoberta, clique na guia JSON.
   • No JSON, 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.
     • VM_Instance_Name: o nome do nó do GKE em que o pod foi executado.
     • Reverse_Shell_Stdin_Redirection_Dst_Ip: o endereço IP remoto da conexão;
     • Reverse_Shell_Stdin_Redirection_Dst_Port: a porta remota;
     • Reverse_Shell_Stdin_Redirection_Src_Ip: o endereço IP local da conexão;
     • Reverse_Shell_Stdin_Redirection_Src_Port: a porta local;
     • Container_Image_Uri: o nome da imagem do contêiner que está sendo executada.

Etapa 2: verificar o cluster e o nó

1. No Console do Google Cloud, acesse a página de 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 do 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 em resource.name e no namespace de 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 do 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 console do Google Cloud

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. Inicie um shell no 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.

   Para visualizar todos os processos em execução no contêiner, execute o seguinte comando no shell do contêiner:

     ps axjf
   

   Isso exige que o contêiner tenha /bin/ps instalado.

Etapa 6: pesquisar métodos de ataque e resposta

1. Revise as entradas do framework MITRE ATT&CK para este tipo de descoberta: Intérprete de comando e scripting, Transferência de ferramentas do Ingress.
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.

Unexpected Child Shell

O Container Threat Detection observou um processo que gerou inesperadamente um processo shell filho. Esse evento pode indicar que um invasor está tentando abusar de comandos e scripts do shell.

Para responder a essa descoberta, siga as etapas abaixo.

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Unexpected Child Shell, 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:
     • Processo pai: o processo que criou inesperadamente o processo do shell filho.
     • Processo filho: o processo do shell filho.
     • Argumentos: os argumentos fornecidos para o binário de processo do shell filho.
     • Variáveis de ambiente: as variáveis de ambiente de processo do shell binário filho.
     • Contêineres: o nome do contêiner.
     • URI dos contêineres: o URI da imagem do contêiner.
     • Pods do Kubernetes: o nome e o namespace do pod.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome de exibição do recurso: o nome do recurso afetado.
     • Nome completo do recurso: o nome completo do recurso do cluster. O nome completo do recurso inclui as seguintes informações:
       • O projeto que contém o cluster: projects/PROJECT_ID
       • O local em que o cluster está: zone/ZONE ou locations/LOCATION
       • projects/CLUSTER_NAME: o nome do cluster.

3. Clique na guia JSON e observe os seguintes campos:

+processes: uma matriz contendo todos os processos relacionados à descoberta. Essa matriz inclui o processo do shell filho e o processo pai. +resource: +project_display_name: o nome do projeto que contém os recursos. +sourceProperties: +VM_Instance_Name: o nome do nó do GKE em que o pod foi executado.

Etapa 2: verificar o cluster e o nó

1. No Console do Google Cloud, acesse a página de 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 do 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 que você anotou no Nome completo do recurso (resource.name) do cluster no resumo de descobertas, se necessário.

3. Clique em Mostrar cargas de trabalho do sistema.

4. Filtre a lista de cargas de trabalho pelo nome do cluster que você anotou em Nome completo do recurso (resource.name) do resumo da descoberta e, se necessário, o conjunto Namespace (kubernetes.pods.ns) que você anotou.

5. Clique no nome da carga de trabalho correspondente ao valor da propriedade VM_Instance_Name anotado anteriormente no JSON de descoberta. A página Detalhes do pod é aberta.

6. Na página Detalhes do pod, veja todas as informações sobre o pod que possam ajudar a resolver a ameaça.

Etapa 4: verificar os registros

1. No Console do 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.

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 console do Google Cloud

2. Na barra de ferramentas do Console do Google Cloud, selecione o projeto listado em resource.project_display_name.

3. Clique em Ativar o Cloud Shell.

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

   Para clusters zonais, execute o seguinte:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Para clusters regionais, execute o seguinte:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Para iniciar um shell no ambiente do contêiner, execute o seguinte:

     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.

   Para visualizar todos os processos em execução no contêiner, execute o seguinte comando no shell do contêiner:

     ps axjf
   

   Isso exige que o contêiner tenha /bin/ps instalado.

Etapa 6: pesquisar métodos de ataque e resposta

1. Revise as entradas do framework MITRE ATT&CK para esse tipo de descoberta: Command and Scripting Interpreter: Unix Shell.
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.

Resposta da detecção de ameaças da VM

Para saber mais sobre a detecção de ameaças da VM, consulte Visão geral da detecção de ameaças da VM.

Execution: Cryptocurrency Mining Hash Match

A detecção de ameaças da VM detectou atividades de mineração de criptomoedas pela correspondência de hashes de memória de programas em execução com hashes de memória conhecidos de softwares de mineração de criptomoedas.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Execution: Cryptocurrency Mining Hash Match, conforme direcionado em 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:

     • Família binária: o aplicativo de ameaça que foi detectado.
     • Binário do programa: o caminho absoluto do processo.
     • Argumentos: os argumentos fornecidos ao invocar o binário do processo.
     • Nomes de processo: o nome do processo, em execução na instância de VM, associado às correspondências de assinatura detectadas

     O VM Threat Detection é capaz de reconhecer builds de kernel das principais distribuições do Linux. Se ele reconhecer o build do kernel da VM afetada, poderá identificar os detalhes do processo do aplicativo e preencher o campo processes da descoberta. Se o VM Threat Detection não puder reconhecer o kernel, por exemplo, se o kernel for personalizado, o campo processes da descoberta não será preenchido.

   • Recurso afetado, especialmente os seguintes campos:

     • Nome completo do recurso: o nome completo do recurso da instância de VM afetada, incluindo o ID do projeto que o contém

3. Para ver o JSON completo dessa descoberta, clique na guia JSON na visualização detalhada.

   • indicator
     • signatures:
       • memory_hash_signature: uma assinatura correspondente a hashes de páginas de memória.
       • detections
         • binary: o nome do binário do aplicativo de criptomoeda. Por exemplo, linux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0.
         • percent_pages_matched: a porcentagem de páginas na memória que correspondem a páginas em aplicativos de criptomoedas conhecidos no banco de dados de hash de página.

Etapa 2: verificar os registros

1. No Console do 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 que contém a instância de VM, conforme especificado na linha Nome completo do recurso na guia Resumo dos detalhes de descoberta.

3. Verifique nos registros se há sinais de invasão na instância da VM afetada. Por exemplo, verifique se há atividades suspeitas ou desconhecidas e sinais de credenciais comprometidas.

Etapa 3: verificar permissões e configurações

1. No Console do Google Cloud, abra a página Painel.

   Ir para o Painel

2. Selecione o projeto especificado na linha Nome completo do recurso na guia Resumo do para encontrar detalhes.

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

4. Clique na instância de VM correspondente ao projeto identificado no Nome completo do recurso. Verifique os detalhes da instância, incluindo as configurações de rede e acesso.

Etapa 4: pesquisar métodos de ataque e resposta

1. Revise as entradas de framework do MITRE ATT&CK para Execução.
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.

Para ajudar na detecção e remoção, use uma solução de detecção e resposta de endpoints.

1. Entre em contato com o proprietário da VM.

2. Confirme se o aplicativo é de mineração:

   • Se o nome do processo e o caminho binário do aplicativo detectado estiverem disponíveis, considere os valores nas linhas Binário do programa, Argumentos e Nomes de processo na guia Resumo dos detalhes da descoberta na sua investigação.

   • Se os detalhes do processo não estiverem disponíveis, verifique se o nome binário da assinatura de hash de memória pode fornecer pistas. Considere um binário chamado linux-x86-64_xmrig_2.14.1. Você pode usar o comando grep para pesquisar arquivos importantes no armazenamento. Use uma parte significativa do nome binário no seu padrão de pesquisa, nesse caso, xmrig. Examine os resultados da pesquisa.

   • Examine os processos em execução, especialmente aqueles com alto uso de CPU, para ver se há algum que você não reconhece. Determine se os aplicativos associados são de mineração.

   • Pesquise os arquivos no armazenamento em busca de strings comuns que os aplicativos de mineração usam, como btc.com, ethminer, xmrig, cpuminer e randomx. Para mais exemplos de strings que podem ser pesquisadas, consulte Nomes de software e regras YARA e a documentação relacionada para cada software listado.

3. Se você determinar que o aplicativo é de mineração e o processo ainda está em execução, encerre o processo. Localize o binário executável do aplicativo no armazenamento da VM e exclua-o.

4. Se necessário, interrompa a instância comprometida e substitua-a por uma nova instância.

Execution: Cryptocurrency Mining YARA Rule

A detecção de ameaças da VM detectou atividades de mineração de criptomoedas por meio da correspondência de padrões de memória, como constantes de prova de trabalho, conhecidos por serem usados por softwares de mineração de criptomoedas.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra uma descoberta Execution: Cryptocurrency Mining YARA Rule, conforme direcionado em 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 regra de YARA: é a regra acionada para os detectores de YARA.
     • Binário do programa: o caminho absoluto do processo.
     • Argumentos: os argumentos fornecidos ao invocar o binário do processo.
     • Nomes de processo: o nome dos processos em execução na instância de VM associada à assinatura detectada.

     O VM Threat Detection é capaz de reconhecer builds de kernel das principais distribuições do Linux. Se ele reconhecer o build do kernel da VM afetada, poderá identificar os detalhes do processo do aplicativo e preencher o campo processes da descoberta. Se o VM Threat Detection não puder reconhecer o kernel, por exemplo, se o kernel for personalizado, o campo processes da descoberta não será preenchido.

   • Recurso afetado, especialmente os seguintes campos:

     • Nome completo do recurso: o nome completo do recurso da instância de VM afetada, incluindo o ID do projeto que o contém

   • 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.
     • Chronicle: link para o Google SecOps.

3. Para ver o JSON completo dessa descoberta, clique na guia JSON na visualização detalhada.

Etapa 2: verificar os registros

1. No Console do 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 que contém a instância de VM, conforme especificado na linha Nome completo do recurso na guia Resumo dos detalhes de descoberta.

3. Verifique nos registros se há sinais de invasão na instância da VM afetada. Por exemplo, verifique se há atividades suspeitas ou desconhecidas e sinais de credenciais comprometidas.

Etapa 3: verificar permissões e configurações

1. No Console do Google Cloud, abra a página Painel.

   Ir para o Painel

2. Selecione o projeto especificado no nome do recurso listado na linha Nome completo do recurso na guia Resumo dos detalhes da descoberta.

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

4. Clique na instância de VM correspondente a resourceName. Verifique os detalhes da instância, incluindo as configurações de rede e acesso.

Etapa 4: pesquisar métodos de ataque e resposta

1. Revise as entradas de framework do MITRE ATT&CK para Execução.
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.

Para ajudar na detecção e remoção, use uma solução de detecção e resposta de endpoints.

1. Entre em contato com o proprietário da VM.

2. Confirme se o aplicativo é de mineração:

   • Se o nome do processo e o caminho binário do aplicativo detectado estiverem disponíveis, considere os valores nas linhas Binário do programa, Argumentos e Nomes de processo na guia Resumo dos detalhes da descoberta na sua investigação.

   • Examine os processos em execução, especialmente aqueles com alto uso de CPU, para ver se há algum que você não reconhece. Determine se os aplicativos associados são de mineração.

   • Pesquise os arquivos no armazenamento em busca de strings comuns que os aplicativos de mineração usam, como btc.com, ethminer, xmrig, cpuminer e randomx. Para mais exemplos de strings que podem ser pesquisadas, consulte Nomes de software e regras YARA e a documentação relacionada para cada software listado.

3. Se você determinar que o aplicativo é de mineração e o processo ainda está em execução, encerre o processo. Localize o binário executável do aplicativo no armazenamento da VM e exclua-o.

4. Se necessário, interrompa a instância comprometida e substitua-a por uma nova instância.

Execution: cryptocurrency mining combined detection

O VM Threat Detection detectou várias categorias de descobertas em um único dia usando apenas uma fonte. Um único aplicativo pode acionar Execution: Cryptocurrency Mining YARA Rule e Execution: Cryptocurrency Mining Hash Match findings simultaneamente.

Para responder a uma descoberta combinada, siga as instruções de resposta para Execution: Cryptocurrency Mining YARA Rule e Execution: Cryptocurrency Mining Hash Match findings.

Malware: Malicious file on disk (YARA)

A VM Threat Detection detectou um arquivo potencialmente malicioso ao verificar os discos persistentes de uma VM em busca de assinaturas de malware conhecidas.

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

Etapa 1: verificar os detalhes da descoberta

1. Abra a descoberta Malware: Malicious file on disk (YARA), 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 regra YARA: a regra YARA correspondente.
     • Files: o UUID da partição e o caminho relativo da possível de um arquivo malicioso que foi detectado.
   • Recurso afetado, especialmente os seguintes campos:
     • Nome completo do recurso: o nome completo do recurso da instância de VM afetada, incluindo o ID do projeto que o contém

3. Para ver o JSON completo dessa descoberta, clique na guia JSON na visualização detalhada.

4. No JSON, observe os seguintes campos:

   • indicator
     • signatures:
       • yaraRuleSignature: uma assinatura correspondente à regra YARA que foi correspondida.

Etapa 2: verificar os registros

1. No Console do 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 que contém a instância de VM, conforme especificado na linha Nome completo do recurso na guia Resumo dos detalhes de descoberta.

3. Verifique nos registros se há sinais de invasão na instância da VM afetada. Por exemplo, verifique se há atividades suspeitas ou desconhecidas e sinais de credenciais comprometidas.

Etapa 3: verificar permissões e configurações

1. No Console do Google Cloud, abra a página Painel.

   Ir para o Painel

2. Selecione o projeto especificado no nome do recurso listado na linha Nome completo do recurso na guia Resumo dos detalhes da descoberta.

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

4. Clique na instância de VM correspondente a resourceName. Verifique os detalhes da instância, incluindo as configurações de rede e acesso.

Etapa 4: pesquisar métodos de ataque e resposta

Verifique o valor de hash SHA-256 do arquivo sinalizado como malicioso em VirusTotal (em inglês). O VirusTotal é um serviço da Alphabet que fornece contexto sobre arquivos potencialmente maliciosos, URLs, domínios e endereços IP.

Observação: o VirusTotal pode não conter hashes para todas as variantes de malware.

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.

1. Entre em contato com o proprietário da VM.

2. Se necessário, localize e exclua o arquivo potencialmente malicioso. Para conseguir o o UUID da partição e o caminho relativo do arquivo, consulte o campo Files a guia "Resumo" dos detalhes da descoberta. Para ajudar na detecção e remoção, use uma solução de detecção e resposta de endpoint.

3. Se necessário, interrompa a instância comprometida e substitua-a por uma nova instância.

   Observação :com o nível Security Command Center Enterprise, também é possível fazer isso com uma resposta à ameaça playbook.

4. Para análise forense, considere fazer backup das máquinas virtuais e os discos permanentes padrão. Para mais informações, consulte Opções de proteção de dados na documentação do Compute Engine.

5. Para uma investigação mais aprofundada, considere usar serviços de resposta a incidentes como Mandiant.

Corrigir vulnerabilidades relacionadas

Para ajudar a evitar que as ameaças ocorram novamente, analise e corrija as descobertas relacionadas a vulnerabilidades e configurações incorretas.

Para encontrar descobertas relacionadas, siga estas etapas:

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

   Acesse Descobertas

2. Analise a descoberta de ameaças e copie o valor de um atributo que provavelmente aparecerá em qualquer descoberta relacionada a vulnerabilidades ou configurações incorretas, como o endereço de e-mail principal ou o nome do recurso afetado.

3. Na página Descobertas, abra o Editor de consultas clicando em Editar consulta.

4. Clique em Adicionar filtro. O menu Selecionar filtro será aberto.

5. Na lista de categorias de filtro no lado esquerdo do menu, selecione a categoria que contém o atributo que você anotou na descoberta de ameaças.

   Por exemplo, se você anotou o nome completo do recurso afetado, selecione Recurso. Os tipos de atributo da categoria Recurso são exibidos na coluna à direita, incluindo o atributo Nome completo.

6. Nos atributos exibidos, selecione o tipo de atributo que você anotou na descoberta de ameaças. Um painel de pesquisa de valores dos atributos será aberto à direita e exibirá todos os valores encontrados para o tipo de atributo selecionado.

7. No campo Filtro, cole o valor do atributo que você copiou da descoberta de ameaças. A lista de valores exibida é atualizada para mostrar apenas os valores que correspondem ao valor colado.

8. Na lista de valores exibidos, selecione um ou mais valores e clique em Aplicar. O painel Resultados da consulta de descobertas é atualizado para mostrar apenas as descobertas correspondentes.

9. Se houver muitas descobertas nos resultados, selecione outras opções no painel Filtros rápidos para filtrá-las.

   Por exemplo, para mostrar apenas as descobertas das classes Vulnerability e Misconfiguration que contêm os valores dos atributos selecionados, role a página para baixo até a seção Classe de descoberta do painel Filtros rápidos e selecione Vulnerabilidade e Configuração incorreta.

Além dos indicadores de comprometimento fornecidos pelo Google, os usuários que são clientes da Palo Alto Networks podem integrar o AutoFocus Threat Intelligence da Palo Alto Networks com o de detecção de ameaças a eventos. O AutoFocus é um serviço de inteligência de ameaças que informa sobre ameaças à rede. Para saber mais, acesse a página AutoFocus no console do Google Cloud.

Como corrigir ameaças

Corrigir as descobertas do Event Threat Detection e do Container Threat Detection não é tão simples como corrigir configurações incorretas e vulnerabilidades identificadas o Security Command Center.

Configurações incorretas e violações de conformidade identificam pontos fracos nos recursos que podem ser explorados. Normalmente, configurações incorretas têm correções conhecidas e facilmente implementadas, ativando um firewall ou fazendo a rotação de uma chave de criptografia.

As ameaças diferem das vulnerabilidades porque são dinâmicas e indicam uma possível exploração ativa contra um ou mais recursos. Uma recomendação de correção pode não ser eficaz na proteção de seus recursos porque os métodos exatos usados para conseguir a exploração podem não ser conhecidos.

Por exemplo, uma descoberta Added Binary Executed indica que um binário não autorizado foi iniciado em um contêiner. Uma recomendação de correção básica pode recomendar que você coloque o contêiner em quarentena e exclua o binário, mas isso pode não resolver a causa raiz subjacente que permitiu acesso ao invasor para executar o binário. Para corrigir a exploração, você precisa descobrir como a imagem do contêiner foi corrompida. Para determinar se o arquivo foi adicionado por uma porta configurada incorretamente ou por outro meio, é necessária uma investigação completa. Um analista com conhecimento de nível especializado do sistema pode precisar verificá-lo em busca de pontos fracos.

Os usuários de má-fé atacam recursos usando técnicas diferentes. Portanto, aplicar uma correção para uma exploração específica pode não ser eficaz em variações desse ataque. Por exemplo, em resposta a uma descoberta Brute Force: SSH, é possível diminuir os níveis de permissão para algumas contas de usuário para limitar o acesso a recursos. No entanto, senhas fracas ainda podem fornecer um caminho de ataque.

A amplitude dos vetores de ataque dificulta as etapas de correção que funcionam em todas as situações. O papel do Security Command Center no plano de segurança de nuvem é identificar os recursos afetados em tempo quase real, informar quais ameaças você enfrenta e fornecer evidências e contexto para auxiliar nas investigações. No entanto, sua equipe de segurança precisa usar as informações abrangentes das descobertas do Security Command Center para determinar as melhores maneiras de corrigir problemas e proteger recursos contra ataques futuros.

A seguir

• Consulte Visão geral do Event Threat Detection para saber mais sobre o serviço e as ameaças que ele detecta.

• Consulte a Visão geral do Container Threat Detection para saber como o serviço funciona.

• Consulte Informações gerais sobre a Detecção de ameaças à VM para saber mais sobre o serviço e as ameaças detectadas.