Uma campanha de phishing documentada por pesquisadores de segurança em junho de 2026 chamou atenção não por quebrar a autenticação de e-mail, mas porque não precisa fazê-lo. O kit de phishing CodeStorm – uma plataforma de ataque de nível comercial com sobreposições técnicas ao grupo de atores de ameaça Storm-1167 – constrói sua cadeia de ataque sobre contas comprometidas do Microsoft 365. Os e-mails que envia não falsificam um domínio. Vêm de uma identidade M365 real e ativa. O SPF passa. O DKIM passa. O DMARC passa. Cada porta de autenticação é liberada, e o e-mail ainda é uma arma.
Esta é a classe de ataque que as organizações menos compreendem quando implantam o DMARC e acreditam que o trabalho está feito.
O Que o CodeStorm Faz
O kit CodeStorm opera em duas fases distintas. Na primeira, o kit coleta credenciais do Microsoft 365 por meio de uma página de phishing clássica de adversário no meio. A vítima vê o que parece uma familiar tela de login da Microsoft. Ela insere suas credenciais e completa qualquer desafio de autenticação multifator. O kit captura tanto as credenciais quanto o token de sessão emitido após a autenticação bem-sucedida.
Com uma conta M365 real sob controle do atacante, a segunda fase começa. O atacante usa essa conta comprometida como identidade remetente para campanhas de phishing subsequentes. Como a conta remetente é uma identidade genuína e ativa do Microsoft 365 hospedada na própria infraestrutura de e-mail da Microsoft, cada sinal de autenticação verificado por um servidor de e-mail receptor retorna limpo.
Os pesquisadores observaram a capacidade específica do kit para repetição de credenciais com reconhecimento de locatário: a infraestrutura sonda o locatário específico da Microsoft da vítima, repete as credenciais contra os sistemas de identidade ao vivo da Microsoft em tempo real e monitora sinais de sucesso incluindo códigos de erro de login do Entra. O objetivo não é apenas o roubo de credenciais, mas o acesso funcional à conta que possa sustentar uma operação de envio contínua.
Por Que o DMARC Não Pode Ver Isso
O DMARC responde a uma pergunta: o domínio no cabeçalho From está alinhado com o domínio que autenticou a mensagem via SPF ou DKIM?
Quando um atacante envia de uma conta M365 comprometida em empresa-vitima.com, a resposta é sim. O e-mail se origina dos servidores de e-mail da Microsoft. Os registros SPF da Microsoft autorizam esses servidores. A infraestrutura de assinatura DKIM da Microsoft assina a mensagem. O endereço From corresponde ao domínio autenticado. O DMARC avalia tudo isso e emite uma aprovação.
Não há configuração incorreta, falsificação ou falha de alinhamento. A autenticação está correta porque a conta subjacente é real. O DMARC foi projetado para evitar que partes não autenticadas afirmem falsamente seu domínio. Ele não tem mecanismo para detectar que a parte autenticada enviando de seu domínio foi assumida por outra pessoa.
Isso não é um defeito no design do DMARC. É o limite do que a autenticação em nível de domínio é estruturalmente capaz de determinar.
A Isca de Correio de Voz e a Pilha de Evasão
O kit CodeStorm entrega sua carga útil de phishing por meio de uma isca de notificação de correio de voz: um e-mail formatado que imita uma comunicação genuína da Microsoft, incluindo uma duração de chamada, um ID de referência e um botão para abrir um portal de correio de voz. O design visual é indistinguível de uma notificação empresarial legítima.
Abaixo do conteúdo visível, o kit adiciona um longo bloco de conteúdo fictício de encadeamento histórico de e-mail – uma técnica chamada preenchimento de conversa. Os scanners automáticos de conteúdo que classificam mensagens com base no contexto do encadeamento veem o que parece ser uma conversa de negócios em andamento, o que reduz a probabilidade de uma classificação de spam ou phishing.
Quando o destinatário clica para recuperar o correio de voz, encontra uma página de destino protegida por um desafio do Cloudflare Turnstile que bloqueia ferramentas de análise automatizada. A página verifica ativamente as ferramentas de desenvolvimento do navegador e sinais de automação, e encerra a sessão se os detectar. A página que um humano vê e a página que um scanner vê são ambientes diferentes.
O manipulador de envio de credenciais não armazena as credenciais passivamente. Ele as repete contra a infraestrutura de autenticação da Microsoft em tempo real, produzindo eventos de login genuínos no registro de auditoria do Entra da vítima. Da perspectiva dos sistemas da Microsoft, um usuário legítimo se autenticou de um local desconhecido.
O Que o Phishing por Sequestro de Contas Significa para a Entregabilidade e a Confiança
As implicações vão além da segurança. O CodeStorm e campanhas semelhantes baseadas em sequestro de contas degradam a reputação de domínios de envio legítimos.
Quando uma conta M365 comprometida envia phishing em escala, os provedores de destinatários observam uma mudança repentina no padrão de envio desse domínio: destinatários diferentes, volumes incomuns, conteúdo que gera reclamações de spam. Esses sinais alimentam os sistemas de reputação do remetente. Um domínio que foi usado como veículo de phishing – mesmo por meio de uma conta comprometida em vez de falsificada – pode ver sua entregabilidade aos principais provedores prejudicada mesmo depois que a conta é recuperada e a ameaça removida.
Organizações que não monitoram seu comportamento de e-mail de saída não têm como saber se uma conta comprometida começou a enviar de seu domínio até que os provedores de destinatários comecem a adiar ou rejeitar seu e-mail legítimo. A essa altura, o dano à reputação já está se acumulando.
Os Sinais Que Podem Detectar Isso
Como o DMARC não consegue distinguir o envio legítimo do envio por sequestro de conta, outras classes de sinais precisam fazer esse trabalho.
Anomalias de login no Entra. Quando o CodeStorm repete as credenciais contra o locatário de uma vítima, ele gera eventos de auditoria do Entra. Geografias de login incomuns, horários de login que não correspondem aos padrões do titular da conta e impressões digitais de dispositivos que diferem dos dispositivos registrados são todos visíveis nos logs do Entra. Organizações que monitoram esses sinais podem detectar comprometimento da conta antes que a fase de envio comece.
Linhas de base de comportamento de envio. Aumentos repentinos no volume de saída de uma conta específica, envios para destinatários fora do gráfico de contatos normal da organização e picos nas taxas de rejeição ou reclamações de spam são sinais comportamentais que ficam acima da camada de autenticação. Os relatórios agregados do DMARC mostram quais fontes estão enviando em nome do seu domínio. Uma fonte que não estava lá na semana passada – ou uma fonte existente que mudou drasticamente seu comportamento – é um sinal que vale a pena investigar.
Relatórios forenses do DMARC. Enquanto os relatórios agregados RUA mostram o volume de envio e as taxas de aprovação/falha por fonte, os relatórios forenses RUF podem incluir amostras de mensagens de eventos com falha. Mesmo quando uma campanha de sequestro de conta passa na autenticação, o aparecimento repentino de envios de infraestrutura em nuvem que não está no conjunto esperado de fontes aparece nos dados do relatório agregado.
Regras de caixa de entrada pós-comprometimento. Após obter acesso à conta, os atacantes frequentemente criam regras de caixa de entrada para encaminhar e-mails recebidos ou suprimir notificações de entrega. Essas regras são visíveis nos logs de auditoria do M365 e servem como indicador secundário de comprometimento da conta.
A Base do DMARC Ainda Importa
Nada disso é um argumento contra a aplicação do DMARC. É um argumento para entender o que a aplicação do DMARC oferece.
Um domínio em p=reject impede atacantes externos – aqueles sem acesso à sua infraestrutura ou uma conta comprometida – de enviar e-mail que afirme ser do seu domínio. Essa proteção elimina a maioria dos ataques de falsificação de domínio. O Relatório de Adoção de DMARC 2026 da EasyDMARC descobriu que 52,1% dos 1,8 milhão de principais domínios agora têm um registro DMARC, acima dos 47,7% do ano anterior. Mas mais da metade desses registros permanecem em p=none, a política somente de monitoramento que não para nada. Chegar ao p=reject ainda é o primeiro passo mais impactante que a maioria das organizações pode dar.
O que o CodeStorm demonstra é que o p=reject é um piso, não um teto. Uma organização com DMARC em nível de aplicação elimina a falsificação de partes externas. Não elimina o risco de que uma conta interna seja comprometida e weaponizada. Ambas as proteções são necessárias. Nenhuma substitui a outra.
Organizações que equiparam “temos DMARC” com “nosso e-mail está seguro” estão se preparando para uma surpresa específica: phishing autenticado do seu próprio domínio, que passa em cada verificação e não enfrenta nenhum atrito de entrega.
O Que Fazer Agora
Se seu domínio envia e-mail, há três coisas que vale verificar esta semana.
Primeiro, verifique se sua política DMARC está em p=quarantine ou p=reject. Se você ainda está em p=none, qualquer ator externo que queira falsificar seu domínio pode fazê-lo livremente.
Segundo, revise seus relatórios agregados do DMARC em busca de fontes de envio inesperadas. Qualquer intervalo de IP ou serviço de e-mail que não esteja em sua infraestrutura de envio conhecida enviando em seu nome é um problema – seja indicando um serviço mal configurado que você esqueceu de autorizar ou um atacante usando acesso comprometido.
Terceiro, estabeleça uma linha de base para o comportamento de envio de saída de suas contas M365. Saiba como é o volume normal, os destinatários normais e a geografia normal para cada conta. Quando o CodeStorm ou um kit similar assume uma conta, o desvio comportamental dessa linha de base é o sinal que você tem.
O Excello Mail oferece visibilidade contínua dos relatórios DMARC do seu domínio, fontes de envio e configuração de autenticação em todos os seus fluxos de e-mail. Cadastre-se gratuitamente no Excello Mail e saiba exatamente o que está enviando do seu domínio – antes que uma conta comprometida te avise primeiro.