Análise de Phishing e Cabeçalhos de E-mail

Nota 06 do capítulo 25, que abre o bloco de análise de artefatos de campanhas de phishing e fraude.
O foco é a leitura forense de cabeçalhos de e-mail, a evidência que o remetente não consegue apagar e a primeira etapa de qualquer resposta a phishing.
Dialoga com as notas 07 e 08 deste capítulo, com a nota 15 do capítulo 08 (hunting em e-mails) e com o capítulo 05 (agrupamento de campanhas).

1. Contexto e Posicionamento na Biblioteca

O e-mail é o vetor de entrega dominante em campanhas de phishing, fraude e distribuição de malware, e o cabeçalho é a única parte da mensagem que o remetente não controla por completo: o corpo pode ser editado, o anexo substituído e o link removido, mas os registros acrescentados por cada servidor no caminho permanecem gravados. A análise de cabeçalhos converte uma denúncia de usuário em evidência estruturada: quem enviou, por onde a mensagem passou, se passou por autenticação e o que tentou esconder. Essa leitura também decide o encaminhamento do caso, porque spam rotineiro, tentativa de fraude financeira e campanha dirigida a cargos sensíveis exigem respostas e níveis de disseminação diferentes.

Esta nota cobre a leitura técnica da mensagem isolada; a nota 07 segue para os links e kits de phishing acessados a partir dela, e a nota 08 trata do BEC, caso em que o e-mail é a fraude inteira e não existe payload. O hunting em escala sobre o mesmo domínio está na nota 15 do capítulo 08, e os artefatos extraídos aqui alimentam o agrupamento de campanhas do capítulo 05. O contexto é defensivo e legítimo: a análise detalha a mecânica da fraude para que a organização detecte, bloqueie e produza inteligência a partir dela.

2. Envelope, Cabeçalho e Corpo: as Três Camadas da Mensagem

Uma mensagem de e-mail tem três camadas com responsabilidades distintas. O envelope é definido durante a conversa SMTP, com os comandos MAIL FROM e RCPT TO, e não aparece para o usuário; o cabeçalho é o bloco de campos estruturados que descreve a mensagem e registra o caminho; o corpo é o conteúdo visível, com texto, HTML e anexos. O ponto central para a análise é que o SMTP original não autentica nada: qualquer cliente pode declarar um From arbitrário, e é exatamente essa lacuna que os mecanismos SPF, DKIM e DMARC foram criados para reduzir décadas depois.

A tabela abaixo posiciona as camadas e o que cada uma entrega ao analista.

Na prática operacional, o acesso ao cabeçalho cru varia por cliente e por interface: o Outlook pede a opção de exibir a origem da mensagem, os clientes de webmail expõem a função de mostrar original e os gateways guardam cópia completa para revisão administrativa. O analista deve acostumar-se a pedir a mensagem com cabeçalhos completos na denúncia, porque os encaminhamentos comuns truncam ou reformatam o conteúdo e destroem justamente os campos que interessam. Quando o que chega é um arquivo .eml ou .msg, a extração dos cabeçalhos é a primeira etapa da triagem, antes de qualquer abertura do corpo.

3. A Cadeia Received e os Mecanismos de Autenticação

A cadeia Received é uma pilha: cada servidor que toca a mensagem acrescenta um bloco no topo, e a leitura correta é de baixo para cima, do servidor mais próximo do remetente para o mais próximo do destinatário. Em cada bloco o analista observa o nome e o IP do salto anterior, o reverse DNS associado, a versão TLS negociada e os carimbos de tempo. Sinais de envio malicioso incluem rDNS ausente ou genérico, IP de hosting barato ou de ASN de VPN, TLS antigo ou ausente e defasagens absurdas entre os carimbos de tempo dos saltos, que indicam relógio manipulado no servidor do atacante.

O campo Authentication-Results, inserido pelo servidor receptor, resume o veredito dos três mecanismos e é o trecho mais objetivo de toda a mensagem.

