security

Device Code Phishing + Vishing: como atacantes comprometem contas Microsoft Entra usando páginas de login legítimas

· 7 min de leitura
securityidentityoauthphishingintermediate
🇺🇸 Read in English
Índice

Atacantes estão apostando em um padrão de engenharia social desagradável (e eficaz): direcionar o usuário para uma página legítima da Microsoft e mesmo assim sair com tokens válidos.

Isso é comumente chamado de device code phishing, e campanhas recentes combinam com vishing (phishing por voz) para aumentar a velocidade e a taxa de sucesso.

TL;DR

Atacantes abusam do fluxo de autorização de dispositivo OAuth 2.0 (“device code flow”) para enganar funcionários a aprovar um login real em microsoft.com/devicelogin. O usuário pode completar o MFA com sucesso — porque o login é real — mas o atacante recebe tokens válidos (frequentemente refresh tokens) para a sessão que ele iniciou. Defenda-se restringindo o device code flow onde possível, endurecendo o Conditional Access, migrando para MFA resistente a phishing, reforçando a governança de apps/consent OAuth e monitorando logins por device code e uso anômalo de tokens.

1) O que é “device code phishing” (e por que é diferente)

Device code phishing não se parece com phishing de credenciais clássico:

  • Pode não haver página de login hospedada pelo atacante.
  • O usuário pode digitar um código em um domínio real da Microsoft.
  • O MFA pode ser completado “com sucesso.”
  • Mesmo assim, o atacante acaba autenticado via tokens.

O truque é simples: o atacante inicia um login por device code para seu client/dispositivo e, em seguida, convence o usuário a completar a autorização. Na prática, o usuário está logando o “dispositivo” do atacante na organização.

Reportes recentes descrevem agentes de ameaça visando contas Microsoft Entra usando device code flow combinado com vishing, frequentemente aproveitando identificadores de client OAuth legítimos da Microsoft no processo.

2) Como o fluxo de autorização de dispositivo OAuth 2.0 funciona (em português simples)

O Device Authorization Grant do OAuth (RFC 8628) existe para dispositivos que não conseguem fazer login interativo via navegador facilmente (smart TVs, sistemas de sala de reunião, impressoras, etc.). A Microsoft o suporta para a plataforma de identidade Microsoft.

Um passo a passo simplificado:

  1. O client solicita um código de pareamento do provedor de identidade, fornecendo um client_id e escopos.
  2. O provedor de identidade retorna:
    • um user_code (curto, para humanos)
    • um device_code (longo, para o client)
    • uma URL de verificação (geralmente direcionando o usuário para uma página da Microsoft como microsoft.com/devicelogin)
    • um tempo de expiração
  3. O usuário abre a URL de verificação e insere o user_code, depois faz login e completa o MFA se necessário.
  4. O client faz polling no endpoint de token usando o device_code até o usuário completar a autenticação.
  5. Uma vez aprovado, o provedor de identidade emite tokens (access token e frequentemente um refresh token).

Por que o MFA pode “funcionar” e você ainda perde

Da perspectiva do Entra, o usuário se autenticou e aprovou uma sessão de login para um dispositivo/app. Se o atacante iniciou o device flow e o usuário o completa, o client do atacante recebe tokens porque o usuário autorizou aquela sessão.

Não é um “bypass” no sentido técnico clássico — é um ataque de autorização com humano no loop.

3) Por que atacantes adoram device code + vishing

Essa técnica remove muita fricção que os defensores estão acostumados a enfrentar:

  • Sem infraestrutura de phishing: menos domínios/páginas de atacante para derrubar.
  • UX legítima: os usuários veem fluxos de login reais da Microsoft, então o treinamento “verifique a URL” pode falhar.
  • Recompensa em tokens: refresh tokens podem sobreviver ao momento do comprometimento.
  • Pressão por telefone: um interlocutor ao vivo pode criar urgência, responder dúvidas e manter a vítima em movimento.

4) Cadeia de ataque comum (device code + vishing)

Uma cadeia típica é:

  1. Seleção do alvo: funções com acesso de alto valor (TI/helpdesk, financeiro, executivos, admins).
  2. O atacante inicia o device code flow usando um client ID OAuth.
  3. Ligação de vishing: o atacante usa um pretexto (“verificação de segurança”, “recuperação de conta”, “login suspeito”) para levar o usuário ao microsoft.com/devicelogin e fazê-lo inserir o código.
  4. Usuário faz login + MFA: o usuário completa os prompts, muitas vezes sob pressão de tempo.
  5. O atacante recebe os tokens e os usa para acessar o Microsoft 365 e potencialmente apps downstream de SSO.
  6. Ações pós-comprometimento: acesso ao mailbox, exfiltração de SharePoint/OneDrive, enumeração via Graph e — se os privilégios permitirem — mecanismos de persistência.

5) Quem está sendo alvo (e por quê)

Isso funciona melhor contra organizações onde:

  • funcionários são treinados para “seguir instruções do TI” rapidamente,
  • há forte dependência do Entra SSO como “chave mestra”,
  • existem funções onde uma única conta dá acesso amplo a dados.

6) O que monitorar: logs, sinais e indícios

