EvilTokens: IA transforma phishing em fraude no M365

A disrupção da plataforma associada ao Storm 2992 expõe uma cadeia que conecta autenticação legítima, persistência por tokens, análise de caixas postais e redirecionamento financeiro.

Resumo técnico

O EvilTokens transformou o fluxo legítimo de código de dispositivo do OAuth em uma capacidade comercial para comprometimento de contas Microsoft 365. A vítima acessava o portal oficial da Microsoft, concluía a autenticação e, quando exigido, aprovava o MFA, mas o token resultante era entregue à sessão iniciada pelo atacante. A plataforma complementava o acesso com reconhecimento no Microsoft Graph, registro de dispositivos, criação de regras de caixa postal e análise de mensagens por inteligência artificial para identificar oportunidades de fraude.

A Microsoft associa o desenvolvimento e o suporte do EvilTokens ao Storm 2992. Desde fevereiro de 2026, a operação comprometeu mais de 12.000 caixas de entrada em mais de 10.000 organizações, antes de uma ação coordenada atingir sua infraestrutura. Os detalhes estão na análise técnica da Microsoft e no relato da operação de disrupção.

O que aconteceu

O EvilTokens foi apresentado em fevereiro de 2026 como uma plataforma de phishing como serviço distribuída por bots e canais no Telegram. O serviço oferecia páginas de captura, geração dinâmica de códigos, administração de campanhas, acompanhamento de vítimas, acesso às caixas postais e recursos para transformar contas comprometidas em oportunidades de fraude por comprometimento de e mail corporativo, conhecida como BEC.

Em setembro de 2026, uma operação liderada pela Microsoft, com participação de autoridades e empresas de diferentes setores, interrompeu componentes relevantes da infraestrutura. A Microsoft informa a apreensão de 50 sites usados pela operação e a desativação de mais de 150 domínios adicionais. Dois homens foram presos no Reino Unido em 11 de setembro e liberados sob condições enquanto a investigação prossegue.

Fontes secundárias apresentam o total como 175 domínios. Como a relação completa não foi publicada em uma fonte primária consultada, a formulação mais segura é: 50 sites apreendidos e mais de 150 domínios adicionais desabilitados.

Quem foi afetado

A Microsoft identificou vítimas em distribuição, construção, serviços financeiros, mercado imobiliário, ensino superior e saúde. As maiores concentrações públicas ocorreram nos Estados Unidos, Canadá, Reino Unido, Austrália, Índia e França.

As campanhas exploraram propostas comerciais, documentos para assinatura, logística, folha de pagamento, convites, mensagens de voz, compras e compartilhamento de arquivos. O conjunto indica foco em profissionais que mantêm contato com fornecedores, parceiros e processos de pagamento, principalmente finanças, compras, recursos humanos, vendas, jurídico e direção executiva.

Não há confirmação pública robusta de concentração de vítimas no Brasil. Ainda assim, empresas brasileiras que utilizam Microsoft 365 estão expostas à mesma técnica quando mantêm o fluxo de código de dispositivo disponível, não correlacionam eventos de identidade com atividade de caixa postal ou concentram aprovações financeiras em conversas por e mail.

Como o ataque funcionava

Preparação da campanha

Os afiliados escolhiam o alvo e um tema compatível com sua atividade. A plataforma oferecia dezenas de modelos e recursos de inteligência artificial para adaptar linguagem, contexto e abordagem, reduzindo a repetição entre mensagens e dificultando filtros baseados somente em conteúdo.

Entrega

A campanha chegava por links ou arquivos em formatos como PDF, HTML, DOCX, XLSX e SVG. Os documentos direcionavam a vítima para páginas hospedadas em infraestrutura própria, domínios comprometidos ou serviços legítimos de nuvem, incluindo Cloudflare Workers, Vercel, Railway e AWS.

Código de dispositivo

