Esta página foi traduzida pela API Cloud Translation.

Investigar e responder a ameaças

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

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

Antes de começar

Você precisa dos papéis adequados do 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. O Event Threat Detection também detecta ameaças ao identificar táticas, técnicas e procedimentos adversos conhecidos no fluxo de geração de registros e ao detectar desvios do comportamento anterior da organização ou do projeto. Se você ativar o nível Premium do Security Command Center no nível da organização, o Event Threat Detection também poderá verificar seus 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:

No console do Google Cloud, acesse a página Descobertas do Security Command Center.
Acesse Descobertas
Se necessário, selecione o projeto, a pasta ou a organização do Google Cloud.
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.
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.
Para visualizar a definição JSON da descoberta, clique na guia JSON.

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

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

Entradas do framework do MITRE ATT&CK. O framework explica técnicas de ataques contra recursos da nuvem e fornece orientações para correção.
VirusTotal, um serviço pertencente à Alphabet que fornece contexto sobre arquivos, URLs, domínios e endereços IP potencialmente maliciosos. Se disponível, o campo Indicador do VirusTotal fornece um link para o VirusTotal para ajudar você a investigar possíveis problemas de segurança.

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

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

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:

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

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.
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.
Se quiser, clique na guia JSON para visualizar outros campos de descoberta.

Etapa 2: pesquisar métodos de ataque e resposta

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

`Defense Evasion: Breakglass Workload Deployment Created`

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

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

Etapa 1: verificar os detalhes da descoberta

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

EmResumo guia dos detalhes da descoberta no console do Google Cloud, acesseExplorador de registros clicando no link URI do Cloud Logging campo
Verifique o valor no campo protoPayload.resourceName para identificar a solicitação de assinatura de certificado específica.
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

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.
Verifique as descobertas relacionadas clicando no link em Descobertas relacionadas na linha Descobertas relacionadas na guia Resumo dos detalhes da descoberta.
Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

`Defense Evasion: Breakglass Workload Deployment Updated`

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

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

Etapa 1: verificar os detalhes da descoberta

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

EmResumo guia dos detalhes da descoberta no console do Google Cloud, acesseExplorador de registros clicando no link URI do Cloud Logging campo
Verifique o valor no campo protoPayload.resourceName para identificar a solicitação de assinatura de certificado específica.
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

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.
Verifique as descobertas relacionadas clicando no link em Descobertas relacionadas na linha Descobertas relacionadas na guia Resumo dos detalhes da descoberta.
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)`

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

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.
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?
Se a aprovação de uma CSR não era esperada ou for considerada maliciosa, o cluster vai exigir uma rotação de credenciais para invalidar o certificado. Consulte as orientações sobre como fazer a rotação das credenciais do cluster.

`Defense Evasion: Modify VPC Service Control`

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

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

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

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

Etapa 1: verificar os detalhes da descoberta

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.
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.
Clique na guia JSON.
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

Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
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

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

Etapa 4: implementar a resposta

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

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

`Defense Evasion: Potential Kubernetes Pod Masquerading`

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

Confirme se o pod é legítimo.
Determine se há outros sinais de atividade maliciosa do pod ou do principal nos registros de auditoria no Cloud Logging.
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.
Se o principal for uma conta de serviço (IAM ou Kubernetes), identifique a origem da ação para determinar a legitimidade.
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.

`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

Abra uma descoberta Discovery: Can get sensitive Kubernetes object check, conforme direcionado em Como verificar descobertas.
No painel Detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:
- Em O que foi detectado:
  - Avaliações de acesso do Kubernetes: as informações solicitadas para a análise de acesso, com base no recurso SelfSubjectAccessReview do k8s.
  - E-mail principal: a conta que fez a chamada.
- Em Recurso afetado:
  - Nome de exibição do recurso: o cluster do Kubernetes em que a ação ocorreu.
- Em Links relacionados:
  - URI do Cloud Logging: link para as entradas do Logging.

Etapa 2: verificar os registros

Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
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

Analise as entradas do framework do MITRE ATT&CK em busca deste tipo de descoberta: Descoberta.
Confirme a confidencialidade do objeto consultado e determine se há outros sinais de atividade maliciosa pelo principal nos registros.
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.
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`

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

Confirme se o pod tem um motivo legítimo para especificar estes comandos e argumentos.
Determine se há outros sinais de atividade maliciosa do pod ou do principal nos registros de auditoria no Cloud Logging.
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.
Se o principal for uma conta de serviço (IAM ou Kubernetes), identifique a legitimidade do que fez com que a conta de serviço realizasse essa ação.
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.

`Execution: Suspicious Exec or Attach to a System Pod`

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

Analise os registros de auditoria no Cloud Logging para determinar se essa era a atividade esperada pelo principal.
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

Abra a descoberta Exfiltration: BigQuery Data Exfiltration, conforme instruído em Como verificar descobertas.
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.
  - Google Security Operations: link para o Google SecOps.
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.
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 essa 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 unificada. 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.

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

Acesse Descobertas
No painel Filtros rápidos, role para baixo até Nome de exibição da origem.
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.
Na tabela, em categoria, clique em uma descoberta Exfiltration: BigQuery Data Exfiltration. O painel de detalhes da descoberta será aberto.
Na seção Links relacionados do painel de detalhes da descoberta, clique em Investigar no Google Security Operations.
Siga as instruções na interface do usuário guiada do Google SecOps.

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

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

No console do Google Cloud, abra a página IAM.

Acessar IAM
Se necessário, selecione o projeto listado no campo projectId no JSON de descoberta.
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

Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
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

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

Etapa 6: implementar a resposta

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

Abra uma descoberta Exfiltration: BigQuery Data Extraction, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
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.
No painel de detalhes da descoberta, clique na guia JSON.
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

No console do Google Cloud, abra a página IAM.

Acessar o IAM
Se necessário, selecione o projeto listado no campo projectId no JSON de descoberta (da Etapa 1).
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

Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
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

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

Etapa 5: implementar a resposta

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

Abra uma descoberta Exfiltration: BigQuery Data to Google Drive, conforme direcionado em Como verificar descobertas.
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.
Para mais informações, clique na guia JSON.
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

No console do Google Cloud, abra a página IAM.

Acessar IAM
Se necessário, selecione o projeto listado no campo projectId no JSON de descoberta (da Etapa 1).
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

Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
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

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

Etapa 5: implementar a resposta

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

Abra uma descoberta Exfiltration: Cloud SQL Data Exfiltration, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
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.
Clique na guia JSON.
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

No console do Google Cloud, abra a página IAM.

Acessar IAM
Se necessário, selecione o projeto da instância listada no campo projectId no JSON de descoberta (da Etapa 1).
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

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

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

Etapa 5: implementar a resposta

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

Abra uma descoberta Exfiltration: Cloud SQL Restore Backup to External Organization, conforme direcionado em Como verificar descobertas.
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.
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.
Clique na guia JSON.
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

No console do Google Cloud, abra a página IAM.

Acessar IAM
Se necessário, selecione o projeto da instância listada no campo projectId no JSON de descoberta (da Etapa 1).
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

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

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

Etapa 5: implementar a resposta

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.
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 do PostgreSQL (ou todas as funções ou procedimentos em um banco de dados) são concedidos a um ou mais usuários do banco de dados.

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

Etapa 1: verificar os detalhes da descoberta

Abra uma descoberta Exfiltration: Cloud SQL Over-Privileged Grant, conforme instruído em Como verificar descobertas.
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.
Para ver o JSON completo da descoberta, clique na guia JSON.

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

Conecte-se ao banco de dados PostgreSQL.
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

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

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

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.

`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 normais diárias. 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. Isso 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

Abra uma descoberta Initial Access: Database Superuser Writes to User Tables, conforme direcionado em Como verificar descobertas.
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 da instância do Cloud SQL.
  - 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.
Para ver o JSON completo da descoberta, clique na guia JSON.

Etapa 2: verificar os registros

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.
Verifique se há registros de auditoria do pgaudit do PostgreSQL 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

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

Revise os usuários autorizados a se conectar ao banco de dados.
- Para o PostgreSQL, consulte Criar e gerenciar usuários.
- Para o MySQL, consulte Gerenciar usuários com a autenticação integrada.
Considere mudar a senha do superusuário.
- Para o PostgreSQL, consulte Definir a senha do usuário padrão.
- Para o MySQL, consulte Definir a senha do usuário padrão.
Crie um usuário de acesso limitado para os diferentes tipos de consultas usadas na instância.
- Conceda ao novo usuário apenas as permissões necessárias para executar as consultas.
  - Para o PostgreSQL, consulte Grant (command).
  - Para o MySQL, consulte Controle de acesso e gerenciamento de contas.
