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

Investigação de Business Email Compromise e Regras de Caixa de Entrada

6 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre investigação de BEC na área de Resposta a Incidentes e DFIR

Resposta rápida

A investigação de BEC é um processo controlado que equilibra a contenção de danos com a preservação de evidências. Documentamos a fonte, a hora e a ferramenta, mantemos o Hash, construímos uma linha do tempo e separamos fatos, interpretações e decisões.

A Resposta a Incidentes e o DFIR exigem um equilíbrio entre velocidade, preservação de evidências, continuidade de negócios e documentação. Uma ação correta é uma ação que pode ser explicada, reproduzida e revisada após o incidente. Este artigo concentra-se na investigação de BEC e é destinado a analistas SOC e investigadores do Microsoft 365. O objetivo é fornecer um método de trabalho que possa ser aplicado na prática, em entrevistas profissionais e no ambiente de trabalho, sem se contentar com uma definição de dicionário.

O principal desafio é que os dados são quase sempre parciais. A "Received chain", "Return-Path" e "SPF" podem apontar uma direção, mas o seu significado depende do tempo, do ativo, do utilizador e da atividade esperada. Por isso, construiremos a verificação em torno de uma questão de investigação, evidências necessárias e um critério claro para conclusão.

O cenário prático neste artigo é: um cenário de conta comprometida com uma regra de reencaminhamento oculta. Todos os exemplos são dados de laboratório ou descrição de processos. Quando se trata de "Penetration Testing", "Web" ou "Cloud", deve-se trabalhar apenas com aprovação explícita, "Scope" definido e a capacidade de parar a verificação.

BEC vs. Spoofing

O tópico 'BEC vs. Spoofing' é uma parte central do trabalho na investigação de BEC. Recomenda-se dividi-lo em três questões: qual é a entrada, que decisão queremos tomar e que evidência é suficiente para justificá-la. Estas questões impedem o uso automático da ferramenta sem compreender o objetivo.

Na prática, registe a "Received chain", "Return-Path", "SPF", "DKIM", "DMARC", compare com o comportamento esperado e defina pelo menos um "Pivot". O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Sign-in e Evidências de Identidade

O tópico 'Sign-in e Evidências de Identidade' é uma parte central do trabalho na investigação de BEC. Recomenda-se dividi-lo em três questões: qual é a entrada, que decisão queremos tomar e que evidência é suficiente para justificá-la. Estas questões impedem o uso automático da ferramenta sem compreender o objetivo.

Regras de Caixa de Entrada/Reencaminhamento

O tópico 'Regras de Caixa de Entrada/Reencaminhamento' é uma parte central do trabalho na investigação de BEC. Recomenda-se dividi-lo em três questões: qual é a entrada, que decisão queremos tomar e que evidência é suficiente para justificá-la. Estas questões impedem o uso automático da ferramenta sem compreender o objetivo.

Auditoria de Caixa de Entrada e OAuth

O tópico 'Auditoria de Caixa de Entrada e OAuth' é uma parte central do trabalho na investigação de BEC. Recomenda-se dividi-lo em três questões: qual é a entrada, que decisão queremos tomar e que evidência é suficiente para justificá-la. Estas questões impedem o uso automático da ferramenta sem compreender o objetivo.

Definição de Âmbito, Contenção e Notificação

A resposta à investigação de BEC deve reduzir o risco sem apagar as evidências que ainda são necessárias. Comece com uma ação reversível e focada, confirme a propriedade e a autoridade, e documente a hora, o executante e o resultado.

A correção a longo prazo aborda a raiz: permissões, configuração, "Validation", "Telemetry", processo ou treinamento. Após a implementação, realize um "Retest" e monitorize sinais de recorrência, em vez de se contentar com o fecho do "Ticket".

Pontos de Verificação Exclusivos

Neste tópico, recomenda-se construir antecipadamente um mapa de evidências focado. Os principais pontos de verificação são: "Received chain", "Return-Path", "SPF", "DKIM", "DMARC", "Message-ID", "mailbox rules". A lista não é uma "Checklist" automática; cada item é escolhido porque pode ligar uma entidade, ação e tempo ou explicar um comportamento legítimo.

"Received chain": Defina o valor esperado, o que seria considerado anómalo e qual fonte adicional confirmaria a descoberta.
"Return-Path": Defina o valor esperado, o que seria considerado anómalo e qual fonte adicional confirmaria a descoberta.
"SPF": Defina o valor esperado, o que seria considerado anómalo e qual fonte adicional confirmaria a descoberta.
"DKIM": Defina o valor esperado, o que seria considerado anómalo e qual fonte adicional confirmaria a descoberta.
"DMARC": Defina o valor esperado, o que seria considerado anómalo e qual fonte adicional confirmaria a descoberta.
"Message-ID": Defina o valor esperado, o que seria considerado anómalo e qual fonte adicional confirmaria a descoberta.

