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

Device code phishing abusa de um OAuth Device Authorization Flow legítimo para fazer uma 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 por dispositivo da Microsoft, concluir a autenticação normal, satisfazer MFA e ainda assim permitir que o client controlado pelo atacante receba tokens.

Essa distinção é importante. Device code phishing não é password spraying, não é OAuth consent phishing, não é MFA fatigue e não é uma página genérica de roubo de credenciais. É um caminho de ataque centrado em tokens contra um fluxo de autenticação válido, criado para dispositivos com entrada limitada. Defensores precisam avaliá-lo por meio de Conditional Access, logs de sign-in, investigação de tokens e atividade pós-autenticação.

Equipes que já revisam MFA fatigue, password spraying, os limites de MFA sozinho ou uma auditoria de segurança do Microsoft Entra ID devem tratar device code phishing separadamente. A interação inicial do usuário e a sessão resultante não se parecem com uma página clássica de phishing de senha.

O que é Device Code Phishing?

Device code phishing é uma técnica de engenharia social que abusa do OAuth 2.0 Device Authorization Grant. O atacante inicia um device code flow a partir de um client que controla, recebe um user code e uma verification URI, e convence o usuário alvo a inserir esse código em um navegador. Se a vítima completa a autenticação, o client do atacante pode receber tokens para o recurso e os scopes solicitados.

O fluxo legítimo existe para dispositivos que não conseguem exibir facilmente um navegador completo ou receber entrada rica. A documentação Microsoft cita cenários como smart TV, dispositivo IoT ou impressora. O dispositivo exibe um código, o usuário entra por outro dispositivo e o client com entrada limitada consulta o token endpoint até a autorização ser concluída ou expirar.

Device code phishing inverte esse desenho. O dispositivo solicitando autorização não é uma TV de sala ou impressora corporativa na frente do usuário. É uma sessão client controlada pelo atacante. A vítima insere o código em uma página legítima da Microsoft, tornando a experiência mais difícil de distinguir de um login normal.

Por isso a expressão “bypass de MFA” precisa ser precisa. Em muitos casos, MFA não é quebrado criptograficamente. O usuário pode realmente concluir MFA durante o login Microsoft. O problema é que ele autoriza a sessão device-code do atacante. MFA bem-sucedido não prova que a sessão resultante pertence a um dispositivo, local ou workflow confiável.

Como funciona OAuth Device Code Flow

O OAuth Device Authorization Grant é definido na RFC 8628. O client solicita autorização de dispositivo ao authorization server e recebe valores como device_code, user_code, verification_uri, expiração e intervalo de polling. O usuário visita a verification URI e insere o user code. Enquanto isso, o client consulta o token endpoint com o device_code.

A Microsoft identity platform implementa esse padrão por meio de device code flow. Uma resposta de token bem-sucedida pode incluir access token, ID token quando openid é solicitado, e refresh token quando o scope original incluiu offline_access. Em um cenário de phishing, esse material de token é o objetivo. O atacante não precisa conhecer a senha se a vítima conclui o fluxo de autorização.

A RFC 8628 discute remote phishing explicitamente. Ela explica que o fluxo pode ser iniciado em um dispositivo sob posse do atacante e que o atacante pode enviar uma mensagem instruindo a vítima a visitar a verification URL e inserir o user code. A RFC recomenda que o authorization server informe o usuário de que ele está autorizando um dispositivo e confirme que esse dispositivo está em sua posse.

Diferenças em relação a ataques semelhantes

Device code phishing fica próximo de outros ataques de identidade, mas o mecanismo é diferente.

Essas diferenças mudam a remediação. Um tenant pode ter bons controles de senha e ainda estar exposto se device code flow for permitido amplamente. Um tenant pode exigir MFA e mesmo assim ser comprometido se usuários autorizam sessões que não controlam. Bloquear device code flow também não substitui corrigir riscos de Conditional Access ou políticas de Identity Protection.

Por que funciona contra Entra ID

O ataque funciona porque a vítima não envia a senha para um domínio obviamente atacante. Ela pode ser enviada para uma página de verificação hospedada pela Microsoft e ver prompts familiares de autenticação. Treinamento que foca apenas em domínios falsos ou páginas de senha suspeitas não cobre bem esse padrão.

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