- Atualizar as credenciais dos clientes que se conectam à instância do Cloud SQL

`Initial Access: Anonymous GKE resource created from the internet`

Detecta quando um ator 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) 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 para essa descoberta.

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

`Initial Access: GKE resource modified anonymously from the internet`

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

system:anonymous
system:authenticated
system:unauthenticated

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

Analise o recurso modificado 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 para essa 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

Abra uma descoberta Initial Access: Dormant Service Account Action, conforme instruído em Como verificar descobertas.
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

Use as ferramentas da conta de serviço, como o Activity Analyzer, para investigar a atividade da conta de serviço inativa.
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

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

Abra uma descoberta Initial Access: Dormant Service Account Key Created, conforme instruído em Como verificar descobertas.
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

Use as ferramentas da conta de serviço, como o Activity Analyzer, para investigar a atividade da conta de serviço inativa.
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

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

Abra uma descoberta Initial Access: Leaked Service Account Key Used, conforme instruído em Como verificar descobertas.
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

No console do Google Cloud, acesse a Análise de registros clicando no link no URI do Cloud Logging.
Na barra de ferramentas do console do Google Cloud, selecione o projeto ou a organização.
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

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

Abra uma descoberta Initial Access: Excessive Permission Denied Actions, conforme instruído em Como verificar descobertas.
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.
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

No console do Google Cloud, acesse a Análise de registros clicando no link no URI do Cloud Logging.
Na barra de ferramentas do console do Google Cloud, selecione o projeto.
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

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

Etapa 4: implementar a resposta

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

Abra uma descoberta Brute Force: SSH, conforme direcionado em Como verificar descobertas.
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.
  - Investigar no Google Security Operations: link para o Google SecOps.
Clique na guia JSON.
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 essa 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.

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

Acesse Descobertas
No painel Filtros rápidos, role para baixo até Nome de exibição da origem.
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.
Na tabela, em categoria, clique em uma descoberta Brute Force: SSH. O painel de detalhes da descoberta será aberto.
Na seção Links relacionados do painel de detalhes da descoberta, clique em Investigar no Google Security Operations.
Siga as instruções na interface do usuário guiada do Google SecOps.

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

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

No console do Google Cloud, acesse o Painel.

Ir para o Painel
Selecione o projeto especificado em projectId.
Acesse o card Recursos e clique em Compute Engine.
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.
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

No console do Google Cloud, acesse a Análise de registros clicando no link no URI do Cloud Logging.
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

Verifique a entrada do framework do MITRE ATT&CK em busca deste tipo de descoberta: Contas válidas: contas locais.
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.
Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 6: implementar a resposta

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

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.
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.
No painel de detalhes, clique na guia JSON.
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

Acesse Grupos do Google.

Acesse Grupos do Google
Clique no nome do grupo que você quer analisar.
No menu de navegação, clique em Participantes.
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

Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
Se necessário, selecione o projeto.
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

Analise a entrada do framework do MITRE ATT&CK para esse tipo de descoberta: Contas válidas.
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)`

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

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.
Determine se há outros sinais de atividade maliciosa do principal nos registros de auditoria no Cloud Logging. Por exemplo:
- O principal que tentou aprovar a CSR é diferente de quem a criou?
- O principal tentou solicitar, criar, aprovar ou excluir outras CSRs?
Se a aprovação de uma CSR não era esperada ou for considerada maliciosa, o cluster vai exigir uma rotação de credenciais para invalidar o certificado. Consulte as orientações sobre como fazer a rotação das credenciais do cluster.

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

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

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

`Credential Access: 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

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

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
No painel de navegação, clique em Diretório e selecione Grupos.
Clique no nome do grupo que você quer analisar.
Clique em Configurações de acesso e, em Quem pode participar do grupo, verifique a configuração de participação do grupo.
No menu suspenso, se necessário, altere a configuração de participação.

Etapa 3: verificar os registros

Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
Se necessário, selecione o projeto.
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

Analise a entrada do framework do MITRE ATT&CK para esse tipo de descoberta: Contas válidas.
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`

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

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

Acesse a página IAM no Console do Google Cloud.

Acessar IAM
No campo Filtro, digite o nome da conta listado em groupName.
Analise os papéis confidenciais concedidos ao grupo.
Se o papel sensível recém-adicionado não for necessário, revogue o papel.

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

Etapa 3: verificar os registros

Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
Se necessário, selecione o projeto.
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

Analise a entrada do framework do MITRE ATT&CK para esse tipo de descoberta: Contas válidas.
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

Abra uma descoberta Malware: Cryptomining Bad IP, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
Na guia Resumo, confira as informações nas seguintes seções:
- O que foi detectado, especialmente os seguintes campos:
  - IP de origem: o endereço IP de criptomineração suspeito.
  - Porta de origem: a porta de origem da conexão, se disponível.
  - IP de destino: é o endereço IP de destino.
  - Porta de destino: a porta de destino da conexão, se disponível.
  - Protocolo: o protocolo IANA associado à conexão.
- Recurso afetado
- Links relacionados, incluindo os seguintes campos:
  - URI do Logging: link para as entradas do Logging.
  - Método MITRE ATT&CK: link para a documentação do MITRE ATT&CK.
  - Descobertas relacionadas: links para quaisquer descobertas relacionadas.
  - Flow Analyzer (pré-lançamento): link para o recurso Flow Analyzer do Network Intelligence Center. Esse campo aparece apenas quando os registros de fluxo da VPC estão ativados.
Na visualização detalhada da descoberta, clique na guia Propriedades de origem.
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
```
Para ver o JSON completo da descoberta, clique na guia JSON.

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

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

Ir para o Painel
Selecione o projeto especificado em properties_project_id.
Acesse o card Recursos e clique em Compute Engine.
Clique na instância de VM correspondente a properties_sourceInstance. Investigue a instância possivelmente comprometida em busca de malware.
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

No Console do Google Cloud, acesse o Explorador de registros.

Acessar o Explorador de registros
Na barra de ferramentas do console do Google Cloud, selecione o projeto.
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

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

Etapa 5: implementar a resposta

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

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

No console do Google Cloud, acesse o Explorador de registros clicando no link no URI do Cloud Logging da Etapa 1.
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

Analise a entrada do framework da MITRE ATT&CK para esse tipo de descoberta: Explorar aplicativo voltado para o público.
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.
Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 4: implementar a resposta

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. Saiba mais em A regra do 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

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.
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.
Na visualização detalhada da descoberta, clique na guia JSON.
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

No console do Google Cloud, acesse o Explorador de registros clicando no link no URI do Cloud Logging da Etapa 1.
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

Analise a entrada do framework da MITRE ATT&CK para esse tipo de descoberta: Exploração de serviços remotos.
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.
Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 4: implementar a resposta

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. Saiba mais em A regra do 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

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.
Na guia Resumo, confira as informações nas seguintes seções:

O que foi detectado
Recurso afetado

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

No console do Google Cloud, abra a página IAM.

Acessar IAM
Se necessário, selecione o projeto listado em Project_identifier.
Na página exibida, na caixa Filtro, insira o nome da conta listado em Compromised_account e verifique as permissões atribuídas.
No Console do Google Cloud, acesse a página Contas de serviço.

Acesse Contas de serviço
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

No Console do Google Cloud, acesse o Explorador de registros.

Acessar o Explorador de registros
Na barra de ferramentas do console do Google Cloud, selecione o projeto.
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

Verifique a entrada do framework do MITRE ATT&CK em busca deste tipo de descoberta: Contas válidas: contas do Cloud.
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.
Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 5: implementar a resposta

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

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.
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.
  - Investigar no Google Security Operations: link para o Google SecOps.
  - Indicador do VirusTotal: link para a página de análise do VirusTotal.
  - Flow Analyzer (pré-lançamento): link para o recurso Flow Analyzer do Network Intelligence Center. Esse campo aparece apenas quando os registros de fluxo da VPC estão ativados.
1. Clique na guia JSON e observe o seguinte campo:
  - evidence:
  - sourceLogId:
    - projectID: o ID do projeto em que o problema foi detectado.
  - properties:
  - InstanceDetails: o endereço do recurso da instância do Compute Engine.

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

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

Acesse Descobertas
No painel Filtros rápidos, role a tela até Nome de exibição da origem.
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.
Na tabela, em categoria, clique na descoberta Malware: Bad IP. O painel de detalhes para a descoberta será aberto.
Na seção Links relacionados do painel de detalhes da descoberta, clique em Investigar no Google Security Operations.
Siga as instruções na interface do usuário guiada do Google SecOps.

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

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

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

Ir para o Painel
Selecione o projeto especificado na linha Nome completo do projeto na guia Resumo.
Acesse o card Recursos e clique em Compute Engine.
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.
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

Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
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: verificar o Flow Analyzer

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

