Em 17 de junho de 2026, a equipe de segurança Red Team da Barracuda Networks publicou uma simulação que rastreou um ataque de e-mail impulsionado por inteligência artificial desde a primeira mensagem de phishing até o comprometimento total do endpoint e o acesso persistente do atacante. Toda a cadeia levou menos de cinco minutos.
A simulação não foi um caso extremo fabricado. Ela utilizou ferramentas disponíveis comercialmente e técnicas de ataque realistas observadas em campanhas ativas. O ambiente alvo executava defesas empresariais padrão. O resultado foi uma cadeia de ataque de três etapas que contornou a autenticação multifator, estabeleceu persistência de longo prazo no endpoint, e o fez a partir de um e-mail que não geraria alertas visuais nem para um usuário experiente.
O DMARC não aparece na lista de falhas. O ataque passou pela autenticação em cada etapa.
A Cadeia de Ataque de Três Etapas
Primeira etapa: phishing gerado por IA
O ataque começou com um e-mail elaborado por um modelo de linguagem de grande escala para imitar uma notificação legítima de compartilhamento de arquivos do Microsoft SharePoint. A mensagem não continha erros ortográficos, formatação incomum nem nenhum endereço de remetente que gerasse suspeitas visuais. O link apontava para uma página estilizada como uma visualização de documento do SharePoint.
Este é o efeito prático da IA no phishing em 2026. Os sinais gramaticais nos quais os usuários treinados aprenderam a se concentrar – capitalização inconsistente, fraseologia estranha, spoofing óbvio de domínio – desapareceram em grande parte das campanhas direcionadas. Os modelos de linguagem de grande escala geram texto de isca limpo e contextualmente apropriado em escala, e o conteúdo passa pela revisão humana casual assim como por muitos filtros automatizados de conteúdo. O registro DMARC do domínio remetente era válido. O alinhamento SPF estava correto. O DKIM passou.
O e-mail estava autenticado. Também era malicioso.
Segunda etapa: adversário no meio e bypass de MFA
Quando o alvo clicou no link, ele encontrou um proxy de retransmissão em tempo real. Os ataques de adversário no meio (AitM) colocam esse retransmissor entre a vítima e o serviço de login genuíno. A vítima conclui a autenticação normalmente, incluindo a inserção do código MFA. O retransmissor captura tanto as credenciais quanto o token de sessão que o serviço legítimo emite após o login bem-sucedido.
O código MFA é inútil para o atacante. O token de sessão – que não requer o fator MFA para ser reutilizado – é tudo o que ele precisa. Com um token de sessão válido em mãos, o atacante tem acesso autenticado à conta alvo sem nunca conhecer a senha ou o fator MFA. O requisito de autenticação foi satisfeito pelo serviço legítimo em nome da vítima. O atacante chega com uma credencial válida.
Terceira etapa: ClickFix e persistência no endpoint
A terceira etapa apresentou à vítima um aviso falso de solução de problemas que parecia vir de um site de aparência legítima. O aviso instruía o usuário a abrir seu terminal ou caixa de diálogo Executar e colar um comando. O comando estava pré-carregado na área de transferência. Um clique de confirmação o executou.
O ClickFix funciona porque delega a execução à vítima. O atacante não entrega um binário malicioso nem aciona uma assinatura de detecção no endpoint. O usuário executa o comando por conta própria, e esse comando estabelece a persistência do atacante na máquina.
Tempo total decorrido na simulação da Barracuda: menos de cinco minutos desde o e-mail inicial até o acesso persistente ao endpoint.
O Que o DMARC Protege e o Que Não Protege
O DMARC resolve um problema específico e bem definido. Ele verifica se o domínio no cabeçalho From de um e-mail está alinhado com o domínio que autenticou a mensagem via SPF ou DKIM. Isso impede que terceiros externos enviem e-mails que falsamente afirmam originar-se do seu domínio. Se a sua organização possui um registro DMARC em p=reject, nenhum atacante pode enviar e-mail afirmando ser do seu domínio para destinatários cujos provedores respeitam a aplicação do DMARC.
Essa é uma proteção extremamente valiosa. Ela fecha a porta para a falsificação direta de domínio, que é o mecanismo mais comum na falsificação de marca e nos ataques de comprometimento de e-mail empresarial lançados de infraestrutura externa.
O que o DMARC não aborda é o que acontece após a entrega de uma mensagem. Um e-mail que passa no DMARC foi autenticado na camada de transporte. O conteúdo desse e-mail – o link que ele contém, a página que esse link carrega, cada instrução que o destinatário segue após o evento de entrega – está completamente fora do escopo do DMARC.
A simulação da Barracuda explorou exatamente esse limite. O e-mail de phishing era autêntico no nível do remetente. O DMARC viu um domínio corretamente configurado, SPF válido e uma assinatura DKIM aprovada. O ataque existiu inteiramente no que veio após o evento de entrega: a página de retransmissão AitM, a captura de credenciais, o roubo do token de sessão, o aviso ClickFix.
Nenhuma dessas etapas é visível para o DMARC. Todas tiveram sucesso.
A Escala da Lacuna de Autenticação em 2026
A simulação da Barracuda foi publicada em um contexto de falhas de autenticação persistentes no ecossistema geral de e-mail. O Relatório de Ameaças 2026 da Cloudflare, elaborado a partir da análise de 450 milhões de e-mails, descobriu que 43% falharam nas verificações SPF, 44% careciam de assinaturas DKIM válidas, e 46% falharam completamente na validação DMARC.
Esses números representam dois problemas distintos operando simultaneamente. A grande parte dos e-mails que falham na autenticação são remetentes que não implementaram corretamente os fundamentos – e-mails que não deveriam passar pelos portões de autenticação e frequentemente não passam. Essa população é o alvo principal da aplicação do DMARC.
Mas dentro dos e-mails que passam na autenticação – os e-mails que DMARC, SPF e DKIM validam – há um subconjunto crescente de phishing elaborado com IA projetado especificamente para passar nessas verificações enquanto executa ataques de múltiplas etapas contra os destinatários. O mesmo relatório da Cloudflare documentou mais de 123 milhões de dólares em tentativas de roubo financeiro BEC interceptadas em 2025, com uma tentativa média calibrada em 49.225 dólares, um valor definido deliberadamente logo abaixo dos limiares de aprovação de pagamentos executivos típicos.
O Que a Simulação Significa para a Segurança do Seu E-mail
A aplicação do DMARC em p=reject continua sendo o ponto de partida inegociável. A simulação da Barracuda não é um argumento contra o DMARC. É um argumento para entender o que o DMARC cobre, para que você não o trate como uma solução completa. Sem o DMARC em aplicação, terceiros externos podem falsificar diretamente o seu domínio. Se a sua organização ainda não está em p=reject, essa continua sendo a primeira prioridade.
A proteção pós-entrega cobre a lacuna que o DMARC não consegue alcançar. A cadeia de ataque de cinco minutos teve sucesso na camada que existe após a entrega. A segurança de e-mail pós-entrega – capacidades que podem retirar mensagens após a entrega, detectar infraestrutura de retransmissão AitM e sinalizar comportamento anômalo de sessão – opera precisamente na camada que o DMARC não alcança.
Cadeias de ataque com IA exigem resposta automatizada na mesma velocidade. Uma cadeia de ataque que atinge acesso persistente ao endpoint em cinco minutos não deixa tempo para um analista humano detectar, investigar e responder. A detecção e resposta precisam operar em velocidade de automação.
O MFA padrão não detém AitM. A simulação contornou o MFA capturando o token de sessão após a conclusão da autenticação legítima. Essa é uma limitação bem conhecida do MFA baseado em TOTP e SMS quando a infraestrutura AitM está no caminho. A autenticação vinculada ao hardware, como chaves de acesso FIDO2 e credenciais de sessão vinculadas ao dispositivo, resiste ao AitM porque a credencial não pode ser reproduzida a partir de uma máquina diferente.
Os Fundamentos de Autenticação Importam – e Sozinhos Não São Suficientes
A adoção do DMARC entre os 1,8 milhões de domínios mais importantes atingiu 52,1% em 2026, acima dos 47,7% no ano anterior e 27,2% há três anos. Google, Yahoo e Microsoft exigem DMARC para remetentes em massa e aplicam penalidades de entrega a e-mails que não estão em conformidade. A trajetória é clara, e o piso de autenticação está subindo.
Essa base vale a pena construir com cuidado. Cada organização que avança de p=none para p=reject fecha a superfície de ataque de falsificação direta que o DMARC foi projetado para eliminar. Isso importa.
O que a simulação da Barracuda demonstra é que a superfície de ataque não termina no portão de autenticação. Um e-mail pode ser completamente autenticado, entregue com sucesso, passar por todos os filtros na camada de transporte, e ainda assim iniciar uma cadeia de ataque que alcança o endpoint em menos de cinco minutos. As organizações que entendem essa distinção estão construindo uma postura em camadas – DMARC em aplicação, proteção pós-entrega, autenticação resistente ao AitM e controles de endpoint – em vez de tratar qualquer camada individual como a resposta completa.
O Excello Mail oferece visibilidade completa sobre a configuração de DMARC, SPF e DKIM em todos os seus domínios de envio, para que você possa fechar a lacuna de autenticação antes que os atacantes a explorem. Cadastre-se gratuitamente no Excello Mail e certifique-se de que sua base de autenticação de e-mail seja sólida.