Quando verificar a URL não é suficiente: ataque de Device Code Phishing por meio de recurso da Microsoft

Uma das recomendações mais comuns para proteção contra phishing é verificar o nome de domínio do site que solicita credenciais. Em geral, domínios maliciosos são identificáveis visualmente, pois apresentam pequenas variações ortográficas em relação aos domínios oficiais. Entretanto, recentemente nos deparamos com um esquema em que o invasor propõe à vítima inserir dados em um recurso legítimo de uma empresa conhecida. Trata-se da Microsoft Identity Platform, que suporta a especificação do protocolo OAuth 2.0 denominada Device Authorization Grant.

Esta especificação foi desenvolvida para a comodidade dos usuários de smart TVs, dispositivos IoT, impressoras e outros dispositivos com entrada limitada, sem navegador completo ou teclado. Ela permite autorizar tal dispositivo para acesso aos recursos do usuário via smartphone ou computador. Para isso, o usuário precisa inserir um código de uso único em uma página de autorização especial. Este código, juntamente com o link onde deve ser inserido, é fornecido pela Microsoft Identity Platform em resposta à solicitação https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode, motivo pelo qual o cenário de ataque que abusa deste mecanismo é chamado de Device Code Phishing.

Este artigo detalha o funcionamento da especificação Device Authorization Grant (também conhecida como Device authorization grant flow ou Device code flow). Analisaremos ataques reais usando esta tecnologia e também explicaremos como se proteger do Device Code Phishing.

Principais etapas do Device Authorization Grant

1. Solicitação do código de autorização
   Quando o usuário inicia um aplicativo em um dispositivo cliente (por exemplo, um serviço de streaming de vídeo em uma smart TV), ele detecta a ausência de autorização e envia uma solicitação POST para o endereço https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode com os parâmetros client_id (identificador único do aplicativo registrado no Microsoft Entra ID (Azure AD)) e scope (lista de permissões de acesso solicitadas). Em resposta, o aplicativo recebe os parâmetros device_code (código secreto para uso interno), user_code (código curto que o usuário verá), verification_uri (link para acessar), expires_in (tempo de vida do código) e interval (frequência de consulta ao servidor).
2. Exibição do código para o usuário
   O dispositivo mostra ao usuário o user_code e o verification_uri, propondo realizar a autorização em outro dispositivo. Por exemplo, uma smart TV exibe o código e o link para serem inseridos em um smartphone, sendo que o link verification_uri pode ser apresentado na forma de QR Code.