Verifique se você fez upgrade do bucket de registros para usar a Análise de dados de registros. Para instruções, consulte Fazer upgrade de um bucket para usar a Análise de dados de registros. Não há custo extra para fazer o upgrade.
No console do Google Cloud, acesse a página Flow Analyzer:

Acessar o Flow Analyzer

Também é possível acessar o Flow Analyzer pelo link URL do Flow Analyzer na seção Links relacionados na guia Resumo do painel Detalhes da descoberta.
Para investigar mais informações relacionadas à descoberta da detecção de ameaças a eventos, use o seletor de período na barra de ações para mudar o período. O período deve refletir quando a descoberta foi relatada pela primeira vez. Por exemplo, se a descoberta foi relatada nas últimas 2 horas, defina o período como Últimas 6 horas. Isso garante que o período no Flow Analyzer inclua o momento em que a descoberta foi informada.
Filtre o Flow Analyzer para mostrar os resultados apropriados para o endereço IP associado à descoberta de IP malicioso:
1. No menu Filtro, na linha Origem da seção Consulta, selecione IP.
2. No campo Valor, digite o endereço IP associado à descoberta e clique em Executar nova consulta.
  
  Se o Analisador de fluxo não mostrar nenhum resultado para o endereço IP, limpe o filtro da linha Origem e execute a consulta novamente com o mesmo filtro na linha Destino.
Analise os resultados. Para mais informações sobre um fluxo específico, clique em Detalhes na tabela Todos os fluxos de dados para abrir o painel Detalhes do fluxo.

Etapa 6: pesquisar métodos de ataque e resposta

Analise as entradas do framework do MITRE ATT&CK em busca deste tipo de descoberta: Resolução dinâmica e Comando e controle.
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.
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.
Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 6: implementar a resposta

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.

`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

Abra uma descoberta Persistence: IAM Anomalous Grant conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
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.
  - Investigar no Google Security Operations: link para o Google SecOps.
Clique na guia JSON. O JSON completo da descoberta será exibido.
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 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.

Não é possível investigar as descobertas do Security Command Center no Google SecOps se você ativar o Security Command Center no nível do projeto.

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

Acesse Descobertas
No painel Filtros rápidos, role para baixo até Nome de exibição da origem.
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.
Na tabela, em categoria, clique em uma descoberta Persistence: IAM Anomalous Grant. O painel de detalhes para a descoberta será aberto.
Na seção Links relacionados do painel de detalhes da descoberta, clique em Investigar no Google Security Operations.
Siga as instruções na interface do usuário guiada do Google SecOps.

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

Etapa 3: verificar os registros

Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
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

Verifique as entradas do framework do MITRE ATT&CK em busca deste tipo de descoberta: Contas válidas: contas do Cloud.
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.
Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 5: implementar a resposta

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

Abra uma descoberta Persistence: Impersonation Role Granted for Dormant Service Account, conforme instruído em Como verificar descobertas.
Nos detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:

Em O que foi detectado:
- E-mail principal: o usuário que realizou a ação de concessão
- Nome do principal das concessões de acesso inadequado: o principal que recebeu o papel de representação
Em Recurso afetado:
- Nome de exibição do recurso: a conta de serviço inativa como um recurso
- Nome completo do projeto: o projeto em que está a conta de serviço inativa

Etapa 2: pesquisar métodos de ataque e resposta

Use as ferramentas da conta de serviço, como o Activity Analyzer, para investigar a atividade da conta de serviço inativa.
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

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

Entre em contato com o proprietário do projeto em que a ação foi realizada.
Remova o acesso do proprietário do E-mail principal se ele estiver comprometido.
Remova o papel de representação concedido recentemente do membro de destino.
Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os aplicativos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, 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.

`Persistence: Unmanaged Account Granted Sensitive Role`

Detecta eventos em que um papel sensível é concedido a uma conta não gerenciada. As contas não gerenciadas não podem ser controladas por administradores do sistema. Por exemplo, quando o funcionário correspondente saiu da empresa, o administrador não pode 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

Abra uma descoberta Persistence: Unmanaged Account Granted Sensitive Role, conforme instruído em Como verificar descobertas.
Nos detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:

Em O que foi detectado:
- E-mail principal: o usuário que realizou a ação de concessão
- Nome do principal das concessões de acesso inadequado: 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

Entre em contato com o proprietário do campo E-mail principal. Confirme se o proprietário legítimo realizou a ação.
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

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

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

Abra a descoberta Persistence: New API Method, conforme instruído em Como verificar descobertas.
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

Verifique as entradas do framework do MITRE ATT&CK em busca deste tipo de descoberta: Persistência.
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.
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

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

Na visualização detalhada da descoberta, clique na guia JSON.
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

No console do Google Cloud, abra a página IAM.

Acessar IAM
Se necessário, selecione o projeto listado no campo projectID no JSON de descoberta.
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

Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
Se necessário, selecione o projeto.
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

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

Etapa 5: implementar a resposta

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

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

No console do Google Cloud, abra a página IAM.

Acessar IAM
Se necessário, selecione o projeto listado em projectId.
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.
No Console do Google Cloud, acesse a página Contas de serviço.

Acesse Contas de serviço
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.
Verifique as chaves e as datas de criação das chaves da conta de serviço.

Etapa 3: verificar os registros

Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
Se necessário, selecione o projeto.
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

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

Etapa 5: implementar a resposta

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

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.
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.
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.
Na vinculação exibida, observe os detalhes dela.

Etapa 2: verificar os registros

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

Revise as entradas do framework MITRE ATT&CK para esse tipo de descoberta: Escalonamento de privilégios.
Confirme se o objeto é sensível e se a modificação foi justificada.
Nas vinculações, verifique o assunto e investigue se o assunto precisa do papel ao qual ele está vinculado.
Determine se há outros sinais de atividade maliciosa pelo principal nos registros.
Se o e-mail principal não for uma conta de serviço, entre em contato com o proprietário da conta para confirmar se o proprietário legítimo realizou a ação.

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

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

EmResumo guia dos detalhes da descoberta no console do Google Cloud, acesseExplorador de registros clicando no link URI do Cloud Logging campo
Verifique o valor no campo protoPayload.resourceName para identificar a solicitação de assinatura de certificado específica.
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

Revise as entradas do framework MITRE ATT&CK para esse tipo de descoberta: Escalonamento de privilégios.
Investigue se a permissão de acesso ao cluster-admin é garantida.
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.
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

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

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

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

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

system:anonymous
system:authenticated
system:unauthenticated

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

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

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

`Privilege Escalation: 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

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

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

Revise as entradas do framework MITRE ATT&CK para esse tipo de descoberta: Escalonamento de privilégios.
Se a CSR específica estiver disponível na entrada de registro, investigue a confidencialidade do certificado e se a ação foi garantida.
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

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

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

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

Abra uma descoberta Privilege Escalation: Dormant Service Account Granted Sensitive Role, conforme instruído em Como verificar descobertas.
Nos detalhes da descoberta, na guia Resumo, observe os valores dos seguintes campos:

Em O que foi detectado:
- E-mail principal: o usuário que realizou a ação de concessão
- Nome do principal das concessões de acesso inadequado: 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

Use as ferramentas da conta de serviço, como o Activity Analyzer, para investigar a atividade da conta de serviço inativa.
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

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

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

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

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.
Investigue os principais da cadeia de delegação para verificar se a solicitação é anormal e se alguma conta foi comprometida.
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

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

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

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.
Investigue os principais da cadeia de delegação para verificar se a solicitação é anormal e se alguma conta foi comprometida.
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

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

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

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.
Investigue os principais da cadeia de delegação para verificar se a solicitação é anormal e se alguma conta foi comprometida.
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

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

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

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.
Investigue os principais da cadeia de delegação para verificar se a solicitação é anormal e se alguma conta foi comprometida.
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

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

Abra uma descoberta Privilege Escalation: Anomalous Service Account Impersonator for Data Access, conforme instruído em Como verificar descobertas.
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

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.
Investigue os principais da cadeia de delegação para verificar se a solicitação é anormal e se alguma conta foi comprometida.
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

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`

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 recebam privilégios cluster-admin. Para mais detalhes, consulte a mensagem de registro desse alerta.

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

`Privilege Escalation: ClusterRoleBinding to Privileged Role`

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

Analise todos os ClusterRoleBinding que fazem referência ao ClusterRole system:controller:clusterrole-aggregation-controller.
Analise as modificações no system:controller:clusterrole-aggregation-controller ClusterRole.
Determine se há outros sinais de atividade maliciosa do principal que criou o ClusterRoleBinding nos registros de auditoria no Cloud Logging.

`Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape`

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

Confirme se o pod é legítimo.
Determine se há outros sinais de atividade maliciosa do pod ou do principal nos registros de auditoria no Cloud Logging.
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.
Se o principal for uma conta de serviço (IAM ou Kubernetes), identifique a origem da ação para determinar a legitimidade.
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`

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

