Phishing de código de dispositivo: aprovando um login que ninguém iniciou
Em fevereiro de 2025, o Microsoft Threat Intelligence Center documentou uma campanha ativa do ator que acompanha como Storm-2372, que roubava sessões de login de organizações na Europa, América do Norte, África e Oriente Médio. O notável na técnica, o phishing de código de dispositivo, é o que ela evita: não há página de login falsa para identificar, nenhuma senha para roubar e nenhum malware para detectar. A vítima nunca digita um segredo. Um código fornecido pelo invasor é digitado na página de login genuína da Microsoft, a vítima aprova o pedido no próprio dispositivo, e o invasor sai com uma sessão funcionando.
Um recurso legítimo, usado contra você
O device code flow é um recurso real do OAuth 2.0, não uma falsificação. Ele existe para hardware sem teclado ou navegador utilizáveis: impressoras, televisores, telas de salas de reunião, decodificadores. O dispositivo exibe um código curto, o usuário abre o portal de login em um celular ou notebook, digita o código, entra e aprova. O dispositivo recebe seus tokens. A Storm-2372 inverteu essa sequência. Segundo a Microsoft, o grupo conduziu a campanha a partir de agosto de 2024: abria chats no Microsoft Teams se passando por executivos ou autoridades e, sob o pretexto de compartilhar documentos, movia a conversa para o Signal ou WhatsApp. Convites de reunião enviados por e-mail traziam a mesma isca, disfarçada de tráfego comum do Teams. A cobertura do BleepingComputer sobre a mesma campanha descreveu vítimas às quais se pedia autenticar um dispositivo para receber um documento importante: elas seguiam um link para a página real de login da Microsoft, digitavam o código recebido e aprovavam o login, incluindo a etapa habitual de autenticação multifator. Os alvos documentados pela Microsoft incluíam órgãos governamentais, provedores de serviços de TI, defesa, telecomunicações, saúde, ensino superior e empresas de energia.Por que isso contorna completamente a MFA
A ordem das operações é o que faz funcionar. O invasor inicia primeiro uma solicitação legítima de código de dispositivo e só depois envolve a vítima. Quando ela digita o código e aprova, todas as verificações da página passam honestamente: a página é real, o código é válido e a pessoa que interage conclui um login genuíno, incluindo a autenticação multifator aplicável. Os tokens que a Microsoft emite, incluindo refresh tokens de longa duração, vão para quem iniciou a solicitação — o invasor. Do ponto de vista do diretório, um usuário simplesmente entrou com sucesso. Não há nada para filtros de e-mail ou proxies sinalizarem, porque a infraestrutura envolvida é inteiramente legítima. O relato da Microsoft registra o que aconteceu depois nos tenants comprometidos: os invasores vasculhavam caixas de correio com consultas à Graph API por termos como credenciais, senhas e admin, exfiltravam correspondência e usavam contas internas confiáveis para enviar phishing a colegas, de modo que uma única aprovação podia se propagar em cascata pela organização. Em uma atualização publicada um dia depois do post original, a Microsoft também documentou uma mudança para solicitações pelo cliente Microsoft Authentication Broker, permitindo registrar dispositivos controlados pelo invasor e solicitar primary refresh tokens. A Proofpoint, que acompanhou a técnica enquanto ela se espalhava por kits de phishing durante 2026, apontou um refinamento adicional: códigos gerados sob demanda no instante em que a vítima clica em um link, contornando a expiração de quinze minutos de um código pré-gerado.O conselho usual, examinar de perto a página de login antes de digitar qualquer coisa, não ajuda aqui. Como aponta a análise da Proofpoint sobre campanhas mais recentes, checar a URL falha porque o portal é genuinamente o da Microsoft; o que é abusado é a aprovação da vítima, não a barra de endereço.
Sinais de alerta que valem ser ensinados
Os sinais são consistentes entre campanhas, e nenhum deles exige conhecimento técnico para ser notado.- um login que você não iniciou: um código de dispositivo só existe porque alguém o solicitou
- urgência e pressão para agir antes que o código expire ou uma reunião comece
- um e-mail, chat ou mensagem pedindo para aprovar ou autenticar algo com um código que você nunca pediu
- contato que troca de plataforma, como uma conversa do Teams que muda para o Signal ou WhatsApp
- um documento ou convite de reunião que só é liberado depois de verificar um código