Tutorial: Investigar incidentes com dados da UEBA

  • Artigo

Este artigo descreve métodos comuns e procedimentos de exemplo para usar a análise de comportamento de entidade do usuário (UEBA) em seus fluxos de trabalho de investigação regulares.

Importante

Os recursos observados neste artigo estão atualmente em VISUALIZAÇÃO. Consulte os Termos de Utilização Suplementares das Pré-visualizações do Microsoft Azure para obter os termos legais adicionais que se aplicam às funcionalidades do Azure que estão em versão beta, pré-visualização ou ainda não disponibilizadas para disponibilidade geral.

Nota

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

Pré-requisitos

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

Comece a procurar informações sobre máquinas cerca de uma semana depois de ativar a UEBA.

Execute pesquisas proativas e rotineiras em dados de entidade

Recomendamos a execução de pesquisas regulares e proativas através da atividade do usuário para criar leads para investigação adicional.

Você pode usar a pasta de trabalho do Microsoft Sentinel User and Entity Behavior Analytics para consultar seus dados, como:

  • Utilizadores de alto risco, com anomalias ou incidentes associados
  • Dados sobre usuários específicos, para determinar se o sujeito foi realmente comprometido 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 da UEBA e use-as para encontrar atividades anômalas e práticas potencialmente não conformes.

Investigar um início de sessão anómalo

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

  1. Na área Pastas de Trabalho do Sentinel , procure e abra a pasta de trabalho do User and Entity Behavior Analytics .

  2. Pesquise um nome de usuário específico para investigar e selecione seu nome na tabela Principais usuários a serem investigados .

  3. Role para baixo pelas tabelas Detalhamento de incidentes e Detalhamento de anomalias para visualizar os incidentes e anomalias associados ao usuário selecionado.

  4. Na anomalia, como uma chamada Anomalous Successful Logon, revise os detalhes mostrados na tabela para investigar. Por exemplo:

    Passo Description
    Observe a descrição à direita Cada anomalia tem uma descrição, com um link para saber mais na base de conhecimento MITRE ATT&CK.
    Por exemplo:

    Acesso inicial
    O adversário está tentando entrar na sua rede.
    O Acesso Inicial consiste em técnicas que usam vários vetores de entrada para ganhar sua posição inicial dentro de uma rede. As técnicas usadas para ganhar uma posição incluem spear phishing direcionado e exploração de fraquezas em servidores Web voltados para o público. Os pontos de apoio obtidos através do acesso inicial podem permitir o acesso contínuo, como contas válidas e uso de serviços remotos externos, ou podem ser de uso limitado devido à alteração de senhas.
    Observe o texto na coluna Descrição Na linha de anomalias, desloque-se para a direita para ver uma descrição adicional. Selecione o link para visualizar o texto completo. Por exemplo:

    Os adversários podem roubar as credenciais de um usuário ou conta de serviço específica usando técnicas de Acesso a Credenciais ou capturar credenciais anteriormente em seu processo de reconhecimento por meio de engenharia social para obter Acesso Inicial. O APT33, por exemplo, usou contas válidas para acesso inicial. A consulta abaixo gera uma saída de Login bem-sucedido realizado por um usuário a partir de uma nova localização geográfica da qual ele nunca se conectou antes, e nenhum de seus colegas também.
    Observe os dados do UsersInsights Role mais para a direita na linha de anomalia para exibir os dados de perceção do usuário, como o nome de exibição da conta e o ID do objeto da conta. Selecione o texto para visualizar os dados completos à direita.
    Observe os dados de evidência Role mais para a direita na linha de anomalia para visualizar os dados de evidência para a anomalia. Selecione o texto para exibir os dados completos à direita, como os seguintes campos:

    - AçãoUncommonlyPerformedByUser
    - IncomumHighVolumeOfActions
    - FirstTimeUserConnectedFromCountry
    - PaísIncomumConectadoDeAmongPeers
    - FirstTimeUserConnectedViaISP
    - ISPUncommonlyUsedAmongPeers
    - PaísRaramenteConectadoFromInTenant
    - ISPUncommonlyUsedInTenant

