O Device Code Phishing é desconfortável justamente porque quebra uma regra que muita gente aprendeu a usar como sinal de segurança: “confira se o site é legítimo”. Nesse ataque, o site pode ser legítimo, o domínio pode estar correto e o MFA pode aparecer normalmente. Ainda assim, a vítima termina autorizando uma sessão que foi iniciada pelo atacante.
Não há necessidade de copiar a página de login, roubar a senha ou apresentar um formulário falso. O criminoso explora um fluxo previsto no próprio ecossistema de identidade e desloca a engenharia social para outro ponto: convencer o usuário a digitar um código que não foi gerado pelo dispositivo dele.
Quando a autenticação legítima é usada contra o usuário
O fluxo de device code existe por um motivo legítimo. Ele foi pensado para equipamentos ou aplicações em que digitar credenciais diretamente não é prático — uma TV, um terminal, uma interface limitada ou um dispositivo sem navegador completo.
A aplicação pede ao provedor de identidade um código temporário. O usuário abre uma página de autenticação em outro dispositivo, informa aquele código e conclui o login. Quando a autorização termina, o cliente que iniciou o processo recebe os tokens necessários para operar.
O mecanismo simplifica a autenticação em equipamentos com interfaces limitadas, mas também oferece uma oportunidade ao criminoso: iniciar a solicitação em seu próprio dispositivo e transferir para outra pessoa a etapa de autorização.
No ataque, quem inicia o pedido de device code é o criminoso. Em seguida, ele envia esse código à vítima por e-mail, chat, telefone, página maliciosa ou qualquer outro canal convincente. A vítima abre o endereço oficial do provedor — por exemplo, a página legítima da Microsoft — e digita o código.
A autenticação acontece de verdade. MFA pode ser exigido e concluído. A vítima pode até perceber o cadeado do navegador e confirmar que está no domínio certo. O problema é que todo esse processo está autorizando o cliente controlado pelo atacante.
O usuário, portanto, não é levado necessariamente a uma página falsa. Ele é induzido a autorizar uma sessão que não iniciou, uma diferença importante para quem ainda associa phishing exclusivamente ao roubo de senhas em sites clonados.
Em setembro de 2026, a Microsoft descreveu a infraestrutura chamada “EvilTokens” e afirmou ter observado comprometimento de mais de 12 mil caixas de correio em mais de 10 mil organizações. O caso é importante porque mostra que essa técnica não é uma curiosidade de laboratório. Ela pode ser automatizada e operada em escala.
O ataque explora sinais que normalmente aumentam a confiança. O endereço é legítimo. O certificado é legítimo. A experiência de autenticação é familiar. Em muitos ambientes, o usuário já viu processos parecidos ao conectar uma TV, um aplicativo ou uma ferramenta corporativa.
Além disso, o código pode chegar acompanhado de uma narrativa plausível: “revalidar o Microsoft 365”, “concluir a ativação”, “verificar o dispositivo”, “restaurar acesso ao e-mail”. Quando a pessoa chega ao site oficial, a desconfiança costuma cair.
Notícias Relacionadas
- GhostCode explora fluxo legítimo da Microsoft para contornar MFA e assumir contas em segundos
- Vishing contra o suporte de TI: como criminosos contornam MFA e invadem o SaaS
Isso não significa que a autenticação multifator tenha perdido sua utilidade. O MFA continua sendo uma proteção importante contra ataques baseados em senhas comprometidas, mas não garante, por si só, que a pessoa esteja autorizando a operação que imagina.
O que o Device Code Phishing mostra é outra coisa: um fator adicional pode autenticar uma transação que o usuário não compreendeu corretamente. O problema não está necessariamente no fator; está no contexto da autorização.
É a mesma razão pela qual a segurança de identidade vem se deslocando de “adicionar mais um fator” para “garantir que o fator esteja vinculado à operação certa”. Métodos resistentes a phishing, políticas de acesso e validação de contexto tentam justamente reduzir a possibilidade de reutilizar ou redirecionar a autenticação.
Depois de receber tokens válidos, o atacante passa a operar como uma sessão autenticada. O alcance vai depender do aplicativo, dos escopos e das permissões da conta.
No Microsoft 365, por exemplo, o interesse pode estar em e-mail, arquivos, contatos e APIs. Uma conta comprometida também pode ser usada para continuar a cadeia de fraude: mensagens internas parecem mais confiáveis quando partem de uma identidade real.
É por isso que a resposta ao incidente precisa ir além da pergunta “houve login de um IP estranho?”. O analista precisa olhar tokens, consentimentos, métodos de autenticação, chamadas de API, regras de e-mail e alterações realizadas durante a sessão.
Medidas que atacam o mecanismo, não apenas a mensagem de phishing
Treinamento continua relevante, mas não deveria ser a única barreira. O melhor cenário é reduzir a possibilidade técnica de usar esse fluxo onde ele não faz falta.
- Bloquear o Device Code Flow quando não houver necessidade real. Se a organização não usa esse método, deixá-lo habilitado apenas cria superfície.
- Restringir quem pode usar o fluxo. Quando houver necessidade, o acesso pode ser limitado a usuários, aplicações, dispositivos e condições específicas.
- Adotar métodos resistentes a phishing. Passkeys e FIDO2 reduzem várias técnicas de captura e relay, embora não eliminem todo abuso de fluxos paralelos.
- Monitorar OAuth e APIs. Uso incomum de Graph, novos consentimentos e padrões de acesso fora da rotina precisam entrar nos casos de detecção.
- Tratar códigos como parte do processo de autorização. Um código recebido por outra pessoa não deve ser digitado sem entender qual aplicativo ou dispositivo está sendo associado.
- Revogar sessões e tokens em caso de suspeita. Redefinir a senha, sozinho, pode deixar acessos ativos.
Há um ponto que costuma ficar de fora: usuários não devem precisar adivinhar se uma solicitação é legítima. Se a empresa utiliza device code em algum processo oficial, isso precisa ser claro, documentado e previsível. Quanto mais ambígua a experiência real, mais fácil é para o atacante imitar o contexto.
O help desk também precisa conhecer a técnica. Uma vítima pode relatar algo aparentemente inofensivo — “digitei um código na página da Microsoft” — e isso ser tratado como evento benigno. Em determinados cenários, essa frase deveria iniciar imediatamente uma investigação de identidade.
O caso expõe um limite das recomendações tradicionais de segurança. Conferir o domínio continua importante, mas não basta para reconhecer o abuso de um fluxo legítimo: a página pode ser autêntica enquanto a autorização beneficia outra pessoa. Para as empresas, isso exige políticas de identidade que considerem não apenas quem se autenticou, mas também qual aplicação iniciou o pedido e o que recebeu como resultado.
A pergunta que precisa entrar no hábito do usuário e no desenho técnico é: quem iniciou este fluxo, qual aplicação vai receber a autorização e por que isso está sendo solicitado agora? Em identidade moderna, a intenção da autenticação passou a importar tanto quanto o endereço mostrado no navegador.
Veja também
- Segurança de identidades: por que a defesa começa antes do login
- Deepfakes em chamadas corporativas: voz e vídeo já não bastam para provar identidade
Be the first to comment