Entrevista em cibersegurança: investigue um alerta de login suspeito

Ao receber um alerta de login suspeito, decida o próximo passo sem antecipar uma conclusão. Você precisa explicar o que os registros mostram, quais hipóteses continuam abertas e por que a próxima ação é proporcional ao risco. Uma localização distante não prova invasão; uma autenticação bem-sucedida também não prova que o acesso foi autorizado pelo usuário.

Este caso original acompanha uma conta fictícia, dois acessos compatíveis com VPN e uma sessão posterior que o usuário não reconhece. Monte uma linha do tempo, peça a evidência que falta e entregue um resumo que outra pessoa consiga continuar. Para ampliar o treino, use Design a Security Monitoring Framework e conecte cada alerta a uma ação verificável.

Limite da evidência: a documentação da Microsoft fundamenta a leitura de sinais de autenticação e os limites da revogação de acesso. O pacote, os horários e a conversa são sintéticos, não registros de uma empresa ou relatos de candidatos. Os IPs vêm de blocos reservados para documentação; países e dispositivos foram atribuídos ficticiamente. Verificamos oito propriedades do pacote em Python, sem acessar um provedor real ou executar contenção.

Leia o pacote sem inventar o que não foi coletado

A conta u17 acessa um portal de relatórios. O pacote reúne registros de autenticação, um evento da aplicação e uma conversa verificada com o usuário. Todos os horários apresentados estão em UTC. Há nove linhas brutas, mas oito eventos distintos: uma cópia idêntica do evento de exportação foi recebida duas vezes.

O contrato deste exercício define id como identificador global do evento. Esse contrato permite remover a cópia idêntica deste pacote. Em sistemas reais, esclareça a chave e a origem antes de deduplicar: dois eventos com o mesmo usuário, segundo e IP podem ser tentativas diferentes. Se o mesmo ID vier com conteúdo divergente, preserve o conflito em vez de escolher uma versão silenciosamente.

A exportação aceita não está registrada como concluída ou baixada. O status 202 sustenta que a solicitação foi aceita; não demonstra conclusão ou download da exportação. Solicite o estado do job J7, o objeto produzido, os acessos ao resultado e os controles de autorização aplicados. Não preencha essas lacunas com a palavra “vazamento”.

O evento atrasado também muda a leitura. Ordenar apenas pela chegada colocaria a falha de 07:58 depois do acesso bem-sucedido de 08:14. Neste pacote, os campos de ocorrência e ingestão têm significados definidos. Em uma exportação real, confirme a semântica do campo e o fuso antes de reconstruir a sequência.

Distingua sinal geográfico de identidade do usuário

A documentação dos detalhes de login explica que um IP não determina de forma definitiva a localização física do dispositivo. VPNs e redes móveis podem usar saídas distantes. No exercício, S1 aparece com países BR e NL em seis minutos, mas permanece ligada ao dispositivo D04 e a saídas corporativas previamente cadastradas.

Esses elementos sustentam uma explicação benigna para o par S1. Não encerram automaticamente toda investigação da conta. Verifique se o inventário da VPN estava atualizado naquele horário, se o dispositivo realmente pertence ao usuário e se o acesso ao aplicativo corresponde à atividade reconhecida. Uma etiqueta “corporativo” sem origem verificável pode estar errada.

A página de detecções de risco distingue detecções como atypical travel e impossible travel. A primeira considera contexto e pode excluir situações evidentes de VPN. Não trate todos os nomes de alerta como sinônimos nem transfira regras de uma ferramenta para outra sem conferir o produto e a fonte.

Neste pacote não executamos o algoritmo de risco da Microsoft. Recebemos um alerta genérico de deslocamento e examinamos sinais fictícios. Portanto, não afirmamos que esses eventos gerariam determinada severidade, licença ou classificação em um tenant real. O exercício avalia sua interpretação e sua comunicação da incerteza.

Quando surgir S9, a justificativa usada para S1 deixa de ser suficiente. A saída não está no inventário corporativo fornecido, falta identificação de dispositivo e o usuário nega a sessão. “É tudo VPN” passa a ignorar sinais diferentes. Analise o novo conjunto sem presumir que a primeira explicação se aplica a todos os eventos.

Leia MFA como uma sequência, não como um selo

Duas recusas de MFA seguidas por sucesso merecem investigação, mas não identificam sozinhas a técnica usada. O usuário pode ter rejeitado solicitações indevidas, uma sessão previamente válida pode ter sido reutilizada ou os registros podem estar incompletos. O pacote não permite concluir roubo de senha, aprovação por cansaço ou replay de token como fatos.

A Microsoft descreve detalhes de autenticação que incluem métodos e requisitos satisfeitos por claims anteriores. A mesma página alerta que alguns detalhes podem aparecer incompletos antes da agregação. O texto “satisfeito por claim anterior” não significa que o usuário aprovou uma nova solicitação naquele instante.

Por isso, peça os passos de autenticação completos, o estado de agregação e os identificadores relevantes. Compare o tipo de cliente e o recurso acessado. Um campo vazio de dispositivo significa “não informado neste registro”; não prova que o dispositivo era criminoso, externo ou não gerenciado. Para afirmar qualquer dessas propriedades, busque uma fonte que realmente a represente.

No caso, as recusas e o sucesso pertencem à mesma conta e ao mesmo IP sintético. Isso fortalece a necessidade de correlação, mas não demonstra que todas as requisições foram feitas pelo mesmo processo. IPs podem ser compartilhados. A ligação mais útil para o pedido de exportação é a sessão S9 registrada pelo aplicativo sob o contrato do pacote.