A leitura conjunta importa mais do que a leitura isolada: um DKIM válido assinado no domínio do atacante com um From de domínio vítima é a assinatura técnica do spoofing, porque a assinatura existe, mas não se alinha. Inversamente, um SPF softfail com domínio do envelope igual ao domínio do From sugere encaminhamento legítimo e deve ser tratado com prudência antes de classificar a mensagem como maliciosa. O DMARC resolve exatamente essa ambiguidade ao exigir alinhamento, e por isso o seu veredito é o ponto de partida da triagem.

Uma sutileza de protocolo importa na leitura: cada servidor que avalia a autenticação acrescenta o seu próprio Authentication-Results, e a mensagem pode carregar vários blocos ao longo da rota. O resultado confiável é o do primeiro receptor legítimo após o envio, porque os resultados posteriores podem refletir encaminhamentos que quebram o SPF sem malícia alguma. O analista lê todos os blocos e usa a diferença entre eles como evidência adicional de manipulação de rota.

4. Campos de Identidade: From, Reply-To, Return-Path e Display Name

O From é o campo que o usuário vê e o que o atacante quer forjar, e existem três formas principais de fazê-lo sem tocar no protocolo. O spoofing direto declara um From de domínio alheio, esperando que o DMARC não rejeite; a impersonação de display name carrega o nome do executivo entre aspas com um endereço de domínio próprio, porque muitas interfaces exibem apenas o nome; e o domínio lookalike aposta em homoglifos, trocas de letras e TLDs alternativos para parecer legítimo à primeira vista. Cada técnica deixa marcas distintas nos cabeçalhos e demanda tratamento distinto na resposta.

O campo Reply-To é o sinal mais produtivo de BEC em cabeçalhos: a mensagem afirma vir do executivo, mas a resposta seria enviada para uma caixa externa sob controle do atacante, e a divergência entre From e Reply-To de domínios diferentes raramente tem explicação legítima. O Return-Path, que carrega o envelope, compara-se ao From para expor a diferença entre remetente real e declarado. O Message-ID revela o domínio da plataforma que compôs a mensagem, incoerente com o From em envios fabricados, e o Subject e o Date completam o quadro com gatilhos de urgência e horários fora do fuso do destinatário.

5. X-headers e Metadados de Serviço

Campos iniciados com X são extensões não padronizadas acrescentadas por MTAs, gateways antispam e aplicações web, e com frequência entregam mais do que o atacante imagina, porque são acrescentados por componentes que ele não controla. Um X-Mailer de biblioteca de script em uma mensagem que se apresenta como comunicação de diretoria é incoerência imediata, e um X-Originating-IP de país inesperado em webmail comprometido aponta o local real de acesso à caixa. Os campos de veredito de antispam registram o que o gateway anterior calculou e permitem reconstruir por que a mensagem passou ou parou em cada estágio da rota.

Nos dois lados do envio, os X-headers também documentam o funcionamento interno do ecossistema de correio: clusters de transporte, marcadores de quarentena e trilhas de reescrita de assunto aparecem nos campos estendidos, e o analista aprende a lê-los como histórico operacional da mensagem. Esse histórico é especialmente útil em casos de encaminhamento e de arquivamento, onde a mensagem acumula camadas antes de chegar à caixa do usuário final. Na dúvida, o cabeçalho completo, do primeiro Delivered-To ao último campo estendido, é a fonte primária, e qualquer resumo gerado por ferramenta deve ser conferido contra ele.

Nos dois lados do envio, os X-headers também documentam o funcionamento interno do ecossistema de correio: clusters de transporte, marcadores de quarentena e trilhas de reescrita de assunto aparecem nos campos estendidos, e o analista aprende a lê-los como histórico operacional da mensagem. Esse histórico é especialmente útil em casos de encaminhamento e de arquivamento, onde a mensagem acumula camadas antes de chegar à caixa do usuário final. Na dúvida, o cabeçalho completo, do primeiro Delivered-To ao último campo estendido, é a fonte primária, e qualquer resumo gerado por ferramenta deve ser conferido contra ele.