Use os dados encontrados na pasta de trabalho do User and Entity Behavior Analytics para determinar se a atividade do usuário é suspeita e requer ação adicional.

Usar dados da UEBA para analisar falsos positivos

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

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

Analise um falso positivo

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

Por exemplo:

Open an incident's user entity page.

A página de entidade do usuário também é vinculada a partir da própria página de incidente e do gráfico de investigação.

Gorjeta

Depois de confirmar os dados na página de entidade do usuário para o usuário específico associado ao incidente, vá para a área Microsoft Sentinel Hunting para entender se os pares do usuário geralmente se conectam dos mesmos locais também. Se assim for, este conhecimento seria um argumento ainda mais forte para um falso positivo.

Na área Hunting, execute a consulta Logon de Localização Geográfica Anômalo. Para obter mais informações, consulte Procurar ameaças com o Microsoft Sentinel.

Incorporar dados IdentityInfo em suas regras de análise (Visualização pública)

Como os atacantes costumam usar as próprias contas de usuário e serviço da organização, os dados sobre essas contas de usuário, incluindo a identificação e os privilégios do usuário, são cruciais para os analistas no processo de uma investigação.

Incorpore dados da tabela IdentityInfo para ajustar suas regras de análise para se adequar aos seus casos de uso, reduzindo falsos positivos e, possivelmente, acelerando seu processo de investigação.

Por exemplo:

  • Para correlacionar eventos de segurança com a tabela IdentityInfo em um alerta que é acionado se um 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 é acionado 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 sincroniza com o espaço de trabalho do Microsoft Entra para criar um instantâneo dos dados do perfil do usuário, como metadados do usuário, informações de grupo e funções do Microsoft Entra atribuídas a cada usuário. Para obter mais informações, consulte a tabela IdentityInfo na referência de enriquecimento da UEBA.

Identificar tentativas de spray de senha e spear phishing

Sem a autenticação multifator (MFA) habilitada, as credenciais do usuário ficam vulneráveis a invasores que procuram comprometer ataques com pulverização de senha ou tentativas de spear phishing .

Investigue um incidente de pulverização de senha com as informações da UEBA

Por exemplo, para investigar um incidente de pulverização de senha com informações da UEBA, você pode fazer o seguinte para saber mais:

  1. No incidente, no canto inferior esquerdo, selecione Investigar para visualizar as contas, máquinas e outros pontos de dados que foram potencialmente alvo de um ataque.

    Navegando pelos dados, você pode ver uma conta de administrador com um número relativamente grande de falhas de logon. Embora isso seja suspeito, talvez você não queira restringir a conta sem mais confirmações.

  2. Selecione a entidade de usuário administrativo no mapa e, em seguida, selecione Insights à direita para encontrar mais detalhes, como o gráfico de entradas 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 para detalhar ainda mais.

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

Gorjeta

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

Detonação de URL (visualização pública)

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

O gráfico Investigação inclui um nó para a URL detonada, bem como os seguintes detalhes:

  • DetonaçãoVeredicto. A determinação booleana de alto nível da detonação. Por exemplo, Bad significa que o lado foi classificado como hospedagem de malware ou conteúdo de phishing.
  • DetonationFinalURL. O URL final e observado da página de destino, afinal redireciona do URL original.

Por exemplo:

Sample URL detonation shown in the Investigation graph.

Gorjeta

Se não vir URLs nos seus registos, verifique se o registo de URLs, também conhecido como registo de ameaças, está ativado para os seus gateways Web seguros, proxies Web, firewalls ou IDS/IPS herdados.

Você também pode criar logs personalizados para canalizar URLs específicas de interesse para o Microsoft Sentinel para investigação adicional.

Próximos passos

Saiba mais sobre a UEBA, investigações e caça: