Tutorial: investigar incidentes usando dados do UEBA

  • Artigo

Este artigo descreve os métodos comuns e os procedimentos de exemplo para usar a Análise de Comportamento de Usuários e Entidades (UEBA) em seus fluxos de trabalho de investigação regular.

Importante

Os recursos indicados neste artigo estão em VERSÃO PRÉVIA no momento. Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para termos legais adicionais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.

Observação

Este tutorial fornece procedimentos baseados em cenários para uma tarefa principal do cliente: investigação usando dados do UEBA. Para obter mais informações, confira Investigar incidentes com o Microsoft Sentinel.

Pré-requisitos

Antes de poder usar os dados do UEBA em suas investigações, você deve habilitar a Análise de Comportamento de Usuários e Entidades (UEBA) no Microsoft Sentinel.

Comece a procurar os insights fornecidos pela máquina cerca de uma semana após habilitar o UEBA.

Executar pesquisas rotineiras proativas nos dados de entidade

É recomendável executar pesquisas regulares e proativas na atividade do usuário para criar listas de clientes potenciais para uma investigação mais aprofundada.

Você pode usar a Pasta de trabalho de análise de comportamento de usuários e entidades do Microsoft Sentinel para consultar dados do tipo:

  • Principais usuários suspeitos, com anomalias ou incidentes anexados
  • Dados de usuários específicos, para determinar se a entidade foi realmente comprometida ou se há uma ameaça interna devido a uma ação que se desvia do perfil do usuário.

Além disso, capture ações não rotineiras na pasta de trabalho do UEBA e use-as para encontrar atividades anômalas e práticas potencialmente não conformes.

Investigar uma entrada anômala

Por exemplo, as etapas a seguir descrevem a investigação de um usuário que se conectou a uma VPN que nunca havia usado, o que é considerado uma atividade anômala.

  1. Na área Pastas de trabalho do Sentinel, procure e abra a pasta de trabalho Análise de comportamento de usuários e entidades.

  2. Procure um nome de usuário específico para investigar e selecionar o nome do usuário na tabela Principais usuários a investigar.

  3. Role para baixo até as tabelas de Detalhamento de incidentes e Detalhamento de anomalias para exibir os incidentes e anomalias associados ao usuário selecionado.

  4. Na anomalia, como por exemplo esta denominada Logon anômalo realizado com sucesso, examine os detalhes mostrados na tabela investigada. Por exemplo:

    Etapa Descrição
    Observe a descrição à direita Cada anomalia tem uma descrição, com um link para saber mais na Base de dados de conhecimento do MITRE ATT&CK.
    Por exemplo:

    Acesso inicial
    A persona non grata está tentando entrar na sua rede.
    O acesso inicial consiste em técnicas que usam vários vetores de entrada para obter uma posição inicial em uma rede. As técnicas usadas para obter uma posição incluem spear phishing direcionado e a exploração de vulnerabilidades em servidores Web voltados ao público. As posições obtidas com o acesso inicial podem permitir acesso contínuo, como contas válidas e o uso de serviços remotos externos, ou podem ter uso limitado devido à alteração de senhas.
    Observe o texto da coluna Descrição Na linha de anomalias, role para a direita para exibir uma descrição adicional. Selecione o link para exibir o texto completo. Por exemplo:

    As personas non gratas podem roubar as credenciais de uma conta de serviço ou usuário específico usando técnicas de acesso de credenciais ou capturar credenciais em uma etapa anterior do processo de reconhecimento por meio da engenharia social, a fim de obter acesso inicial. APT33, por exemplo, usou contas válidas para obter acesso inicial. A consulta abaixo gera uma saída das entradas bem-sucedidas realizadas por um usuário de um novo local geográfico, do qual nem o usuário, tampouco nenhum dos colegas dele se conectaram antes.
    Observe os dados do UsersInsights Role mais à direita na linha de anomalias para exibir os dados de insight do usuário, como o nome de exibição da conta e a ID do objeto da conta. Selecione o texto para exibir os dados completos à direita.
    Observe os dados de evidência Role mais para a direita na linha de anomalias para exibir os dados de evidência da anomalia. Selecione o texto para exibir os dados completos à direita, como os seguintes campos:

    - ActionUncommonlyPerformedByUser
    - UncommonHighVolumeOfActions
    - FirstTimeUserConnectedFromCountry
    - CountryUncommonlyConnectedFromAmongPeers
    - FirstTimeUserConnectedViaISP
    - ISPUncommonlyUsedAmongPeers
    - CountryUncommonlyConnectedFromInTenant
    - ISPUncommonlyUsedInTenant

Use os dados encontrados na pasta de trabalho Análise de comportamento de usuários e entidades para determinar se a atividade do usuário é suspeita e requer ações adicionais.

Usar dados do UEBA para analisar falsos positivos

Algumas vezes, um incidente capturado em uma investigação é um falso positivo.

Um exemplo comum de falso positivo é quando uma atividade de viagem impossível é detectada, como um usuário que entrou em um aplicativo ou portal de Nova York e de Londres no decorrer da mesma hora. Apesar de o Microsoft Sentinel registrar a viagem impossível como uma anomalia, uma investigação com o usuário pode esclarecer que foi usada uma VPN em um local alternativo àquele onde o usuário realmente estava.

Analisar um falso positivo

