Cibersegurança e segurança da informação

Microsoft Sentinel: Guia de Investigação de Incidentes para Analistas Iniciantes

7 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre investigação de incidentes no Microsoft Sentinel na área de SIEM e deteção

Resposta rápida

A investigação de incidentes no Microsoft Sentinel começa com a compreensão da história do caso: que alertas foram agrupados, quem são as entidades, qual a severidade e qual a origem da deteção. Em seguida, o analista verifica utilizadores e ativos, examina evidências e a linha do tempo, executa KQL complementar, documenta decisões e escala ou responde. Um incidente é um caso de trabalho — não uma prova de que o ataque foi bem-sucedido — e, portanto, a classificação deve basear-se em evidências e contexto.

O Microsoft Sentinel centraliza a Deteção, Investigação e Resposta em torno de Incidentes. Um incidente pode ser gerado a partir de uma regra de análise, de um alerta importado de outro produto ou do agrupamento de vários alertas relacionados com a mesma atividade. Herda características como Severidade, Status, táticas MITRE ATT&CK e Entidades identificadas nos alertas.

A interface fornece muitas informações, mas uma boa investigação não é uma transição automática entre separadores. O analista precisa de definir uma questão de investigação, identificar o que é conhecido e o que falta, e usar as ferramentas da interface para recolher evidências. O guia é adequado para dados de laboratório ou para um ambiente organizacional onde a permissão existe.

A Microsoft está a unificar a experiência SOC dentro do portal Microsoft Defender. De acordo com a documentação atual, o suporte para o Sentinel através do portal Azure está previsto para terminar após 31 de março de 2027, pelo que é preferível aprender o fluxo de trabalho principal e familiarizar-se com o portal Defender em vez de depender de uma localização fixa de um botão.

Antes da Investigação: Preparativos Básicos

Um analista precisa de permissões adequadas para visualizar, atribuir e modificar incidentes. A Microsoft indica o Sentinel Responder como uma das funções necessárias para a investigação. As permissões devem seguir o princípio do menor privilégio, e numa organização real é importante separar a visualização de dados sensíveis das ações de resposta, como isolar um ativo ou desativar um utilizador.

Certifique-se de que o incidente inclui Entidades úteis. O mapeamento de Entidades na regra de análise permite que o sistema identifique Contas, Anfitriões, IPs, URLs, Ficheiros ou Processos. Sem mapeamento, a investigação gráfica e os links para o contexto serão limitados. Além disso, verifique se os Conectores de Dados estão íntegros e se não há atrasos significativos na ingestão.

Antes de abrir um incidente, defina um SLA ou objetivo de Triagem, um Proprietário e critérios de escalonamento. Um incidente sem Proprietário pode ficar em espera mesmo que a Severidade seja alta.

Passo 1: Leitura da Fila de Incidentes

Na fila de incidentes, é realizada a priorização inicial. Não se contente com a Severidade. Verifique a Hora de Criação, Última Atividade, Produto, Táticas, número de Alertas, Entidades, Proprietário e Status. Conecte isso à criticidade do ativo e à identidade do utilizador. Um incidente Médio numa conta Privilegiada pode receber uma Prioridade mais alta do que um incidente Alto num ativo isolado num laboratório.

Questão Inicial	O que Verificar	Por que é Importante
O que aconteceu?	Título, Provedores de Alerta, Táticas, Descrição	Define a hipótese inicial
A quem aconteceu?	Conta, Anfitrião, IP, Recurso na Cloud	Determina o Escopo e a Criticidade
Quando?	Primeira/Última atividade, Hora de Criação	Define a janela de investigação
Ainda está ativo?	Novos Alertas, Sessões, Atividade de Rede	Afeta a urgência e a contenção
Quem está a tratar?	Proprietário, Status, Tarefas	Evita duplicação e espera

Passo 2: Abrir um Incidente e Entender a História

Leia o Resumo e a lista de Alertas. Vários alertas podem ser resultados da mesma Regra ou de produtos diferentes. Verifique se o agrupamento de alertas reuniu atividades lógicas ou se criou um incidente muito amplo. Preste atenção ao intervalo de tempo: um alerta tardio pode expandir o incidente e esconder o início da atividade.

