Entre 3 e 5 de agosto de 2026, a Microsoft Threat Intelligence rastreou mais de um milhão de e-mails chegando a caixas de entrada corporativas nos Estados Unidos, cada um construído em torno da mesma proposta: uma fatura de assinatura anual da ServiceNow, um pedido urgente do próprio CEO da empresa, e uma transferência ACH de quase 50 mil dólares esperando aprovação. Os domínios por trás de aproximadamente 87,7 por cento desse volume enviavam a partir dos Estados Unidos. Nada disso precisou de um domínio falsificado para chegar lá. Saiu pela infraestrutura de e-mail real de empresas reais, autenticando exatamente como deveria.
Um Pacote Convincente, Não um Cabeçalho Quebrado
O próprio e-mail fez o trabalho que em outros casos normalmente cabe a um truque de cabeçalho. Os atacantes personificaram o CEO, CFO ou presidente de cada empresa-alvo no nome de exibição do remetente, no nome de exibição do reply-to e na assinatura, e então pediram à equipe de contas a pagar que processasse o pagamento ACH descrito em uma fatura anexada. Essa fatura não era um modelo genérico. Trazia a marca da ServiceNow, um número de fatura específico, uma data de faturamento, e uma seção “FATURADO PARA” endereçada à empresa-alvo real. Abaixo dela havia uma sequência de e-mails encaminhados fabricada, construída para parecer que o CEO personificado e um representante da ServiceNow já haviam discutido a compra, de modo que o destinatário em contas a pagar entrava em uma conversa que parecia já ter consenso por trás. A Microsoft não encontrou evidências de que a própria ServiceNow, ou qualquer outra marca citada nas iscas, estivesse comprometida ou envolvida.
Contas Reais, Domínios Reais, Autenticação Real
A escolha de infraestrutura é o que torna essa campanha digna de um segundo olhar. Em vez de montar domínios parecidos para enviar, os operadores encaminharam o mais de um milhão de mensagens por meio de múltiplas contas em um serviço legítimo de envio em massa de e-mail, com endereços de envio ligados a negócios reais e não relacionados: [email protected], [email protected], [email protected], entre outros. O e-mail enviado por essas contas autentica contra os próprios registros SPF e DKIM desses domínios, exatamente como aconteceria para qualquer cliente legítimo daquela plataforma, porque, mecanicamente, é exatamente isso. Dois domínios de apoio, service-nowinc[.]com e domainlify[.]net, ambos registrados em 31 de julho, existiam apenas para receber respostas caso uma vítima escrevesse de volta, não para carregar a identidade autenticada da mensagem. As verificações de alinhamento do DMARC comparam o domínio no cabeçalho From visível com o domínio que realmente enviou o e-mail. Aqui, os dois fatos coincidiam. O engano vivia inteiramente no nome de exibição ao lado de um endereço preciso e alinhado, um campo que o DMARC nunca foi feito para avaliar.
As Digitais da IA, e Por Que Elas Não Importam Para o DMARC
Os pesquisadores da Microsoft sinalizaram vários indícios consistentes com IA generativa tendo participado da construção dos modelos: comentários HTML extensos rotulando cada seção da fatura e da sequência de e-mails, formatação incomumente uniforme em toda a amostra, uso pesado de separadores em estilo banner, e uso consistente de travessões longos ao longo do texto. Os pesquisadores fizeram questão de destacar que esses indícios estabelecem o envolvimento da IA na construção dos modelos, não quanto do conteúdo de qualquer e-mail individual um modelo realmente redigiu. De qualquer forma, a técnica se posiciona uma camada acima da autenticação. Seja um humano ou um modelo quem escreveu a fatura falsa da ServiceNow, a mensagem ainda precisava de um domínio para ser enviada, e usou um que tinha pleno direito de enviá-la.
Por Que o DMARC Nunca Foi a Camada Que Vigiava Isso
Essa campanha não é tanto uma nova espécie de evasão de autenticação quanto um lembrete do que o DMARC foi definido para verificar desde o início: se o domínio no cabeçalho From corresponde a um domínio autorizado a enviar aquele e-mail. Ele não diz nada sobre se o nome de exibição ao lado desse endereço corresponde ao CEO real de uma empresa, se uma fatura anexada é genuína, ou se uma sequência de e-mails encaminhados por baixo dela realmente aconteceu. Uma plataforma de envio em massa com milhares de contas de clientes legítimos vai, por design, passar em SPF e DKIM para cada uma delas, tanto as honestas quanto as sequestradas. Esse é um modo de falha diferente da violação em uma plataforma de marketing que deixou um único atacante alcançar 138 contas de clientes e falsificar avisos por meio de várias marcas fintech ao mesmo tempo, ou do truque de cabeçalhos autofalsificados que fazia o e-mail de phishing parecer vir do próprio endereço do destinatário. Aqui, nenhum comprometimento das contas de envio parece sequer necessário: um atacante só precisa de uma conta, um nome de remetente plausível, e um documento convincente o bastante para sobreviver a uma leitura apressada em contas a pagar.
O Que Isso Significa Para Seu Programa
Dê a contas a pagar uma etapa de verificação que não dependa da caixa de entrada. Qualquer solicitação de ACH ou transferência ligada a uma nova relação com fornecedor, ou a uma mudança repentina em uma já existente, deveria exigir uma ligação de confirmação para um número de telefone obtido de um sistema interno, não um encontrado no próprio e-mail. O DMARC passar não é evidência de que a solicitação seja real.
Fique atento a incompatibilidades no nome de exibição, não só no domínio. Uma regra que sinalize quando o nome de exibição de um remetente corresponde ao de um executivo, mas o domínio autenticado não corresponde a nenhum domínio com o qual sua equipe financeira já tenha transacionado antes, captura exatamente esse padrão, mesmo quando SPF e DKIM estão limpos.
Trate uma sequência de e-mails encaminhados dentro de uma mensagem como não verificada até prova em contrário. Uma captura de tela ou uma conversa citada incorporada em uma mensagem é texto, não evidência. Ela não carrega autenticação própria e nunca deveria ser o que move uma solicitação de pagamento de suspeita para aprovada.
Lembre-se de que o trabalho do DMARC termina no domínio, não no negócio. Um domínio pode ter uma política DMARC rigorosa e nunca ver uma mensagem falsificada chegar a uma caixa de entrada, enquanto um domínio completamente diferente e totalmente autenticado envia a fraude de fatura que esvazia uma conta bancária. Os dois resultados são consistentes com o DMARC fazendo exatamente o que foi construído para fazer.
A Conclusão
Um milhão de e-mails chegaram a caixas de entrada corporativas em três dias sem que nenhum precisasse falhar em SPF, DKIM ou DMARC para isso. Os operadores escolheram uma infraestrutura que autentica de forma limpa por padrão e construíram um documento convincente o bastante para que a verificação de autenticação nunca fosse o obstáculo em seu caminho. O DMARC verificou o domínio corretamente em cada mensagem. Nunca foi solicitado, nem construído, para verificar a fatura.
O DMARC confirma que um domínio está autorizado a enviar. Ele não tem como dizer se esse domínio pertence a um remetente em massa cujos outros clientes estão sendo personificados para fraudar sua equipe financeira. O Excello Mail oferece visibilidade contínua e em linguagem clara sobre sua postura real de autenticação, para que você saiba exatamente onde termina a cobertura do DMARC e onde o resto da sua defesa precisa começar. Cadastre-se gratuitamente no Excello Mail e veja hoje sua imagem real de autenticação.