Analise a carga de trabalho para determinar se esse volume de hostPath é necessário para a funcionalidade pretendida. Se sim, verifique se o caminho está no diretório mais específico possível. Por exemplo, /etc/myapp/myfiles em vez de / ou /etc.
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 do pod.

`Privilege Escalation: Workload with shareProcessNamespace enabled`

Alguém implantou uma carga de trabalho com a opção shareProcessNamespace definida como true, permitindo que todos os contêineres compartilhem o mesmo namespace de processo do Linux. Isso pode permitir que um contêiner não confiável ou comprometido aumente privilégios 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 a mensagem de registro deste alerta.

Confirme se a carga de trabalho realmente exige acesso a um namespace de processo compartilhado para todos os contêineres na carga de trabalho.
Verifique se há outros sinais de atividade maliciosa do principal nos registros de auditoria no Cloud Logging.
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.
Se o principal for uma conta de serviço (IAM ou Kubernetes), identifique a legitimidade do que fez com que a conta de serviço realizasse essa ação.

`Service account self-investigation`

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

Etapa 1: verificar os detalhes da descoberta

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

No console do Google Cloud, abra a página IAM.

Acessar IAM
Se necessário, selecione o projeto listado no campo projectID do JSON de descoberta.
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.
No Console do Google Cloud, acesse a página Contas de serviço.

Acesse Contas de serviço
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

Na guia "Resumo" do painel de detalhes da descoberta, clique no link URI do Cloud Logging para abrir o Explorador de registros.
Se necessário, selecione o projeto.
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

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

Etapa 5: implementar a resposta

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

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

No projeto em que a ação foi realizada, acesse o console de gerenciamento.
Confirme se o host excluído não está mais na lista de hosts de backup e DR.
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

Abra a descoberta Inhibit System Recovery: Google Cloud Backup and DR remove plan, conforme detalhado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
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.

No projeto em que a ação foi realizada, acesse o console de gerenciamento.
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 registros de auditoria para detectar a exclusão anômala de um modelo. Um modelo é uma configuração básica de backups que pode ser aplicada a vários aplicativos.

Etapa 1: verificar os detalhes da descoberta

Abra a descoberta Inhibit System Recovery: Google Cloud Backup and DR delete template, conforme detalhado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
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.

No projeto em que a ação foi realizada, acesse o console de gerenciamento.
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.
Para adicionar novamente um modelo, acesse a guia Planos de backup, selecione Modelos e 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

Abra a descoberta Inhibit System Recovery: Google Cloud Backup and DR delete policy, conforme detalhado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
Na guia Resumo, confira as informações nas seguintes seções:
- O que foi detectado, especialmente os seguintes campos:
  - Nome da política: o nome de uma única política, que define a frequência, a programação e o tempo de retenção do backup
  - Assunto principal: um usuário que executou uma ação com sucesso
- Recurso afetado
  - Nome de exibição do recurso: o projeto do qual a política foi excluída.
- Links relacionados, principalmente os seguintes campos:
  - Método MITRE ATTACK: link para a documentação do MITRE ATT&CK
  - URI do Logging: link para abrir a Análise de registros.

Etapa 2: pesquisar métodos de ataque e resposta

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

Etapa 3: implementar a resposta

`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

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.
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 do principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: implementar a resposta

`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

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.
Na guia Resumo, confira as informações nas seguintes seções:
- O que foi detectado, especialmente os seguintes campos:
  - Nome do pool de armazenamento: o nome dos buckets de armazenamento em que os backups são armazenados.
  - Assunto principal: um usuário que executou uma ação com sucesso
- Recurso afetado
  - Nome de exibição do recurso: o projeto do qual o pool de armazenamento foi excluído.
- Links relacionados, principalmente os seguintes campos:
  - Método MITRE ATTACK: link para a documentação do MITRE ATT&CK
  - URI do Logging: link para abrir a Análise de registros

Etapa 2: pesquisar métodos de ataque e resposta

Entre em contato com o proprietário da conta de serviço no campo E-mail 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 "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

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.
Na guia Resumo, confira as informações nas seguintes seções:
- O que foi detectado, especialmente os seguintes campos:
  - Nome da política: o nome de uma única política, que define a frequência, a programação e o tempo de retenção do backup
  - Nome do modelo: o nome de um conjunto de políticas que definem a frequência, a programação e o tempo de retenção do backup
  - Nome do perfil: especifica o destino de armazenamento para backups de dados de aplicativo e VM.
  - Assunto principal: um usuário que executou uma ação com sucesso
- Recurso afetado
  - Nome de exibição do recurso: o projeto do qual a imagem de backup foi excluída.
- Links relacionados, principalmente os seguintes campos:
  - Método MITRE ATTACK: link para a documentação do MITRE ATT&CK
  - URI do Logging: link para abrir a Análise de registros

Etapa 2: pesquisar métodos de ataque e resposta

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

Etapa 3: implementar a resposta

`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

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.
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 do principal. Confirme se o proprietário legítimo realizou a ação.

Etapa 3: implementar a resposta

`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

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.
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 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 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 detectar se a data de validade de um backup em um dispositivo de serviço de backup e DR foi reduzida.

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

Etapa 1: verificar os detalhes da descoberta

Abra a descoberta Impact: Google Cloud Backup and DR reduced backup expiration, conforme detalhado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
Na guia Resumo, confira as informações nas seguintes seções:
- O que foi detectado, especialmente os seguintes campos:
  - Descrição: informações sobre a detecção
  - Assunto principal: um usuário ou uma conta de serviço que executou uma ação
- 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.

No projeto em que a ação foi realizada, acesse o console de gerenciamento.
Na guia App Manager, encontre o aplicativo afetado em que a expiração do backup foi reduzida e verifique se a expiração foi intencional pelo principal.
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

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.
Na guia Resumo, confira as informações nas seguintes seções:
- O que foi detectado, especialmente os seguintes campos:
  - Descrição: informações sobre a detecção
  - Assunto principal: um usuário ou uma conta de serviço que executou uma ação
- Recurso afetado
  - Nome de exibição do recurso: o projeto em que a frequência de backup foi reduzida.
- Links relacionados, principalmente os seguintes campos:
  - Método MITRE ATTACK: link para a documentação do MITRE ATT&CK.
  - URI do Logging: link para abrir a Análise de registros.

Etapa 2: pesquisar métodos de ataque e resposta

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

Etapa 3: implementar a resposta

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