A técnica é relevante para Entra ID e Microsoft 365 porque os tokens resultantes podem ser usados contra recursos cloud como Exchange Online, Microsoft Graph, SharePoint Online ou Teams, dependendo da app, recurso e scopes. Isso não significa que todo sign-in device code seja malicioso. Significa que defensores precisam saber se esse fluxo é usado legitimamente no tenant, por quais apps, de quais locais e sob quais decisões de Conditional Access.

Um erro comum é tratar MFA bem-sucedido como prova final de legitimidade. Em device code phishing, o evento MFA pode ser real. A pergunta é se o usuário queria autorizar o client que recebeu o token. A revisão de sign-in deve incluir protocolo de autenticação, aplicação, recurso, IP, detalhes do dispositivo, status de Conditional Access, riscos, identificadores de sessão e atividade workload posterior.

Cadeia de ataque

Uma cadeia típica:

1. O atacante inicia uma solicitação device authorization a partir de infraestrutura ou tooling controlado.
2. A plataforma de identidade retorna user code, verification URI, expiração e intervalo de polling.
3. O atacante entrega o código por email, chat, convite colaborativo, documento-isca ou outro canal social.
4. A vítima visita a página de verificação, insere o código, faz login e completa as etapas de autenticação.
5. O client do atacante consulta o token endpoint e recebe tokens após a autorização.
6. O atacante usa o acesso para ler email, consultar Microsoft Graph, enumerar dados do tenant, criar regras de mailbox, acessar arquivos ou executar ações permitidas pelo token e privilégios da conta.
7. O defensor pode ver um sign-in device code bem-sucedido, seguido de uso não interativo de token e atividade workload.

A cadeia não deve ser reduzida a um indicador único. deviceCode no protocolo de autenticação é importante, mas apenas indica o fluxo usado. Não prova intenção maliciosa sozinho. A investigação fica mais forte quando esse evento é correlacionado com local incomum, app inesperada, detalhes de risco, acesso anômalo a recursos, criação de regra de email, atividade Graph ou um usuário que normalmente não usa device code flow.

Detection

Criar baseline de uso legítimo

A detecção começa com baseline do que é legítimo. Muitas organizações têm pouco ou nenhum uso real de device code flow. Outras usam para ferramentas legacy, dispositivos de sala, workflows de desenvolvedor ou registro de dispositivos. A primeira pergunta é se o fluxo era esperado.

Nos sign-in logs do Microsoft Entra exportados para Log Analytics, a tabela SigninLogs inclui AuthenticationProtocol. A Microsoft documenta deviceCode como valor possível. Outros campos úteis incluem OriginalTransferMethod, AppDisplayName, ResourceDisplayName, IPAddress, DeviceDetail, UserAgent, ConditionalAccessStatus, RiskLevelDuringSignIn, RiskEventTypes_V2, SessionId e UniqueTokenIdentifier.

Procurar autenticação deviceCode

Uma query básica inventaria usos bem-sucedidos e falhos:

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 como ponto de partida, não como detecção completa. Revise se aplicação e recurso fazem sentido para o papel do usuário. Um desenvolvedor autenticando uma CLI conhecida de uma rede conhecida é diferente de um usuário financeiro autorizando device code flow de outro país e gerando atividade Graph ou Exchange.

Para uma detecção mais forte, compare uso recente com 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 por contexto

Priorize eventos com essas características:

• primeiro device code flow observado para o usuário ou departamento
• app ou recurso incomum para o papel do usuário
• sign-in de IP, ASN, país ou rede não associada ao usuário
• RiskEventTypes_V2 relacionados a IP anônimo ou threat intelligence
• device code flow bem-sucedido seguido por uso não interativo de tokens de infraestrutura inesperada
• novas regras de mailbox, acesso suspeito a email, atividade Graph incomum, acesso SharePoint ou Teams após o sign-in
• registro ou join de dispositivo próximo no tempo e sem relação com onboarding normal

