Desarticulação do EvilTokens pela Microsoft Expõe um Pipeline de Fraude Guiado por IA
A Microsoft desarticulou o EvilTokens após o serviço comprometer mais de 12.000 caixas de e-mail em mais de 10.000 organizações no mundo. A operação da Microsoft contra o EvilTokens teve como alvo uma infraestrutura que sustentava um sistema empacotado de phishing, acesso a contas, análise de caixas de correio e fraude financeira.
A operação é relevante porque o EvilTokens fez mais do que ajudar criminosos a redigir mensagens persuasivas. Seu assistente de IA examinava caixas de entrada roubadas, mapeava relações comerciais, identificava autoridade para pagamentos e recomendava pessoas a serem personificadas.
Essa capacidade condensou um trabalho que antes exigia paciência e conhecimento especializado. No entanto, desativar a infraestrutura não elimina a técnica subjacente. O phishing por código de dispositivo continua disponível, sessões roubadas podem sobreviver à redefinição de senhas e serviços relacionados podem copiar o modelo operacional.
A Desarticulação do EvilTokens pela Microsoft Atingiu uma Plataforma Completa de Fraude
A Microsoft e seus parceiros atacaram a infraestrutura que conectava o phishing inicial à fraude financeira direcionada.
A Microsoft anunciou a ação coordenada em 22 de setembro de 2026. Sua Digital Crimes Unit obteve autorização judicial para apreender infraestrutura ativa e redirecionar domínios associados ao serviço.
A ação envolveu a Health-ISAC, empresas de tecnologia, investigadores financeiros, pesquisadores de segurança e autoridades policiais. A Cloudflare desativou separadamente projetos e contas do Workers que apoiavam campanhas do EvilTokens.
Segundo os registros judiciais, a Microsoft e a Health-ISAC apresentaram o caso no Distrito Leste da Virgínia. Os réus nomeados são Felix Utomi, Waidi Segun Adams e várias pessoas não identificadas.
A Microsoft atribuiu o desenvolvimento e o suporte do EvilTokens a um agente de ameaça que rastreia como Storm-2992. A atribuição, nesse contexto, representa a avaliação da Microsoft, e não uma condenação criminal.
A operação teria apreendido 50 sites e desativado mais de 150 domínios adicionais. A polícia britânica também prendeu dois homens em conexão com o EvilTokens, segundo reportagem independente.
Os homens foram libertados sob fiança condicional enquanto a investigação prosseguia. Suas prisões não devem ser tratadas como constatações de culpa.
A Cloudflare afirmou que a operação coordenada contra a infraestrutura começou em 15 de setembro. A empresa identificou centenas de contas de clientes ligadas à atividade do EvilTokens e desativou os projetos de suporte.
Essa abordagem jurídica e técnica combinada era necessária porque o EvilTokens dependia de serviços operados por provedores não relacionados. Sua infraestrutura atravessava plataformas de hospedagem, registradores de domínio, serviços de comunicação, sistemas de pagamento e redes de nuvem.
O EvilTokens surgiu no início de 2026 e rapidamente ganhou adoção entre invasores motivados financeiramente. A Microsoft o associou a mais de 12.000 caixas de entrada comprometidas em mais de 10.000 organizações em poucos meses.
As maiores concentrações de atividade observada entre vítimas apareceram nos Estados Unidos, Canadá, Reino Unido, Austrália, Índia e França. Os setores afetados incluíam construção, finanças, saúde, mercado imobiliário, distribuição atacadista e ensino superior.
Esses números descrevem a atividade observada, não um censo completo. Algumas contas comprometidas podem continuar não descobertas, enquanto uma única organização pode conter várias caixas de entrada afetadas.
O foco corporativo foi incomumente acentuado. Dados da SpyCloud citados por repórteres de segurança classificaram cerca de 97,5% das contas identificadas como pertencentes a domínios empresariais.
O EvilTokens também gerou receitas substanciais. A Coinbase teria rastreado cerca de US$ 1,1 milhão em receita até a operação enquanto auxiliava a investigação.
Esses números explicam a escala, mas não capturam a mudança central. O EvilTokens conectou várias tarefas criminosas antes separadas por meio de uma única interface gerenciada.
Assinantes recebiam ferramentas de campanha, modelos de phishing, gerenciamento de tokens, acompanhamento de vítimas, buscas em caixas de correio e orientação pós-comprometimento. Canais de suporte e painéis administrativos faziam a operação se assemelhar a um serviço comercial de software.
A distinção importa para os defensores. Remover um domínio malicioso pode interromper uma campanha, mas não desmonta um modelo de serviço transferível.
A Microsoft descreveu a ação como uma desarticulação, e não como prova de que todos os operadores, assinantes e sistemas relacionados haviam desaparecido. Portanto, as equipes de segurança devem esperar redução de atividade, não eliminação permanente.
Como o EvilTokens Transformou um Login Legítimo em Acesso à Conta
O EvilTokens explorou a confiança do usuário na página real de autenticação da Microsoft, em vez de depender apenas de um formulário de login falsificado.
A plataforma era centrada no phishing por código de dispositivo. Essa técnica abusa de um fluxo de autenticação OAuth destinado a dispositivos sem teclados convenientes ou navegadores completos.
Smart TVs, impressoras, equipamentos de conferência e alguns dispositivos Teams podem usar esse processo. Um dispositivo exibe um código curto, enquanto o usuário conclui a autenticação em outra tela.
Em um fluxo malicioso, o invasor inicia a solicitação e envia seu código ao alvo. Uma mensagem enganosa convence essa pessoa a inserir o código pela página legítima de login de dispositivo da Microsoft.
A vítima pode ver um domínio Microsoft válido e concluir a autenticação multifator normal. No entanto, essa aprovação autoriza a sessão em espera do invasor, e não a atividade que a vítima esperava.
Nenhuma senha precisa passar por um site falsificado. Essa característica enfraquece as orientações conhecidas centradas em verificar um domínio ou recusar-se a inserir credenciais em páginas suspeitas.
O painel do EvilTokens ajudava assinantes a empacotar esse processo em iscas realistas. A Microsoft identificou 44 temas envolvendo faturas, arquivos compartilhados, solicitações de assinatura, avisos de senha, benefícios, propostas e parcerias comerciais.
As campanhas usavam links, documentos PDF, anexos HTML, redirecionamentos e páginas de verificação imitadas. O serviço também utilizava plataformas legítimas de nuvem e sites comprometidos para tornar a infraestrutura mais difícil de classificar.
Quando uma vítima aprovava o código, o EvilTokens capturava um token de autenticação. Um token é um artefato digital que permite a uma sessão autorizada acessar serviços específicos sem repetir a senha.
Tokens roubados podiam fornecer acesso ao e-mail e a recursos relacionados do Microsoft 365. Os operadores também podiam renovar tokens, inspecionar privilégios administrativos e receber alertas por palavra-chave em caixas de correio via Telegram.
A Microsoft observou casos em que invasores criaram regras maliciosas de caixa de entrada para ocultar mensagens. Em alguns incidentes, eles registraram dispositivos para estabelecer acesso mais duradouro pouco depois do comprometimento inicial.
Essa persistência muda a resposta a incidentes. Redefinir uma senha não encerra necessariamente uma sessão já autorizada nem remove um dispositivo registrado.
Os defensores devem revogar sessões e renovar tokens, inspecionar registros de autenticação, remover dispositivos não autorizados e examinar regras de caixa de correio. Caso contrário, o invasor poderá manter o acesso após a alteração da credencial visível.
A análise técnica recomenda bloquear a autenticação por código de dispositivo quando uma organização não precisa dela. Exceções necessárias devem ser limitadas a contas específicas e dispositivos aprovados.
As organizações também precisam monitorar solicitações inesperadas de código de dispositivo e logins arriscados. Os usuários devem rejeitar códigos associados a processos de autenticação que não iniciaram pessoalmente.
A autenticação resistente a phishing, incluindo passkeys e chaves de segurança FIDO2, pode reforçar a proteção. Ainda assim, uma autenticação mais forte não pode corrigir todos os caminhos de engenharia social quando usuários são induzidos a aprovar uma solicitação válida.
Essa limitação é a troca de segurança mais profunda. A autenticação por código de dispositivo atende hardware com interfaces limitadas, mas seu processo de aprovação separado enfraquece a ligação entre a intenção do usuário e a sessão solicitante.
Os invasores não quebraram a criptografia da Microsoft nem calcularam a senha de uma vítima. Eles manipularam um mecanismo legítimo de autorização até que a vítima concedesse acesso.
A lição vai além de uma plataforma. Qualquer fluxo de segurança que separa uma solicitação de sua aprovação precisa de contexto claro e controles rigorosos de política.
Os usuários precisam entender o que estão autorizando, qual aplicativo solicitou acesso e onde a sessão resultante irá operar. Prompts genéricos de aprovação criam espaço para engano.
O EvilTokens tornou esse engano repetível. Sua contribuição não foi inventar o phishing por código de dispositivo, mas empacotá-lo para uso mais amplo e rápido.
A IA Passou de Escrever Iscas a Escolher Alvos de Fraude
A capacidade definidora do EvilTokens surgiu após o comprometimento da conta, quando a IA transformava uma caixa de entrada desconhecida em um plano prático de fraude.
A IA generativa é frequentemente associada a e-mails de phishing bem redigidos. O EvilTokens a aplicou a um problema mais valioso: entender a organização de uma vítima após obter acesso.
Uma caixa de correio comprometida pode conter anos de conversas, anexos, faturas, aprovações, nomes e relações hierárquicas. Essas informações são valiosas, mas revisá-las manualmente exige tempo e discernimento.
O EvilTokens automatizou grande parte desse trabalho. Suas ferramentas podiam resumir e traduzir mensagens, identificar discussões financeiras, mapear funções organizacionais e revelar relações externas confiáveis.
Buscas predefinidas teriam localizado conversas sobre transferências bancárias, faturas, responsabilidades de pagamento e funcionários que poderiam autorizar transações. A Microsoft afirmou que o assistente também podia recomendar quem um invasor deveria personificar.
A plataforma então ajudava a gerar mensagens que correspondiam ao contexto roubado. Uma solicitação fraudulenta poderia fazer referência a um projeto, fornecedor, gestor, fatura ou conversa em andamento reais.
Esse processo sustenta o comprometimento de e-mail corporativo, ou BEC. Em um ataque BEC, criminosos personificam participantes confiáveis para redirecionar pagamentos ou induzir outras ações financeiramente valiosas.
O BEC tradicional frequentemente depende de operadores experientes. Eles precisam estudar padrões de comunicação, reconhecer autoridade, esperar por uma transação útil e elaborar uma intervenção plausível.
O EvilTokens reduziu essa carga investigativa. Segundo reportagens sobre a operação, tarefas que poderiam consumir vários dias poderiam ser condensadas em horas.
Essa compressão importa mais do que uma melhoria marginal de gramática. Um e-mail de phishing genérico e bem escrito ainda precisa alcançar a pessoa certa no momento certo.
A análise da caixa de correio fornece ao invasor timing, contexto e conhecimento organizacional. A IA pode transformar esses detalhes dispersos em uma lista classificada de oportunidades promissoras.
A tecnologia também ajudava assinantes menos experientes. Um novo operador não precisava de conhecimento profundo em sistemas de identidade, engenharia social, reconhecimento por e-mail e fraude de pagamentos.
O EvilTokens combinava essas especialidades em um fluxo de trabalho guiado. Seu chatbot agia menos como um assistente de redação e mais como um analista que aconselhava o próximo passo do invasor.
A Microsoft também encontrou evidências de que grandes partes da própria plataforma foram construídas com programação assistida por IA. Essa conclusão sugere que a IA reduziu barreiras tanto para os desenvolvedores da plataforma quanto para os clientes.
A descoberta não significa que a IA tenha criado ou operado autonomamente o serviço. Humanos ainda construíram o negócio, selecionaram alvos, gerenciaram a infraestrutura e agiram com base nas recomendações do sistema.
Também não estabelece que um modelo comercial específico tenha fornecido todas as capacidades de IA. A Microsoft afirmou que os investigadores observaram o uso de vários modelos de IA.
As evidências públicas, portanto, sustentam uma conclusão mais restrita. Ferramentas de IA existentes ajudaram criminosos a desenvolver software e interpretar informações roubadas com mais eficiência.
Isso representa uma mudança significativa na economia do crime. A triagem mais rápida de caixas de correio permite que um operador examine mais vítimas sem expandir proporcionalmente sua equipe ou especialização.
A escala também melhora a seleção. Atacantes podem abandonar oportunidades fracas mais cedo e concentrar-se em contas ligadas ao controle de pagamentos, fornecedores confiáveis ou executivos seniores.
A operação contra EvilTokens da Microsoft teve como alvo essa camada de conversão entre acesso não autorizado e monetização. Essa camada explica por que o serviço atraiu atenção além da infraestrutura comum de phishing.
Uma caixa de entrada roubada já é prejudicial por si só. Um sistema que explica rapidamente como explorar essa caixa de entrada pode aumentar tanto a velocidade quanto o valor esperado da invasão.
Esse modelo pressionará equipes de identidade, provedores de segurança de email e empresas de IA. Cada um controla apenas uma parte de uma cadeia de ataque que atravessa diversos serviços independentes.
Provedores de IA podem suspender contas abusivas, mas os atacantes podem trocar de modelo. Plataformas de hospedagem podem remover infraestrutura, mas os operadores podem migrar entre provedores.
Fornecedores de identidade podem bloquear sessões suspeitas, mas recursos legítimos de autenticação ainda precisam atender dispositivos reais. Os defensores precisam coordenar-se através dessas fronteiras mais rapidamente do que os criminosos conseguem reconstruir.
Por que a desativação do EvilTokens não encerra o phishing por código de dispositivo
A operação removeu infraestrutura importante, mas a fraqueza subjacente de autenticação e a demanda criminosa permanecem intactas.
Relatórios de segurança já identificaram o APToken como um serviço relacionado ou derivado. Seu surgimento ilustra como afiliados podem reproduzir um design bem-sucedido de phishing como serviço.
A relação exata entre esses clones e o Storm-2992 permanece incerta. Recursos semelhantes não comprovam propriedade comum ou infraestrutura compartilhada.
Ainda assim, o risco de cópia é claro. O EvilTokens demonstrou demanda por um produto integrado que reúne roubo de tokens, análise de caixas de correio e preparação para fraude.
Seus operadores também disseminaram conhecimento por meio de suporte ao cliente, tutoriais, interfaces e relações com parceiros. Desativar servidores não pode apagar habilidades já adquiridas pelos assinantes.
É por isso que a palavra “desarticulação” é importante. A Microsoft e seus parceiros prejudicaram as operações atuais, coletaram inteligência, elevaram os custos operacionais e apoiaram investigações contínuas.
Essas conquistas podem reduzir o volume imediato de ataques. Elas não garantem que todos os clientes perderam o acesso, que todos os tokens roubados foram revogados ou que todas as vítimas foram notificadas.
O processo judicial pode revelar mais sobre a organização e a rede financeira da plataforma. As investigações das autoridades também podem resultar em prisões, acusações ou apreensões adicionais.
Até lá, várias alegações centrais dependem principalmente da telemetria da Microsoft e das empresas participantes. Seu acesso lhes proporciona visibilidade valiosa, mas nenhum provedor enxerga todo o mercado criminoso.
Os totais de vítimas também podem mudar à medida que parceiros correlacionam registros. As 12.000 caixas de entrada relatadas representam um mínimo documentado vinculado às observações atuais.
Medir a perda financeira direta apresenta um problema ainda mais difícil. Nem toda caixa de entrada comprometida resultou em fraude de pagamento bem-sucedida, enquanto algumas organizações podem evitar divulgação pública.
O papel da IA também exige precisão. O EvilTokens usou IA para desenvolvimento de software, criação de iscas, tradução, análise de caixas de correio e recomendações de alvos.
No entanto, os relatos públicos não quantificam com que frequência esses recursos produziram fraudes bem-sucedidas. Tampouco comparam as taxas de sucesso com campanhas sem apoio de IA.
As evidências mostram integração operacional, não um teste controlado de eficácia. Alegações de que a IA, por si só, causou a escala da plataforma iriam, portanto, além dos dados disponíveis.
O EvilTokens se beneficiou de várias capacidades que não envolviam IA. Entre elas estavam persistência de tokens, infraestrutura automatizada, modelos reutilizáveis, redirecionamentos evasivos e acesso a serviços legítimos de nuvem.
Sua popularidade provavelmente refletiu esse pacote completo. A IA tornou partes do fluxo de trabalho mais rápidas, mas o serviço ao redor converteu essas capacidades em operações repetíveis.
Os defensores devem evitar responder apenas com outro produto de IA. Os controles imediatos continuam sendo política de identidade, visibilidade de sessões, verificação de usuários, inteligência de infraestrutura e resposta coordenada a incidentes.
Organizações que não exigem autenticação por código de dispositivo podem desativá-la. Aquelas que precisam do recurso podem limitá-lo por meio do Acesso Condicional e de contas dedicadas a recursos.
As equipes de segurança também devem procurar registros inesperados de dispositivos, atividade de renovação de tokens, alterações em regras de caixa de entrada, acesso incomum ao Graph e aprovações de aplicativos desconhecidos.
A orientação da Microsoft sobre código de dispositivo fornece um caminho de política para restringir o fluxo de autenticação. A implementação ainda exige testes com equipamentos legítimos e processos de negócios.
As defesas de email devem considerar mensagens que levam usuários a domínios autênticos. Um destino confiável não pode compensar uma solicitação fraudulenta ou um contexto enganoso.
O treinamento deve, portanto, enfatizar a iniciação e a intenção. Os usuários só devem inserir um código de dispositivo quando tiverem iniciado o login correspondente em um dispositivo conhecido.
As organizações também precisam de procedimentos rápidos para suspeitas de roubo de tokens. As equipes de suporte devem saber que uma simples redefinição de senha pode deixar a sessão hostil ativa.
A documentação é importante durante esses incidentes porque as equipes de identidade, email, jurídico, finanças e executivos frequentemente precisam das mesmas evidências. Uma base de conhecimento técnico pesquisável pode preservar decisões, indicadores e responsabilidades de remediação.
Essa disciplina operacional ajuda a fechar a lacuna explorada pelo EvilTokens. Criminosos usaram automação para coordenar seu lado, enquanto muitos defensores ainda dividem evidências entre sistemas desconectados.
O que vem depois da operação contra EvilTokens da Microsoft
Três sinais mostrarão se essa operação produziu pressão duradoura ou apenas uma queda temporária nas campanhas.
O primeiro sinal é a atividade mensurável do EvilTokens após a ação contra a infraestrutura. Provedores de segurança devem observar a redução do phishing por código de dispositivo, mudanças de domínios e migração para outros serviços de nuvem.
Uma queda sustentada indicaria que as apreensões de domínios e a coordenação entre provedores prejudicaram mais do que uma camada descartável da campanha. Um retorno rápido sugeriria que os operadores mantiveram clientes, ferramentas e infraestrutura alternativa.
A avaliação de ameaças da Cloudflare oferece indicadores úteis e descreve a operação coordenada. Atualizações futuras dos provedores participantes podem mostrar se a infraestrutura relacionada reaparece.
O segundo sinal é a adoção por clones e concorrentes. APToken e serviços semelhantes merecem atenção porque podem preservar o modelo comercial sem reutilizar a marca EvilTokens.
Pesquisadores devem comparar seus métodos de autenticação, funções de análise de caixas de correio, redes de suporte e infraestrutura. Código ou operadores compartilhados fortaleceriam o argumento de continuidade.
Serviços independentes que adotem o mesmo design indicariam uma mudança mais ampla no mercado. Isso mostraria que a análise pós-comprometimento orientada por IA se tornou um recurso padrão de produtos criminosos.
O terceiro sinal é o resultado jurídico e investigativo. O processo civil da Microsoft identifica supostos operadores, enquanto as autoridades britânicas continuam sua investigação separada.
Novas peças judiciais podem esclarecer propriedade, fluxos de receita, relações com clientes e controle de infraestrutura. Acusações criminais ou apreensões financeiras aumentariam a pressão sobre operadores e compradores do serviço.
Um resultado fraco de aplicação da lei não invalidaria a desarticulação técnica. No entanto, poderia limitar o efeito dissuasório se operadores substitutos acreditarem que o risco jurídico continua administrável.
Os defensores também devem acompanhar a resposta de produto da Microsoft. O EvilTokens abusou de um fluxo de trabalho legítimo, e não de uma vulnerabilidade de software com uma correção simples.
A Microsoft pode melhorar avisos, detecção, controles de tokens e visibilidade para administradores. Ainda assim, precisa preservar a autenticação por código de dispositivo para equipamentos compatíveis e cenários acessíveis de login.
Esse equilíbrio torna os padrões de política especialmente importantes. Configurações seguras por padrão podem reduzir a exposição sem exigir que cada organização compreenda uma técnica especializada de abuso de OAuth.
Provedores de nuvem e identidade enfrentam uma questão mais ampla de design. As telas de aprovação precisam comunicar qual dispositivo, aplicativo e sessão receberão acesso.
Os usuários também precisam de um aviso claro quando o contexto solicitante for diferente do dispositivo atual. Um contexto melhor pode tornar uma página de login legítima menos útil como prova social para atacantes.
As empresas de IA têm outro papel. A detecção de abuso pode identificar contas que analisam repetidamente correspondência roubada, geram mensagens de personificação ou automatizam fluxos de trabalho criminosos conhecidos.
Esses controles não impedirão modelos operados fora das principais plataformas. Ainda assim, podem elevar custos e contribuir com evidências quando criminosos dependem de serviços comerciais.
A disputa mais ampla é entre automação criminosa empacotada e defesa coordenada. O EvilTokens teve êxito porque reuniu abuso de identidade, infraestrutura de nuvem, análise por IA e experiência em fraude.
A resposta usou um modelo igualmente conectado. A Microsoft combinou autoridade judicial, inteligência de ameaças, aplicação de regras da plataforma, rastreamento financeiro e cooperação com as autoridades.
Essa simetria é a lição central da operação contra EvilTokens da Microsoft. Nenhum produto de segurança isolado pode lidar com uma cadeia de ataque construída em vários sistemas legítimos.
As organizações devem começar confirmando se a autenticação por código de dispositivo é necessária e, em seguida, revisar políticas, procedimentos de revogação de sessões e cobertura de monitoramento. Também devem testar a rapidez com que as equipes financeiras conseguem validar solicitações de pagamento incomuns.
O próximo serviço malicioso pode usar outro nome, modelo ou provedor de hospedagem. A questão importante é se os defensores conseguem reconhecer o fluxo de trabalho antes que uma comunicação roubada se transforme em um plano de fraude convincente.