No projeto em que a ação foi realizada, acesse o console de gerenciamento.
Na guia App Manager, encontre o aplicativo afetado em que a frequência de backup foi reduzida e verifique se a mudança foi intencional do principal.
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: Suspicious Kubernetes Container Names - Coin Mining`

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 obteve acesso inicial ao cluster para usar os recursos dele na mineração de criptomoedas. Para mais detalhes, consulte a mensagem de registro desse alerta.

Confirme se o pod é legítimo.
Determine se há outros sinais de atividade maliciosa do pod ou do principal nos registros de auditoria no Cloud Logging.
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.
Se o principal for uma conta de serviço (IAM ou Kubernetes), identifique a origem da ação para determinar a legitimidade.
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 de disco suspeitos entre os recursos de instância do Compute Engine. Um disco de inicialização potencialmente modificado foi anexado ao Compute Engine.

Etapa 1: verificar os detalhes da descoberta

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.
Na guia Resumo, observe os valores dos seguintes campos.

Em O que foi detectado:
- E-mail principal: a conta de serviço que realizou a ação
- Nome do serviço: o nome da API do serviço 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

Use as ferramentas da conta de serviço, como o Activity Analyzer, para investigar a atividade da conta de serviço associada.
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

Entre em contato com o proprietário do projeto em que a ação foi realizada.
Considere usar a Inicialização segura nas instâncias de VM do Compute Engine.
Considere excluir a conta de serviço potencialmente comprometida, bem como trocar e excluir todas as chaves de acesso da conta de serviço do projeto comprometido. Após a exclusão, os aplicativos que usam a conta de serviço para autenticação perdem o acesso. Antes de prosseguir, 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

Abra uma descoberta Privilege Escalation: AlloyDB Over-Privileged Grant, conforme instruído em Como verificar descobertas.
Na guia Resumo do painel de detalhes da descoberta, revise as informações nas seguintes seções:
- O que foi detectado, especialmente os seguintes campos:
  - Nome de exibição do banco de dados: o nome do banco de dados na instância do AlloyDB para PostgreSQL que foi afetada.
  - Nome de usuário do banco de dados: o usuário do PostgreSQL que concedeu privilégios demais.
  - Consulta do banco de dados: a consulta do PostgreSQL executada que concedeu os privilégios.
  - Beneficiários do banco de dados: os beneficiários dos privilégios excessivos.
- Recurso afetado, especialmente os seguintes campos:
  - Nome completo do recurso: o nome do recurso da instância do AlloyDB para PostgreSQL que foi afetada.
  - Nome completo do pai: o nome do recurso da instância do AlloyDB para PostgreSQL.
  - Nome completo do projeto: o projeto 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.
Para ver o JSON completo da descoberta, clique na guia JSON.

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

Conectar-se à instância do AlloyDB para PostgreSQL.
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

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

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

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 em tabelas de usuários. 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

Abra uma descoberta Privilege Escalation: AlloyDB Database Superuser Writes to User Tables, conforme direcionado em Como verificar descobertas.
Na guia Resumo do painel de detalhes da descoberta, revise as informações nas seguintes seções:
- O que foi detectado, especialmente os seguintes campos:
  - Nome de exibição do banco de dados: o nome do banco de dados na instância do AlloyDB para PostgreSQL que foi afetada.
  - Nome de usuário do banco de dados: o superusuário.
  - Consulta de banco de dados: a consulta SQL executada 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 AlloyDB para PostgreSQL que foi afetada.
  - Nome completo do pai: o nome do recurso da instância do AlloyDB para PostgreSQL.
  - Nome completo do projeto: o projeto 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.
Para ver o JSON completo da descoberta, clique na guia JSON.

Etapa 2: verificar os registros

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

Etapa 3: pesquisar métodos de ataque e resposta

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

Revise os usuários autorizados a se conectar ao banco de dados.
Considere mudar a senha do superusuário.
Crie 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.
- Atualizar 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

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/

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

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/

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.

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` Substitua`ORGANIZATION_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

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.

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` Substitua`ORGANIZATION_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

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.

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` Substitua`ORGANIZATION_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

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.

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` Substitua`ORGANIZATION_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

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.

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` Substitua`ORGANIZATION_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

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.

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

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.

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

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.

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` Substitua`ORGANIZATION_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

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:

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

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

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

Detecções de ameaças do Cloud IDS

`Cloud IDS: THREAT_ID`

As descobertas do Cloud IDS são geradas pelo Cloud IDS, que é um serviço de segurança que monitora o tráfego de entrada e saída dos recursos 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

Abra a descoberta Cloud IDS: THREAT_ID, conforme instruído em Como verificar descobertas.
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
Para ver o JSON completo da descoberta, clique na guia JSON.

Etapa 2: procurar métodos de ataque e resposta

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

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

Respostas do Container Threat Detection

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

`Added Binary Executed`

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

Etapa 1: verificar os detalhes da descoberta

Abra uma descoberta Added Binary Executed, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
Na guia Resumo, confira as informações nas seguintes seções:
- O que foi detectado, especialmente os seguintes campos:
  - Binário do programa: o caminho absoluto do binário adicionado.
  - Argumentos: os argumentos fornecidos ao invocar o binário adicionado.
- Recurso afetado, especialmente os seguintes campos:
  - Nome completo do recurso: o nome completo do recurso do cluster, inclusive o número, o local e o nome do cluster do projeto.
- Links relacionados, principalmente os seguintes campos:
  - Indicador do VirusTotal: link para a página de análise do VirusTotal.
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.
Identifique outras descobertas que ocorreram em um horário semelhante para esse contêiner. As descobertas relacionadas podem indicar que essa atividade foi maliciosa, em vez de uma falha em seguir as práticas recomendadas.

Etapa 2: verificar o cluster e o nó

No Console do Google Cloud, acesse a página de clusters do Kubernetes.
Acesse Clusters do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Clique na guia Nós. Selecione o nó listado em VM_Instance_Name.
Clique na guia Detalhes e anote a anotação container.googleapis.com/instance_id.

Etapa 3: verificar o pod

No console do Google Cloud, acesse a página Cargas de trabalho do Kubernetes.
Acesse Cargas de trabalho do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Selecione o pod listado em Pod_Name. Anote os metadados sobre o pod e o proprietário dele.

Etapa 4: verificar os registros

No Console do Google Cloud, acesse o Explorador de registros.

Acessar o Explorador de registros
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Defina Selecionar período como o período de interesse.
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.

Acesse o console do Google Cloud.

Abrir o console do Google Cloud
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Clique em Ativar o Cloud Shell.
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
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.
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

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

Etapa 7: implementar a resposta

Se o binário foi incluído no contêiner, recrie a imagem do contêiner com o binário incluído. 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.

`Added Library Loaded`

Uma biblioteca que não fazia parte da imagem do contêiner original foi carregada. Os invasores podem carregar bibliotecas maliciosas em programas existentes para ignorar as proteções de execução de código e ocultar o código malicioso. Garantir que os contêineres sejam imutáveis é uma prática recomendada importante. Essa é uma descoberta de baixa gravidade, porque sua organização pode não estar seguindo essa prática recomendada. Há resultados Execution: Added Malicious Library Loaded correspondentes quando o hash do binário é um indicador de comprometimento (IoC, na sigla em inglês) conhecido. Para responder a essa descoberta, faça o seguinte:

Etapa 1: verificar os detalhes da descoberta

Abra uma descoberta Added Library Loaded, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
Na guia Resumo, confira as informações nas seguintes seções:
- O que foi detectado, especialmente os seguintes campos:
  - Binário do programa: o caminho completo do binário do processo que carregou a biblioteca.
  - Bibliotecas: detalhes sobre a biblioteca adicionada.
  - Argumentos: os argumentos fornecidos ao invocar o binário do processo.
- Recurso afetado, especialmente os seguintes campos:
  - Nome completo do recurso: o nome completo do recurso do cluster.
- Links relacionados, principalmente os seguintes campos:
  - Indicador do VirusTotal: link para a página de análise do VirusTotal.
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.
Identifique outras descobertas que ocorreram em um horário semelhante para esse contêiner. As descobertas relacionadas podem indicar que essa atividade foi maliciosa, em vez de uma falha em seguir as práticas recomendadas.

Etapa 2: verificar o cluster e o nó

No Console do Google Cloud, acesse a página de clusters do Kubernetes.
Acesse Clusters do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Selecione o cluster listado em resource.name. Anote os metadados sobre o cluster e o proprietário dele.
Clique na guia Nós. Selecione o nó listado em VM_Instance_Name.
Clique na guia Detalhes e anote a anotação container.googleapis.com/instance_id.

Etapa 3: verificar o pod

No console do Google Cloud, acesse a página Cargas de trabalho do Kubernetes.
Acesse Cargas de trabalho do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Selecione o pod listado em Pod_Name. Anote os metadados sobre o pod e o proprietário dele.

Etapa 4: verificar os registros

No Console do Google Cloud, acesse o Explorador de registros.

Acessar o Explorador de registros
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Defina Selecionar período como o período de interesse.
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.

Acesse o console do Google Cloud.

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

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

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

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

Etapa 7: implementar a resposta

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 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 Binary Executed`

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

Etapa 1: verificar os detalhes da descoberta

Abra uma descoberta Execution: Added Malicious Binary Executed, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
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 dos 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.
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ó

No Console do Google Cloud, acesse a página de clusters do Kubernetes.
Acesse Clusters do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Clique na guia Nós. Selecione o nó listado em VM_Instance_Name.
Clique na guia Detalhes e anote a anotação container.googleapis.com/instance_id.

Etapa 3: verificar o pod

No console do Google Cloud, acesse a página Cargas de trabalho do Kubernetes.
Acesse Cargas de trabalho do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Selecione o pod listado em Pod_Name. Anote os metadados sobre o pod e o proprietário dele.

Etapa 4: verificar os registros

No Console do Google Cloud, acesse o Explorador de registros.

Acessar o Explorador de registros
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Defina Selecionar período como o período de interesse.
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.

Acesse o console do Google Cloud.

Abrir o console do Google Cloud
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Clique em Ativar o Cloud Shell.
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
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.
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

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

Etapa 7: implementar a resposta

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

Abra uma descoberta Execution: Added Malicious Library Loaded, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
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 dos 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.
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ó

No Console do Google Cloud, acesse a página de clusters do Kubernetes.
Acesse Clusters do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Clique na guia Nós. Selecione o nó listado em VM_Instance_Name.
Clique na guia Detalhes e anote a anotação container.googleapis.com/instance_id.

Etapa 3: verificar o pod