Por exemplo, em um incidente de viagem impossível, depois de confirmar com o usuário que foi usada uma VPN, navegue do incidente até a página da entidade do usuário. Use os dados exibidos ali para determinar se os locais capturados estão incluídos nos locais normalmente conhecidos do usuário.

Por exemplo:

Open an incident's user entity page.

Existem links para a página da entidade do usuário também a partir da própria página do incidente e do grafo de investigação.

Dica

Após confirmar os dados na página da entidade do usuário para o usuário específico associado ao incidente, acesse a área de Busca do Microsoft Sentinel para entender se os pares do usuário também costumam se conectar dos mesmos locais. Se for esse o caso, esse conhecimento seria um indício ainda maior de se tratar de um falso positivo.

Na área de Busca, execute a consulta de Logon de localização geográfica anômala. Para saber mais, confira Buscar ameaças com o Microsoft Sentinel.

Inserir dados do IdentityInfo nas regras de análise (versão prévia pública)

Como os invasores geralmente usam as contas de usuário e de serviço da organização, os dados sobre essas contas de usuário, incluindo a identificação de usuário e os privilégios, são cruciais para os analistas no processo de uma investigação.

Insira dados da tabela IdentityInfo para ajustar as regras de análise de acordo com os casos de uso, reduzindo os falsos positivos e, possivelmente, acelerando o processo de investigação.

Por exemplo:

  • Para correlacionar eventos de segurança com a tabela IdentityInfo em um alerta que será disparado se algum servidor for acessado por alguém fora do departamento de TI:

    SecurityEvent
| where EventID in ("4624","4672")
| where Computer == "My.High.Value.Asset"
| join kind=inner  (
    IdentityInfo
    | summarize arg_max(TimeGenerated, *) by AccountObjectId) on $left.SubjectUserSid == $right.AccountSID
| where Department != "IT"

  • Para correlacionar os logs de entrada do Microsoft Entra com a tabela IdentityInfo em um alerta que será disparado se um aplicativo for acessado por alguém que não seja membro de um grupo de segurança específico:

    SigninLogs
| where AppDisplayName == "GithHub.Com"
| join kind=inner  (
    IdentityInfo
    | summarize arg_max(TimeGenerated, *) by AccountObjectId) on $left.UserId == $right.AccountObjectId
| where GroupMembership !contains "Developers"

A tabela IdentityInfo é sincronizada com o workspace do Microsoft Entra para criar um instantâneo dos dados de perfil do usuário, como metadados de usuário, informações de grupo e funções do Microsoft Entra atribuídas a cada usuário. Para obter mais informações, confira a tabela IdentityInfo na referência de enriquecimentos do UEBA.

Identificar tentativas de pulverização de senha e spear phishing

Sem a MFA (autenticação multifator) habilitada, as credenciais do usuário ficam vulneráveis a invasores que visam a ataques de comprometimento por meio da pulverização de senhas ou de tentativas de spear phishing.

Investigar um incidente de pulverização de senha com insights do UEBA

Por exemplo, ao investigar um incidente de pulverização de senha com insights do UEBA, você pode fazer o seguinte para saber mais:

  1. No incidente, na parte inferior esquerda, selecione Investigar para exibir as contas, as máquinas e outros pontos de dados que foram alvos potenciais em um ataque.

    Ao navegar pelos dados, pode ser que você veja uma conta de administrador com um número relativamente elevado de falhas de logon. Embora isso seja suspeito, você pode não querer restringir a conta antes de uma confirmação posterior.

  2. Selecione a entidade de usuário administrativo no mapa e, em seguida, selecione Insights à direita para encontrar mais detalhes, como o grafo de logons ao longo do tempo.

  3. Selecione Informações à direita e, em seguida, selecione Exibir detalhes completos para ir para a página de entidade do usuário e realizar uma busca mais detalhada.

    Verifique, por exemplo, se este é o primeiro incidente de Pulverização de senha potencial do usuário, ou observe o histórico de conexão do usuário para entender se as falhas foram anômalas.

Dica

Você também pode executar a consulta de busca de Logon com falha anômala para monitorar todos os logons com falha anômala de uma organização. Utilize os resultados da consulta para iniciar investigações sobre possíveis ataques de pulverização de senha.

Detonação de URL (versão prévia pública)

Quando há URLs nos logs ingeridos no Microsoft Sentinel, essas URLs são detonadas automaticamente para ajudar a acelerar o processo de triagem.

O grafo de investigação inclui um nó para a URL detonada, bem como os seguintes detalhes:

  • DetonationVerdict. A determinação booliana de alto nível da detonação. Por exemplo, Bad significa que o lado foi classificado como hospedagem de conteúdo de malware ou de phishing.
  • DetonationFinalURL. A URL da página de aterrissagem final observada, após todos os redirecionamentos da URL original.

Por exemplo:

Sample URL detonation shown in the Investigation graph.

Dica

Se as URLs não aparecerem nos logs, verifique se o log de URL, também conhecido como log de ameaças, está habilitado para os gateways Web seguros, proxies da Web, firewalls ou IDS/IPS herdados.

Você também pode criar logs personalizados para URLs específicas do canal de interesse no Microsoft Sentinel para uma investigação mais detalhada.

Próximas etapas

Saiba mais sobre UEBA, investigações e busca: