Device Code Phishing Ameaça Real na Microsoft 365 sem Páginas de Início Falsas

Entre o final de junho e os primeiros dias de julho de 2026, pesquisadores da ZeroBEC descreveram uma campanha ativa de phishing que aproveita o fluxo legítimo de autenticação por dispositivo da Microsoft 365 para seqüestrar contas, usando cogumelos de colaboração (mensagem, convites a pastas compartilhadas, avisos de pagamento) que incitam a vítima a introduzir um código de dispositivo fornecido pelo atacante. A ameaça não depende de páginas de entradas falsas tradicionais: explora uma funcionalidade real e de confiança, o que a torna mais difícil de detectar por usuários distraídos e por controles que buscam formulários de login falsos.

A técnica, conhecida como device code phishing, abusa do mecanismo padrão OAuth 2.0 Device Authorization Grant, projetado para dispositivos com interfaces limitadas. Na prática, um atacante inicia a geração de um código de dispositivo, engana a vítima para o introduzir em microsoft.com/devicelogin e assim autoriza, sem saber, a sessão controlada pelo atacante. A Microsoft documenta o fluxo e suas propriedades em seu guia técnico, que convém ler para entender por que o processo é legítimo e o que logs restam após seu uso: https://learn.microsoft.com/en-us/azure/active-diretory/develop/v2-oauth2-device-code.

O preocupante dos achados é a industrialização do ataque. ZeroBEC e outros equipamentos identificaram uma camada reutilizável de tooling chamada DEBULL e plataformas de phishing-as-a-service (PhaaS) como EvilTokens, ARToken ou Tycoon que empacotam desde a orquestração do código até painéis pós-compromissores para manter persistência, exfiltrar e-mails e automatizar campanhas de business email compromise (BEC) por AI. Isso torna o que antes era uma tática complexa em um serviço acessível para operadores com diferentes níveis de habilidade, multiplicando o risco e a velocidade de propagação.

As implicações são severas: superar a MFA, obter tokens válidos sem roubar senhas, persistência em ambientes Microsoft 365, acesso ao Exchange, OneDrive/SharePoint, e movimento lateral suportado por APIs da Microsoft Graph. Além disso, o uso de contas já comprometidas para distribuir links legítimos faz com que as mensagens pareçam confiáveis para destinatários que confiam no remetente, facilitando o efeito multiplicador das campanhas.

Para usuários individuais a recomendação mais imediata é simples, mas crítica: nunca introduzir códigos de dispositivo que lhe chegam em um e-mail, chat ou chamada Se não estão aparecendo no ecrã do dispositivo onde você tenta autenticar-se. Trátalos como um OTP sensível: se você não iniciou uma ação consciente em um dispositivo que controla, não autorize nada e comunícate por canais verificados com quem supostamente lhe pede a ação.

No plano organizacional, convém priorizar mitigações que reduzam a janela de abuso e que favoreçam métodos de autenticação resistentes ao phishing: implementar autenticadores phishing-resistentes (FIDO2, Windows Hello for Business), exigir dispositivos administrados ou conformes mediante Conditional Access, monitorar e investigar logins com o grant type "device_code" nos registros de sign-in do Azure AD e configurar alertas para padrões anormais (tokens emitidos de locais estranhas ou sessões concorrentes). Também é recomendável rever a exposição da função se não for utilizada e avaliar o bloqueio ou restrição do Device Authorization Grant a ambientes controlados. Para orientação geral sobre prevenção de phishing e boas práticas, CISA oferece recursos públicos úteis: https://www.cisa.gov/publication/phishing.

Detectar e responder requer combinar sinais técnicos e processos: correlacionar registros de autenticação que indiquem uso de device codes com atividade de e-mail e acesso ao SharePoint/OneDrive, bloquear domínios e infra-estruturas associadas a PhaaS conhecidas, rotar credenciais elevadas e aplicar acesso just‐in‐time e privilégios mínimos. Além disso, a formação contínua de funcionários deve incluir exemplos concretos deste vetor e procedimentos claros de verificação para pedidos de acesso ou pagamentos que cheguem por correio ou chat.

Finalmente, a evolução para painéis completos da BEC utilizáveis por afiliados e com funções impulsionadas por IA sublinha que a defesa deve ser proativa e adaptativa. Não basta com MFA tradicional; há que adicionar controles phishing-resistentes, visibilidade nos logs de autenticação e processos de detecção e resposta que assumam que qualquer conta pode ser o ponto de partida de uma campanha. A combinação de educação, endurecimento de políticas de identidade e visibilidade operacional é a forma mais prática de reduzir o impacto dessas campanhas.