No console do Google Cloud, acesse a página Cargas de trabalho do Kubernetes.
Acesse Cargas de trabalho do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Selecione o pod listado em Pod_Name. Anote os metadados sobre o pod e o proprietário dele.

Etapa 4: verificar os registros

No Console do Google Cloud, acesse o Explorador de registros.

Acessar o Explorador de registros
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Defina Selecionar período como o período de interesse.
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.

Acesse o console do Google Cloud.

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

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

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 a biblioteca maliciosa adicionada.
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

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

Etapa 7: implementar a resposta

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 invasor tem controle do repositório de imagens do contêiner ou do 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

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

No Console do Google Cloud, acesse a página de clusters do Kubernetes.
Acesse Clusters do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Clique na guia Nós. Selecione o nó listado em VM_Instance_Name.
Clique na guia Detalhes e anote a anotação container.googleapis.com/instance_id.

Etapa 3: verificar o pod

No console do Google Cloud, acesse a página Cargas de trabalho do Kubernetes.
Acesse Cargas de trabalho do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Selecione o pod listado em Pod_Name. Anote os metadados sobre o pod e o proprietário dele.

Etapa 4: verificar os registros

No Console do Google Cloud, acesse o Explorador de registros.

Acessar o Explorador de registros
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Defina Selecionar período como o período de interesse.
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.

Acesse o console do Google Cloud.

Abrir o console do Google Cloud
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Clique em Ativar o Cloud Shell.
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
Extraia 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.
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

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

Etapa 7: implementar a resposta

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: Container Escape`

Um binário de ferramenta suspeita conhecida para atividades de escape de contêiner foi executado. Isso pode indicar uma tentativa de escape do contêiner, em que um processo dentro dele tenta sair do isolamento e interagir com o sistema host ou outros contêineres. Essa é uma descoberta de alta gravidade, porque sugere que um atacante pode estar tentando acessar além dos limites do contêiner, comprometendo potencialmente o host ou outra infraestrutura. As fugas de contêineres podem resultar de configurações incorretas, vulnerabilidades em ambientes de execução de contêineres ou exploração de contêineres privilegiados.

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

Etapa 1: verificar os detalhes da descoberta

Abra uma descoberta Execution: Container Escape, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
Na guia Resumo, confira as informações nas seguintes seções:
- O que foi detectado, especialmente os seguintes campos:
  - Binário do programa: o caminho absoluto do binário executado.
  - Argumentos: os argumentos transmitidos durante a execução do binário.
- 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.
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 cluster.
- finding:
  - processes:
  - binary:
    - path: o caminho completo do binário executado.
  - args: os argumentos fornecidos durante a execução do binário.
- sourceProperties:
  - Pod_Namespace: o nome do namespace do Kubernetes do pod.
  - Pod_Name: o nome do pod do GKE.
  - Container_Name: o nome do contêiner afetado.
  - Container_Image_Uri: o nome da imagem do contêiner que está sendo implantada.
  - VM_Instance_Name: o nome do nó do GKE em que o pod foi executado.
Identifique outras descobertas que ocorreram em um horário semelhante para esse contêiner. As descobertas relacionadas podem indicar que essa atividade foi maliciosa, em vez de uma falha em seguir as práticas recomendadas.

Etapa 2: verificar o cluster e o nó

No Console do Google Cloud, acesse a página de clusters do Kubernetes.
Acesse os clusters do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Clique na guia Nós. Selecione o nó listado em VM_Instance_Name.
Clique na guia Detalhes e anote a anotação container.googleapis.com/instance_id.

Etapa 3: verificar o pod

No console do Google Cloud, acesse a página Cargas de trabalho do Kubernetes.
Acesse Cargas de trabalho do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Selecione o pod listado em Pod_Name. Anote os metadados sobre o pod e o proprietário dele.

Etapa 4: verificar os registros

No Console do Google Cloud, acesse o Explorador de registros.

Acessar a Análise de registros
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Defina Selecionar período como o período de interesse.
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.

Acesse o console do Google Cloud.

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

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

Extraia o binário executado:

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

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

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

Analise as entradas do framework do MITRE ATT&CK para esse tipo de descoberta: Escape to Host.
Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 7: implementar a resposta

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: Kubernetes Attack Tool Execution`

Uma ferramenta de ataque do Kubernetes foi executada no contêiner, indicando uma tentativa de exploração de vulnerabilidades no ambiente do Kubernetes. Essas ferramentas geralmente são usadas por invasores para aumentar privilégios, realizar movimentos laterais ou comprometer outros recursos no cluster. Essa é uma verificação de gravidade crítica, porque a execução dessas ferramentas sugere uma tentativa deliberada de assumir o controle de componentes do Kubernetes, como o servidor da API, nós ou cargas de trabalho. Os invasores podem usar essas ferramentas para contornar os controles de segurança, manipular configurações ou exfiltrar dados sensíveis.

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

Etapa 1: verificar os detalhes da descoberta

Abra uma descoberta Execution: Kubernetes Attack Tool Execution, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
Na guia Resumo, confira as informações nas seguintes seções:
- O que foi detectado, especialmente os seguintes campos:
  - Binário do programa: o caminho absoluto do binário executado.
  - Argumentos: os argumentos transmitidos durante a execução do binário.
- 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.
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 cluster.
- finding:
  - processes:
    - binary:
    - path: o caminho completo do binário executado.
  - args: os argumentos fornecidos durante a execução do binário.
- sourceProperties:
  - Pod_Namespace: o nome do namespace do Kubernetes do pod.
  - Pod_Name: o nome do pod do GKE.
  - Container_Name: o nome do contêiner afetado.
  - Container_Image_Uri: o nome da imagem do contêiner que está sendo implantada.
  - VM_Instance_Name: o nome do nó do GKE em que o pod foi executado.
Identifique outras descobertas que ocorreram em um horário semelhante para esse contêiner. As descobertas relacionadas podem indicar que essa atividade foi maliciosa, em vez de uma falha em seguir as práticas recomendadas.

Etapa 2: verificar o cluster e o nó

No Console do Google Cloud, acesse a página de clusters do Kubernetes.
Acesse os clusters do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Clique na guia Nós. Selecione o nó listado em VM_Instance_Name.
Clique na guia Detalhes e anote a anotação container.googleapis.com/instance_id.

Etapa 3: verificar o pod

No console do Google Cloud, acesse a página Cargas de trabalho do Kubernetes.
Acesse Cargas de trabalho do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Selecione o pod listado em Pod_Name. Anote os metadados sobre o pod e o proprietário dele.

Etapa 4: verificar os registros

No Console do Google Cloud, acesse o Explorador de registros.

Acessar a Análise de registros
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Defina Selecionar período como o período de interesse.
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.

Acesse o console do Google Cloud.

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

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

Extraia o binário executado:

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

Substitua LOCAL_FILE por um caminho de arquivo local para armazenar o binário executado.

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

Revise as entradas do framework do MITRE ATT&CK para esse tipo de descoberta: Obter recursos: ferramenta.
Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 7: implementar a resposta

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: Local Reconnaissance Tool Execution`

Uma ferramenta de reconhecimento local foi executada no contêiner, sugerindo que um invasor está coletando informações sobre o ambiente do contêiner, como configurações de rede, processos ativos ou sistemas de arquivos montados. Esse tipo de ferramenta geralmente é usado nos estágios iniciais de um ataque para mapear possíveis alvos e identificar pontos fracos. Essa é uma descoberta de gravidade média, porque indica que o invasor está sondando ativamente o contêiner em busca de mais oportunidades de exploração.

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

Etapa 1: verificar os detalhes da descoberta

Abra uma descoberta Execution: Local Reconnaissance Tool Execution, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
Na guia Resumo, confira as informações nas seguintes seções:
- O que foi detectado, especialmente os seguintes campos:
  - Binário do programa: o caminho absoluto do binário executado.
  - Argumentos: os argumentos transmitidos durante a execução do binário.
- Recurso afetado, especialmente os seguintes campos:
  - Nome completo do recurso: o nome completo do recurso do cluster, incluindo o número, o local e o nome do cluster 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 cluster.
- finding:
  - processes:
    - binary:
    - path: o caminho completo do binário executado.
  - args: os argumentos fornecidos durante a execução do binário.
- sourceProperties:
  - Pod_Namespace: o nome do namespace do Kubernetes do pod.
  - Pod_Name: o nome do pod do GKE.
  - Container_Name: o nome do contêiner afetado.
  - Container_Image_Uri: o nome da imagem do contêiner que está sendo implantada.
  - VM_Instance_Name: o nome do nó do GKE em que o pod foi executado.
Identifique outras descobertas que ocorreram em um horário semelhante para esse contêiner. As descobertas relacionadas podem indicar que essa atividade foi maliciosa, em vez de uma falha em seguir as práticas recomendadas.

Etapa 2: verificar o cluster e o nó

No Console do Google Cloud, acesse a página de clusters do Kubernetes.
Acesse Clusters do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Clique na guia Nós. Selecione o nó listado em VM_Instance_Name.
Clique na guia Detalhes e anote a anotação container.googleapis.com/instance_id.

Etapa 3: verificar o pod

No console do Google Cloud, acesse a página Cargas de trabalho do Kubernetes.
Acesse Cargas de trabalho do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Selecione o pod listado em Pod_Name. Anote os metadados sobre o pod e o proprietário dele.

Etapa 4: verificar os registros

No Console do Google Cloud, acesse o Explorador de registros.

Acessar a Análise de registros
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Defina Selecionar período como o período de interesse.
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.

Acesse o console do Google Cloud.

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

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

Extraia o binário adicionado:

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.

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

Revise as entradas do framework do MITRE ATT&CK para esse tipo de descoberta: Verificação ativa.
Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 7: implementar a resposta

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`

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 os contêineres sejam imutáveis é uma prática recomendada importante. O uso de scripts para transferir ferramentas pode imitar a técnica de transferência de ferramentas de entrada do invasor e resultar em detecções indesejadas.

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

