Phishing de código de dispositivo: por que esse golpe contra Microsoft 365 preocupa tanto em 2026

O phishing clássico não desapareceu. Ele amadureceu. Em vez de roubar senha em uma página falsa, atacantes estão convencendo a vítima a autenticar um código legítimo e, com isso, entregando a sessão de acesso quase de bandeja. O resultado é incômodo: campanhas recentes mostraram que o fluxo de device code virou atalho eficiente para invadir contas do Microsoft 365. Neste artigo, o foco é entender onde está o risco, por que a defesa costuma falhar e o que mudar agora.

O que mudou no jogo do phishing

Boa parte dos programas de conscientização ainda ensina o usuário a procurar o domínio errado, o botão suspeito e o formulário malfeito. Só que o device code phishing escapa desse roteiro. O atacante não precisa montar uma cópia convincente da tela de login nem interceptar credenciais com um kit adversário-no-meio. Ele só precisa convencer a pessoa a inserir um código legítimo em uma página legítima.

É isso que torna a técnica desconfortável para equipes defensivas. O ambiente parece normal. O domínio é real. Em muitos casos, a autenticação multifator também é real. O que está errado não é a página, mas o contexto. O usuário foi induzido a autorizar uma sessão iniciada por outra pessoa.

Como funciona o golpe, na prática

O fluxo de código de dispositivo existe para permitir login em dispositivos com entrada limitada, como smart TVs, equipamentos de sala de reunião e terminais que não lidam bem com autenticação interativa completa. O atacante explora justamente essa conveniência.

Em um cenário típico, ele gera um código de autenticação legítimo e envia para a vítima em formato de convite de reunião, pedido de acesso, alerta interno ou mensagem urgente em apps como Teams, Signal e WhatsApp. A vítima entra em um portal legítimo, digita o código e conclui o login achando que está entrando em uma reunião ou autorizando um recurso corporativo. Na outra ponta, o invasor recebe o token dessa sessão autenticada e passa a operar a conta comprometida.

O detalhe mais importante aqui é o seguinte: não se trata, necessariamente, de exploração de falha no Microsoft 365. Trata-se de abuso de um fluxo previsto, que foi desenhado para casos de uso legítimos. Quando a empresa não controla bem esse caminho, o que era conveniência vira superfície de ataque.

Por que o MFA sozinho não segura esse tipo de ataque

Esse é o ponto em que muita organização tropeça. Há anos o mercado repetiu, corretamente, que MFA reduz drasticamente o comprometimento por phishing. Continua verdadeiro. Mas não é verdade absoluta para todos os fluxos de autenticação.

No device code phishing, o usuário pode completar o MFA de forma legítima. O problema não é a quebra do segundo fator, e sim a autorização indevida de uma sessão iniciada pelo atacante. Em outras palavras: o MFA foi cumprido, mas em favor do adversário.

Isso muda o desenho defensivo. Não basta “ter MFA”. É preciso restringir fluxos de autenticação, criar contexto de acesso, monitorar sinais anômalos e tratar identidade como perímetro de fato. Quando a organização se acomoda na frase “temos MFA, então estamos cobertos”, ela abre um buraco operacional exatamente onde o atacante quer passar.

O que as campanhas recentes mostram sobre o risco real

Em fevereiro de 2025, a Microsoft publicou detalhes sobre a atividade que atribui ao grupo Storm-2372, descrevendo campanhas de device code phishing ativas desde agosto de 2024, com alvos em governo, ONGs, tecnologia, telecom, saúde, energia e ensino superior em várias regiões. A empresa relatou lures que imitavam experiências de WhatsApp, Signal e Microsoft Teams e destacou que o objetivo era capturar tokens para acesso persistente a contas e dados.

No mesmo período, a Volexity detalhou campanhas altamente direcionadas contra contas Microsoft 365, atribuídas com alta confiança a atores russos, com casos em que o acesso comprometido foi seguido por download rápido de arquivos do OneDrive e uso de infraestrutura como VPS e Tor. O ponto mais relevante da apuração da Volexity é simples: esse método estava funcionando melhor do que muito spear phishing tradicional.

