Device Code Phishing: como o OAuth Device Flow compromete contas Entra ID

O device code phishing abusa de um fluxo legítimo de autorização de dispositivo OAuth para fazer a vítima autorizar uma sessão controlada pelo atacante. Em ambientes Microsoft Entra ID, o usuário pode inserir um código curto na página real de login de dispositivo da Microsoft, concluir a autenticação e até o MFA, enquanto o cliente que aguarda o token é do atacante.

Essa distinção é importante. O device code phishing não é password spraying, não é OAuth consent phishing, não é MFA fatigue, nem uma página genérica de coleta de credenciais. É um caminho de ataque focado em tokens contra um fluxo de autenticação válido, projetado para dispositivos com entrada limitada. Os defensores precisam avaliá-lo sob a ótica do Conditional Access, da telemetria de sign-in, da investigação de tokens e da atividade pós-autenticação.

Para equipes que já revisam MFA fatigue, password spraying, por que o MFA sozinho não é suficiente, ou controles mais amplos de auditoria de segurança do Microsoft Entra ID, o device code phishing merece tratamento separado: a interação inicial e a sessão resultante não lembram um site clássico de phishing de login falso.

O que é Device Code Phishing?

O device code phishing é uma técnica de engenharia social que abusa da concessão de autorização de dispositivo do OAuth 2.0: o atacante inicia um fluxo de device code a partir de um cliente que controla, recebe user_code e verification_uri do servidor de autorização, e engana o usuário-alvo para que insira esse código em um navegador. Se o alvo concluir a autenticação, o cliente do atacante recebe tokens para o recurso e os escopos solicitados.

O fluxo legítimo de autorização de dispositivo existe para dispositivos que não conseguem exibir facilmente um navegador completo ou aceitar entrada rica. A documentação da Microsoft descreve cenários como smart TV, dispositivo IoT ou impressora. O dispositivo exibe um código, o usuário faz login em outro dispositivo, e o cliente com entrada limitada consulta periodicamente o endpoint de token até a autorização ser bem-sucedida ou expirar.

O device code phishing inverte esse design. O dispositivo que solicita a autorização não é uma TV corporativa ou impressora à frente do usuário, mas uma sessão de cliente controlada pelo atacante. Pede-se à vítima que insira um código em uma página legítima da Microsoft, o que dificulta distinguir a experiência do sign-in normal.

Por isso, a expressão "bypass de MFA" exige formulação cuidadosa: em muitos casos, o MFA não é quebrado criptograficamente — o usuário genuinamente o conclui durante o sign-in da Microsoft. O problema é que ele está autorizando a sessão de device code do atacante, portanto a satisfação do MFA por si só não prova que a sessão resultante pertence a um dispositivo, local ou fluxo de trabalho confiável do usuário.

Como funciona o OAuth Device Code Flow

A concessão de autorização de dispositivo do OAuth é definida na RFC 8628. O cliente solicita autorização de dispositivo ao servidor de autorização e recebe valores como device_code, user_code, verification_uri, um valor de expiração e um intervalo de consulta. O usuário é instruído a visitar o verification_uri e inserir o user_code; enquanto se autentica, o cliente consulta periodicamente o endpoint de token usando o device_code.

A plataforma de identidade da Microsoft implementa esse padrão via device code flow. Uma resposta de token bem-sucedida pode incluir access token, ID token quando openid é solicitado, e refresh token quando o escopo original incluía offline_access. Esse material é o objetivo do atacante: ele não precisa saber a senha do usuário se a vítima concluir o fluxo de autorização.

O fluxo tem três propriedades de segurança que os defensores precisam entender:

A RFC 8628 discute o phishing remoto: declara que o fluxo pode ser iniciado em um dispositivo na posse de um atacante, que pode enviar uma mensagem instruindo o usuário-alvo a visitar a URL de verificação e inserir o user code. A RFC recomenda que os servidores de autorização informem o usuário de que está autorizando um dispositivo e confirmem que esse dispositivo está de fato em sua posse.

Em que o Device Code Phishing difere de ataques semelhantes

O device code phishing situa-se próximo a vários outros ataques de identidade, mas o mecanismo é diferente.

Essas distinções afetam a remediação: um tenant com controles de senha robustos ainda pode estar exposto ao device code phishing se permitir esse fluxo amplamente; com MFA, ainda pode sofrer comprometimento se os usuários autorizarem sessões que não controlam. Bloquear o fluxo de device code também não dispensa tratar lacunas no Conditional Access, políticas de risco do Identity Protection, ou registros de aplicativo com privilégios excessivos.

