Quando a maioria das pessoas pensa em "phishing", geralmente pensa em usuários sendo enganados para revelar suas credenciais ou baixar malware.
Um dos métodos de ataque que mais cresce não faz nenhuma das duas coisas. Em vez disso, o usuário visado é enganado para autorizar um cliente controlado pelo atacante. Esses ataques exploram a confiança do usuário nos fluxos de autorização baseados em OAuth, usados para conceder a um aplicativo acesso a dados em outro aplicativo.
No início de 2026, o phishing de códigos de dispositivos está em ascensão. Este ataque explora vulnerabilidades conhecidas na concessão de autenticação por código de dispositivo – um método no qual os usuários autorizam um cliente em um dispositivo fazendo login em outro dispositivo. Essa concessão foi destinada a facilitar o login em dispositivos com "recursos de entrada limitados" – onde digitar uma senha é complicado. Mas também vemos seu uso em muitos outros casos, inclusive em casos de uso relacionados à força de trabalho. Os agentes maliciosos agora se apropriaram desse fluxo com notável sucesso para enganar os usuários e levá-los a autorizar seus aplicativos maliciosos.
Pesquisadores de ameaças da Push Security observaram um aumento de 15 vezes nos ataques de phishing que visam usuários do Microsoft 365 desde o início do ano. Pesquisadores da Okta Threat Intelligence e da Proofpoint agora observaram indícios de que alguns agentes de ameaças migraram de ataques de phishing AitM para ataques de phishing por código de dispositivo.
O phishing de código de dispositivo ganhou destaque porque os ataques foram industrializados por meio de operações de "phishing como serviço", como EvilTokens.
EvilTokens fornece a um cibercriminoso com pouca experiência a infraestrutura, as iscas, as ferramentas de evasão de defesa e os sistemas de alerta/mensagens necessários para lançar ataques de phishing de código de dispositivo contra clientes da Microsoft em grande escala e com o mínimo esforço por parte do usuário.
Neste artigo, explicaremos para que serve o fluxo de código do dispositivo, como ele é explorado e as condições que tornam essa forma de ataque "phishing com dinamite".
The device code authorization grant
O phishing de código de dispositivo explora um fluxo de autorização OAuth 2.0 específico, projetado para dispositivos com restrições de entrada: a concessão de autorização de código de dispositivo OAuth 2.0 (RFC8628).
Um dispositivo com entrada limitada pode ser um aplicativo de streaming na sua TV, aplicativos que controlam seus eletrodomésticos ou até mesmo os sistemas de entretenimento do seu carro. Em qualquer sistema onde seja complicado digitar uma senha longa e complexa, o fluxo de código do dispositivo permite que o usuário faça login fora da banda em um celular ou laptop e autorize (consinta) o cliente a acessar os dados da sua conta.
Se usássemos a ideia de um aplicativo de streaming de vídeo para ilustrar:
Um usuário deseja fazer login em um aplicativo de streaming em sua televisão.
O navegador do smartphone do usuário é o dispositivo de autorização fora do canal.
Um servidor de autorização intermedia o acesso aos servidores de back-end do serviço de streaming.
Em um fluxo de autorização de código de dispositivo legítimo:
- Um usuário tenta entrar em sua conta de serviço de streaming a partir de uma TV.
- Um aplicativo na TV solicita acesso a um servidor de autorização enviando um ID de cliente em uma solicitação para um endpoint específico. O servidor de autorização retorna um código de dispositivo, um código de usuário e um URI de verificação.
- O aplicativo instrui o usuário a visitar o URI de verificação — apresentando-o como um endereço da web ou um código QR na tela da TV — e também fornece ao usuário um código de usuário de oito caracteres para inserir em seu smartphone para autorizar o aplicativo.
- Ao acessar o endereço web fornecido, o usuário é solicitado a inserir o código de usuário e a verificar sua identidade. O usuário poderá ser solicitado a consentir em conceder ao aplicativo acesso a recursos hospedados no servidor (dados da conta no serviço de streaming).
- Em segundo plano, o aplicativo consulta continuamente o servidor de autorização em solicitações que incluem o ID do cliente e o código do dispositivo. Na prática, o aplicativo cliente está perguntando ao servidor de autorização se o usuário o autorizou. Assim que o usuário der seu consentimento, o servidor de autorização responderá a uma solicitação de consulta com um token de acesso. Esse token de acesso pode então ser usado para fazer chamadas de API para o serviço de streaming.
Figura 1: fluxo de autorização de código de dispositivo OAuth 2.0
Todas essas interações acontecem em poucos segundos. O processo é conveniente e incentiva o uso de métodos de autenticação mais robustos (especialmente quando comparado a senhas curtas e códigos OTP inseridos em dispositivos com capacidade de entrada limitada).
Infelizmente, o fluxo de código do dispositivo também é suscetível a abusos em ataques de engenharia social.
Phishing com código de dispositivo
Em um ataque de phishing de código de dispositivo, por outro lado, o atacante controla o aplicativo cliente:
- O atacante registra um novo aplicativo em um locatário controlado por ele ou usa um ID de cliente conhecido por ser confiável pelo servidor de autorização do usuário-alvo. As solicitações ao servidor de autorização são tratadas como válidas porque o fluxo de autorização do código do dispositivo não exige que o aplicativo cliente seja autenticado ou mesmo registrado no servidor de autorização. Nada impede que um invasor abuse de um ID de cliente conhecido, e os IDs de cliente normalmente não são protegidos como segredos.
- O atacante fornece o código de usuário e o URI de verificação a um usuário alvo por meio de um site de phishing ou por telefone, através de uma chamada de engenharia social. Se o usuário autenticado visitar este endereço web e inserir o código de usuário, ele estará efetivamente concedendo ao aplicativo do atacante acesso aos seus recursos. O atacante precisa apenas consultar o servidor de autorização e receberá um token de acesso como resposta.
Figura 2. Phishing de código de dispositivo
Phishing com dinamite
Nos ataques que observamos até o momento, os invasores demonstraram interesse em se passar por clientes que:
São autorizados por um servidor de autorização comum,
São atribuídos a todos os usuários por padrão em novos locatários (incluindo locatários gratuitos/de teste).
Ter um ID de cliente conhecido/comum que seja o mesmo em todos os locatários
Infelizmente, os aplicativos da Microsoft atendem a esse critério em vários aspectos:
Um usuário do EvilTokens pode iniciar um fluxo de código de dispositivo enviando uma solicitação POST para o mesmo endpoint comum que se aplica a todos os clientes da Microsoft (/common/oauth2/devicecode).
Esta solicitação POST deve incluir um ID de cliente válido. Os IDs de cliente dos aplicativos de primeira parte que estão disponíveis por padrão nos locatários da Microsoft são rotineiramente listados e apresentados em tabelas, e as relações incomuns entre eles são discutidas abertamente. Pesquisadores de ameaças observaram que, por padrão, o EvilTokens abusa do ID de cliente conhecido do Microsoft Office, mas outros pesquisadores observaram o abuso de aplicativos adicionais da Microsoft.
Isso significa que uma única ferramenta é útil para atacar praticamente todos os clientes da Microsoft no planeta, independentemente de ser um adolescente autorizando um aplicativo em seu Xbox ou um gerente de TI autorizando um aplicativo para uma empresa da Fortune 500.
A vantagem para um atacante de todos os usuários se autenticarem por meio de um único domínio (login.microsoft.com) é que isso facilita muito o ataque em larga escala. Em um ataque de phishing de código de dispositivo contra clientes da Microsoft, os atacantes direcionam todos os usuários visados para um endpoint comum (login.microsoft.com/common/oauth2/v2.0/devicecode). Nesse endpoint, qualquer usuário dos serviços da Microsoft é um usuário válido, especialmente ao usar IDs de cliente, que provavelmente serão atribuídos a muitos ou a todos os usuários.
Em contrapartida, a plataforma Okta foi projetada com base no princípio de que cada organização possui seus próprios servidores de autorização independentes e descentralizados. Não existe o conceito de um ponto final "comum" onde usuários de diferentes organizações verifiquem sua identidade em um único local.
Isso significa que, embora os clientes criados no Okta não sejam imunes a ataques de phishing de código de dispositivo, a arquitetura do Okta força os invasores a pesquisarem muito mais sobre qualquer alvo em potencial.
Recursos
Conheça a história completa
Para saber mais sobre a abordagem da Okta para se defender contra o uso indevido do fluxo de código do dispositivo, os contatos de segurança dos clientes da Okta podem acessar uma versão estendida deste artigo em security.okta.com
Recomendações
- Permitir o uso do fluxo de código do dispositivo somente em casos excepcionais. Os clientes da Microsoft devem implementar uma Política de Acesso Condicional que bloqueie todo o acesso usando o fluxo de código do dispositivo.
Quando o fluxo de código do dispositivo for considerado o mais adequado para um aplicativo cliente criado no Okta:
Inclua na lista de permissões o intervalo de IPs a partir do qual um token para um determinado cliente pode ser emitido. Isso pode ser configurado para qualquer cliente em Aplicativos > Geral > IP de Rede. Quando configurado, o recurso negará solicitações de token de acesso provenientes de um cliente controlado por um atacante fora do intervalo de IPs permitidos.
Solicita-se o monitoramento de solicitações anômalas de tokens e concessões de usuários.