Identificadores correlacionáveis do Microsoft Entra tornam a fase pós-autenticação mais acionável. Comece com SessionId ou UniqueTokenIdentifier e correlacione com logs do Exchange Online, Microsoft Graph, SharePoint Online ou Teams. A Microsoft documenta esse modelo para rastrear atividades feitas por uma sessão ou token específico.

Microsoft Defender e Entra ID Protection podem adicionar sinais de maior confiança, como IP anônimo, Microsoft Entra threat intelligence, anomalous token e suspicious API traffic. Use esses sinais para enriquecimento e priorização, não como substituto para entender se device code flow deveria ter ocorrido.

Remediation e hardening

Bloquear ou restringir device code flow

O controle mais direto é restringir ou bloquear device code flow com Conditional Access. A Microsoft recomenda chegar o mais perto possível de um bloqueio unilateral, auditar primeiro o uso existente e permitir o fluxo apenas para casos documentados e protegidos. Para organizações que não usam esse fluxo, a Microsoft fornece um padrão de Conditional Access usando a condição authentication flows, selecionando device code flow e bloqueando acesso.

Caminho prático:

1. Inventariar uso atual de device code flow nos sign-in logs Entra.
2. Identificar usuários, apps, recursos, locais e dependências legítimas.
3. Criar política Conditional Access em report-only para device code flow.
4. Excluir contas emergency access e casos de uso documentados.
5. Revisar impacto e logs.
6. Mover a política para enabled quando o impacto for entendido.
7. Monitorar tentativas bloqueadas e exclusões inesperadas.

Verificar compatibilidade antes do enforcement

Há uma ressalva importante. A Microsoft indica que se a organização usa device code flow contra Device Registration Service e uma política authentication flows mira todos os recursos, talvez seja necessário excluir Device Registration Service. A Microsoft documenta o client ID e como filtrar sign-in logs por recurso e fluxo. Não bloqueie todos os recursos sem verificar dependências de registro de dispositivos.

Grant controls de Conditional Access também exigem precisão. A Microsoft documenta que quando o device-code OAuth flow é usado, grant controls que exigem estado de dispositivo gerenciado não são suportados da mesma forma, porque o dispositivo que autentica não consegue fornecer seu estado ao dispositivo que fornece o código. Um modelo baseado apenas em compliant device ou hybrid-joined device pode não se comportar como esperado. Use a condição authentication flows para controlar o flow em si.

Reduzir o blast radius

Controles complementares:

• exigir autenticação phishing-resistant para papéis privilegiados onde suportado, sem assumir que bloqueia todo cenário device-code
• usar Conditional Access baseado em risco e Identity Protection para desafiar ou bloquear sessões arriscadas
• reduzir exposição privilegiada e papéis permanentes, como em acesso privilegiado Azure
• revisar app consent e permissões para reduzir o impacto de abuso de token
• monitorar Exchange, Graph, SharePoint e Teams após sign-ins suspeitos
• usar Safe Links, antiphishing e workflow de reporte de usuários para reduzir entrega de iscas e tempo de triagem
• avaliar token protection onde client, plataforma e workload são suportados

Resposta a incidente

Preservar evidências de sign-in e workload

Quando houver suspeita, a resposta deve focar contenção de tokens e escopo de workload, não apenas reset de senha.

Capture usuário, aplicação, recurso, IP, local, AuthenticationProtocol, OriginalTransferMethod, resultado de Conditional Access, detalhes de risco, SessionId e UniqueTokenIdentifier. Preserve a mensagem de phishing original com headers e URLs, mas não dependa apenas de reputação de URL: a vítima pode ter usado uma página legítima da Microsoft.

Revogar sessões

Revogue sessões ativas. Microsoft Graph revokeSignInSessions invalida refresh tokens emitidos para aplicações de um usuário e cookies de sessão do navegador ao redefinir o timestamp de validade de sessão. A Microsoft observa possível atraso de alguns minutos e que usuários externos fazem login pelo home tenant. Se a identidade comprometida for convidada, revise também a exposição de contas de convidado Azure.

Resete credenciais apenas se a investigação justificar. Device code phishing pode comprometer tokens sem roubar diretamente a senha. Reset pode ser necessário se houver credential theft, regras de mailbox, alteração de método MFA, registro suspeito de dispositivo ou outros caminhos. O ponto principal: reset de senha sozinho não basta se refresh tokens e sessões ativas permanecem válidos.

