Campanha explorou o fluxo legítimo de autorização por dispositivo para obter tokens persistentes em mais de 340 organizações, usando redirecionamentos, páginas falsas e infraestrutura em serviços de nuvem.
| Componente | Identidades Microsoft 365 e fluxo OAuth de autorização por código de dispositivo no Microsoft Entra ID. |
| Vetor | E-mails de phishing conduzem a páginas que exibem um código de verificação e levam a vítima ao endpoint legítimo microsoft[.]com/devicelogin. |
| Impacto | Após a autenticação da vítima, o operador obtém tokens de acesso e atualização que podem manter acesso à conta mesmo depois de troca de senha. |
| Prioridade | Revisar logs de entrada em busca de autenticações associadas à infraestrutura Railway, revogar tokens de atualização de usuários afetados e restringir tentativas de autenticação dessa origem quando possível. |
| Alcance | Mais de 340 organizações observadas nos Estados Unidos, Canadá, Austrália, Nova Zelândia e Alemanha, com expansão posterior para outras regiões. |
| Artefatos | Redirecionamentos por Cloudflare Workers, Vercel, sites comprometidos, serviços legítimos de redirecionamento de fornecedores de segurança e infraestrutura Railway. |
Uma campanha ativa de phishing por código de dispositivo mirou identidades Microsoft 365 em mais de 340 organizações. A atividade foi observada inicialmente em 19 de fevereiro de 2026 e acelerou nos casos posteriores. O foco técnico não é a coleta direta de senha em uma página falsa tradicional, mas o abuso do fluxo OAuth de autorização por dispositivo, no qual a vítima insere um código em uma página legítima da Microsoft e conclui a autenticação com seus fatores normais.
O diferencial operacional está no uso combinado de iscas, automação de geração de código e múltiplos serviços intermediários. Foram observados temas como propostas de construção, páginas que geram o código na chegada da vítima, imitação de DocuSign, notificações de correio de voz e uso indevido de páginas Microsoft Forms. A cadeia também usou redirecionamentos por serviços legítimos de fornecedores de segurança, Cloudflare Workers, Vercel, sites comprometidos e infraestrutura hospedada em Railway, que concentrou parte relevante dos eventos registrados.
No fluxo de autorização por dispositivo, um cliente solicita um código ao provedor de identidade e o usuário autentica esse código em uma página legítima. Em um cenário normal, esse mecanismo facilita login em dispositivos com entrada limitada. Na campanha observada, o operador controla a etapa inicial de solicitação do código e apresenta esse valor à vítima em uma página de phishing. Quando a vítima acessa o endpoint legítimo microsoft[.]com/devicelogin, insere o código e conclui a autenticação, os tokens emitidos passam a beneficiar quem conhece o código usado na requisição original.
Esse modelo reduz sinais visíveis para o usuário porque a autenticação final ocorre em infraestrutura real da Microsoft. A vítima vê uma experiência de login legítima e pode concluir senha e segundo fator sem perceber que está autorizando uma sessão iniciada pelo operador. O risco aumenta porque os tokens de atualização podem permanecer válidos mesmo após redefinição de senha, exigindo revogação explícita de sessões e tokens para interromper o acesso já concedido.
A cadeia de entrega começa em e-mails de phishing com URLs encapsuladas em serviços de redirecionamento associados a fornecedores conhecidos, o que ajuda a atravessar filtros de correio e reputação. Depois disso, a navegação passa por uma sequência de intermediários, incluindo sites comprometidos, instâncias Cloudflare Workers e Vercel, até chegar à página final. Quase todos os sites de phishing por código de dispositivo observados foram hospedados em instâncias workers[.]dev, explorando a confiança operacional que muitas empresas concedem a esse serviço.
Nas páginas finais, o código é renderizado diretamente para a vítima e acompanhado de um botão de continuidade para a Microsoft. Esse detalhe remove uma etapa manual comum em campanhas anteriores, nas quais o operador precisava gerar e entregar o código por outro canal. A página também emprega controles anti-análise, como bloqueio de clique direito, seleção de texto, arraste, atalhos de ferramentas de desenvolvedor e visualização de código-fonte, além de heurística baseada em tamanho de janela para tentar detectar ferramentas abertas.
A superfície exposta inclui contas Microsoft 365 em organizações de construção, entidades sem fins lucrativos, mercado imobiliário, manufatura, serviços financeiros, saúde, jurídico e governo. A campanha foi inicialmente descrita com vítimas nos Estados Unidos, Canadá, Austrália, Nova Zelândia e Alemanha, mas análises posteriores associadas ao mesmo modelo de phishing como serviço indicaram alcance mais amplo, incluindo América do Norte, América Central, América do Sul, Europa, Oriente Médio, Ásia e Oceania.
O serviço de phishing como serviço EvilTokens foi associado a esse conjunto de técnicas. O kit oferece páginas de phishing para código de dispositivo Microsoft, painéis operados por Telegram, templates de páginas que imitam serviços confiáveis e recursos voltados a comprometimento de e-mail corporativo, como coleta de e-mails, reconhecimento, interface de webmail e automação apoiada por IA. O modelo permite que múltiplos operadores usem a mesma base técnica, o que dificulta atribuição única e amplia a quantidade de campanhas com comportamento semelhante.
- Contas Microsoft 365 capazes de concluir autenticação por código de dispositivo.
- Usuários expostos a iscas de documentos, assinatura eletrônica, voicemail, arquivos, reuniões, logística, finanças ou folha de pagamento.
- Ambientes que permitem tráfego para
workers[.]dev, Railway e cadeias de redirecionamento pouco inspecionadas. - Organizações que tratam redefinição de senha como contenção suficiente sem revogar tokens de atualização.
A investigação deve começar por logs de entrada e eventos de identidade relacionados ao fluxo de código de dispositivo. O ponto crítico é correlacionar autenticações concluídas em páginas legítimas da Microsoft com origens incomuns, endereços associados à infraestrutura Railway e acessos subsequentes a serviços Microsoft 365. Como o usuário autentica corretamente, a detecção não deve depender apenas de falha de senha ou desafio de MFA negado.
Também é necessário revisar eventos de e-mail e navegação. A cadeia observada pode conter mensagens com links que passam por serviços legítimos de redirecionamento, múltiplos saltos e landing pages hospedadas em Cloudflare Workers. Em endpoints e proxies, sinais úteis incluem sequência de acesso a uma página de isca, abertura de pop-up para microsoft[.]com/devicelogin, autenticação bem-sucedida e novo uso de sessão a partir de infraestrutura não usual para o usuário.
- Entradas Microsoft 365 com fluxo de autenticação por dispositivo e origem em infraestrutura Railway.
- Sessões novas após acesso a páginas
workers[.]devou redirecionamentos encadeados por Vercel e sites comprometidos. - Usuários com login bem-sucedido seguido de criação ou uso de tokens persistentes sem padrão normal de dispositivo.
- Mensagens com temas de DocuSign, voicemail, documentos, propostas de construção, arquivos financeiros, reuniões, logística ou folha de pagamento.
- Mudanças de atividade em caixas de e-mail que indiquem reconhecimento, coleta de mensagens ou preparação para fraude por e-mail corporativo.
A contenção deve tratar a emissão de tokens como o evento principal. Para contas suspeitas, a redefinição de senha isolada não encerra necessariamente a exposição, porque o token de atualização pode continuar válido. A resposta precisa incluir revogação de todos os tokens de atualização, invalidação de sessões ativas, revisão de métodos de autenticação, inspeção de regras de caixa de entrada e análise de atividades recentes em Exchange Online, SharePoint, OneDrive e aplicações conectadas.
Controles preventivos devem reduzir a utilidade do fluxo de dispositivo quando ele não for necessário, aplicar políticas de acesso condicional e restringir autenticações de origens de alto risco. Onde o negócio permitir, tentativas vindas de infraestrutura Railway devem ser bloqueadas ou submetidas a validação adicional. A filtragem de web e e-mail também precisa considerar abuso de redirecionadores legítimos e landing pages em serviços de nuvem populares, porque a reputação do domínio intermediário pode não refletir o risco da sessão completa.
- Revogar tokens de atualização e encerrar sessões de usuários com sinais de comprometimento.
- Revisar logs de entrada para autenticações por código de dispositivo associadas a origens incomuns.
- Bloquear ou desafiar autenticações originadas de infraestrutura Railway quando compatível com a operação.
- Avaliar a necessidade real do fluxo OAuth de autorização por dispositivo e restringi-lo quando possível.
- Procurar regras de encaminhamento, alterações de caixa postal, acessos a webmail e atividade anômala após o login suspeito.
- Ajustar detecções para cadeias com Cloudflare Workers, Vercel, redirecionadores legítimos e temas de isca recorrentes.
0 Comentários