6. Ferramentas de Análise de Cabeçalho

O trabalho manual com o cabeçalho cru em editor de texto é o ponto de partida, mas as ferramentas aceleram e padronizam a leitura. O Messageheader do Google Admin Toolbox e o Message Header Analyzer da Microsoft expandem a cadeia Received em saltos legíveis e destacam o veredito de autenticação; analisadores web como o Analysisher e o MXToolbox agregam verificação de listas de bloqueio e dos registros DNS do domínio remetente. Para automação, bibliotecas como mail-parser em Python convertem o cabeçalho em objeto estruturado e permitem enriquecimento em lote dentro do pipeline de triagem da nota 01 deste capítulo.

A cautela obrigatória é de sigilo: cabeçalhos reais carregam endereços internos, IPs, marcas de gateways e regras de transporte, e colar mensagens de produção em serviços públicos só é aceitável após mascaramento dos dados sensíveis ou com domínios de teste, em conformidade com a classificação TLP da organização. A prática profissional recomendada é manter um cabeçalho de referência gerado em laboratório para treinar a equipe e validar ferramentas, reservando os cabeçalhos reais para o caso sob investigação.

7. Exemplo Prático: Leitura Campo a Campo de um Cabeçalho de BEC

O cabeçalho abaixo, encurtado e com dados fictícios, ilustra uma tentativa de fraude do executivo contra a tesouraria de uma varejista. A mensagem declara vir do CFO, mas cada campo estrutural aponta para fabricação, e o diagnóstico fecha sem depender do corpo.

Delivered-To: controller@varejo-brasil.example
Received: by mx04.varejo-brasil.example with SMTP id 4Vx2Qk
        Mon, 19 Jan 2026 09:14:05 -0300 (BRT)
Received: from smtp-dispatch.example (unknown [203.0.113.77])
        by mx04.varejo-brasil.example (Postfix) with ESMTPS id 4Vx2Qk
        (TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384)
        Mon, 19 Jan 2026 09:14:02 -0300 (BRT)
Authentication-Results: mx04.varejo-brasil.example;
        spf=softfail (domain owner discourages this sender) smtp.mailfrom=smtp-dispatch.example;
        dkim=none (message not signed);
        dmarc=fail action=quarantine header.from=varejo-brasil.example
Return-Path: bounce@smtp-dispatch.example
Reply-To: tesouraria.aprovacoes@mail-secure.example
From: "Paulo Menezes - CFO" <p.menezes@varejo-brasil.example>
To: <controller@varejo-brasil.example>
Subject: URGENTE: instrucao de pagamento externa - CONFIDENCIAL
Date: Mon, 19 Jan 2026 11:12:47 +0000
X-Mailer: PHP Mailer 5.2.27
Message-ID: <20260119111247.4471.php@mail-secure.example>

O conjunto fecha o diagnóstico: spoofing de domínio com Reply-To externo, infraestrutura descartável e gatilhos de urgência no Subject. A resposta imediata inclui o bloqueio dos artefatos, a verificação se a variante da campanha atingiu outros cargos e a extração dos indicadores para a esteira do restante do capítulo. A decisão de quarentena já existia no campo action=quarantine do DMARC, e a análise de cabeçalho confirma que a política corretamente configurada fez o trabalho que deveria fazer.

8. Sinais de Spear Phishing nos Cabeçalhos

Spear phishing se distingue do phishing em massa pela personalização e pelo baixo volume, e os cabeçalhos refletem essa assinatura. Os sinais mais úteis estão na lista abaixo, e nenhum deles é conclusivo isoladamente; a força está na convergência de dois ou três deles na mesma mensagem.