Esse é o sinal de autoridade que importa para o gestor: não estamos falando de hipótese acadêmica nem de uma técnica exótica sem tração. Estamos falando de uma rota de intrusão que já produziu comprometimento real, com bom retorno para o atacante e baixa fricção operacional.

Onde as empresas erram ao tentar defender

O erro mais comum é tratar o tema como problema exclusivo de conscientização do usuário. Treinamento ajuda, mas não substitui controle técnico. Se o fluxo continua liberado para qualquer cenário, o defensor está pedindo para a operação depender do discernimento perfeito do funcionário sob pressão.

Outro erro frequente é enxergar identidade de forma fragmentada. A equipe de e-mail cuida do phishing, a equipe de IAM cuida do login, o SOC cuida do alerta e ninguém fecha o circuito completo. Só que o device code phishing cruza exatamente essas fronteiras. O convite chega por uma isca de engenharia social, a autenticação acontece num serviço legítimo e o dano aparece depois na movimentação de sessão, no acesso a arquivos e no uso de aplicativos conectados.

Há ainda um terceiro problema: pouca gente monitora com atenção os sinais específicos desse fluxo. Em muitos ambientes, eventos de autenticação por código de dispositivo não recebem o mesmo escrutínio que logins interativos, consentimentos OAuth ou atividade de caixa postal. O atacante percebe essa diferença rápido.

Os controles que mais valem a pena agora

Nem toda organização consegue bloquear o fluxo de device code de forma ampla sem impacto operacional. Mas quase toda organização consegue fazer alguma combinação de restrição, compensação e monitoramento. Eis o pacote mais sensato para começar:

• Restringir ou bloquear o fluxo de device code onde ele não for necessário: se a empresa não usa esse método para casos legítimos relevantes, o melhor controle continua sendo desligar a porta.
• Aplicar políticas de acesso condicional por contexto: limitar apps, usuários, condições e cenários onde autenticações menos comuns podem ocorrer reduz bastante o espaço de abuso.
• Exigir MFA resistente a phishing para contas sensíveis: não resolve sozinho todos os casos, mas eleva o custo do adversário e reduz outras rotas paralelas de comprometimento.
• Monitorar eventos de autenticação e uso de token com foco em anomalia: logins a partir de VPS, Tor, geolocalização incompatível, sequência incomum entre autenticação e download massivo, uso atípico de OneDrive e Exchange precisam entrar no radar.
• Rever consentimentos, sessões e persistência pós-login: quando há suspeita, a contenção não pode parar em reset de senha. É preciso revogar sessões e analisar o que ficou autorizado.

Na prática, o melhor desenho é assumir que o usuário pode ser persuadido e montar controles para que uma autenticação isolada não vire domínio prolongado sobre conta, e-mail e arquivos.

Como SOC e liderança devem tratar esse risco sem cair em ruído nem pânico

Caçar tudo indiscriminadamente é receita para fadiga. O caminho mais eficiente para o SOC é montar hipóteses específicas: autenticação por device code seguida, em curto intervalo, de acesso a arquivos em volume incomum; login associado a IPs de VPS ou saída Tor; contas de alto valor usando um fluxo que raramente aparece no histórico delas; ou autenticações originadas após contatos externos suspeitos por e-mail e mensageria.

Também vale cruzar telemetria de identidade com contexto de negócio. Um diplomata, um pesquisador de temas sensíveis, um executivo de relações institucionais ou alguém de finanças pode receber convites e pedidos plausíveis de colaboração externa. Esse perfil é terreno fértil para engenharia social refinada. Detecção boa não é só procurar evento raro. É procurar evento raro no usuário certo, na hora errada, com consequência relevante.