Os IDs também têm limites. A documentação diz que o correlation ID pode se basear em parâmetros do cliente e não tem precisão garantida pela Microsoft. Neste exercício, S9 é uma ligação sintética explicitamente fornecida, não um correlation ID mágico. Em produção, valide como cada sistema gera e propaga os campos antes de usá-los como prova única.

Mantenha hipóteses concorrentes e escolha a próxima evidência

Uma investigação não precisa listar todas as ameaças possíveis. Precisa manter alternativas que produzam pedidos diferentes de evidência. Aqui três explicações ajudam: acesso legítimo mal identificado, uso indevido de uma sessão ou erro de correlação/coleta. Sua tarefa é encontrar observações que aumentem ou reduzam a confiança em cada uma.

A resposta do usuário às 08:30 é uma evidência importante, mas precisa de procedência. No exercício, o contato ocorre por um canal já verificado. Em um incidente real, não confie em uma mensagem enviada pela própria sessão sob suspeita para validar essa sessão. Registre o meio de confirmação sem coletar informações pessoais desnecessárias.

Para verificar a atividade de J7, pergunte: “Você iniciou uma exportação no portal entre 08:14 e 08:16 UTC?” Evite pedir senha, código de MFA ou token para confirmar a história. Pergunte também se recebeu solicitações de autenticação não iniciadas por ele. A intenção é confirmar atividade, não ensinar o usuário a aprovar uma solicitação desconhecida.

O conjunto S9 negada, recusas de MFA e pedido de exportação justifica escalada no procedimento fictício deste caso. Nossa confiança é maior na necessidade de investigar do que na técnica de ataque ou no impacto final. Essa distinção permite agir cedo sem relatar como comprovado algo que ainda não foi demonstrado.

Proponha contenção com responsável e verificação posterior

Na entrevista, descreva a ação autorizada pelo procedimento da organização e seu efeito esperado. Neste caso, proponha encaminhar imediatamente ao responsável de resposta, preservar o pacote e avaliar bloqueio da sessão suspeita e do job de exportação. Não diga que você bloqueou algo: nenhum comando de contenção foi executado neste exercício.

A orientação de revogação de acesso da Microsoft mostra que tokens e sessões de aplicação têm comportamentos diferentes. Uma aplicação pode manter seu próprio token de sessão. O tempo até perder acesso depende da forma como o aplicativo concede e reavalia autorização. Revogar no provedor não demonstra encerramento instantâneo de todos os acessos.

A consequência prática para o caso é verificar o portal além do provedor de identidade. Quem pode invalidar S9 no aplicativo? O job J7 ainda está na fila? A contenção impede novas exportações, encerra downloads existentes ou só impede autenticações futuras? Essas perguntas especificam o alcance da ação sem prometer reversão de dados eventualmente transferidos.

Preserve o que permite reconstruir a decisão: eventos originais, janela temporal, origem, filtros usados e um hash da cópia coletada. O hash ajuda a detectar alteração daquela cópia; não certifica a veracidade do evento de origem. Restrinja acesso ao material e siga a retenção aplicável. Não inclua tokens completos ou dados de relatórios em um resumo de entrevista.

Depois de uma medida autorizada, defina como confirmar o efeito e quem acompanhará. Uma nova tentativa controlada de acesso, quando permitida, e os registros de aplicação podem mostrar se o bloqueio foi efetivo. Ausência de novos alertas, sozinha, pode refletir atraso de coleta. Preserve uma janela e uma fonte de observação explícitas.

Entregue um handoff que outra pessoa consiga continuar

Um handoff que separa evidência e lacunas pode dizer: “Conta u17: acessos S1 às 08:00/08:06 são compatíveis com VPN corporativa e reconhecidos pelo usuário. S9 às 08:14 não é reconhecida; houve duas recusas de MFA antes e um pedido de exportação J7 às 08:16. Recomendo escalada para validar a sessão e conter atividade conforme procedimento. Conclusão ou download da exportação e técnica de comprometimento permanecem desconhecidos.”

Acrescente o responsável, a próxima atualização e os IDs das evidências. Isso evita uma passagem vaga como “parece invasão, favor verificar”. O próximo analista deve conseguir encontrar J7, distinguir S1 de S9 e saber qual hipótese você tentou testar. O handoff não precisa reproduzir todo o log para cumprir essa função.

Os oito checks locais confirmaram nove linhas para oito eventos únicos, ordenação do evento atrasado, seis eventos de autenticação, três sucessos, duas recusas de MFA, um pedido de exportação, nenhuma conclusão registrada e a ligação de e5/e6 a S9. Eles verificam a consistência do material didático, não a eficácia de uma detecção de ataques.

Se perguntarem “o que faria você reduzir a severidade?”, cite evidência concreta: reconhecimento verificado de S9, origem legítima corroborada e atividade autorizada explicariam parte do risco. Se o job mostrar download não autorizado ou surgir alteração de privilégio, o impacto pode crescer. Justifique a classificação com a evidência e a matriz da organização, mantendo as lacunas registradas.

As questões abaixo ampliam fundamentos de engenharia úteis à investigação. Elas não são uma bateria oficial de SOC nem perguntas confirmadas de uma empresa:

Continue com Design a Security Monitoring Framework. Apresente um sinal, duas explicações concorrentes e uma observação que faria sua decisão mudar.

Sources and Further Reading

• Microsoft Learn — Sign-in log activity details.
• Microsoft Learn — What are risk detections?.
• Microsoft Learn — Revoke user access in an emergency.
• RFC 5737 — IPv4 Address Blocks Reserved for Documentation.