Ao acessar a página, um script solicitava ao provedor de identidade um código válido e o apresentava à vítima. A pessoa era orientada a continuar em microsoft.com/devicelogin, inserir o código e concluir a autenticação. O domínio era legítimo, mas o código vinculava a autorização à sessão iniciada pelo atacante.

Captura de tokens

Após a aprovação, o backend recebia tokens OAuth de acesso e atualização. A senha não precisava ser capturada diretamente. O atacante passava a usar uma sessão autorizada pela própria vítima, reduzindo a eficácia de controles baseados somente em credencial e MFA convencional.

Persistência

A plataforma podia renovar tokens, registrar um novo dispositivo no Microsoft Entra ID e obter um Primary Refresh Token. A Microsoft observou registros de dispositivos em até dez minutos após o comprometimento, ampliando a persistência e o acesso silencioso a serviços integrados.

Reconhecimento

Com o Microsoft Graph, os operadores podiam consultar usuários, grupos, funções, contatos, calendários, mensagens, organograma, domínios e recursos de nuvem. Essa etapa transformava uma conta comprometida em um mapa de relações, processos e oportunidades de monetização.

Análise por IA

A Sekoia documentou um fluxo que processava até 5.000 mensagens em lotes de 250. Modelos de linguagem eram usados para identificar exposição financeira, resumir relações comerciais, atribuir uma pontuação de potencial BEC, redigir mensagens compatíveis com o contexto da vítima e traduzir conteúdo.

Ocultação e fraude

Regras de caixa postal podiam mover, excluir, encaminhar ou marcar mensagens como lidas, reduzindo a chance de que alertas e respostas fossem percebidos pelo usuário. A análise automatizada priorizava conversas sobre fornecedores, faturas, transferências e autorizações, permitindo alterar instruções de pagamento ou redirecionar criptomoedas dentro de uma relação comercial real.

O papel da IA

A inteligência artificial não criou a fragilidade no fluxo de autenticação e não substituiu a engenharia social. Seu papel foi industrializar tarefas que antes exigiam trabalho manual, como personalizar mensagens, selecionar conversas relevantes, identificar pessoas com autoridade financeira e produzir textos coerentes com o histórico da caixa postal.

O primeiro estágio analisava grandes volumes de mensagens para localizar sinais de exposição financeira. O segundo transformava esses sinais em cenários de fraude, com sugestões sobre identidade a ser imitada, conversa a ser explorada e mensagem a ser enviada. A tradução automática ampliava a capacidade dos operadores de trabalhar com vítimas em diferentes idiomas.

Essa automação reduz o tempo entre comprometimento e impacto. Para o SOC, isso significa que uma autenticação anômala não pode aguardar horas por triagem manual quando o atacante consegue mapear a caixa postal e preparar uma fraude em minutos.

TTPs observados

Acesso inicial

• T1566.002, Spearphishing Link: links e documentos levavam a páginas que geravam códigos de dispositivo. O sinal defensivo é a sequência entre mensagem recebida, clique e autenticação por código.

Execução pelo usuário

• T1204.001, Malicious Link e T1204.002, Malicious File: a vítima abria um link ou arquivo e concluía o fluxo. O sinal defensivo é a abertura de um documento seguida de acesso ao portal de código de dispositivo.

Acesso a credenciais

• T1528, Steal Application Access Token: captura de tokens OAuth de acesso e atualização. O sinal defensivo é a emissão por Device Code seguida de uso em contexto incompatível.

Conta válida

• T1078.004, Cloud Accounts: uso da identidade comprometida no Microsoft 365 e Entra ID. O sinal defensivo é uma sessão válida com dispositivo, cliente, rede ou localização incomum.

Persistência

T1098.005, Device Registration: registro de dispositivo para sustentar acesso e obter PRT. O sinal defensivo é um novo dispositivo logo após autenticação por código.

Descoberta