Você precisa de cobertura para:

  1. o evento de login por device code, e
  2. atividade pós-autenticação habilitada pela posse do token.

A) Logs de login do Entra (eventos de device code)

Fique atento a:

  • logins por device code para usuários que nunca usam device code flow,
  • logins por device code fora do horário normal,
  • logins por device code seguidos de atividade rápida em Exchange/SharePoint/Graph,
  • padrões incomuns de IP/geografia (especialmente para o uso de token subsequente).

B) Sinais de app/client

Mesmo quando campanhas usam client IDs legítimos da Microsoft, você ainda pode procurar:

  • valores de client_id novos/incomuns aparecendo no seu tenant,
  • nomes de aplicação que não correspondem à função do usuário,
  • picos do mesmo client em muitos usuários em um curto período.

C) Conditional Access / sinais de risco

Se você usa Entra ID Protection/controles baseados em risco, correlacione:

  • propriedades de login desconhecidas,
  • viagem atípica/viagem impossível,
  • sessões que passam MFA uma vez e depois mostram acesso contínuo sem prompts adicionais.

D) Atividade em serviços downstream

Fique atento a:

  • downloads em alto volume,
  • padrões incomuns de acesso ao mailbox,
  • regras de inbox/encaminhamento suspeitas,
  • uso inesperado da Graph API.

7) Detecções que você pode implementar (lógica de alto sinal)

Você não precisa de parsing perfeito no dia um. Comece com correlações de alta confiança:

  • Login por device code + novo país/IP dentro de 15–60 minutos
  • Login por device code + rajada de atividade em Graph/Exchange/SharePoint
  • Login por device code por funções privilegiadas
  • Mesmo client OAuth usado em múltiplos usuários em uma janela curta
  • Login por device code + relato do usuário de que “Microsoft/suporte de TI” ligou para ele

Se você usa o Microsoft Sentinel (ou outro SIEM), transforme isso em regras analíticas e hunting queries.

8) Mitigações que realmente reduzem o risco

1) Restringir ou desabilitar o device code flow onde não for necessário

Se sua organização não tem um requisito de negócio forte, bloqueie o device code flow. É uma das mitigações mais limpas porque remove o mecanismo principal do atacante.

2) Endurecimento do Conditional Access para cenários de device code

Se você precisa permitir, restrinja ao máximo:

  • permita apenas para usuários/grupos específicos,
  • restrinja a locais/dispositivos confiáveis onde viável,
  • exija MFA resistente a phishing para acessos sensíveis,
  • bloqueie geografias/faixas de IP de alto risco (onde o negócio permitir).

3) Endurecimento do MFA (reduzir risco de aprovação humana)

Afaste-se de padrões que dependem apenas de aprovação:

  • priorize MFA resistente a phishing (FIDO2/passkeys/baseado em certificado) para admins e funções sensíveis,
  • habilite number matching / contexto adicional onde suportado,
  • reduza padrões de fadiga de push.

4) Governança OAuth + controles de consent

Mesmo se atacantes usam clients legítimos, governança OAuth importa:

  • restrinja o consent de usuário e exija aprovação de admin para escopos arriscados,
  • monitore novas concessões e permissões delegadas de alto privilégio,
  • audite apps enterprise regularmente.

5) Atualize o treinamento: “URL legítima” não é prova de legitimidade

O treinamento deve dizer explicitamente:

  • “Uma URL real da Microsoft não significa que a solicitação é legítima.”
  • “Nunca insira um código de device login porque alguém pediu por telefone.”
  • “Se o TI ligar para você, desligue e ligue de volta por um número interno conhecido.”

9) Resposta a incidentes: o que fazer se você suspeitar de comprometimento por device code

1) Conter

  • revogar sessões / refresh tokens,
  • resetar a senha (mesmo que o atacante possa não tê-la),
  • re-registrar MFA se o comprometimento for suspeito,
  • remover métodos de autenticação suspeitos.

2) Dimensionar

Revise:

  • logs de login do Entra ao redor do evento (usuário, app/client, IPs),
  • acesso ao mailbox e regras de encaminhamento/inbox,
  • downloads de SharePoint/OneDrive,
  • acesso a apps SSO,
  • qualquer tentativa de escalonamento de privilégios.

3) Erradicar persistência + endurecer

  • verificar novas concessões OAuth/service principals com permissões arriscadas,
  • confirmar que as políticas de Conditional Access não foram adulteradas,
  • implementar restrições de device code e MFA mais forte para funções de alto risco.

O que fazer hoje (checklist)

  • Decidir se o device code flow é necessário; se não, bloquear em todo o tenant.
  • Se necessário, restringir a grupos específicos + restrições de Conditional Access.
  • Criar alertas para eventos de autenticação por device code, especialmente para usuários privilegiados.
  • Correlacionar eventos de device code com atividade pós-autenticação no M365/Graph.
  • Endurecer políticas de consent OAuth e monitorar concessões.
  • Priorizar MFA resistente a phishing para admins/funções sensíveis.
  • Atualizar treinamento de conscientização + procedimento de “ligar de volta” do helpdesk.
  • Documentar um runbook de IR para device code/vishing.

Fontes