Etapa 1: verificar os detalhes da descoberta

Abra uma descoberta Execution: Malicious Python executed, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
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 literal de scripts, 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, incluindo o número, o local e o nome do cluster.
- Links relacionados, principalmente os seguintes campos:
  - Indicador do VirusTotal: link para a página de análise do VirusTotal.
Na visualização detalhada da descoberta, clique na guia JSON.
No JSON, observe os seguintes campos.
- finding:
  - processes:
  - script:
    - contents: o conteúdo do script executado, que pode ser truncado 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.
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ó

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

Acesse Clusters do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Clique na guia Nós. Selecione o nó listado em VM_Instance_Name.
Clique na guia Detalhes e anote a anotação container.googleapis.com/instance_id.

Etapa 3: verificar o pod

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

Acesse Cargas de trabalho do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Filtre no cluster listado em resource.name e no namespace de pod listado em Pod_Namespace, se necessário.
Selecione o pod listado em Pod_Name. Anote os metadados sobre o pod e o proprietário dele.

Etapa 4: verificar os registros

No Console do Google Cloud, acesse o Explorador de registros.

Acessar o Explorador de registros
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Defina Selecionar período como o período de interesse.
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.

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

Acesse Clusters do Kubernetes
Clique no nome do cluster mostrado em resource.labels.cluster_name.
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.
Pressione Enter e, se a caixa de diálogo Autorizar o Cloud Shell aparecer, clique em Autorizar.
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

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

Etapa 7: implementar a resposta

Se o Python estiver fazendo mudanças pretendidas no contêiner, recrie a imagem do contêiner para que nenhuma mudança 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.
Identificado como malicioso com base na inteligência contra 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

Abra uma descoberta Execution: Modified Malicious Binary Executed, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
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 dos 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.
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ó

No Console do Google Cloud, acesse a página de clusters do Kubernetes.
Acesse Clusters do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Clique na guia Nós. Selecione o nó listado em VM_Instance_Name.
Clique na guia Detalhes e anote a anotação container.googleapis.com/instance_id.

Etapa 3: verificar o pod

No console do Google Cloud, acesse a página Cargas de trabalho do Kubernetes.
Acesse Cargas de trabalho do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Selecione o pod listado em Pod_Name. Anote os metadados sobre o pod e o proprietário dele.

Etapa 4: verificar os registros

No Console do Google Cloud, acesse o Explorador de registros.

Acessar o Explorador de registros
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Defina Selecionar período como o período de interesse.
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.

Acesse o console do Google Cloud.

Abrir o console do Google Cloud
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Clique em Ativar o Cloud Shell.
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
Extraia 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.
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

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

Etapa 7: implementar a resposta

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

Abra uma descoberta Execution: Modified Malicious Library Loaded, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
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 dos 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.
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ó

No Console do Google Cloud, acesse a página de clusters do Kubernetes.
Acesse Clusters do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Selecione o cluster listado em resource.name. Anote os metadados sobre o cluster e o proprietário dele.
Clique na guia Nós. Selecione o nó listado em VM_Instance_Name.
Clique na guia Detalhes e anote a anotação container.googleapis.com/instance_id.

Etapa 3: verificar o pod

No console do Google Cloud, acesse a página Cargas de trabalho do Kubernetes.
Acesse Cargas de trabalho do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Selecione o pod listado em Pod_Name. Anote os metadados sobre o pod e o proprietário dele.

Etapa 4: verificar os registros

No Console do Google Cloud, acesse o Explorador de registros.

Acessar o Explorador de registros
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Defina Selecionar período como o período de interesse.
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.

Acesse o console do Google Cloud.

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

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

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

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

Etapa 7: implementar a resposta

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 aprendizado de máquina 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 de transferência de ferramentas de entrada do invasor e resultar em detecções indesejadas.

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

Etapa 1: verificar os detalhes da descoberta

Abra uma descoberta Malicious Script Executed conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
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, incluindo o número, o local e o nome do cluster.
- Links relacionados, principalmente os seguintes campos:
  - Indicador do VirusTotal: link para a página de análise do VirusTotal.
Na visualização detalhada da descoberta, clique na guia JSON.
No JSON, observe os seguintes campos.
- finding:
  - processes:
  - script:
    - contents: o conteúdo do script executado, que pode ser truncado 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.
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ó

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

Acesse Clusters do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
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.
Clique na guia Nós. Selecione o nó listado em VM_Instance_Name.
Clique na guia Detalhes e anote a anotação container.googleapis.com/instance_id.

Etapa 3: verificar o pod

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

Acesse Cargas de trabalho do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Filtre no cluster listado em resource.name e no namespace de pod listado em Pod_Namespace, se necessário.
Selecione o pod listado em Pod_Name. Anote os metadados sobre o pod e o proprietário dele.

Etapa 4: verificar os registros

No Console do Google Cloud, acesse o Explorador de registros.

Acessar o Explorador de registros
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Defina Selecionar período como o período de interesse.
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.

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

Acesse Clusters do Kubernetes
Clique no nome do cluster mostrado em resource.labels.cluster_name.
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.
Pressione Enter e, se a caixa de diálogo Autorizar o Cloud Shell for exibida, clique em Autorizar.
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

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

Etapa 7: implementar a resposta