• T1087.004, Cloud Account: enumeração de usuários e contas pelo Microsoft Graph.
• T1069.003, Cloud Groups: mapeamento de grupos e permissões.
• T1526, Cloud Service Discovery: enumeração de assinaturas e recursos Azure.

Coleta

T1114.002, Remote Email Collection: leitura de mensagens, anexos, contatos e itens enviados.

T1119, Automated Collection: processamento automatizado de milhares de mensagens.

Evasão

T1564.008, Email Hiding Rules: regras para ocultar alertas, respostas e evidências.

Coleta contínua

T1114.003, Email Forwarding Rule: encaminhamento de mensagens para monitoramento contínuo.

Impacto financeiro

BEC e fraude financeira: alteração de beneficiário, conta bancária ou carteira digital dentro de uma conversa existente.

Perfil do Storm 2992

O Storm 2992 é um agrupamento temporário usado pela Microsoft para acompanhar os responsáveis pelo desenvolvimento e suporte do EvilTokens. A designação não significa que cada mensagem, domínio ou fraude tenha sido operada diretamente pelo mesmo indivíduo, pois a estrutura como serviço separava desenvolvedores, suporte, afiliados e responsáveis pela monetização.

• Motivação: financeira, com receita por assinatura e suporte à fraude BEC.
• Modelo operacional: venda e atendimento por Telegram, painel central, bots e produtos complementares.
• Clientes: afiliados com diferentes níveis técnicos e funções operacionais.
• Alvos prioritários: identidades Microsoft 365 com acesso a pagamentos, fornecedores, informações executivas e processos internos.
• Setores observados: distribuição, construção, serviços financeiros, imóveis, educação e saúde.
• Vetor preferido: phishing por link ou arquivo seguido de autorização por código de dispositivo.
• Ações posteriores: tokens, PRT, Microsoft Graph, coleta de e mail, regras ocultas e preparação de BEC.
• Infraestrutura: Cloudflare Workers, Railway, Vercel, AWS e domínios comprometidos ou controlados por afiliados.

Modelo comercial

A Sekoia documentou uma taxa de US$ 1.500 para acesso ao painel e uma licença de US$ 500 por mês para o kit e sua API. Produtos adicionais incluíam ferramentas para envio B2B, envio SMTP e navegação em múltiplas contas. A operação oferecia suporte contínuo, implantação de páginas e atualizações por Telegram.

Esses valores mostram que o EvilTokens não era apenas um kit técnico. A plataforma funcionava como uma operação comercial completa, criada para reduzir a barreira de entrada de afiliados e transformar capacidades complexas de identidade em um serviço consumível.

Plataformas relacionadas

EvilTokens

• Relação: plataforma associada ao Storm 2992.
• Recursos: código de dispositivo, captura de tokens, análise com IA, painel e webmail.
• Confiança: alta.

ARToken

• Relação: painel associado ao ecossistema EvilTokens.
• Recursos: mais de 80 endpoints de API e múltiplas camadas de evasão, conforme a análise da Cisco Talos.
• Confiança: alta para a relação técnica e baixa para a continuidade do mesmo operador.

Kali365

• Relação: concorrente no mesmo mercado.
• Recursos: captura de tokens Microsoft 365, geração de iscas e administração por Telegram.
• Confiança: alta como serviço distinto, conforme o alerta do FBI IC3.

APToken

• Relação: possível clone surgido após a disrupção.
• Recursos: funcionalidades semelhantes de phishing por código.
• Confiança: média para existência e baixa para atribuição ao Storm 2992.

GhostCode

• Relação: kit que utiliza o mesmo vetor de autenticação.
• Recursos: tokens, registro de dispositivos e persistência.
• Confiança: alta para a técnica e baixa para vínculo com o Storm 2992.

A disrupção da marca não elimina a técnica nem o mercado. Afiliados podem migrar para clones, concorrentes ou infraestrutura própria, mantendo o mesmo comportamento operacional com novos domínios e painéis.

Monitoramento criminal