• Lista curta de destinatários em BCC ou endereçamento individual, diferente do volume alto das campanhas industriais.
• Thread hijacking com Reply-To injetado em uma conversa real comprometida, em que o histórico legítimo empresta credibilidade à resposta fraudulenta.
• Referências a projetos, cargos ou fornecedores reais no Subject, resultado de reconhecimento prévio da organização.
• Ausência de anexo e de link em mensagens atribuídas a executivos, compatível com BEC, em contraste com campanhas de malware.
• Horários de envio deslocados do fuso corporativo e reuso de identidade de cargos sensíveis entre campanhas distintas.

O mapeamento das técnicas observadas em cabeçalhos para o ATT&CK orienta a priorização e o registro no TIP, e a tabela abaixo fixa o vínculo entre sinal e técnica usado ao longo deste capítulo.

A técnica de resposta interna, em que uma caixa já comprometida envia phishing para colegas usando a reputação do próprio domínio, merece atenção especial porque herda a autenticação legítima do domínio e por isso escapa das regras baseadas em SPF, DKIM e DMARC. Nesses casos a detecção se desloca do cabeçalho para a telemetria de caixa: fluxo anômalo de envio, criação de regras de caixa de entrada que escondem respostas do gerente e encaminhamento automático para endereços externos, tema retomado na nota 08.

9. Erros Comuns e Pontos de Atenção

O erro mais caro é julgar a mensagem pelo corpo antes de ler a estrutura: link bem construído, anexo limpo em scan e texto persuasivo enganam analistas experientes, enquanto a cadeia Received e o Authentication-Results são objetivos. O erro simétrico é tratar qualquer falha de SPF como malícia, gerando filas cheias de encaminhamentos legítimos e perdendo o sinal real. Ambos se resolvem com a mesma disciplina: protocolo de leitura fixo, campo a campo, com convergência de evidências antes do veredito.

Completam a lista os itens abaixo.

• Ler a cadeia Received de cima para baixo, invertendo a ordem real dos saltos e reconstruindo o caminho ao contrário.
• Confundir display name com endereço real na triagem rápida, tratando como legítima uma mensagem cujo domínio é lookalike.
• Ignorar o fuso horário dos carimbos, perdendo defasagens e horários que expõem a plataforma do atacante.
• Descartar X-headers como ruído, quando X-Originating-IP e X-Mailer frequentemente resolvem o caso.
• Analisar cabeçalhos reais em serviços públicos sem mascaramento, expondo dados internos fora do controle de TLP da organização.
• Fechar o caso no primeiro indicador, sem verificar a presença da variante em outras caixas e sem alimentar o bloqueio em escala.
• Basear o veredito apenas no veredito do antispam do gateway, sem reconstruir a cadeia e a autenticação por conta própria.

• Não registrar os cabeçalhos completos no caso, perdendo a evidência que sustenta o relatório e as correlações futuras.

• Tratar o Reply-To de domínio igual ao From como prova de legitimidade, quando o mesmo gateway pode ter sido comprometido na origem.

10. Integração com o Restante da Biblioteca

Os artefatos extraídos aqui, domínios, IPs, Reply-To, Message-ID e assinatura de campanha no Subject, são os IOCs que a nota 07 persegue na cadeia de URLs e que o capítulo 03 classifica, pontua e gesta ao longo do ciclo de vida. O hunting em e-mail em escala sobre os mesmos campos está na nota 15 do capítulo 08, e a fraude financeira que este cabeçalho exemplifica é o tema da nota 08, que cobre os procedimentos de verificação fora de banda e os controles de processo. O capítulo 05 recebe o conjunto como insumo de agrupamento de campanhas, e o relatório final do caso segue o formato tático da nota 04 daquele capítulo, com BLUF e expressão de confiança. A disciplina que esta nota estabelece é simples e decisiva: antes de qualquer ferramenta, ler a mensagem inteira, campo a campo, com a cadeia Received e a autenticação como espinha dorsal da evidência.