Se o script estava fazendo mudanças no contêiner, recrie a imagem do contêiner para que nenhuma mudança 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`

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

Abra uma descoberta Malicious URL Observed conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
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.
- Links relacionados, principalmente os seguintes campos:
  - Indicador do VirusTotal: link para a página de análise do VirusTotal.
Na guia JSON, no atributo sourceProperties, observe o valor da propriedade VM_Instance_Name.

Etapa 2: verificar o cluster e o nó

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

Acesse Clusters do Kubernetes
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.
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.
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.
Clique na guia Nós.
Nos nós listados, selecione o nó que corresponde ao valor de VM_Instance_Name que você anotou no JSON de descoberta anteriormente.
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

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

Acesse Cargas de trabalho do Kubernetes
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.
Clique em Mostrar cargas de trabalho do sistema.
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.
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.
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

No Console do Google Cloud, acesse o Explorador de registros.

Acessar o Explorador de registros
Na barra de ferramentas do console do Google Cloud, selecione o projeto que aparece em Nome completo do recurso (resource.name), se necessário.
Defina Selecionar período como o período de interesse.
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.

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

Acesse Clusters do Kubernetes
Clique no nome do cluster mostrado em resource.labels.cluster_name.
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.
Pressione Enter e, se a caixa de diálogo Autorizar o Cloud Shell for exibida, clique em Autorizar.
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

Verifique o Status do site na Navegação segura para ver detalhes sobre o motivo da classificação do URL como malicioso.
Revise as entradas do framework MITRE ATT&CK para esse tipo de descoberta: Transferência de ferramenta de entrada.
Verifique o valor de hash SHA-256 do binário sinalizado como malicioso no VirusTotal clicando no link no indicador do VirusTotal. O VirusTotal é um serviço pertencente à Alphabet que fornece contexto sobre arquivos, URLs, domínios e endereços IP potencialmente maliciosos.
Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE e a análise do VirusTotal.

Etapa 7: implementar a resposta

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

Abra uma descoberta Reverse Shell, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
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: o projeto do Google Cloud afetado.
- Links relacionados, principalmente os seguintes campos:
  - Indicador do VirusTotal: link para a página de análise do VirusTotal.
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ó

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

Acesse Clusters do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Selecione o cluster listado em resource.name. Anote os metadados sobre o cluster e o proprietário dele.
Clique na guia Nós. Selecione o nó listado em VM_Instance_Name.
Clique na guia Detalhes e anote a anotação container.googleapis.com/instance_id.

Etapa 3: verificar o pod

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

Acesse Cargas de trabalho do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Filtre no cluster listado em resource.name e no namespace de pod listado em Pod_Namespace, se necessário.
Selecione o pod listado em Pod_Name. Anote os metadados sobre o pod e o proprietário dele.

Etapa 4: verificar os registros

No Console do Google Cloud, acesse o Explorador de registros.

Acessar o Explorador de registros
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Defina Selecionar período como o período de interesse.
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.

Acesse o console do Google Cloud.

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

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

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

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

Etapa 7: implementar a resposta

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

Abra uma descoberta Unexpected Child Shell, conforme direcionado em Como verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
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.
- Links relacionados, principalmente os seguintes campos:
  - Indicador do VirusTotal: link para a página de análise do VirusTotal.
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ó

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

Acesse Clusters do Kubernetes
Na barra de ferramentas do console do Google Cloud, selecione o projeto listado em resource.project_display_name, se necessário.
Selecione o cluster listado em resource.name. Anote os metadados sobre o cluster e o proprietário dele.
Clique na guia Nós. Selecione o nó listado em VM_Instance_Name.
Clique na guia Detalhes e anote a anotação container.googleapis.com/instance_id.

Etapa 3: verificar o pod

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

Acesse Cargas de trabalho do Kubernetes
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.
Clique em Mostrar cargas de trabalho do sistema.
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.
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.
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

No Console do Google Cloud, acesse o Explorador de registros.

Acessar a Análise de registros
Na barra de ferramentas do Console do Google Cloud, selecione o projeto listado em resource.project_display_name.
Defina Selecionar período como o período de interesse.
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.

Acesse o console do Google Cloud.

Abrir o console do Google Cloud
Na barra de ferramentas do Console do Google Cloud, selecione o projeto listado em resource.project_display_name.
Clique em Ativar o Cloud Shell.

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

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

Revise as entradas do framework MITRE ATT&CK para esse tipo de descoberta: Command and Scripting Interpreter: Unix Shell.
Verifique o valor de hash SHA-256 do binário sinalizado como malicioso no VirusTotal clicando no link no indicador do VirusTotal. O VirusTotal é um serviço pertencente à Alphabet que fornece contexto sobre arquivos, URLs, domínios e endereços IP potencialmente maliciosos.
Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE e a análise do VirusTotal.

Etapa 7: implementar a resposta

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.

`Defense Evasion: Rootkit`

A VM Threat Detection detectou uma combinação de sinais que correspondem a um rootkit no modo kernel conhecido em uma instância de VM do Compute Engine.

A categoria de descoberta Defense Evasion: Rootkit é um superconjunto das seguintes categorias de descoberta. Portanto, esta seção também se aplica a essas categorias de descoberta.

Defense Evasion: Unexpected ftrace handler (Pré-lançamento)
Defense Evasion: Unexpected interrupt handler (Pré-lançamento)
Defense Evasion: Unexpected kernel code modification (Pré-lançamento)
Defense Evasion: Unexpected kernel modules (Pré-lançamento)
Defense Evasion: Unexpected kernel read-only data modification (Pré-lançamento)
Defense Evasion: Unexpected kprobe handler (Pré-lançamento)
Defense Evasion: Unexpected processes in runqueue (Pré-lançamento)
Defense Evasion: Unexpected system call handler (Pré-lançamento)

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

Etapa 1: verificar os detalhes da descoberta

Abra a descoberta, conforme instruído em Verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
Na guia Resumo, confira as informações nas seguintes seções:
- O que foi detectado, especialmente os seguintes campos:
  - Nome do rootkit do kernel: o sobrenome do rootkit que foi detectado, por exemplo, Diamorphine.
  - Páginas inesperadas de código do kernel: se as páginas de código do kernel estão presentes em regiões de código de kernel ou módulo em que não são esperadas.
  - Manipulador inesperado de chamadas do sistema: se os gerenciadores de chamadas do sistema estão presentes em regiões de código de kernel ou módulo em que não são esperados.
- Recurso afetado, especialmente o seguinte campo:
  - Nome completo do recurso: o nome completo do recurso da instância de VM afetada, incluindo o ID do projeto que o contém
Para ver o JSON completo dessa descoberta, clique na guia JSON na visualização detalhada.

Etapa 2: verificar os registros

No Console do Google Cloud, acesse o Explorador de registros.

Acessar a Análise de registros
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 da descoberta.
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

Na guia Resumo dos detalhes da descoberta, clique no link no campo Nome completo do recurso.
Revise os detalhes da instância de VM, incluindo as configurações de rede e acesso.

Etapa 4: inspecionar a VM afetada

Siga as instruções em Inspecionar uma VM para verificar se há sinais de adulteração da memória do kernel.

Etapa 5: pesquisar métodos de ataque e resposta

Revise as entradas do framework do MITRE ATT&CK para Evasão de defesa.
Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 6: implementar a resposta

Entre em contato com o proprietário da VM.
Se necessário, interrompa a instância comprometida e substitua-a por uma nova instância.
Para análises forenses, considere fazer backup das máquinas virtuais e dos discos persistentes. Para mais informações, consulte Opções de proteção de dados na documentação do Compute Engine.
Exclua a instância da VM.
Para uma investigação mais detalhada, considere usar serviços de resposta a incidentes, como Mandiant.

`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

Abra uma descoberta Execution: Cryptocurrency Mining Hash Match, conforme direcionado em Verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
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
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

No Console do Google Cloud, acesse o Explorador de registros.

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

Na guia Resumo dos detalhes da descoberta, clique no link no campo Nome completo do recurso.
Revise os detalhes da instância de VM, incluindo as configurações de rede e acesso.

Etapa 4: pesquisar métodos de ataque e resposta

Revise as entradas de framework do MITRE ATT&CK para Execução.
Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 5: implementar a resposta

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

Entre em contato com o proprietário da VM.
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.
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.
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

Abra uma descoberta Execution: Cryptocurrency Mining YARA Rule, conforme direcionado em Verificar descobertas. O painel de detalhes da descoberta é aberto na guia Resumo.
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.
  - Investigar no Google Security Operations: link para o Google SecOps.
Para ver o JSON completo dessa descoberta, clique na guia JSON na visualização detalhada.

Etapa 2: verificar os registros

No Console do Google Cloud, acesse o Explorador de registros.

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

Na guia Resumo dos detalhes da descoberta, clique no link no campo Nome completo do recurso.
Revise os detalhes da instância de VM, incluindo as configurações de rede e acesso.

Etapa 4: pesquisar métodos de ataque e resposta

Revise as entradas de framework do MITRE ATT&CK para Execução.
Para desenvolver um plano de resposta, combine os resultados da investigação com a pesquisa do MITRE.

Etapa 5: implementar a resposta

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

Entre em contato com o proprietário da VM.
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.
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.
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 permanentes 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

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.
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 que foi correspondida.
  - Arquivos: o UUID da partição e o caminho relativo do arquivo potencialmente 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
Para ver o JSON completo dessa descoberta, clique na guia JSON na visualização detalhada.
No JSON, observe os seguintes campos:
- indicator
  - signatures:
    - yaraRuleSignature: uma assinatura correspondente à regra YARA que foi correspondida.

Etapa 2: verificar os registros

No Console do Google Cloud, acesse o Explorador de registros.

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

Na guia Resumo dos detalhes da descoberta, clique no link no campo Nome completo do recurso.
Revise os detalhes da instância de VM, 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 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 5: implementar a resposta

Entre em contato com o proprietário da VM.
Se necessário, localize e exclua o arquivo potencialmente malicioso. Para conferir o UUID da partição e o caminho relativo do arquivo, consulte o campo Files na guia Summary dos detalhes da descoberta. 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.

Observação: com o nível Security Command Center Enterprise, também é possível realizar essa ação usando um playbook de resposta a ameaças.
Para análises forenses, considere fazer backup das máquinas virtuais e dos discos persistentes. Para mais informações, consulte Opções de proteção de dados na documentação do Compute Engine.
Para uma investigação mais detalhada, 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:

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

Acesse Descobertas
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.
Na página Descobertas, abra o Editor de consultas clicando em Editar consulta.
Clique em Adicionar filtro. O menu Selecionar filtro será aberto.
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.
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.
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.
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.
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 quanto corrigir erros de configurações incorretas e vulnerabilidades identificadas pelo 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 Visão geral da detecção de ameaças da VM para saber mais sobre o serviço e as ameaças que ele detecta.