Abra cada Alerta principal e leia a fonte de Deteção, Descrição, Consulta ou Evidência, Limite e Entidades. Pergunte: qual condição foi realmente acionada? É baseada em Indicador, anomalia, comportamento ou Correlação? Qual é o nível de certeza? Quais dados não foram verificados?

Evite o viés do título. Um alerta chamado “Conta comprometida” ainda requer verificação. Um nome dramático não é Evidência.

Passo 3: Entidades e Relações

As Entidades são as âncoras da investigação. Comece pela conta principal, Anfitrião ou IP e verifique os Insights: atividade anterior, alertas adicionais, pertença a grupos, inícios de sessão, anfitriões relacionados e inteligência de ameaças. Não confie apenas no gráfico; ele mostra as relações que o sistema conseguiu mapear, não toda a realidade.

Para cada Entidade, crie um pequeno cartão de investigação: identificador, tipo, Proprietário, criticidade, último estado conhecido como bom, atividade anómala e fontes de dados. Quando houver nomes semelhantes, certifique-se de que está a seguir o ID do objeto ou SID e não apenas o nome de exibição.

Perguntas para Conta de Utilizador

A conta é privilegiada ou uma conta de serviço?
A MFA foi ativada e qual foi o resultado da autenticação?
O IP, o dispositivo e o país são conhecidos?
Existem falhas, redefinições, consentimentos ou alterações de permissão?
O utilizador confirma a atividade através de um canal de comunicação fiável?

Perguntas para Anfitrião

A estação está gerida e atualizada?
Qual é a árvore de processos e a linha de comando é incomum?
Existem conexões, ficheiros ou indicadores de persistência?
Um alerta adicional do EDR ou sensor de rede apoia a história?
O isolamento da estação afetará um serviço crítico?

Passo 4: Evidências e Linha do Tempo

A Evidência centraliza as descobertas que o sistema associou ao Incidente. Verifique a fonte, hora e valor. Distinga entre evento Raw, evidência de Alerta e Enriquecimento. Um Indicador que aparece na Threat Intelligence não é suficiente se não houver conexão com a atividade do ativo.

A Linha do Tempo organiza Alertas, marcadores e operações. Use-a para identificar o início, expansão e resposta, mas construa também a sua própria Linha do Tempo quando houver fontes fora do Sentinel. Normalize o UTC, documente o tempo do Evento versus o tempo de Ingestão e assinale as lacunas.

As Tarefas podem garantir que o analista verifica os passos necessários: verificação do utilizador, pesquisa de inícios de sessão, verificação do anfitrião, contacto com a TI e adição de Classificação. Uma tarefa concluída não significa que o resultado esteja correto; um Ticket deve incluir o que foi verificado e o que foi encontrado.

Passo 5: Pesquisa Complementar em Registos

A interface de incidentes fornece contexto, mas uma consulta complementar em registos é geralmente o cerne da investigação. Comece por uma Entidade e uma janela de tempo, expanda um pouco antes e depois da atividade, e procure eventos de apoio ou contraditórios.

let TargetUser = "student@contoso.example";
let StartTime = datetime(2026-08-01 08:30:00);
let EndTime = datetime(2026-08-01 10:30:00);
SigninLogs
| where TimeGenerated between (StartTime .. EndTime)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType, ResultDescription
| order by TimeGenerated asc

KQL: Pesquisa de eventos de autenticação para uma conta e IP específicos

Após a autenticação, verifique o registo de Auditoria, Ponto Final, DNS ou atividade na Cloud de acordo com a história. Não se estenda a todas as tabelas sem um objetivo. Cada consulta deve responder a uma pergunta: Houve sucesso? Foi criada uma sessão? Foi realizada uma alteração de permissão? A estação criou um processo ou conexão incomum?

Cenário: Utilizador e IP Suspeitos

