A Huntress publicou uma pesquisa em 7 de julho de 2026 detalhando uma campanha de phishing que funcionou sem interrupções por cerca de oito meses ao explorar algo que nenhum protocolo de autenticação foi criado para detectar: um recurso real, funcionando exatamente como projetado, acionado por um atacante em vez de uma empresa legítima. Os e-mails chegavam de [email protected]. Eles realmente vinham dos próprios servidores do Meta. Passavam por SPF, DKIM e DMARC porque não havia nada para falhar. O engano começava somente depois que o destinatário clicava.
Um Recurso, Não uma Falsificação
O Meta Business Manager permite que uma empresa envie uma “solicitação de parceria” convidando outra conta para colaborar em contas de anúncios ou Páginas, um fluxo de trabalho rotineiro usado constantemente por agências e equipes de marketing. A Huntress descobriu que os agentes de ameaça, ativos desde pelo menos novembro de 2025, haviam aprendido a configurar o nome de exibição e o nome da empresa em sua própria conta controlada pelo atacante para que parecesse uma iniciativa oficial do Meta, algo semelhante a um convite do Programa de Parceiros de Agências do Meta ou a uma oferta de verificação. A plataforma do Meta então fazia exatamente o que foi criada para fazer: gerava um e-mail de notificação real a partir de sua própria infraestrutura e o entregava, endereçado como se viesse do próprio Meta, porque, no que dizia respeito ao sistema de e-mail, era mesmo.
Do Google Sites a um Chatbot Falso
A campanha evoluiu ao longo do tempo. Uma versão anterior, ativa em maio de 2026, direcionava os cliques para uma página falsa do Programa de Parceiros de Agências do Meta hospedada no Google Sites. Em junho, os operadores já haviam adicionado um chatbot fraudulento do Facebook Messenger à cadeia, apresentando às vítimas opções como “Obter Selo de Verificação” ou “Ativar Monetização” antes de redirecioná-las para páginas de phishing hospedadas no Netlify. Os domínios registrados pelo atacante por trás dessas páginas foram criados para se misturar com as próprias convenções de nomenclatura do Meta: agency-ad-hub.com, agency-partner-register.com, marketing-partner-join.com. Nada dessa infraestrutura precisava tocar no e-mail em si. O e-mail já havia feito seu trabalho ao ser real.
O Que o Kit Realmente Roubava
As páginas de phishing coletavam credenciais de contas do Meta, códigos MFA, números de telefone pessoais e da empresa, endereços de e-mail, e uma fotografia do documento de identidade ou passaporte da vítima, o suficiente para assumir o controle de uma conta e, ao mesmo tempo, driblar a reverificação de identidade. A Huntress rastreou a exfiltração até um bot do Telegram, encontrou trechos de texto em vietnamita no código do lado do cliente, e identificou o nome de usuário do operador do bot, apontando para uma infraestrutura provavelmente ligada ao Vietnã por trás de uma campanha que atingiu empresas em várias regiões antes de o Meta implementar salvaguardas em junho de 2026 que, segundo os pesquisadores, a interromperam desde então.
Por Que o DMARC Não Tinha Nada a Sinalizar
O DMARC existe para confirmar que o domínio no cabeçalho “From” de uma mensagem está autorizado a enviar em seu próprio nome. Nessa campanha, business.facebook.com enviou o e-mail, assinou-o e alinhou-o, tudo corretamente, tudo de forma genuína. Não havia domínio parecido, nenhum cabeçalho suplantado, nenhuma brecha de autenticação que o DMARC pudesse detectar, porque a plataforma que enviava a notificação e o domínio que a notificação dizia representar eram, por uma vez, exatamente a mesma coisa. O atacante nunca precisou suplantar o Meta. Ele só precisava conseguir que o Meta enviasse uma mensagem em seu nome, usando um campo de nomenclatura de conta sobre o qual o DMARC não tem nenhuma visibilidade nem autoridade.
O Que as Empresas Devem Fazer Agora
Verificar qualquer notificação de “parceiro”, “verificação” ou “agência” diretamente dentro do Meta Business Suite, nunca pelo link do próprio e-mail. Navegue até a plataforma por conta própria e revise as solicitações de parceria pendentes por lá.
Auditar quem pode enviar solicitações de parceria para sua empresa, e revisar esse acesso periodicamente. As configurações de parceiros e acessos do Business Manager controlam isso diretamente; permissões permanentes não revisadas são exatamente do que essa campanha dependia.
Nunca enviar uma foto de documento de identidade, passaporte ou um código MFA em resposta a um link dentro de um e-mail, não importa quão legítimo o endereço remetente pareça. A verificação de identidade legítima acontece dentro de uma sessão autenticada que você mesmo iniciou.
Mantenha a aplicação de DMARC no seu próprio domínio de qualquer forma. Isso não vai impedir que o sistema de notificações do seu provedor seja usado contra você, mas ainda fecha o caminho muito mais comum pelo qual um atacante falsifica seu nome diretamente, liberando a atenção da sua equipe para pontos cegos como este.
A Conclusão
Essa campanha nunca precisou vencer o DMARC, porque nunca teve que enfrentá-lo. A própria infraestrutura do Meta enviou uma mensagem que a própria infraestrutura do Meta tinha todo o direito de enviar, em nome de uma conta que a própria infraestrutura do Meta havia verificado como real. A única coisa falsa era a intenção por trás disso, um campo que o DMARC nunca foi criado para ler. A autenticação diz quem enviou uma mensagem. Ela nunca afirmou dizer por quê.
A Excello Mail mantém todos os domínios que você administra totalmente autenticados e aplicados, fechando a porta para a suplantação direta, para que a atenção da sua equipe vá para os pontos cegos que vivem uma camada mais profunda, nos recursos de plataforma e na lógica de negócio que o DMARC nunca foi criado para vigiar. Cadastre-se gratuitamente na Excello Mail para ver hoje mesmo a postura real de autenticação do seu domínio.