Em 14 de abril de 2026, uma campanha de phishing começou a chegar às caixas de entrada de sistemas de saúde, bancos, escritórios de advocacia e empresas de tecnologia em 26 países. Em 16 de abril, havia terminado. Nessas 48 horas, a equipe de inteligência de ameaças da Microsoft havia registrado mais de 35.000 usuários-alvo em mais de 13.000 organizações. Noventa e dois por cento estavam nos Estados Unidos.
A Microsoft publicou sua análise em 4 de maio de 2026. A campanha usou infraestrutura de adversário no meio (AiTM, na sigla em inglês) para capturar tokens de sessão em tempo real, o que significa que contornou completamente a autenticação multifator. Mas antes de qualquer token ser roubado, o ataque precisou chegar a uma caixa de entrada. Esse primeiro passo, a entrega, é onde a autenticação de e-mail segura a linha ou falha.
Como a campanha funcionou
As mensagens de phishing usavam o que os pesquisadores da Microsoft chamaram de “modelos HTML elaborados no estilo empresarial com layouts estruturados e declarações de autenticidade preventivas”. A isca era uma solicitação de confirmação de código de conduta, o tipo de mensagem que os funcionários estão condicionados a responder sem muito escrutínio. Organizações de saúde e ciências da vida receberam 19% do volume da campanha. Serviços financeiros receberam 18%. Serviços profissionais e empresas de tecnologia dividiram o restante.
O mecanismo de entrega explorou um padrão que a Microsoft havia alertado quatro meses antes, em janeiro de 2026: configurações de roteamento de e-mail complexas em que os registros MX não apontam diretamente para o Microsoft 365, combinadas com conectores de terceiros que carregam confiança implícita. Nesses ambientes, um invasor que roteia por meio de um relay confiável pode injetar mensagens que parecem ter origem dentro da organização, contornando as verificações de DMARC e SPF que teriam sinalizado ou rejeitado a mesma mensagem enviada diretamente.
Quando a mensagem chegava à caixa de entrada, clicar no link levava a uma página de login servida pela infraestrutura AiTM. O proxy AiTM ficava entre a vítima e o login real da Microsoft, capturava as credenciais e o token de sessão resultante em tempo real, e transmitia um login bem-sucedido para a vítima para evitar levantar suspeitas. Com um token de sessão válido em mãos, o invasor tinha acesso autenticado à conta independentemente do método de MFA cadastrado.
O problema de configuração incorreta de roteamento
O aviso de segurança da Microsoft de janeiro de 2026 descreveu a superfície de ataque com precisão. Organizações que roteiam e-mails de entrada por meio de um gateway de segurança de terceiros antes de chegar ao Microsoft 365 geralmente configuram um conector de entrada que concede a esse gateway confiança elevada. Se esse conector estiver configurado incorretamente, especificamente se permitir mensagens que afirmam vir de domínios aceitos internamente sem verificar o alinhamento de SPF ou a assinatura DKIM, então um invasor que pode alcançar esse conector pode enviar e-mails que o Microsoft 365 trata como de origem interna.
As condições técnicas que criam essa exposição são comuns:
- Os registros MX apontam para um serviço de filtragem de terceiros, não diretamente para o Exchange Online
- O conector de entrada para esse serviço está configurado para aceitar qualquer mensagem que o serviço encaminhe, em vez de validar a autenticação em cada mensagem
- A política DMARC no próprio domínio da organização é
p=none, o que significa que os sistemas receptores recebem instrução para monitorar, mas nunca bloquear e-mails não autenticados
Cada condição é individualmente nada incomum. As organizações usam gateways de e-mail de terceiros por razões legítimas. Conectores de entrada exigem concessões de confiança por design. p=none é o ponto de partida para a implantação do DMARC. Juntos, eles criam um caminho de fora da organização para uma caixa de entrada que aparece como interna.
A mitigação que a Microsoft recomendou em janeiro foi direta: definir DMARC como p=reject com SPF configurado para hard fail (-all), e auditar cada conector de terceiros para verificar se ele valida SPF e DKIM em vez de herdar confiança geral. Organizações cujos registros MX apontam diretamente para o Exchange Online não estão expostas a esse vetor de ataque específico. Aquelas com roteamento de terceiros no caminho estão, se sua configuração de autenticação for permissiva.
Por que a MFA não salvou esses usuários
A técnica AiTM ataca o token de sessão emitido após autenticação bem-sucedida, inclusive após a conclusão do desafio de MFA. A vítima faz login, passa pelo segundo fator e recebe um cookie de sessão. O proxy AiTM captura esse cookie antes que o navegador o armazene. O invasor apresenta o mesmo cookie ao serviço e recebe acesso autenticado completo.
Isso não é uma vulnerabilidade nas implementações de MFA. É uma técnica que opera acima da camada de autenticação, na camada de sessão. Funciona contra códigos TOTP, senhas de uso único por SMS, aprovações push e a maioria das implementações de tokens de hardware. Métodos de MFA resistentes a phishing vinculados à URL de origem, como chaves de acesso FIDO2 e autenticação baseada em certificado, bloqueiam AiTM porque o autenticador se recusa a operar em um domínio que não reconhece. Mas a MFA resistente a phishing não é a norma nas 13.000 organizações que foram alvo em abril.
A implicação prática é que a MFA reduz, mas não elimina, o risco de phishing de credenciais. O DMARC em nível de aplicação, combinado com SPF preciso, reduz o risco de entrega que torna possível a tentativa de phishing de credenciais em primeiro lugar. Nenhum controle por si só é suficiente. Ambos são componentes necessários de uma defesa em camadas.
A primeira barreira
A autenticação de e-mail em p=reject é a primeira barreira na cadeia de eliminação de phishing. Ela não impede todas as campanhas de phishing, mas elimina uma categoria grande e importante: mensagens que afirmam vir do seu domínio ou de um domínio que você controla e que na verdade não estão autenticadas a partir da sua infraestrutura.
Se as organizações visadas na campanha de abril tivessem aplicado p=reject em seus próprios domínios e auditado sua configuração de conectores para garantir que o alinhamento de SPF fosse verificado no nível do conector de entrada, o caminho de ataque que dependia de parecer ter origem interna teria sido bloqueado antes da entrega. O e-mail de phishing que parece uma comunicação interna de RH é muito menos convincente quando precisa chegar de um domínio que o invasor realmente controla, em vez de falsificar a própria identidade da organização.
Esta é a lacuna de aplicação que os relatórios de adoção de DMARC de 2026 documentam. Dos aproximadamente 937.000 domínios com registros DMARC, menos da metade passou para quarentena ou rejeição. A maioria está em p=none, que gera relatórios e não faz nada para bloquear a entrega. Para organizações que roteiam e-mails por gateways de terceiros com conectores permissivos, p=none não oferece nenhuma proteção contra o padrão de ataque que a Microsoft documentou.
A auditoria de configuração que você deve realizar agora
A combinação do aviso de roteamento de janeiro de 2026 e a divulgação da campanha AiTM de maio de 2026 define uma lista de verificação específica para qualquer organização que use o Microsoft 365 com roteamento de e-mail de terceiros:
Nível de política DMARC. Verifique se seu domínio organizacional tem um registro DMARC em p=quarantine ou p=reject. Se seu registro estiver em p=none, agende a migração de aplicação e trate-a como uma correção de segurança, não como uma caixa de seleção de conformidade.
Hard fail de SPF. Revise seu registro SPF e confirme que termina em -all, não em ~all. Um softfail (~all) diz aos servidores receptores que e-mails não autenticados ainda podem ser legítimos. Um hard fail (-all) diz a eles para rejeitar. A configuração ~all existe para a fase de monitoramento da implantação do DMARC. Uma vez que a aplicação está em vigor, ela deve ser substituída.
Validação do conector de entrada. Se você usa um gateway de terceiros, revise a configuração do conector no Centro de administração do Exchange. Confirme que o conector valida SPF e DKIM em mensagens de entrada em vez de confiar implicitamente em tudo que o gateway encaminha. A documentação da Microsoft cobre isso em “Filtragem aprimorada para conectores”.
Política de subdomínio. A política DMARC do seu domínio apex não se aplica automaticamente a subdomínios a menos que você inclua sp=reject no seu registro. A atualização RFC 9989 introduziu a tag np= especificamente para subdomínios inexistentes. Se os invasores puderem enviar de mail.seudominio.com ou rh.seudominio.com sem atingir uma política de aplicação, esses subdomínios são superfície de ataque.
Monitoramento de relatórios agregados. Executar em p=reject sem revisar os relatórios agregados significa que você não saberá quando uma nova fonte de envio legítima aparecer e falhar na autenticação. A aplicação do DMARC sem análise contínua de relatórios é manutenção sem monitoramento.
A conclusão
A campanha de abril de 2026 visou mais de 13.000 organizações em dois dias usando técnicas documentadas há anos. A vulnerabilidade de configuração incorreta de roteamento que contribuiu para seu alcance foi divulgada publicamente pela Microsoft em janeiro de 2026 com etapas concretas de correção. A lacuna entre a divulgação e a correção é onde os invasores operam.
A autenticação de e-mail em nível de aplicação não é uma conquista técnica sofisticada. É um estado de configuração. O desafio não é saber o que configurar; o desafio é concluir o processo em cada fonte de envio, cada conector e cada subdomínio, e então manter essa configuração conforme a infraestrutura muda. Essa continuidade operacional é o que separa as organizações que estão protegidas daquelas que estão documentadas, mas expostas.
Fechar a lacuna de roteamento e aplicar DMARC p=reject em um ambiente de envio complexo é exatamente o tipo de trabalho operacional contínuo que o Excello Mail gerencia para você. Análise de relatórios agregados, descoberta de fontes, orientação sobre conectores e monitoramento de aplicação em uma única plataforma. Cadastre-se gratuitamente em excello.email →