O acompanhamento de fóruns e canais deve priorizar indicadores de continuidade, não somente o nome EvilTokens. Termos úteis incluem device code, capture link, Office 365 capture, PRT, B2B sender, SMTP sender, Graph recon, inbox AI, BEC score, APToken, ARToken, Kali365 e GhostCode.

Para cada anúncio ou conversa observada, o registro deve incluir:

1. Nome do serviço, usuário, bot e canal.
2. Data da primeira e da última observação.
3. Recursos anunciados e demonstrações apresentadas.
4. Preço inicial, mensalidade, licença e programa de indicação.
5. Métodos de pagamento e carteiras associadas.
6. Domínios, painéis, chaves de afiliado e padrões de API.
7. Promessas de suporte a Gmail, Okta ou outros provedores.
8. Relação técnica com infraestrutura ou código já conhecidos.
9. Nível de confiança e restrição TLP.

A pesquisa pública confirmou a operação comercial do EvilTokens no Telegram, mas não permite validar o conteúdo atual de grupos privados ou a identidade de eventuais sucessores. Similaridade de nome, painel ou tema não é suficiente para atribuição. A continuidade deve ser sustentada por reutilização de código, API, carteira, bot, infraestrutura, licença ou conta administrativa.

IOCs e oportunidades de caça

A infraestrutura do EvilTokens combinava domínios próprios, ativos comprometidos e provedores legítimos. Por isso, indicadores isolados têm vida útil curta e podem gerar falsos positivos. O maior valor defensivo está na correlação entre entrega, navegação, autenticação, token, dispositivo, Microsoft Graph e alterações de caixa postal.

Padrões relevantes

1. Requisições para /api/device/start seguidas de consultas a /api/device/status/.
2. Uso do cabeçalho HTTP X Antibot Token no fluxo das páginas.
3. Conteúdo cifrado com AES GCM e descriptografado no navegador.
4. Subdomínios workers.dev com referências a Adobe, DocuSign, OneDrive, SharePoint, voicemail, calendário ou quarentena.
5. Autenticação por Device Code imediatamente após clique em mensagem.
6. Registro de novo dispositivo ou emissão de PRT em seguida.
7. Enumeração de usuários, grupos e recursos pelo Microsoft Graph.
8. Criação de regra de caixa postal, coleta de mensagens ou envio anômalo.

Amostra pública de domínios associados

authdocspro[.]com
backdoor-hub[.]com
bumpgames[.]net
eventcalender-schedule[.]com
framebound[.]cloud
notificationsmanagersec[.]com
serenitygovsupplys[.]com
smstltle[.]net
topbuysella[.]com
youremplregroup[.]com

A lista completa dos sites e domínios desativados não foi encontrada em fonte primária pública. A busca interna deve usar DNS histórico, logs de proxy, gateway de e mail, Microsoft Entra ID, Microsoft 365 e fontes comerciais de inteligência para ampliar o inventário.

Detecções prioritárias

Prioridade 1: clique, Device Code e novo dispositivo

Correlacionar um clique externo, autenticação por Device Code e registro de novo dispositivo em até 30 minutos. A resposta deve conter a identidade e validar o evento com o usuário por canal confiável.

Prioridade 1: uso anômalo de token ou PRT

Quando Device Code for seguido de uso anômalo de token ou PRT, desabilitar temporariamente a conta, revogar sessões e investigar os recursos acessados.

Prioridade 1: regra de caixa postal

Quando Device Code for seguido de criação ou alteração de regra, remover a configuração, revisar mensagens ocultas e iniciar investigação de fraude BEC.

Prioridade 1: enumeração e coleta pelo Graph

Quando houver enumeração de usuários, funções, contatos, calendário ou grande volume de mensagens, interromper o token e delimitar o conteúdo acessado.

Prioridade 1: mudança financeira

Quando surgir mudança de beneficiário, conta bancária ou carteira após atividade suspeita, suspender o pagamento e validar a solicitação fora do e mail.

