10 falhas dos filtros de email: os sinais sutis que seu gateway ignora
Por CaptainDNS
Publicado em 28 de março de 2026
- Os gateways de email bloqueiam o spam óbvio mas não detectam ataques sofisticados que exploram falhas sutis nos cabeçalhos
- 10 indicadores precisos nos cabeçalhos denunciam emails maliciosos: desalinhamento de envelope, DKIM de terceiros, Reply-To divergente, cadeia Received anormal e outros seis sinais técnicos
- Cada indicador é desconstruído do ponto de vista do atacante (como ele explora) e do defensor (como detectar)
- A análise de cabeçalhos após o gateway é a última linha de defesa para o 1% de emails que superam todos os filtros
Seu gateway de email exibe uma taxa de bloqueio de 99,5%. O relatório mensal é tranquilizador, os paineis estão verdes e sua equipe de segurança passa para o próximo assunto. O problema se esconde nos 0,5% restantes. Sobre um volume de 200 000 emails mensais, isso representa 1 000 mensagens não filtradas. Entre elas, basta um único email de spear-phishing direcionado ao funcionário certo para comprometer uma conta privilegiada, exfiltrar dados ou acionar um ransomware. O custo médio de uma violação iniciada por phishing atinge 4,8 milhões de dolares (IBM, Cost of a Data Breach 2025), e o tempo médio para detectar um comprometimento por phishing é de 207 dias (IBM, 2025). Segundo o relatório Verizon DBIR 2025, o tempo mediano entre o recebimento de um email de phishing e o primeiro clique é de 21 segundos. Seus usuários não refletem: reagem.
Os gateways de segurança de email (Secure Email Gateways, SEG) como Proofpoint, Mimecast, Barracuda ou Microsoft Defender for Office 365 analisam o conteúdo, a reputação IP, as assinaturas conhecidas e as heurísticas comportamentais. Mas compartilham um ponto cego comum: os sinais sutis nos cabeçalhos SMTP e MIME que atacantes sofisticados manipulam para superar os filtros sem disparar nenhum alerta. Os números são claros: os gateways falham em 30 a 50% das ameaças avançadas, e o volume de emails maliciosos que eludem os SEG aumentou 105% em um ano, ou seja, um email malicioso a cada 19 segundos que supera os filtros (Cofense, Annual State of Email Security 2026). Sem surpresa, 91% dos responsáveis de segurança se declaram frustrados com o desempenho de seu SEG (Egress, Email Security Risk Report 2024). Não é um problema teórico. Em 2025, o grupo Tycoon2FA explorou falhas de roteamento MX e autenticação de email para gerar 13 milhões de emails maliciosos em um único mes, eludindo os gateways de milhares de organizações. No total, 78% das organizações sofreram pelo menos uma violação de email nos últimos 12 meses (Barracuda, 2025).
Este artigo disseca 10 indicadores precisos nos cabeçalhos de email que a maioria dos gateways ignora ou subestima. Para cada indicador, a perspectiva do atacante (como ele explora) e a do defensor (como detectar) são detalhadas com exemplos concretos de cabeçalhos. Se você é engenheiro de segurança, analista SOC, administrador de email ou CISO, esses 10 sinais devem fazer parte da sua grade de análise pós-gateway.
Análise seus cabeçalhos de email
Por que os filtros de email não são suficientes
O que os gateways verificam (e o que ignoram)
Os gateways de email modernos se baseiam em várias camadas de filtragem. A reputação IP verifica se o endereço do servidor emissor consta em listas negras (Spamhaus, Barracuda, SpamCop). A análise de conteúdo busca palavras-chave suspeitas, URLs maliciosas e anexos perigosos. As assinaturas anti-malware comparam os arquivos com bases de definições conhecidas. As heurísticas comportamentais detectam padrões de envio em massa e anomalias estatísticas.
Essa arquitetura funciona contra o spam em massa e as campanhas de phishing genéricas. Um servidor com IP em lista negra, um email com "Clique aqui para recuperar seu prêmio" e um anexo .exe são bloqueados antes de chegar a caixa de entrada. A taxa de bloqueio de 99% é real para esse tipo de ameaça.
Mas os atacantes que visam sua organização não fazem nada disso. Enviam a partir de IPs limpos (alugados em ESPs legítimos), redigem mensagens criveis e manipulam os cabeçalhos SMTP para que a mensagem pareca um email legítimo. Dado notável: 82,6% dos emails de phishing analisados usam agora alguma forma de IA para a redação (KnowBe4, Phishing Threat Trends 2025), e a taxa de clique nesses emails gerados por IA atinge 54%, contra 12% para emails redigidos manualmente (Brightside AI, 2025). Além disso, 76,4% dos ataques de phishing contem pelo menos um traco polimórfico, ou seja, cada email enviado é ligeiramente diferente para escapar das assinaturas estáticas (KnowBe4, 2025). O gateway ve um email que "passa" todos os seus critérios padrão e o deixa entrar.
O que os gateways ignoram em grande parte são os sinais de coerência nos cabeçalhos. Um email legítimo apresenta coerência interna: o domínio do From corresponde ao domínio do Return-Path e do Message-ID, a assinatura DKIM cobre o domínio correto, a cadeia Received é lógica e os cabeçalhos proprietários da plataforma de hospedagem estão presentes. Quando um atacante falsifica um email, reproduz os cabeçalhos visiveis (From, Subject, Date) mas deixa incoerencias nos cabeçalhos técnicos que somente um exame aprofundado revela. Os gateways não fazem esse exame.
O paradoxo da adaptação
Quanto mais rigoroso é um filtro, mais o atacante se adapta. Os grupos de ameaças avançadas (APT, operações de spear-phishing direcionado) testam sistematicamente seus emails contra os gateways do mercado antes de lançar uma campanha. Servicos clandestinos oferecem "SEG testing": o atacante envia seu email e recebe um relatório indicando quais gateways o bloqueiam e quais o deixam passar. É um processo iterativo. O atacante ajusta os cabeçalhos, o conteúdo e a infraestrutura de envio até obter uma taxa de passagem satisfatória.
O resultado: os emails que chegam a caixa de entrada após o gateway não são tentativas fracassadas. São as tentativas mais bem-sucedidas, aquelas que foram otimizadas para eludir suas defesas específicas. É um viés cognitivo frequente nas equipes de segurança: considerar que o que supera o gateway é "provavelmente legítimo". Na realidade, é exatamente o contrário. O que supera o gateway após uma filtragem rigorosa é potencialmente mais perigoso que o spam médio, porque foi projetado para passar.
Esse fenomeno explica por que os usuários treinados para reconhecer os sinais visuais do phishing continuam caindo. Os emails que superam o gateway não contem mais erros de ortografia, layouts aproximados ou URLs evidentes. Parecem emails legítimos porque foram otimizados para isso. A única diferenca reside nos cabeçalhos técnicos, invisíveis para o usuário final.
A última linha de defesa: a análise pós-gateway
Por isso a análise de cabeçalhos após a filtragem e crítica. Os 10 indicadores detalhados neste artigo não substituem o gateway: complementam a detecção examinando sinais que os filtros automatizados não verificam ou verificam mal. Essa análise pode ser manual (para incidentes individuais), semi-automatizada (regras de transporte Exchange/Gmail) ou integrada a um SIEM para detecção em larga escala.
Os 10 indicadores que seu gateway ignora
1. Desalinhamento Return-Path / From (desalinhamento de envelope)
Como o atacante explora. O protocolo SMTP separa duas identidades distintas: o remetente de envelope (MAIL FROM, visível no cabeçalho Return-Path) e o remetente exibido (cabeçalho From). O atacante configura seu servidor para enviar com um Return-Path que ele controla (bounce@atacante-infra.net) enquanto exibe um From credível (direction@captaindns.com). A maioria dos clientes de email exibe apenas o From. O destinatário ve um email que parece vir da direção, sem desconfiar que o envelope aponta para outro lugar.
Por que os filtros ignoram. Os gateways verificam SPF no Return-Path e DKIM no From, mas poucos comparam ativamente os dois e alertam sobre um desalinhamento. Um SPF pass no Return-Path e um DKIM pass em um domínio de terceiros costumam ser suficientes para deixar a mensagem passar.
O que o defensor deve verificar. Comparar o domínio no Return-Path com o domínio no From. Se diferem sem razão legítima (lista de distribuição, ESP configurado), é um sinal forte.
Exemplo de cabeçalho:
Return-Path: <bounce-7842@atacante-infra.net>
From: "Direção Geral" <direction@captaindns.com>
O desalinhamento é visível imediatamente: o envelope vem de atacante-infra.net, o From exibe captaindns.com. Um email legítimo enviado via ESP teria um Return-Path contendo o domínio do ESP configurado no SPF do domínio remetente, não um domínio de terceiros desconhecido.
Quando o desalinhamento é legítimo. É normal que o Return-Path difira do From em certos casos: os ESPs (SendGrid, Mailgun, Amazon SES) usam seu próprio domínio para o Return-Path a fim de gerenciar os bounces. As listas de distribuição reescrevem o Return-Path. A chave é verificar se o domínio do Return-Path é o de um serviço conhecido e configurado no SPF do domínio do From. Um Return-Path para um domínio desconhecido (atacante-infra.net) associado a um From empresarial (captaindns.com) sem vínculo SPF é um sinal forte.
2. DKIM assinado por um domínio de terceiros (assinatura delegada)
Como o atacante explora. O atacante cria uma conta em um ESP legítimo (SendGrid, Mailgun, Amazon SES) e configura DKIM para seu próprio domínio. Em seguida, envia um email com um From falsificado (compta@captaindns.com). A mensagem carrega uma assinatura DKIM válida, mas assinada pelo domínio do atacante (d=atacante-marketing.com), não por captaindns.com. O gateway ve "dkim=pass" e considera a mensagem autenticada.
Por que os filtros ignoram. Os gateways verificam que a assinatura DKIM é tecnicamente válida (a chave pública corresponde, o hash do corpo esta correto). Mas a maioria não verifica se o domínio assinante (d=) corresponde ao domínio do From. Isso é papel do alinhamento DMARC, e muitas organizações ainda não implantaram DMARC em modo rigoroso.
O que o defensor deve verificar. No cabeçalho DKIM-Signature, comparar o campo d= com o domínio do From. Se não correspondem, o email está assinado por um terceiro que não tem autoridade sobre o domínio exibido.
Exemplo de cabeçalho:
DKIM-Signature: v=1; a=rsa-sha256; d=atacante-marketing.com;
s=sel2026; c=relaxed/relaxed;
h=from:to:subject:date:message-id;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...
From: "Servico Contabilidade" <compta@captaindns.com>
O d=atacante-marketing.com não corresponde ao From captaindns.com. A assinatura é tecnicamente válida mas o alinhamento esta quebrado.
3. SPF pass mas alinhamento DMARC falhou
Como o atacante explora. O atacante envia a partir de um servidor cujo IP é autorizado pelo SPF de um domínio que ele controla (seu próprio domínio ou um domínio de ESP). O MAIL FROM (envelope) usa esse domínio autorizado, resultando em SPF pass. Mas o From (cabeçalho) exibe o domínio do alvo (rh@captaindns.com). SPF passa, DKIM esta ausente ou assinado por outro domínio, e DMARC falha em alinhamento. Se o domínio alvo tem uma política DMARC p=none, nenhuma ação é tomada. E essa falha é massiva: 84,2% dos ataques de phishing analisados passam nos controles DMARC (Egress, Email Security Risk Report 2024), em grande parte porque 47% dos domínios de email não tem nenhuma configuração DMARC (Barracuda, 2025), 63% dos implementadores permanecem em p=none (Mailgun/Email on Acid, 2025) e apenas 4% dos domínios aplicam p=reject (Valimail, 2025).
Por que os filtros ignoram. O gateway ve spf=pass nos resultados de autenticação e atribui uma pontuação positiva. O fato de o alinhamento DMARC falhar é frequentemente subponderado se a política é p=none. O resultado líquido: a mensagem passa na filtragem com uma "pontuação de autenticação aceitável".
O que o defensor deve verificar. No cabeçalho Authentication-Results, procurar a combinação spf=pass com dmarc=fail. Essa combinação indica que o SPF passou em um domínio diferente do From, sinal clássico de falsificação.
Exemplo de cabeçalho:
Authentication-Results: mx.captaindns.com;
spf=pass (sender IP is 198.51.100.42)
smtp.mailfrom=bounces.atacante-esp.com;
dkim=none;
dmarc=fail (p=none dis=none) header.from=captaindns.com
O spf=pass se refere a atacante-esp.com (envelope), não a captaindns.com (From). DMARC falha porque nenhum mecanismo (SPF ou DKIM) esta alinhado com o domínio do From. A política p=none deixa passar.
4. Reply-To para um domínio diferente do From
Como o atacante explora. O atacante falsifica um From credível (support@captaindns.com) mas insere um Reply-To para um endereço que ele controla (support-captaindns@protonmail.com ou support@captaindns-helpdesk.com). Quando o destinatário responde, sua resposta vai para o atacante. É uma técnica extremamente eficaz para o BEC (Business Email Compromise), que causou 55,5 bilhões de dolares em perdas acumuladas em dez anos (FBI IC3, 2024). O primeiro email não contem nem link nem anexo, o que evita qualquer detecção por análise de conteúdo.
Por que os filtros ignoram. O Reply-To é um cabeçalho informativo, não um mecanismo de autenticação. Os gateways geralmente não comparam o domínio do Reply-To com o do From. Um email sem URL suspeita nem anexo, com um SPF pass e um conteúdo textual limpo, supera os filtros sem dificuldade.
O que o defensor deve verificar. Comparar o domínio do cabeçalho Reply-To com o do From. Um desalinhamento para um domínio gratuito (Gmail, ProtonMail, Outlook.com) ou um domínio similar (typosquatting) é um sinal forte de BEC.
Exemplo de cabeçalho:
From: "Jean Dupont - DAF" <jean.dupont@captaindns.com>
Reply-To: jean.dupont.captaindns@protonmail.com
Subject: Transferencia urgente - fatura fornecedor
O From exibe um endereço interno credível. O Reply-To redireciona para uma conta ProtonMail que o atacante controla. Se o destinatário responde sem verificar, a conversa continua com o atacante.
Variantes avançadas. Os atacantes mais sofisticados não usam um domínio gratuito óbvio. Registram um domínio de typosquatting próximo ao domínio alvo: captaindns-support.com, captaindns.net, captaindnss.com. Esses domínios são mais difíceis de detectar em uma leitura rápida do Reply-To. Outra variante consiste em usar um subdominio enganoso: captaindns.service-desk.com (o domínio real é service-desk.com, não captaindns). Para a detecção automatizada, mantenha uma lista branca de domínios Reply-To autorizados e sinalize tudo que não conste nela.
5. Cadeia Received anormalmente curta ou longa
Como o atacante explora. Cada servidor que processa um email adiciona um cabeçalho Received no topo da pilha. Um email legítimo atravessa geralmente de 3 a 5 hops (servidor do remetente, gateway de saida, MX do destinatário, gateway de entrada, servidor de caixa postal). O atacante pode manipular essa cadeia de duas formas. Primeira opção: enviar diretamente a partir de um script para o MX do destinatário, produzindo uma cadeia com apenas 1 ou 2 hops, sinal de um envio não padrão. Segunda opção: injetar cabeçalhos Received falsos para simular um transito por servidores legítimos, alongando artificialmente a cadeia.
Por que os filtros ignoram. Os gateways não contam sistematicamente o número de hops nem verificam a coerência temporal entre os Received. Um email com 8 hops dos quais 3 são falsificados passa nos controles padrão se os cabeçalhos forjados estão bem formatados.
O que o defensor deve verificar. Contar os cabeçalhos Received e verificar duas coisas. Primeiro, a coerência temporal: os timestamps devem progredir de baixo (primeiro hop) para cima (último hop). Um salto no tempo (um hop datado antes do anterior) indica um cabeçalho forjado. Segundo, o número de hops: menos de 2 ou mais de 7 é anormal para um email profissional padrão.
Exemplo de cabeçalho (cadeia suspeita, muito curta):
Received: from mail-gw.captaindns.com (10.0.1.5) by mailbox.captaindns.com;
Thu, 27 Mar 2026 09:15:22 +0100
Received: from unknown (HELO send-node-14.atacante.net) (45.77.200.18)
by mail-gw.captaindns.com; Thu, 27 Mar 2026 09:15:20 +0100
Apenas 2 hops. Sem servidor de saida, sem gateway do remetente. A mensagem foi enviada diretamente de um no de envio para o MX de captaindns.com, sinal de um envio por script, não de um servidor de mensagens empresarial.
A técnica dos cabeçalhos Received forjados. Um atacante mais sofisticado insere cabeçalhos Received falsos para simular um transito por servidores legítimos. Adiciona por exemplo um hop Received: from mail-out.captaindns.com (10.0.1.2) by gateway.captaindns.com no fundo da pilha. A armadilha: os servidores de recepção adicionam os cabeçalhos Received no topo da pilha, não no fundo. Os cabeçalhos do fundo são os mais antigos e os primeiros a terem sido adicionados. Um cabeçalho Received que afirma vir de um servidor interno mas que se encontra no fundo da pilha (antes do primeiro hop legítimo) é um cabeçalho forjado pelo emissor. Verifique sempre a coerência da cadeia comecando pelo fundo.
6. Ausência de TLS no primeiro hop (STARTTLS ausente)
Como o atacante explora. O atacante usa um servidor configurado sem suporte TLS ou desativa voluntariamente STARTTLS. O objetivo não é a criptografia em si, mas o que revela sua ausência. Um servidor de email legítimo em 2026 suporta STARTTLS. Um servidor que envia em texto simples é provavelmente um script, uma ferramenta de ataque ou um servidor comprometido. A ausência de TLS também pode indicar um ataque de downgrade SMTP, onde um atacante intercepta a negociação TLS para forcar a transmissão em texto simples.
Por que os filtros ignoram. Os gateways não bloqueiam emails recebidos sem TLS. O protocolo SMTP é projetado para funcionar em texto simples com TLS como extensão opcional. Muitos gateways aceitam conexões não criptografadas para não perder correspondência legítima proveniente de servidores antigos. O fato de o primeiro hop ser em texto simples não é um critério de filtragem padrão.
O que o defensor deve verificar. No primeiro cabeçalho Received (o mais baixo na pilha), procurar a menção with ESMTPS (conexão TLS) versus with SMTP ou with ESMTP (conexão em texto simples). Um email profissional em 2026 deveria sempre transitar com TLS ativado no primeiro hop.
Exemplo de cabeçalho:
Received: from send-node.atacante.net (45.77.200.18)
by mail-gw.captaindns.com with SMTP;
Thu, 27 Mar 2026 09:15:20 +0100
A menção with SMTP (sem o S de ESMTPS) indica uma conexão em texto simples. Um servidor de email empresarial legítimo teria with ESMTPS ou with TLS. Essa ausência de criptografia é um sinal fraco mas significativo quando combinado com outros indicadores.
7. X-Mailer ou User-Agent suspeito
Como o atacante explora. Os clientes de email e os servidores inserem um cabeçalho X-Mailer ou User-Agent identificando o software utilizado. Os atacantes usam scripts Python (biblioteca smtplib ou aiosmtplib), ferramentas de envio em massa (GoPhish, King Phisher, Social Engineering Toolkit) ou frameworks próprios. Alguns atacantes omitem esse cabeçalho (o que já é um sinal), outros o falsificam para imitar um cliente legítimo (Outlook, Thunderbird). As falsificações costumam ser imperfeitas: uma versão inexistente, um formato de string incoerente ou um X-Mailer que não corresponde aos demais cabeçalhos presentes.
Por que os filtros ignoram. O X-Mailer não é um cabeçalho padronizado pelas RFCs. Os gateways não o consideram um critério de segurança e não mantem uma base de assinaturas de clientes maliciosos. Um email enviado pelo GoPhish com um X-Mailer falsificado Microsoft Outlook 16.0 passa nos filtros se o conteúdo e a reputação IP estão limpos.
O que o defensor deve verificar. Procurar o cabeçalho X-Mailer ou User-Agent. Um User-Agent Python (Python/3.11 aiosmtplib/2.0) é um sinal forte. A ausência total de X-Mailer em um email supostamente proveniente do Outlook é suspeita. Uma versão do Outlook que não existe (por exemplo Microsoft Outlook 17.5 quando a última versão é 16.x) denuncia uma falsificação.
Exemplo de cabeçalho:
X-Mailer: Python/3.11 aiosmtplib/2.0.1
From: "Servico TI" <it-support@captaindns.com>
Subject: Atualização obrigatoria da sua senha
Um email de "atualização de senha" enviado a partir de um script Python. Nenhum serviço de TI legítimo envia emails criticos por meio de um script Python com aiosmtplib. Esse cabeçalho denuncia uma ferramenta de ataque ou um teste de phishing interno.
8. Message-ID com domínio incoerente
Como o atacante explora. O cabeçalho Message-ID é um identificador único gerado pelo servidor de envio. Contem tipicamente um hash ou um identificador aleatório seguido do domínio do servidor que o gerou. O atacante que falsifica o From @captaindns.com mas envia a partir de seu próprio servidor gera um Message-ID com seu próprio domínio ou um identificador genérico. Esse desalinhamento entre o domínio do From e o domínio no Message-ID revela a infraestrutura real do atacante.
Por que os filtros ignoram. O Message-ID é usado para rastreamento de threads de conversa e deduplicação, não para segurança. Os gateways não comparam o domínio do Message-ID com o domínio do From. É um cabeçalho técnico que poucos sistemas de filtragem analisam sob o ângulo da coerência.
O que o defensor deve verificar. Extrair o domínio após o @ no Message-ID e compara-lo com o domínio do From. Um desalinhamento indica que a mensagem foi gerada por um servidor que não pertence ao domínio exibido.
Exemplo de cabeçalho:
Message-ID: <a3f8e2c1-9b47-4d6e-b5a2-1c7d3e9f0482@vps-node-14.atacante.net>
From: "Recursos Humanos" <rh@captaindns.com>
O Message-ID revela o servidor real: vps-node-14.atacante.net. Um email legítimo de captaindns.com teria um Message-ID contendo captaindns.com ou o domínio do ESP utilizado (por exemplo amazonses.com se a organização usa Amazon SES).
9. Cabecalhos X-MS-Exchange ou X-Google ausentes
Como o atacante explora. As grandes plataformas de email inserem cabeçalhos proprietários específicos. Microsoft 365 adiciona X-MS-Exchange-Organization-AuthSource, X-MS-Exchange-Organization-AuthAs, X-MS-Has-Attach, X-MS-TNEF-Correlator e outros. Gmail adiciona X-Gm-Message-State, X-Google-DKIM-Signature, X-Google-Smtp-Source. Quando um email afirma vir de um domínio hospedado no Microsoft 365 mas não contem nenhum desses cabeçalhos, não transitou pela plataforma Microsoft. O atacante que falsifica o From @captaindns.com (domínio hospedado no M365) mas envia de seu próprio servidor não consegue reproduzir esses cabeçalhos proprietários de forma credível.
Por que os filtros ignoram. Os gateways de terceiros (não Microsoft, não Google) não conhecem a lista de cabeçalhos proprietários esperados para cada plataforma. Mesmo os gateways integrados (Defender, Gmail) não verificam sistematicamente a coerência entre o domínio From e a presença dos cabeçalhos esperados da plataforma de hospedagem.
O que o defensor deve verificar. Identificar a plataforma de hospedagem do domínio do From (M365, Google Workspace, outra). Verificar que os cabeçalhos proprietários correspondentes estão presentes. Um email @captaindns.com (hospedado no M365) sem nenhum cabeçalho X-MS-Exchange-* não transitou pelo Microsoft 365.
Exemplo de cabeçalho (email suspeito, From M365 mas sem cabeçalhos Exchange):
From: "Direção Financeira" <daf@captaindns.com>
To: contabilidade@captaindns.com
Subject: Validação urgente - transferencia internacional
Date: Thu, 27 Mar 2026 09:15:00 +0100
Message-ID: <random-id@send-node.atacante.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Nenhum cabeçalho X-MS-Exchange-*, nenhum X-MS-Has-Attach, nenhum X-OriginatorOrg. Se captaindns.com esta hospedado no Microsoft 365, este email não transitou pela plataforma. É uma falsificação enviada a partir de um servidor externo.
10. Content-Type multipart com anexo .html encapsulado
Como o atacante explora. O atacante encapsula uma pagina HTML de roubo de credenciais (credential harvesting) no corpo MIME da mensagem. Ao contrário de um anexo clássico (.exe, .zip) que dispara os alertas, um arquivo .html é frequentemente considerado inofensivo pelos gateways. Quando o usuário abre o anexo HTML, seu navegador carrega uma pagina de login falsa que imita Microsoft 365, Google Workspace ou outro serviço. As credenciais inseridas são enviadas ao servidor do atacante. A pagina HTML pode funcionar completamente offline (sem download de recursos externos), o que dificulta a detecção pelos sandboxes.
Por que os filtros ignoram. Os arquivos HTML não são executaveis e não contem código malicioso no sentido tradicional (sem shellcode, sem macro). Os gateways que analisam anexos se concentram em formatos de risco (.exe, .docm, .xlsm, .js, .vbs). Um arquivo HTML é conteúdo web estático, e muitos filtros o deixam passar. Alguns gateways analisam as URLs no HTML, mas se a pagina funciona offline com JavaScript embutido, não ha URL para bloquear no momento da entrega.
O que o defensor deve verificar. Nos cabeçalhos MIME, procurar uma parte com Content-Type: text/html e Content-Disposition: attachment. A combinação HTML + attachment é um sinal forte. Analisar o conteúdo do arquivo HTML: a presença de tags <form>, <input type="password"> ou de JavaScript ofuscado em um anexo HTML é quase certamente maliciosa.
Exemplo de cabeçalho:
Content-Type: multipart/mixed;
boundary="----=_NextPart_001_0042_01D8F3A2.B5C7E890"
------=_NextPart_001_0042_01D8F3A2.B5C7E890
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Olá, por favor consulte o documento de segurança em anexo.
------=_NextPart_001_0042_01D8F3A2.B5C7E890
Content-Type: text/html; name="security-update-captaindns.html"
Content-Disposition: attachment; filename="security-update-captaindns.html"
Content-Transfer-Encoding: base64
PCFET0NUWVBFIGh0bWw+DQo8aHRtbD4NCjxoZWFkPjx0aXRsZT5DYXB0YWluRE5T...
O boundary MIME contem um anexo security-update-captaindns.html. O corpo em base64 decodifica para uma pagina HTML com um formulário de login. Um email legítimo da CaptainDNS nunca enviaria um arquivo HTML em anexo para uma "atualização de segurança".
Tecnicas de evasao no HTML embutido. Os atacantes usam várias técnicas para evadir os sandboxes que analisam anexos HTML. O JavaScript pode ser ofuscado (codificação base64, concatenação de strings, execução dinâmica de código). A pagina pode verificar se esta sendo executada em um navegador real (detecção de resolução de tela, de movimento de mouse, de plugins) e acionar o formulário de phishing somente se as condições forem atendidas. Algumas paginas HTML usam o protocolo data: ou Blob URLs para construir dinamicamente o formulário, tornando a análise estática ineficaz. Em 2025 e 2026, os anexos .svg contendo JavaScript embutido se tornaram uma variante cada vez mais comum dessa técnica, pois os SVGs são ainda menos monitorados que os arquivos HTML.
Combinar os indicadores: o poder do scoring multi-sinal
Tomados individualmente, cada indicador pode ter uma explicação legítima. Um Return-Path diferente do From é normal quando um ESP envia em nome de uma organização. Um DKIM assinado por um domínio de terceiros é padrão com SendGrid ou Amazon SES. Uma cadeia Received curta pode vir de um servidor on-premise que envia diretamente.
O poder desses 10 indicadores aparece quando são combinados. Um email que apresenta um único indicador merece uma verificação. Um email que apresenta tres indicadores ou mais é quase certamente malicioso. O princípio é o scoring multi-sinal: atribuir uma pontuação a cada indicador detectado e escalar quando a pontuação acumulada supera um limiar.
Exemplo de scoring para um email suspeito:
| Indicador detectado | Pontuação |
|---|---|
| Return-Path ≠ From (domínio desconhecido) | +2 |
| DKIM assinado por domínio de terceiros não ESP | +2 |
| SPF pass + DMARC fail | +3 |
| Reply-To para domínio gratuito | +3 |
| Cadeia Received < 3 hops | +1 |
| Ausência de TLS no primeiro hop | +1 |
| X-Mailer Python/script | +2 |
| Message-ID domínio ≠ From | +2 |
| Ausência cabeçalhos X-MS-Exchange (domínio M365) | +3 |
| Anexo HTML | +2 |
Um limiar de 5 pontos aciona uma sinalização para revisão SOC. Um limiar de 8 pontos aciona uma quarentena automática. Esse scoring pode ser implementado nas regras de transporte Exchange/Gmail ou em um SIEM.
Na prática, os emails de spear-phishing sofisticados combinam geralmente de 3 a 5 indicadores. Os indicadores 1 (desalinhamento Return-Path), 3 (SPF pass + DMARC fail) e 8 (Message-ID incoerente) aparecem juntos na maioria dos casos de falsificação de domínio. Os indicadores 4 (Reply-To divergente) e 9 (ausência de cabeçalhos proprietários) caracterizam os ataques BEC (Business Email Compromise). A combinação 5 (cadeia Received curta) + 6 (ausência TLS) + 7 (X-Mailer script) denuncia um envio a partir de uma ferramenta de ataque.
A lição é clara: nunca julgue um email por um único indicador. Construa um scoring multi-sinal adaptado ao seu ambiente e calibre os limiares analisando seus emails legítimos e seus incidentes passados.
Como detectar esses sinais após o gateway
Análise manual com uma ferramenta de inspeção
Para incidentes individuais (um usuário reporta um email suspeito), a análise manual de cabeçalhos continua sendo o método mais rápido. O usuário exporta os cabeçalhos brutos do seu cliente de email (no Outlook: Arquivo > Propriedades > Cabecalhos de Internet; no Gmail: os tres pontos > Mostrar original). O analista SOC cola os cabeçalhos em uma ferramenta de análise que decompoe cada cabeçalho e destaca as anomalias.
Os pontos a verificar em prioridade durante a análise manual:
- Return-Path vs From: domínios identicos ou justificativa legítima do desalinhamento?
- DKIM d= vs From: a assinatura cobre o domínio correto?
- Authentication-Results: combinação
spf=pass+dmarc=fail? - Reply-To: domínio coerente com o From?
- Cadeia Received: número de hops, coerência temporal, presença de TLS?
- Message-ID: domínio coerente com o From?
- Cabecalhos proprietários: presentes se o domínio esta hospedado no M365/Gmail?
- Partes MIME: anexo HTML suspeito?
Regras de transporte Exchange/Gmail para marcação automática
Para uma detecção sistemática, as regras de transporte (mail flow rules) no Exchange Online ou as regras de roteamento no Google Workspace permitem marcar automaticamente as mensagens que apresentam determinados indicadores.
Exemplo de regra Exchange Online para detectar o desalinhamento Reply-To:
Condição: o cabeçalho Reply-To contem um domínio diferente do domínio do From, E o domínio do Reply-To não esta em uma lista branca (domínios internos, ESPs autorizados). Ação: adicionar um banner de aviso a mensagem ("Esta mensagem tem um Reply-To diferente do remetente exibido") e marca-la para revisão SOC.
Exemplo de regra para detectar a ausência de cabeçalhos M365:
Condição: o domínio do From é um domínio interno hospedado no M365, E o cabeçalho X-MS-Exchange-Organization-AuthSource esta ausente. Ação: colocar em quarentena para revisão manual.
Essas regras não substituem o gateway mas adicionam uma camada de detecção pós-filtragem direcionada aos sinais que o gateway ignora.
Integração SIEM para detecção em larga escala
Para organizações com um volume significativo de emails, a integração com um SIEM (Microsoft Sentinel, Splunk, Elastic Security) permite automatizar a detecção e a correlação. Os logs de transporte Exchange ou Gmail contem os resultados de autenticação, os cabeçalhos-chave e os metadados de roteamento. Regras de detecção personalizadas buscam os seguintes padrões:
- Volume anormal de emails com
dmarc=fail action=nonepara um domínio interno - Emails de entrada com Reply-To para domínios gratuitos quando o From é um domínio interno
- Mensagens sem cabeçalhos
X-MS-Exchange-*quando o domínio From esta hospedado no M365 - Anexos HTML em emails de entrada com um
Frominterno
A correlação SIEM também permite cruzar um email suspeito com as conexões de rede: se um usuário abre um anexo HTML as 09:15 e uma conexão suspeita ao M365 a partir de um IP estrangeiro aparece as 09:18, o incidente é detectado em quase tempo real.
A relação com a entregabilidade e o spam
Os 10 indicadores descritos neste artigo não dizem respeito apenas a segurança. Também afetam a entregabilidade dos seus próprios emails. Se seu domínio apresenta os mesmos sinais que um email de phishing (Return-Path incoerente, DKIM não alinhado, DMARC em p=none), os gateways dos destinatários vao tratar suas mensagens com suspeita. Seus emails legítimos acabam no spam porque sua configuração DNS e seus cabeçalhos acionam os mesmos sinais que os atacantes exploram.
Corrigir seus próprios cabeçalhos (alinhar SPF e DKIM, passar DMARC para p=reject, configurar Message-IDs coerentes) tem um duplo benefício: reforcar a segurança do seu domínio contra falsificação E melhorar a entregabilidade dos seus emails legítimos. É a mesma grade de leitura aplicada a dois objetivos complementares.
Plano de ação
- Auditar seus 50 últimos emails suspeitos: recupere os cabeçalhos dos emails reportados por seus usuários no último mes e análise-os com os 10 indicadores. Essa auditoria revela os tipos de ataques que superam seu gateway.
- Criar regras de transporte para os indicadores 1, 4 e 5: o desalinhamento Return-Path/From, o Reply-To divergente e a cadeia Received anormal são os tres sinais mais fáceis de detectar automaticamente via regras Exchange ou Gmail.
- Reforcar DMARC para p=quarantine ou p=reject: enquanto sua política DMARC for
p=none, os indicadores 1, 2 e 3 continuam exploraveis sem consequência para o atacante. Lembrando que apenas 4% dos domínios aplicamp=reject(Valimail, 2025): cada domínio que migra reduz a superficie de ataque para todo o ecossistema. Use nossa ferramenta de verificação DMARC (link no banner acima) para auditar sua política atual. - Treinar as equipes SOC nos sinais de alerta dos cabeçalhos: os funcionarios treinados reportam quatro vezes mais ameaças que os não treinados, 21% contra 5% (Verizon DBIR, 2025). Os 10 indicadores deste artigo devem fazer parte do procedimento padrão de análise de incidentes de email. Crie um checklist imprimível que os analistas consultem durante cada investigação.
- Integrar a análise de cabeçalhos no processo de resposta a incidentes: as organizações que integram IA em seu pipeline de segurança reduzem o ciclo de violação em 80 dias e economizam em média 1,9 milhão de dolares por incidente (IBM, Cost of a Data Breach 2025). Cada email suspeito reportado deve passar por uma análise pós-gateway sistemática antes de ser classificado como falso positivo.
- Re-testar mensalmente com emails de teste: envie para si mesmo emails que reproduzam cada um dos 10 indicadores. Se seu gateway os deixa passar e suas regras de transporte não os sinalizam, suas defesas tem um ponto cego.
FAQ
Por que meu gateway de email não detecta esses sinais?
Os gateways são otimizados para filtragem em massa: reputação IP, conteúdo suspeito, assinaturas malware. Os 10 indicadores descritos aqui se referem a coerência dos cabeçalhos, um domínio que os gateways não analisam em profundidade. O desalinhamento Return-Path/From ou a ausência de cabeçalhos proprietários não são critérios de filtragem padrão na maioria dos SEGs do mercado.
Quais filtros de email são os mais vulneráveis a esses desvios?
Os gateways que se concentram exclusivamente na reputação IP e na análise de conteúdo são os mais vulneráveis. As soluções que integram análise comportamental e verificação de alinhamento DMARC estão melhor posicionadas, mas nenhum gateway do mercado verifica os 10 indicadores de forma exaustiva. Por isso a análise pós-gateway continua sendo necessária.
Como criar uma regra de transporte Exchange para detectar o desalinhamento Reply-To?
No Exchange Admin Center, crie uma regra de fluxo de email com a condição "Um cabeçalho de mensagem inclui" no cabeçalho Reply-To. Combine com a condição "O domínio do remetente é" para direcionar aos domínios internos. A ação recomendada é adicionar um aviso visível ao destinatário e marcar a mensagem para revisão SOC. Teste em modo de auditoria por duas semanas antes de ativar o bloqueio.
A análise de cabeçalhos pode ser automatizada?
Sim. Os resultados de autenticação e os cabeçalhos-chave são acessíveis nos logs de transporte Exchange Online e Gmail. Um SIEM (Sentinel, Splunk, Elastic) pode ingerir esses logs e aplicar regras de detecção sobre os 10 indicadores. Para organizações sem SIEM, as regras de transporte Exchange/Gmail oferecem um primeiro nível de automação acessível.
Essas técnicas de desvio funcionam contra Gmail e Outlook nativos?
Gmail e Outlook possuem suas próprias camadas de filtragem (Gmail usa modelos ML avançados, Outlook integra Defender). Esses filtros são melhores que a média no alinhamento DMARC e na detecção de Reply-To suspeito. Mas não são infalíveis: os indicadores 5 (cadeia Received anormal), 7 (X-Mailer suspeito), 8 (Message-ID incoerente) e 10 (anexo HTML) continuam sendo pontos cegos mesmo para essas plataformas.
Como treinar minha equipe SOC na análise de cabeçalhos?
Comece com um workshop prático de 2 horas com emails reais (anonimizados) que apresentem cada um dos 10 indicadores. Crie um checklist imprimível que os analistas consultem durante cada investigação. Integre a análise de cabeçalhos nos exercícios de simulação de mesa e nas simulações de phishing internas. O objetivo é que cada analista SOC possa identificar os 10 indicadores em menos de 5 minutos por email.
E preciso substituir meu gateway de email para se proteger?
Não. Os 10 indicadores são complementos ao gateway, não substitutos. O gateway continua indispensável para bloquear o spam em massa, os malwares conhecidos e as campanhas de phishing genéricas. O objetivo é adicionar uma camada de detecção pós-gateway (regras de transporte, análise SOC, SIEM) direcionada aos ataques sofisticados que a filtragem padrão não captura.
Como testar se meu gateway ignora esses sinais?
Envie para si mesmo emails de teste reproduzindo cada um dos 10 indicadores a partir de um servidor externo. Para o desalinhamento Return-Path: configure um MAIL FROM diferente do From. Para o DKIM de terceiros: assine com um domínio diferente. Para o Reply-To: insira um Reply-To para um domínio externo. Documente quais emails superam o gateway e quais são bloqueados. Esse teste revela os pontos cegos específicos da sua configuração.
Glossário
- Return-Path: cabeçalho inserido pelo servidor de recepção contendo o endereço do envelope SMTP (MAIL FROM). Usado para notificações de não entrega (bounces). Verificado pelo SPF.
- DKIM-Signature: cabeçalho contendo a assinatura criptográfica de uma mensagem. O campo
d=identifica o domínio assinante,s=o seletor da chave pública. - Alinhamento DMARC: verificação de que o domínio do From corresponde ao domínio verificado pelo SPF (alinhamento SPF) ou ao domínio assinante DKIM (alinhamento DKIM). O alinhamento pode ser rigoroso (correspondência exata) ou relaxado (correspondência no domínio organizacional).
- Reply-To: cabeçalho opcional indicando o endereço para o qual as respostas devem ser direcionadas. Pode diferir do From.
- Cadeia Received: serie de cabeçalhos adicionados por cada servidor (hop) que processou a mensagem. Lidos de cima para baixo, tracam o percurso da mensagem do último hop (topo) ao primeiro (fundo).
- STARTTLS: extensão SMTP que permite iniciar uma conexão criptografada TLS sobre uma conexão SMTP existente. Visivel nos cabeçalhos Received pela menção
with ESMTPS. - X-Mailer: cabeçalho opcional identificando o software cliente usado para enviar a mensagem. Não padronizado pelas RFCs, mas amplamente usado pelos clientes de email.
- Message-ID: identificador único atribuido a cada mensagem pelo servidor de envio. Formato:
<identificador@domínio>. Usado para encadeamento de conversas e deduplicação. - MIME (Multipurpose Internet Mail Extensions): padrão de codificação de emails que permite anexos, conteúdo HTML e caracteres não ASCII. Definido pelo cabeçalho
Content-Type. - Content-Disposition: cabeçalho MIME indicando se uma parte da mensagem deve ser exibida inline (
inline) ou oferecida para download (attachment). - Remetente de envelope (envelope sender): endereço SMTP usado durante o comando MAIL FROM na sessão SMTP. Distinto do endereço no cabeçalho From visível pelo destinatário.
Seus cabeçalhos escondem sinais suspeitos? Cole seus cabeçalhos brutos em nosso analisador de cabeçalhos de email para um diagnóstico automático cobrindo autenticação, roteamento e as anomalias descritas neste artigo.