3. Inserção do código e confirmação de acesso
   Usando a câmera do smartphone (no caso de QR Code) ou digitando manualmente o endereço, o usuário acessa o verification_uri (por exemplo, https://microsoft.com/devicelogin) e insere o user_code.
4. Consulta ao servidor
   O dispositivo (smart TV) começa a consultar o servidor para saber o status da autorização (se o usuário confirmou o acesso), enviando uma solicitação POST para o endpoint https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token. Na solicitação é transmitido o parâmetro grant_type com o valor urn:ietf:params:oauth:grant-type:device_code, que indica o uso do método Device Authorization Grant. Este parâmetro informa ao servidor de autorização qual método está sendo usado para obter os tokens de acesso. O servidor aguarda até que o usuário insira o user_code em outro dispositivo e confirme o acesso aos seus recursos/dados. Enquanto o usuário não confirmar isso, o servidor retorna authorization_pending (aguarde) ou slow_down (consultas muito frequentes).
5. Obtenção dos tokens de acesso
   Após o usuário confirmar o acesso ao aplicativo, o servidor retorna ao aplicativo o access_token (chave de acesso aos dados), refresh_token (chave para renovação de acesso) e id_token (token com informações sobre o usuário: nome, e-mail e outros dados), além de uma série de outros parâmetros de serviço.
6. Renovação automática de acesso
   O dispositivo, neste caso nossa smart TV, usa o refresh_token para renovar o access_token sem nova autorização do usuário. Quando o prazo do access_token atual expira (geralmente após 1 hora), o dispositivo envia uma solicitação com o parâmetro refresh_token para o endpoint /token e recebe novos access_token e refresh_token, para que o usuário não precise fazer o login novamente.

Este esquema é realmente conveniente para dispositivos que não possuem formulário de entrada ou que possuem formulário limitado. Entretanto, invasores podem abusar dele e obter acesso à conta do usuário, além de manter tal acesso por muito tempo usando o refresh_token. Analisaremos este vetor de ataque com um exemplo.

Análise do ataque de Device Code Phishing

E-mail de phishing

Na campanha de phishing que observamos do início de abril até meados de maio de 2026, o e-mail estava estilizado como uma notificação de um escritório de advocacia. Anexado ao e-mail havia um arquivo PDF protegido por senha.

Após abrir o arquivo PDF e inserir a senha, o usuário via uma página com uma lista de documentos, mas para visualizá-los era necessário abrir um link.

Arquivo PDF com link malicioso

Se prestarmos atenção ao link que sugeriam abrir, em vez do recurso de phishing habitual veremos um endereço legítimo da Microsoft. Mas nos parâmetros do link está incluído um redirecionamento para um recurso de phishing.

O link no documento não leva ao site da Microsoft, mas redireciona para um recurso de phishing

O link redirecionava o usuário para uma página de phishing que se passava por um portal jurídico.

Página de phishing

Curiosamente, nesta página havia vários CAPTCHAs, aparentemente para filtrar crawlers. Após concluí-los, o usuário era direcionado a outra página, na qual pediam que ele copiasse um código de uso único. Esse código é o user_code que o aplicativo no servidor dos agentes maliciosos obteve por meio de uma solicitação para https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode, conforme descrito anteriormente.

Código de uso único

Quando o usuário clicava no código de uso único exibido, este era copiado para a área de transferência e o próprio usuário era redirecionado para a página de autorização genuína da Microsoft (verification_uri), onde pediam para que ele inserisse o código obtido.

Página oficial da Microsoft

Se o usuário inserisse o código, iniciava-se o processo de Device Authorization Grant que descrevemos acima. A vítima desavisada passava por uma autenticação MFA completa na página oficial da Microsoft. Após a conclusão deste processo, o invasor obtinha acesso ao access_token, refresh_token e id_token, o que permitia, por exemplo, ler e enviar e-mails da caixa de correio da vítima, além de obter acesso aos arquivos do OneDrive e mensagens no Teams.

Adaptação do método de ataque

A campanha de phishing descrita não foi muito massiva e durou pouco mais de um mês. Entretanto, o método em si continua sendo usado pelos invasores até hoje, adaptando-o para regiões específicas. Registramos ataques ligeiramente modificados da classe Device Code Phishing direcionados, por exemplo, a usuários brasileiros.

Campanhas de phishing direcionadas ao público brasileiro

 
Neste e-mail não havia arquivo PDF anexado. Em vez disso, havia um link para o recurso legítimo cacoo.com (plataforma da empresa Nulab para criação de diagramas), que, como no esquema descrito anteriormente, redirecionava o usuário para um site de phishing.

Link proxy leva ao recurso legítimo Cacoo.com com redirecionamento para site de phishing

 
Ao clicar no link, o usuário ia para a conhecida página com o código de uso único.

Página com o código

E em seguida a vítima em potencial encontrava novamente a página oficial da Microsoft e o processo de autorização usando o Device Authorisation Grant.

Página da Microsoft para inserção do código

Como se proteger contra o ataque de Device Code Phishing

Como mostra nossa pesquisa, para acessar dados confidenciais os invasores nem sempre dependem do roubo de logins e senhas usando malware — eles podem abusar de ferramentas legítimas também. Portanto, recomenda-se que os usuários mantenham uma postura defensiva mesmo ao interagir com portais oficiais, como páginas da Microsoft ou Cacoo.com.

Recomendações para usuários:

• Se você não iniciou um login em um dispositivo usando o Microsoft Device Authorization Grant, não confirme a autorização.
• Nunca insira códigos de autorização recebidos em e-mails ou mensagens inesperadas, mesmo que o link leve a um site oficial da Microsoft.
• Invasores usam links para domínios legítimos, adicionando aos parâmetros da URL redirecionamentos (redirect_uri, return_url, next após o sinal “?”) ao endereço do recurso malicioso. Antes de abrir um link, posicione o cursor sobre ele e verifique não apenas o domínio principal, mas também parâmetros suspeitos de redirecionamento, e após o acesso certifique-se de que a URL final corresponde ao recurso esperado — este é o mínimo obrigatório antes de inserir credenciais.

As organizações devem avaliar criticamente a necessidade de habilitar o Device Code Flow em seus ambientes corporativos. Caso não haja requisito de negócio justificado, recomenda-se bloquear esse fluxo via políticas de Acesso Condicional no Microsoft Entra ID. Também deve ser configurado o monitoramento de eventos DeviceCodeSignIn, do status de conformidade dos dispositivos (device compliance) e de anomalias de login a partir de localizações incomuns.

Soluções robustas de segurança para e-mail, que garantam a proteção das comunicações corporativas e pessoais, contribuem para reforçar a proteção contra ataques de Device Code Phishing.