Por que o Device Code Phishing funciona contra contas Entra ID

O ataque funciona porque não pede à vítima uma senha para um domínio obviamente do atacante. O usuário é direcionado a uma página de verificação hospedada pela Microsoft e vê prompts de autenticação familiares. Treinamentos de segurança focados apenas em domínios falsos ou páginas de senha suspeitas não cobrem esse padrão.

As pesquisas da Microsoft de 2025 e 2026 sobre device code phishing descrevem o mesmo padrão central: agentes de ameaça abusam do fluxo legítimo de autenticação, fazem a vítima autenticar a sessão do atacante e recebem tokens válidos sem roubar a senha diretamente. A Microsoft também observou evolução das campanhas em 2026, incluindo automação e geração dinâmica de códigos para manter válido o device code de curta duração enquanto o usuário interage com a isca.

A técnica é especialmente relevante para ambientes Entra ID e Microsoft 365: os tokens resultantes podem ser usados contra recursos em nuvem como Exchange Online, Microsoft Graph, SharePoint Online ou Teams, dependendo do aplicativo, do recurso e dos escopos envolvidos. Isso não significa que todo sign-in por device code seja malicioso, mas que os defensores precisam saber se o fluxo legítimo é usado em seu tenant, por quais aplicativos, a partir de quais locais e sob quais decisões de Conditional Access.

Um modo de falha comum é tratar um MFA bem-sucedido como prova final de legitimidade — o evento pode ser genuíno, mas não comprova que o usuário pretendia autorizar o cliente que recebeu o token. Por isso, a revisão de sign-in deve incluir o protocolo de autenticação, o aplicativo, o recurso, o IP, os detalhes do dispositivo, o status do Conditional Access, as detecções de risco, os identificadores de sessão e a atividade de workload pós-autenticação.

Cadeia de ataque

Uma cadeia típica de device code phishing tem a seguinte aparência:

1. O atacante inicia uma solicitação de autorização de dispositivo a partir de infraestrutura ou ferramentas próprias.
2. A plataforma de identidade retorna um user code, um verification URI, um valor de expiração e um intervalo de consulta.
3. O atacante entrega o código à vítima por e-mail, chat, um convite de colaboração, uma isca em documento ou outro canal social.
4. A vítima visita a página de verificação, insere o código, faz login e conclui as etapas de autenticação exigidas.
5. O cliente do atacante consulta periodicamente o endpoint de token e recebe os tokens após a autorização ser concluída.
6. O atacante usa o acesso resultante para ler e-mails, consultar o Microsoft Graph, enumerar dados do tenant, criar regras de caixa de entrada, acessar arquivos ou tentar outras ações permitidas pelo token e pelos privilégios da conta.
7. O defensor pode ver o sign-in inicial como um fluxo de device code bem-sucedido, seguido por uso não interativo de token e atividade de workload.

A cadeia não deve ser reduzida a um único indicador. Um valor deviceCode no protocolo de autenticação importa, mas apenas indica qual fluxo foi usado — não comprova, por si só, intenção maliciosa. A investigação se torna mais robusta quando esse evento é combinado com localização não familiar, aplicativo incomum, detalhes de sign-in arriscados, acesso inesperado a recursos, criação de regras de e-mail, atividade na API do Graph, ou um usuário que normalmente não utiliza o fluxo de device code.

Detecção

Estabelecer a linha de base do uso legítimo de device code

A detecção deve começar estabelecendo uma linha de base do que é conhecido como legítimo. Muitas organizações têm pouca ou nenhuma necessidade legítima do fluxo de device code; outras o utilizam para ferramentas legadas específicas, dispositivos de salas de conferência, fluxos de trabalho de desenvolvedores ou cenários de registro de dispositivos. A primeira pergunta é se esse fluxo é esperado naquele tenant.

Nos logs de sign-in do Microsoft Entra exportados para o Log Analytics, a tabela SigninLogs inclui o campo AuthenticationProtocol, para o qual a Microsoft documenta deviceCode como um dos valores possíveis, além de campos como OriginalTransferMethod, AppDisplayName, ResourceDisplayName, IPAddress, DeviceDetail, UserAgent, ConditionalAccessStatus, RiskLevelDuringSignIn, RiskEventTypes_V2, SessionId e UniqueTokenIdentifier.

Hunting pelo protocolo de autenticação device code

Uma consulta básica de hunting pode inventariar o uso bem-sucedido e malsucedido do device code:

SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| project TimeGenerated, UserPrincipalName, AppDisplayName, ResourceDisplayName,
          IPAddress, Location, DeviceDetail, UserAgent, ConditionalAccessStatus,
          RiskLevelDuringSignIn, RiskEventTypes_V2, ResultType, ResultDescription,
          SessionId, UniqueTokenIdentifier
| order by TimeGenerated desc

Use isso como ponto de partida para a investigação, não como detecção completa. Avalie se o aplicativo e o recurso fazem sentido para aquele usuário: um desenvolvedor autenticando uma CLI conhecida a partir de uma rede conhecida é um sinal diferente de um usuário da área financeira que, de repente, autoriza um device code a partir de um novo país e gera atividade no Graph ou no Exchange.

Para um detector mais robusto, compare os sign-ins recentes por device code com o uso histórico:

let lookback = 30d;
let recent = 1d;
let knownUsers = SigninLogs
| where TimeGenerated between (ago(lookback) .. ago(recent))
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| where ResultType == 0
| distinct UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(recent)
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| where ResultType == 0
| where UserPrincipalName !in (knownUsers)
| project TimeGenerated, UserPrincipalName, AppDisplayName, ResourceDisplayName,
          IPAddress, Location, DeviceDetail, UserAgent, ConditionalAccessStatus,
          RiskLevelDuringSignIn, RiskEventTypes_V2, SessionId, UniqueTokenIdentifier

Priorizar pelo contexto, não por um único evento

Priorize eventos com as seguintes características:

• Primeira ocorrência observada de fluxo de device code para o usuário ou departamento.
• Aplicativo ou recurso não familiar para a função daquele usuário.
• Sign-in a partir de IP, ASN, país ou rede não normalmente associados ao usuário.
• Valores de RiskEventTypes_V2 como IP anônimo ou detecções de threat intelligence.
• Fluxo de device code bem-sucedido seguido por uso não interativo de token a partir de infraestrutura inesperada.
• Novas regras de caixa de entrada, acesso suspeito a e-mails, atividade incomum no Graph, acesso a arquivos no SharePoint ou atividade no Teams após o sign-in.
• Atividade de registro ou ingresso de dispositivo que aparece no mesmo período e não faz parte de um onboarding normal.

Os identificadores vinculáveis do Microsoft Entra tornam a fase pós-autenticação mais acionável. Comece com o SessionId ou o UniqueTokenIdentifier do log de sign-in e correlacione-o com os logs de auditoria do Exchange Online, os logs de atividade do Microsoft Graph e os logs do SharePoint Online ou do Teams. A Microsoft documenta esse modelo de correlação para rastrear atividades realizadas por uma sessão ou token específico.

O Microsoft Defender e o Entra ID Protection podem agregar sinais de maior confiança. A documentação da Microsoft descreve detecções de risco como IP anônimo, threat intelligence do Microsoft Entra, token anômalo e tráfego de API suspeito. Trate esses sinais como enriquecimento e priorização — eles não substituem a necessidade de entender, antes de tudo, se o fluxo de device code deveria ter ocorrido.

Remediação

Bloquear ou restringir o fluxo de device code

O controle mais direto é restringir ou bloquear o fluxo de device code com o Conditional Access. A Microsoft recomenda chegar o mais próximo possível de um bloqueio unilateral: auditar primeiro o uso existente e permitir o fluxo apenas para casos de uso bem documentados e protegidos. Para organizações que não utilizam esse fluxo, a Microsoft fornece um padrão de Conditional Access que visa a condição de fluxos de autenticação, seleciona o device code e bloqueia o acesso.

Um caminho prático de hardening é:

1. Inventariar o uso atual do fluxo de device code nos logs de sign-in do Entra.
2. Identificar usuários, aplicativos, recursos, locais e dependências de registro de dispositivo legítimos.
3. Criar uma política de Conditional Access em report-only direcionada ao fluxo de device code.
4. Excluir contas de acesso de emergência e casos de uso legítimos documentados.
5. Revisar o impacto da política e os logs de sign-in.
6. Mover a política de report-only para habilitada quando o impacto for compreendido.
7. Monitorar tentativas bloqueadas e exclusões inesperadas.

Verificar a compatibilidade antes de aplicar

Há uma ressalva importante de compatibilidade: se uma organização usa o fluxo de device code contra o Device Registration Service e tem uma política de fluxos de autenticação direcionada a todos os recursos, esse recurso deve ficar isento do escopo para evitar impacto. A Microsoft documenta o client ID do Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) e explica que os logs de sign-in podem ser filtrados por esse resource ID e restringidos ao device code com o filtro de protocolo de autenticação. Não bloqueie cegamente todos os recursos sem verificar se algum fluxo de registro de dispositivo depende desse caminho.