Para a diretoria, a mensagem correta não é “temos uma nova moda de phishing e tudo mudou”, nem “isso é só mais do mesmo”. O resumo honesto é que alguns fluxos legítimos de autenticação estão sendo abusados de forma convincente e o modelo tradicional, centrado apenas em senha + MFA + conscientização genérica, já não entrega cobertura suficiente para contas estratégicas. Isso pede investimento seletivo, não pânico: revisar políticas de acesso, endurecer contas críticas, melhorar observabilidade de identidade e treinar usuários para reconhecer pedidos de autenticação fora de contexto.

Checklist prático para reduzir exposição nas próximas duas semanas

• Mapeie se sua organização realmente usa fluxo de device code e para quais aplicações ou equipamentos.
• Se o uso legítimo for inexistente ou marginal, planeje bloqueio controlado.
• Revise políticas de acesso condicional para contas administrativas, executivas e áreas sensíveis.
• Priorize MFA resistente a phishing para administradores, e-mail corporativo e perfis com alto acesso a dados.
• Crie alertas para autenticação por device code fora do padrão, especialmente quando houver IP de VPS, Tor ou geografia improvável.
• Valide se o playbook de resposta inclui revogação de sessões e revisão de tokens, não apenas troca de senha.
• Atualize o treinamento interno com exemplos reais de convite de reunião, pedido de acesso e chat externo que induzem a inserir códigos legítimos.
• Faça um exercício de mesa com SOC, IAM e suporte para testar a resposta a um caso desse tipo.

FAQ

Esse ataque depende de vulnerabilidade no Microsoft 365?

Não necessariamente. O ponto central é o abuso de um fluxo legítimo de autenticação. O problema costuma estar mais na combinação entre engenharia social, permissões excessivas e controles insuficientes do que em uma falha clássica de software.

Bloquear device code resolve tudo?

Resolve muito quando esse fluxo não é necessário no ambiente, mas não substitui higiene de identidade. O atacante pode migrar para outras táticas de phishing, consentimento indevido ou roubo de sessão. O ideal é tratar o bloqueio como uma redução importante de superfície, não como solução única.

MFA resistente a phishing elimina esse risco?

Ajuda bastante no programa de identidade como um todo, mas não deve ser vendido como bala de prata. O valor está em combinar métodos resistentes, políticas contextuais, detecção de comportamento e resposta rápida.

Quem deveria se preocupar primeiro com isso?

Organizações com uso intenso de Microsoft 365, colaboração externa frequente, equipes executivas expostas, áreas de relações governamentais, pesquisa, defesa, energia, saúde, educação e qualquer ambiente em que uma conta de e-mail ou OneDrive comprometida já seja dano relevante.

Qual é o erro de resposta mais comum após o incidente?

Trocar a senha e encerrar o assunto. Em incidentes envolvendo token, é essencial revogar sessões, revisar acessos concedidos, examinar atividade pós-login e entender se houve coleta de dados, regras em e-mail ou abuso de aplicações conectadas.

Fechamento editorial: o avanço do device code phishing é um lembrete incômodo de que a autenticação legítima também pode virar arma quando o contexto é sequestrado pela engenharia social. Para o defensor, a lição não é abandonar MFA nem desconfiar de toda conveniência por padrão. É fazer o trabalho menos glamouroso e mais efetivo: limitar fluxos pouco necessários, observar melhor a identidade e responder com profundidade quando houver sinal de abuso. Quem fizer isso cedo reduz uma avenida inteira de ataque antes que ela vire rotina no ambiente.

Referências

• Microsoft Security Blog. Storm-2372 conducts device code phishing campaign. Publicado em fevereiro de 2025.
• Volexity. Multiple Russian Threat Actors Targeting Microsoft Device Code Authentication. Publicado em fevereiro de 2025.
• Microsoft Learn. Targeting Resources in Conditional Access Policies – Microsoft Entra ID. Documentação consultada para contexto de políticas e escopo de proteção.
• Reddit /r/cybersecurity. O Reddit foi considerado como gatilho editorial, mas o acesso direto ficou limitado por bloqueio de rede neste runtime; a pauta seguiu com fallback em fontes abertas confiáveis, conforme a política editorial.