Delimitar atividade posterior

Use identificadores correlacionáveis para rastrear Exchange Online, Microsoft Graph, SharePoint Online e Teams associados à sessão ou token. Procure regras de mailbox, leitura/exportação de mensagens, downloads de arquivos, mudanças em OAuth apps, grupos, métodos de autenticação, registros de dispositivos e ações administrativas.

Feche a lacuna de controle. Se device code flow não era necessário, bloqueie. Se era necessário para um workflow estreito, restrinja a usuários, apps, locais e recursos documentados. Depois crie alertas para uso fora do padrão aprovado.

Validação após hardening

Validar prevenção

Confirme que a política Conditional Access para authentication flows está habilitada e se aplica aos usuários e recursos pretendidos. Teste com uma conta não privilegiada em caminho controlado. Um device code flow bloqueado deve aparecer nos sign-in logs com a decisão Conditional Access correspondente. Contas break-glass devem permanecer excluídas, mas a lista precisa ser revista regularmente.

Para compatibilidade, verifique registro de dispositivos e ferramentas legacy legítimas. Se Device Registration Service usa device code flow, valide a exclusão documentada e confirme que apenas o recurso pretendido está excluído. Evite exceções amplas.

Validar monitoramento e resposta

Para detecção, confirme que sign-ins device code são visíveis no portal Entra e em Log Analytics. Verifique que AuthenticationProtocol, OriginalTransferMethod, app, recurso, IP, detalhes de dispositivo, risco, SessionId e UniqueTokenIdentifier estão disponíveis para analistas. Confirme pivôs para Exchange, Graph, SharePoint e Teams quando licença e logging permitirem.

Para resposta, execute um tabletop. Comece com um sign-in deviceCode suspeito e exija que o analista identifique usuário, app, recurso, session ID, token identifier, atividade workload posterior, caminho de revogação e evidência final de contenção. Essa é a diferença entre ter um controle e operá-lo durante um incidente.

Como EtcSec detecta exposição relacionada

EtcSec deve tratar device code phishing como caminho de ataque de identidade e problema de postura, não apenas como email security. Achados úteis são as condições que transformam um evento de social engineering baseado em tokens em comprometimento do tenant.

Exposições relevantes incluem políticas Conditional Access que não restringem device code flow, políticas de risco ausentes ou fracas, usuários privilegiados fora de isolamento administrativo forte, excesso de papéis admin permanentes, contas convidadas sem controles fortes e app registrations superpermissivas. Para equipes técnicas, a saída útil é concreta: quem pode usar device code flow, quais usuários estão isentos, se sign-ins arriscados são bloqueados ou apenas logados, quais contas privilegiadas poderiam autorizar sessões cloud de contextos menos confiáveis, e quais apps ou delegated permissions tornariam uma sessão roubada mais perigosa.

Controles relacionados

Device code phishing é eficaz porque fica entre o desenho legítimo de autenticação e a intenção real do usuário. A correção duradoura não é um slogan sobre MFA. É uma postura de tenant na qual fluxos arriscados são restringidos, sign-ins device-code suspeitos são visíveis, atividade de token é rastreável e acesso privilegiado não depende de usuários tomando decisões perfeitas sob pressão social.

Referências principais

• RFC 8628: OAuth 2.0 Device Authorization Grant
• Microsoft identity platform and OAuth 2.0 device authorization grant flow
• Authentication flows as a condition in Conditional Access
• Block authentication flows with Conditional Access policy
• How to configure grant controls in Microsoft Entra
• Protecting tokens in Microsoft Entra ID
• Azure Monitor Logs reference: SigninLogs
• Track and investigate identity activities with linkable identifiers
• Microsoft Graph: revokeSignInSessions
• Microsoft Security Blog: Storm-2372 conducts device code phishing campaign
• Microsoft Security Blog: Inside an AI-enabled device code phishing campaign
• MITRE ATT&CK T1566.002 Spearphishing Link
• MITRE ATT&CK T1550.001 Application Access Token