Quando um dos pontos não está disponível, o hiato deve ser documentado e uma alternativa escolhida. Por exemplo, se o "Process identifier" não é estável, pode-se usar tempo, "Host", "User" e "Parent"; se o "Payload" é criptografado, usa-se "Metadata", volume, frequência e contexto TLS/DNS.

Processo de Trabalho Recomendado

Defina o "Scope" e uma única questão de trabalho sobre a investigação de BEC.
Registe as fontes de dados e evidências necessárias: "Received chain", "Return-Path", "SPF", "DKIM".
Crie uma "Baseline" curta de comportamento normal ou resultado esperado.
Execute a verificação mínima em ambiente de laboratório e guarde tempo, entrada e saída.
Construa uma "Timeline" ou tabela comparativa e separe o facto da interpretação.
Faça um "Pivot" para uma fonte adicional para confirmar ou refutar a explicação inicial.
Resuma a decisão, limitações, ação recomendada e critério de "Retest".

Cenário Prático

O cenário escolhido é um cenário de conta comprometida com uma regra de reencaminhamento oculta. O objetivo do exercício não é provar a capacidade de ataque, mas sim praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, definem-se dados simulados, uma janela de tempo e um resultado esperado.

No final do exercício, deve-se apresentar um produto que outro analista ou auditor possa rever: uma captura de ecrã ou "Export" da evidência, uma "Timeline" curta, uma suposição inicial, evidência de confirmação, uma limitação e uma recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi provado.

Etapa	O que é executado	Produto
Preparação	Defina o "Scope", tempo e objetivo. Registe quais campos ou evidências de "Received chain", "Return-Path", "SPF" são esperados.	Plano de teste curto
Criação de Dados	Execute uma ação segura e simulada relacionada com a investigação de BEC, sem informações reais ou impacto num sistema de produção.	Incidente/Request/Fluxo controlado
Recolha	Recolha a evidência bruta e o contexto de uma fonte adicional. Verifique o "Time zone", identificadores e integridade.	Duas evidências ligadas
Análise	Escreva o que cada evidência prova, o que não prova e qual é a explicação legítima possível.	Conclusão intermédia
Conclusão	Escolha um encerramento, escalonamento, "Finding" ou "Tuning"; adicione uma recomendação e um "Retest".	Produto documentado

Lista de Verificação Prática

Verifique e documente: Fonte da evidência.
Verifique e documente: Hora de recolha e fuso horário.
Verifique e documente: Hash e "Chain of Custody".
Verifique e documente: Ferramenta e versão.
Verifique e documente: Ações de resposta executadas.
Verifique e documente: "Timeline" e suposições de trabalho.
Indique o "Time zone", a versão da ferramenta e a hora de recolha.
Guarde os dados brutos antes de filtrar ou modificar.
Escreva o que a descoberta prova e o que ainda é desconhecido.
Defina um proprietário e uma ação de acompanhamento com uma data.

Erros Comuns

Alterar o sistema antes de preservar as evidências.
Não documentar o fuso horário.
Não calcular o Hash.
Misturar facto e especulação.
Não documentar quem deteve a evidência.
Preferir a integridade teórica em detrimento da contenção imediata de danos.

Resumo e CTA

A investigação de Business Email Compromise e Regras de Caixa de Entrada é um tópico que conecta conhecimento técnico com disciplina de trabalho. Comece com uma pergunta, recolha apenas evidências relevantes, preserve o contexto e o tempo, e escolha uma ação que possa ser justificada e revista.

No curso Cybersecurity & AI da HPI, estes princípios são praticados através de sistemas, registos e laboratórios. O próximo passo natural é passar para os artigos relacionados, realizar o exercício de laboratório e guardar o produto como parte de um portefólio de trabalho profissional.

Perguntas frequentes

A investigação de BEC por si só prova um ataque ou vulnerabilidade?

Não. Fornece um sinal ou descoberta que requer contexto, verificação e uma fonte adicional. Uma conclusão profissional baseia-se numa sequência de evidências e na correspondência com o comportamento esperado.

O que fazer quando faltam alguns dados?

Documente a falta, verifique uma fonte alternativa e reduza o nível de confiança. Não preencha campos por suposição nem apresente "Unknown" como normal.

Quanto tempo as evidências devem ser mantidas?

O tempo depende da política, regulamentação, custo e tipo de incidente. É importante definir antecipadamente a "Retention", "Legal hold" e a capacidade de exportar evidências num formato verificável.

Como praticar sem comprometer um sistema real?

Use máquinas virtuais, dados simulados, CTF ou um laboratório dedicado. Em testes autorizados, defina o "Scope", "Stop conditions" e "backup" antes de começar o trabalho.