O incidente inclui um alerta de início de sessão de um novo país e um alerta adicional de uma regra de caixa de entrada criada.
A triagem identifica que o utilizador trabalha em finanças e que a atividade começou fora do horário normal de trabalho.
Nas Entidades, o IP, a conta e a aplicação são verificados. O IP não é uma VPN conhecida, e a conta não deveria operar do país identificado.
O KQL mostra várias falhas, um sucesso com um método de MFA incomum e uma alteração na caixa de correio posteriormente.
O analista verifica os registos de auditoria, sessões, consentimentos OAuth e atividade adicional do utilizador. Contacta o utilizador através de um canal autenticado.
Após a confirmação de que a atividade não é sua, o incidente é classificado como Verdadeiro Positivo e escalado para a IR. As ações de contenção são realizadas de acordo com o Playbook e a permissão.
O ticket documenta a Linha do Tempo, Consultas, Evidências, ações, proprietários e recomendações para melhorar a Deteção.

Classificação, Resposta e Encerramento

A Classificação deve distinguir entre Verdadeiro Positivo, Falso Positivo e Positivo Benigno, de acordo com o modelo organizacional. Adicione um Motivo e um Comentário que expliquem as evidências. O encerramento sem justificativa prejudica o Ajuste e as métricas.

Se for necessária uma resposta, execute-a de acordo com o Playbook: cancelamento de sessões, redefinição de credenciais, isolamento de Ponto Final, bloqueio de Indicador, preservação de evidências ou contacto com equipas. Ações irreversíveis ou com impacto nos negócios exigem aprovação apropriada.

Antes de encerrar, certifique-se de que o Escopo foi verificado, que a atividade não continua, que todas as Tarefas foram concluídas, que as lições aprendidas foram transmitidas ao proprietário da Deteção e que foram abertas Ações para corrigir a causa raiz.

Lista de Verificação de Investigação

Proprietário e Prioridade definidos.
A lógica de cada Alerta foi lida, não apenas o título.
Contas, Anfitriões e IPs verificados com identificadores estáveis.
Evidências e Linha do Tempo verificadas com fusos horários corretos.
Consultas complementares realizadas nas fontes relevantes.
Factos, suposições e interpretação separados.
Classificação e Severidade atualizadas com justificação.
Ações de resposta documentadas com tempo e executor.
Tarefas de acompanhamento criadas para Ajuste ou Fortalecimento.

Erros Comuns

Assumir que todos os alertas num incidente pertencem ao mesmo ataque.
Confiar no gráfico de investigação sem verificar os registos brutos.
Ignorar o atraso de ingestão ou uma fonte de dados em falta.
Fechar um Falso Positivo apenas porque o utilizador é conhecido.
Realizar pesquisas amplas sem uma questão de investigação.
Realizar uma contenção significativa sem compreender o impacto nos negócios.
Fechar um incidente sem dar feedback ao proprietário da regra.

Resumo e CTA

Crie um incidente simulado no laboratório com uma Conta, IP e dois Alertas. Escreva cinco perguntas de investigação, uma Consulta para cada pergunta e uma Linha do Tempo curta. O objetivo não é clicar em todas as opções na interface, mas sim mostrar como cada ação altera uma decisão. Depois, passe para o artigo da Regra de Análise para entender como um incidente de qualidade começa com uma Deteção que pode ser investigada.

Perguntas frequentes

Um incidente no Sentinel pode incluir vários alertas?

Sim. Um incidente pode agrupar alertas da mesma regra ou de diferentes fontes, dependendo das configurações de agrupamento e da plataforma.

Qual a importância do mapeamento de entidades?

O mapeamento permite que o Sentinel identifique contas, anfitriões, IPs e outras entidades, apresente contexto e relações e apoie a investigação. Sem mapeamento, algumas capacidades são limitadas.

Devo trabalhar no portal Azure ou no portal Defender?

A direção da Microsoft é o portal Defender, e a documentação indica o fim do suporte para o Sentinel através do portal Azure após 31 de março de 2027. O processo de investigação é mais importante do que a localização dos botões.

Quando se encerra um incidente como Falso Positivo?

Só depois de recolhidas evidências que demonstrem que a Deteção foi acionada por uma atividade que não representa a ameaça que a regra se destinava a identificar. A causa raiz deve ser documentada e a sintonia considerada.

É possível responder automaticamente a partir do Sentinel?

Sim, através de regras de automação e Playbooks, dependendo da conexão e das permissões. A automação deve ser ajustada ao nível de certeza e ao impacto potencial.