Os controles de concessão do Conditional Access exigem interpretação precisa. A Microsoft documenta que, no fluxo OAuth de device code, os controles obrigatórios para dispositivo gerenciado ou estado do dispositivo não são suportados, pois o dispositivo que autentica não consegue informar seu estado ao dispositivo que exibe o código. Ou seja, uma política baseada apenas em exigência de dispositivo compatível ou híbrido associado pode não funcionar como esperado nesse fluxo. A orientação da Microsoft é usar o controle de exigir MFA e restringir o próprio fluxo pela condição de fluxos de autenticação.

Considere também o rastreamento de protocolo. A Microsoft documenta que uma sessão via device code é marcada como "protocol tracked", estado mantido nas renovações subsequentes. Uma solicitação posterior na mesma sessão pode ser bloqueada por uma política de fluxos de autenticação mesmo sem ter usado o device code diretamente, e o sign-in reporta o erro AADSTS530036. Espere esse comportamento ao revisar o impacto em report-only, e verifique o original transfer method no sign-in bloqueado antes de tratar o bloqueio como configuração incorreta.

Reduzir o raio de impacto após a autorização

Os controles complementares importam porque o device code phishing costuma ser apenas um dos caminhos para um incidente de identidade maior:

• Exigir autenticação resistente a phishing para funções privilegiadas quando suportado, sem presumir que isso, por si só, bloqueia todos os cenários de device code.
• Usar Conditional Access baseado em risco e políticas do Identity Protection para desafiar ou bloquear sessões arriscadas.
• Limitar a exposição de contas privilegiadas e evitar contas de uso diário com funções amplas no tenant — o mesmo risco descrito nas análises de acesso privilegiado no Azure.
• Revisar as configurações de consentimento e permissões de aplicativos do tenant, para limitar o alcance de um uso indevido de tokens.
• Monitorar a atividade do Exchange, Graph, SharePoint e Teams após sign-ins suspeitos.
• Usar Safe Links, controles antiphishing e denúncia por usuários para reduzir a entrega de iscas e acelerar a triagem.
• Considerar a proteção de tokens onde suportada e apropriada, já que a cobertura depende do cliente, da plataforma e do workload.

Resposta a incidentes após Device Code Phishing

Preservar evidências de sign-in e de workload

Quando um evento de device code phishing é suspeito, a resposta deve se concentrar na contenção de tokens e no escopo do workload, não apenas na redefinição de senha.

Primeiro, capture as evidências de sign-in: usuário, aplicativo, recurso, IP, localização, AuthenticationProtocol, OriginalTransferMethod, resultado do Conditional Access, detalhes de risco, SessionId e UniqueTokenIdentifier. Preserve a mensagem de phishing original, se disponível, com cabeçalhos e URLs, mas não confie apenas na reputação da URL, pois a vítima pode ter sido direcionada a uma página de verificação legítima da Microsoft.

Revogar sessões antes de declarar a contenção

Segundo, revogue as sessões ativas. O revokeSignInSessions do Microsoft Graph invalida os refresh tokens emitidos para os aplicativos do usuário e os cookies de sessão do navegador, redefinindo o timestamp de validade do sign-in. A Microsoft observa um atraso de minutos até a revogação efetiva, e que essa API não revoga sessões de usuários externos, que autenticam via seu tenant de origem. Se a identidade comprometida for um convidado, a revogação deve partir desse tenant de origem — chamá-la no tenant de recurso não contém a sessão. A exposição de contas de convidado deve ser revisada separadamente, onde identidades externas são esquecidas no tenant.

Terceiro, redefina as credenciais apenas quando a investigação justificar: o device code phishing pode comprometer tokens sem roubar diretamente a senha, mas uma redefinição ainda pode ser necessária se houver evidências de roubo de credenciais, regras de caixa de correio, adulteração de métodos de MFA, registro suspeito de dispositivo, ou outros caminhos de comprometimento. O ponto-chave: redefinir a senha sozinha não basta se os refresh tokens e as sessões ativas permanecerem válidos.

Delimitar o escopo da atividade posterior

Quarto, delimite o escopo da atividade posterior. Use identificadores vinculáveis para rastrear a atividade do Exchange Online, Microsoft Graph, SharePoint Online e Teams associada à sessão ou ao token — criação de regras de caixa de correio, leituras e exportações de mensagens, downloads de arquivos, alterações em aplicativos OAuth, associação a grupos e métodos de autenticação, registros de dispositivo e ações administrativas.