Prioridade 2: infraestrutura de nuvem

Acessos por IP de nuvem e páginas em workers.dev devem ser correlacionados com agente de usuário, cliente, dispositivo, URL específica e histórico da identidade. O provedor ou bloco de IP isolado não é evidência suficiente.

O que fazer agora

1. Mapear o uso legítimo de Device Code. Identificar contas, equipamentos e aplicações que realmente precisam desse fluxo.
2. Restringir o fluxo por Acesso Condicional. Bloquear para usuários comuns e limitar exceções às contas de recurso e aos dispositivos necessários.
3. Conter a identidade por completo. Desabilitar temporariamente a conta quando houver evidência forte, revogar sessões, invalidar tokens de atualização e remover dispositivos não reconhecidos.
4. Auditar a caixa postal. Revisar regras, encaminhamentos, itens excluídos, itens enviados, delegações, pesquisas e acessos por API.
5. Investigar o Microsoft Graph. Identificar enumeração de usuários, grupos, calendários, contatos, mensagens, aplicações e recursos Azure.
6. Verificar exposição financeira. Suspender mudanças recentes de beneficiário, conta bancária e carteira. Toda solicitação deve ser confirmada por um canal independente já conhecido.
7. Fortalecer autenticação. Priorizar FIDO2, passkeys e Windows Hello for Business para contas privilegiadas e funções de maior impacto.
8. Conectar sinais no SIEM. Correlacionar e mail, clique, Device Code, token, novo dispositivo, Graph, regra de caixa postal e alteração financeira.
9. Atualizar o playbook. Incluir revogação de tokens, desativação de dispositivos, investigação de PRT, auditoria do Graph e comunicação com finanças, jurídico e privacidade.
10. Compartilhar inteligência. Trocar IOCs e TTPs com CSIRTs, ISACs, fornecedores de identidade, hospedagem, registradores e equipes de fraude, sempre com contexto temporal e classificação TLP.

Por que importa para o Brasil

O EvilTokens não depende de uma vulnerabilidade regional. A técnica explora um recurso legítimo do Microsoft 365 e um processo de confiança presente em organizações de qualquer país. Empresas brasileiras com grande volume de comunicações externas, operações financeiras descentralizadas e dependência de MFA convencional apresentam a mesma exposição observada no exterior.

O impacto ultrapassa a conta comprometida. Uma identidade válida pode acessar arquivos, conversas, fornecedores e informações de pagamentos, além de enviar mensagens a parceiros com a reputação legítima da empresa. O incidente passa a envolver fraude, privacidade, continuidade, reputação e risco de terceiros.

A conclusão operacional é que identidade precisa ser tratada como perímetro do negócio. MFA continua essencial, mas deve ser combinado com controle de fluxos de autenticação, telemetria de sessão, validação de dispositivos, detecção comportamental e processos financeiros resistentes ao comprometimento do e mail.

Leia também

O caso Mirage2FA sequestra sessões do Microsoft 365 e expõe limites do MFA tradicional mostra outra rota para o mesmo risco operacional. Enquanto o EvilTokens explora o código de dispositivo para obter tokens OAuth, o Mirage2FA usa uma infraestrutura intermediária para capturar a sessão depois que a vítima conclui o MFA. Nos dois casos, a resposta precisa revogar sessões e tokens, não apenas trocar a senha.

A análise UNC6671 amplia extorsão por vishing; identidade é vetor crítico para serviços financeiros complementa o tema ao abordar novos dispositivos, regras de caixa postal, consentimentos OAuth, roubo de sessão e validação financeira fora do canal comprometido.

O artigo Verificação de identidade: o novo alvo da engenharia social amplia a discussão para os processos de recuperação e alteração de identidade. A recomendação comum é correlacionar novos dispositivos, mudanças de MFA, consentimentos e sessões anômalas, além de exigir validação independente em operações sensíveis.