Quinto, feche a lacuna de controle: bloqueie o fluxo de device code se for desnecessário ou, se necessário para um fluxo de trabalho restrito, restrinja-o a usuários nomeados, aplicativos conhecidos, locais conhecidos e recursos documentados. Em seguida, crie alertas para o fluxo fora desse padrão aprovado.

Validação após o hardening

Validar a prevenção

A validação deve comprovar tanto a prevenção quanto a visibilidade.

Para a prevenção, confirme que a política de Conditional Access de fluxos de autenticação está habilitada e se aplica aos usuários e recursos pretendidos. Teste com uma conta não privilegiada em laboratório controlado antes de uma implantação ampla. Um fluxo de device code bloqueado deve aparecer nos logs de sign-in com a decisão relevante do Conditional Access. Mantenha as contas de acesso de emergência excluídas, mas revise essa lista regularmente.

Para a compatibilidade, verifique o registro legítimo de dispositivos e ferramentas legadas: se o Device Registration Service usa o fluxo de device code, valide a exclusão documentada e confirme que só o recurso pretendido está excluído. Não crie exclusões amplas que recriem a exposição original.

Validar o monitoramento e a resposta

Para a detecção, confirme que os sign-ins por device code são visíveis no portal do Entra e no Log Analytics, e que AuthenticationProtocol, OriginalTransferMethod, aplicativo, recurso, IP, detalhes do dispositivo, campos de risco, SessionId e UniqueTokenIdentifier estão disponíveis para os analistas. Confirme que conseguem migrar de um sign-in para os dados de auditoria do Exchange, Graph, SharePoint e Teams, onde a configuração de licenciamento e logging permitir.

Para a resposta, execute um exercício tabletop: a partir de um sign-in deviceCode suspeito, exija que o analista identifique o usuário, o aplicativo, o recurso, o session ID, o identificador de token, a atividade de workload subsequente, o caminho de revogação de sessão e a evidência final de contenção. Essa é a diferença entre ter um controle e saber operá-lo durante um incidente de identidade.

Como a EtcSec detecta exposição relacionada

A EtcSec deve tratar o device code phishing como um caminho de ataque de identidade e um problema de postura, não apenas de segurança de e-mail. Os achados de maior valor são as condições que permitem que um evento de engenharia social baseado em tokens se transforme em comprometimento do tenant.

As verificações de exposição relevantes incluem: políticas de Conditional Access que não restringem o fluxo de device code, políticas de risco ausentes ou fracas, usuários privilegiados fora de um isolamento administrativo robusto, funções administrativas permanentes excessivas, contas de convidado sem controles de acesso robustos, e registros de aplicativo com permissões excessivas. Essas áreas se conectam diretamente ao raio de impacto de um device code phishing bem-sucedido.

Para as equipes técnicas, o resultado útil não é um alerta genérico de phishing, mas uma lista curta de identidades e políticas que exigem ação: quem pode usar o fluxo de device code, quais usuários estão isentos, se os sign-ins arriscados são bloqueados ou só registrados em log, quais contas privilegiadas poderiam autorizar sessões a partir de contextos de menor confiança, e quais aplicativos ou permissões delegadas tornariam uma sessão roubada mais danosa. Essa lente de postura integra um trabalho mais amplo de fortalecimento do tenant Azure, não apenas o ajuste de alertas do SOC.

Controles relacionados

O device code phishing é eficaz porque ocupa a lacuna entre o design legítimo de autenticação e a intenção do usuário. A correção duradoura não é um slogan sobre MFA, mas uma postura de tenant em que os fluxos de autenticação arriscados são restringidos, os sign-ins suspeitos por device code são visíveis, a atividade de tokens pode ser rastreada, e o acesso privilegiado não depende de os usuários tomarem decisões perfeitas sob pressão social.

Referências principais

• RFC 8628: OAuth 2.0 Device Authorization Grant
• Plataforma de identidade da Microsoft e o fluxo de concessão de autorização de dispositivo do OAuth 2.0
• Fluxos de autenticação como condição no Conditional Access
• Bloquear fluxos de autenticação com uma política de Conditional Access
• Como configurar controles de concessão no Microsoft Entra
• Protegendo tokens no Microsoft Entra ID
• Referência do Azure Monitor Logs: SigninLogs
• Rastrear e investigar atividades de identidade com identificadores vinculáveis
• Microsoft Graph: revokeSignInSessions
• Microsoft Security Blog: Storm-2372 conduz campanha de device code phishing
• Microsoft Security Blog: Por dentro de uma campanha de device code phishing com uso de IA
• MITRE ATT&CK T1566.002 Spearphishing Link
• MITRE ATT&CK T1550.001 Application Access Token