Ataques de código em dispositivos no Azure: da exploração à detecção

TL, DR

O que é: O phishing de código de dispositivo é uma técnica de abuso do OAuth na qual os atacantes iniciam um fluxo legítimo de autenticação de código de dispositivo contra a Microsoft. Entra IDEm seguida, o atacante engana o usuário para que insira o código resultante na página real login.microsoft.com/devicelogin, fornecendo ao invasor um token de acesso válido sem nunca capturar a senha. 

Por que isso é importante: Em menos de um ano, evoluiu de uma estratégia de ataque cibernético estatal (como o ataque STORM-2372, ligado à Rússia e ativo desde agosto de 2024) para um kit de ataque comercial. O kit de ferramentas EvilTokens PhaaS, apresentado pela Microsoft em abril de 2026, automatiza todo o processo de ponta a ponta, burlando o limite de 15 minutos para expiração do código e executando de 10 a 15 campanhas personalizadas a cada 24 horas. 

Por que é difícil de detectar: Não há página de login falsa, domínio com erros de digitação, captura de credenciais ou código malicioso para analisar. A única URL envolvida é login.microsoft.com/devicelogin. A autenticação multifator (MFA) é concluída com sucesso no dispositivo real da vítima, portanto, todos os sinais que um gateway de e-mail, EDR ou produto de proteção de identidade são treinados para detectar retornam sem erros. 

Em que difere do AiTM: Os ataques Adversário no Meio (AiTM) utilizam um proxy para uma página de login falsa, com o objetivo de roubar cookies de sessão. Já o phishing de código de dispositivo ignora completamente o proxy — a vítima se autentica na página real da Microsoft, portanto não há infraestrutura AiTM para detectar, bloquear ou desativar. 

Sinal de detecção do núcleo: Um login bem-sucedido em que o método de autenticação é o código do dispositivo, o recurso acessado é um cliente Microsoft de primeira linha (por exemplo, Azure CLI, Microsoft Office) e o login é realizado a partir de um local anômalo ou por uma entidade que normalmente não se autentica usando códigos de dispositivo. Quase nenhum fluxo de trabalho legítimo do usuário final gera esse padrão; para muitas organizações, cada ocorrência justifica uma investigação. 

Resposta imediata em caso de detecção: Revogue imediatamente o acesso do usuário (consulte Documentação da MicrosoftDesative o usuário comprometido e remova suas atribuições de função. Observe que revogar tokens de atualização não invalida os tokens de acesso já emitidos — eles permanecem válidos até expirarem. Procure por atividades maliciosas originadas da sessão suspeita. A revogação de tokens por si só não é suficiente — o invasor pode já ter estabelecido persistência.

Principais ações políticas: Bloqueie o fluxo de código do dispositivo por meio do Acesso Condicional para qualquer grupo de usuários que não tenha uma necessidade comercial comprovada para isso. As próprias diretrizes da Microsoft agora recomendam essa prática. A maioria dos usuários corporativos — incluindo a maioria dos desenvolvedores — quase nunca se autentica dessa forma de maneira legítima. Quando a autenticação por código do dispositivo for realmente necessária, restrinja-a a locais confiáveis ​​por meio de geolocalização. 

O que as equipes de segurança precisam saber sobre phishing de código de dispositivo

Um grupo de ameaças patrocinado por um Estado-nação (STORM-2372, ligado a interesses estatais russos) vem conduzindo uma campanha de phishing de código de dispositivo desde agosto de 2024, visando agências governamentais, empresas contratadas pela área de defesa, ONGs, organizações de telecomunicações, energia e saúde em todo o mundo. 

Essa não é uma vulnerabilidade que a Microsoft possa corrigir — é uma característica do protocolo de código de dispositivo OAuth 2.0, compatível com todos os principais provedores de identidade. O ataque burla essa proteção. MFA (a vítima completa o processo voluntariamente), não deixa nenhuma infraestrutura suspeita para ferramentas de segurança sinalizarem (o único URL é microsoft.com) e os tokens resultantes resistem a redefinições de senha. Gateways de e-mail convencionais, CASBs e scanners de URL classificam o link de ataque como seguro porque ele is seguro—aponta para a página de login da Microsoft. 

Após a invasão, observou-se que os atacantes registram dispositivos persistentes em até 10 minutos, mapeiam estruturas organizacionais por meio do Microsoft Graph, filtram alvos de alto valor (funções financeiras, executivas e administrativas), criam regras ocultas na caixa de entrada e extraem detalhes de transferências bancárias e correspondências de executivos — a matéria-prima para o comprometimento de e-mails corporativos e fraudes financeiras. 

A ação organizacional imediata: bloquear o fluxo de autenticação por código do dispositivo via Acesso Condicional para todos os usuários que não o exigem explicitamente, garantindo que seu resposta a incidentes O playbook inclui a revogação de tokens OAuth (e não apenas a redefinição de senhas) e a implementação da vinculação de tokens para contas de alto valor. Consulte as Recomendações Estratégicas abaixo para obter a estrutura de decisão completa.

E se o URL de phishing for microsoft.com?

O phishing de código de dispositivo é uma técnica de roubo de tokens que explora a implementação do fluxo de código de dispositivo OAuth da Microsoft. Ao contrário da maioria das campanhas de phishing reais, os atacantes direcionam a vítima para um URL legítimo da Microsoft — não um domínio falso, um proxy reverso ou um domínio com erros de digitação. A vítima acessa a página de login real da Microsoft, completa a autenticação multifator (MFA) legítima e vê uma tela de sucesso normal. Mas os tokens de autenticação — um método de autenticação adicional que concede privilégios à vítima — são entregues silenciosamente ao atacante em uma máquina completamente diferente. Sem roubo de credenciais, sem sequestro de sessão, sem infraestrutura do atacante para detectar ou desativar. Apenas um fluxo OAuth legítimo fazendo exatamente o que foi projetado para fazer, para a parte errada. 

Está sendo explorado em larga escala hoje em dia — e embora a falha subjacente esteja no próprio padrão OAuth, Entra IDA implementação do 's é o que torna trivial transformá-lo em arma. A Microsoft atribuiu um campanha em andamento para STORM-2372, um agente de ameaça avaliado com confiança moderada por estar alinhado aos interesses do Estado russo. A operação tem como alvo agências governamentais, empresas contratadas pela área de defesa, ONGs, provedores de telecomunicações, empresas de energia e organizações de saúde em vários continentes desde pelo menos agosto de 2024. Em abril de 2026, a Microsoft documentou uma escalada significativa: O surgimento do EvilTokens, um conjunto de ferramentas de phishing como serviço (PhaaS) com inteligência artificial que automatiza o abuso de códigos de dispositivos de ponta a ponta.—gerando códigos ao vivo sob demanda para burlar o prazo de validade de 15 minutos, criando iscas hiperpersonalizadas usando IA generativa e executando de 10 a 15 campanhas distintas a cada 24 horas. A técnica passou de tática secreta de Estado-nação a kit de ataque comum em menos de um ano.  

Neste post do blog, vamos detalhar exatamente como esse ataque funciona no nível do protocolo e realizar uma simulação prática com dados reais. Entra ID As capturas de logs fornecem consultas de busca KQL que você pode executar em seu próprio ambiente hoje mesmo e expandem a lógica de detecção derivada dos logs gerados pelo ataque. 

Qual é o fluxo de código do dispositivo?

A concessão de autorização de dispositivo OAuth 2.0, definida na RFC 8628 e publicada em agosto de 2019, é um fluxo de autenticação projetado para dispositivos que não possuem navegador ou têm recursos de entrada limitados — como smart TVs, consoles de jogos, sensores de IoT, sinalização digital, equipamentos de salas de conferência e ferramentas de linha de comando como a CLI do Azure ou o AWS CloudShell. Em vez de fazer login diretamente no dispositivo, o usuário visualiza um código alfanumérico curto e um URL; ele abre esse URL em um dispositivo separado (normalmente um telefone ou laptop), insere o código e conclui a autenticação ali — incluindo qualquer solicitação de MFA. Enquanto isso, o dispositivo original consulta o servidor de autorização em segundo plano e recebe um token de acesso assim que o usuário aprova. 

O fluxo é amplamente suportado: Microsoft Entra IDO Google, o GitHub, o Okta e a maioria dos principais provedores de identidade o implementam, e ele é o método de login padrão para a CLI do Azure (`az login`). Embora não seja o fluxo OAuth mais comum em aplicações web do dia a dia, é o mecanismo padrão para ambientes sem interface gráfica e com restrições de entrada, sendo amplamente utilizado em ferramentas corporativas, pipelines de DevOps e plataformas de streaming para o consumidor. 

Os riscos de projeto são inerentes à norma, mas Entra IDA implementação do Microsoft Access amplifica esses problemas — e é por isso que todos os kits de phishing disponíveis no mercado têm como alvo a Microsoft. A própria Microsoft agora recomenda bloquear o fluxo por meio do Acesso Condicional sempre que ele não for explicitamente necessário. 

A falha crítica de projeto: O device_code é o único elo entre o dispositivo que está realizando a consulta e o usuário que está se autenticando. A Microsoft não verifica se o dispositivo que está realizando a consulta é aquele que o usuário pretendia autorizar. Ela não verifica a identidade do dispositivo, a localização na rede ou o nível de confiança. Quem tiver o código e estiver consultando-o recebe os tokens. 

Análise de ataque

A praticidade que torna o fluxo de código do dispositivo útil é exatamente o que o torna explorável. Como o protocolo nunca vincula o dispositivo de coleta de dados diretamente ao usuário que está se autenticando, um invasor que obtém um código de dispositivo válido pode coletar silenciosamente os tokens de acesso e atualização resultantes no momento em que a vítima conclui o login. Sem infraestrutura de phishing, sem interceptação de credenciais, sem burla de MFA — apenas uma página de login legítima da Microsoft fazendo exatamente o que foi projetada para fazer, em nome da parte errada. 

Como os atacantes transformam esse fluxo em arma

O endpoint de código de dispositivo da Microsoft é aberto por design — sem segredo do cliente, sem registro de dispositivo, sem comprovação de posse.

Um atacante envia uma única requisição POST não autenticada usando um ID de cliente Microsoft conhecido (o Azure CLI, o Microsoft Office ou qualquer outro cliente público de primeira parte — esses IDs são públicos, facilmente enumeráveis ​​e impossíveis de serem revogados pela Microsoft sem comprometer ferramentas legítimas que dependem deles) e recebe instantaneamente um código de dispositivo válido. Esses IDs de cliente de primeira parte são um presente para o atacante: confiáveis ​​por padrão, com consentimento prévio para amplos escopos e permanentemente disponíveis. O ID do locatário pode ser facilmente obtido assim que o atacante identifica o domínio alvo da vítima. 

curl -X POST https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/devicecode \ 
  -d "client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46&scope=https://management.azure.com/.default" 

O atacante envolve o URL de verificação e o código do usuário em uma isca convincente — um convite para reunião do Teams, uma notificação de compartilhamento de documentos, um alerta de segurança de TI — e a envia por e-mail, Teams, WhatsApp, Signal ou outros meios. O ataque STORM-2372 foi especificamente observado falsificando notificações de reuniões do Teams e convites para grupos do WhatsApp. Enquanto a vítima lê o e-mail, o script do atacante já está em execução. No momento em que a vítima conclui a autenticação, o loop de verificação recebe o par de tokens completo. 

Por que os controles de segurança existentes falham?

O que torna o phishing de código de dispositivo particularmente perigoso é o número de defesas convencionais que ele neutraliza simultaneamente: 

No que diz respeito à plataforma de identidade da Microsoft, este foi um login completamente legítimo. 

• A autenticação multifator (MFA) é cooptada, não ignorada. A vítima completa a MFA normalmente. O token resultante contém o valor mfaAuthenticated=true.
• Não há infraestrutura de ataque para detectar. A única URL na cadeia de ataque é microsoft.com — ela tem reputação perfeita em todos os feeds de inteligência de ameaças e um certificado EV válido. Seu gateway de e-mail, CASB, sandbox de URL e reescrita segura de links do proxy a inspecionam e retornam: segura.
• Os tokens de atualização sobrevivem a redefinições de senha. Ao contrário dos cookies de sessão (que os ataques AiTM roubam), os tokens de atualização do OAuth são projetados para acesso de longo prazo e entre dispositivos. Eles podem ser trocados silenciosamente por novos tokens de acesso sem interação do usuário ou novas solicitações de MFA. Redefinir a senha da vítima não os revoga — o atacante mantém o acesso, a menos que os tokens sejam explicitamente revogados.
• A presença de evidências forenses é mínima. Os registros de login mostram um login bem-sucedido com Nível de Risco = Nenhum e MFA = Sucesso. Não há múltiplas tentativas de login malsucedidas, nenhuma alteração de credenciais ou criação de objetos suspeitos. O único sinal potencial é uma atualização de token não interativa de um IP inesperado — e somente se você estiver monitorando especificamente para isso. 

Importante: Este não é um ataque do tipo "adversário no meio" (AiTM). Ferramentas AiTM como o EvilProxy interceptam sessões por meio de um proxy reverso, capturando cookies após a autenticação multifator (MFA). Isso requer infraestrutura controlada pelo atacante — domínios, certificados, servidores ativos — que deixam um rastro forense. O phishing de código de dispositivo requer apenas uma requisição HTTP POST e um e-mail convincente. Os tokens obtidos têm maior duração e escopo mais amplo do que os cookies de sessão, e não há nenhuma infraestrutura do atacante para investigar ou desativar.

Perspectiva do atacante: Fluxo passo a passo

Para demonstrar a cadeia de ataque completa, reproduzimos o ataque em um ambiente de laboratório controlado, utilizando um servidor dedicado à pesquisa (glich.net). A simulação modela um adversário operando como helpdesk@glich.net, visando o usuário roni@glich.net com uma isca de phishing de código de dispositivo disfarçada de [código do dispositivo]. solicitação de verificação de credenciais. 

Fase 1: Geração do código do dispositivo

O atacante envia um POST para Entra IDO endpoint de autorização do dispositivo, que usa o ID público do cliente da CLI do Azure, recebe um código de dispositivo e um código de usuário e começa a consultar o endpoint de token imediatamente. 

Fase 2: Elaboração e entrega da isca de phishing

O atacante inclui o código do dispositivo e a URL login.microsoft.com/devicelogin em um e-mail com tom de urgência — disfarçado de convite para reunião do Teams, solicitação de verificação de credenciais ou alerta de segurança de TI. 

Fase 3: Aprovação do usuário

O usuário recebe o e-mail e concede acesso ao invasor. 

Quando a vítima fornece o código e as credenciais em seu navegador, o loop de polling coleta os tokens. 

Fase 4: Pós-exploração

Com um token de acesso válido e um token de atualização de longa duração em mãos, o invasor autenticou o acesso ao ambiente Microsoft 365 da vítima — e o tempo está se esgotando. Análise de abril de 2026 Um estudo sobre uma campanha de phishing de código de dispositivo habilitada por IA (uma evolução direta da atividade STORM-2372 relatada pela primeira vez em fevereiro de 2025) documentou o roteiro pós-comprometimento que os agentes de ameaças estão executando na prática. A progressão segue um padrão consistente: 

Registro de dispositivo para persistência 

Em alguns casos, em até 10 minutos após a violação inicial, os agentes maliciosos registraram novos dispositivos na conta comprometida para gerar um Token de Atualização Primário (PRT). Um PRT fornece acesso de longo prazo com capacidade de SSO (Single Sign-On) que persiste mesmo após a revogação de tokens individuais, dando ao invasor uma vantagem persistente significativamente mais difícil de detectar e remediar do que apenas um token de atualização roubado. 

Reconhecimento de Gráficos da Microsoft 

Usando os tokens roubados, os invasores consultaram a API do Microsoft Graph para mapear programaticamente as estruturas organizacionais internas, as funções dos usuários e as atribuições de permissão. Esse reconhecimento automatizado permitiu que eles identificassem rapidamente quais contas comprometidas tinham acesso a recursos confidenciais e onde. escalação de privilégios era possível. 

Filtragem de alvos de alto valor 

Em vez de explorar indiscriminadamente todas as contas comprometidas, os agentes maliciosos filtraram o conjunto de vítimas em busca de perfis de alto valor — especificamente, indivíduos em funções financeiras, executivas ou administrativas. Essa abordagem seletiva concentrou a atividade pós-comprometimento mais invasiva em contas com o maior potencial de retorno. 

Regras maliciosas da caixa de entrada para persistência 

Para alvos selecionados, os agentes maliciosos criaram regras de caixa de entrada usando o aplicativo Microsoft Office para redirecionar, ocultar ou excluir e-mails recebidos. Essas regras tinham um duplo propósito: manter o acesso persistente às comunicações por e-mail sem a necessidade de logins repetidos e ocultar evidências da invasão da vítima (por exemplo, excluindo automaticamente alertas de segurança ou notificações de redefinição de senha). 

Exfiltração de e-mails direcionada 

A atividade mais invasiva foi reservada para usuários com autoridade financeira. Os agentes maliciosos realizaram buscas minuciosas em comunicações por e-mail, visando especificamente detalhes de transferências bancárias, faturas pendentes e correspondências de executivos — a matéria-prima para fraudes por e-mail corporativo (BEC) e fraudes financeiras. 

Execução retardada para evitar detecção 

Nem todos os agentes de ameaça agiram imediatamente. Em diversos casos observados, os atacantes esperaram horas após a invasão inicial antes de tomar qualquer ação pós-exploração — uma técnica de evasão deliberada, projetada para separar o evento de autenticação suspeito da atividade maliciosa nos registros, dificultando a correlação temporal para os defensores. Quando a atividade maliciosa começa, o evento de autenticação que a possibilitou já saiu das filas de triagem de curto prazo e das janelas de alerta em tempo real. Os defensores que revisam um login suspeito em T+0 podem não encontrar nenhuma atividade subsequente e fechá-lo como benigno — apenas para o atacante iniciar a exfiltração horas depois, quando o alerta original já não está mais visível para ninguém. Essa lacuna deliberada entre o acesso e a ação é o que torna o phishing de código de dispositivo particularmente resistente à detecção baseada em tempo: a violação e o impacto nunca aparecem na mesma janela de investigação, a menos que os defensores estejam explicitamente correlacionando em períodos de tempo estendidos. 

Perspectiva do defensor: O que devemos procurar nos registros

Para caçadores de ameaças e analistas de SOC — reais Entra ID Capturas de logs mostrando exatamente o que procurar. 

Nós capturamos Entra ID Registros de login gerados por este fluxo. As solicitações de sondagem do atacante — as respostas repetidas de autorização pendente — não são registradas. Somente a emissão bem-sucedida do token gera registros, divididos em duas abas: 

Entrada 1: Interativa (lado do navegador/vítima)

A vítima acessou microsoft.com/devicelogin e aprovou o código. A autenticação multifator (MFA) foi considerada válida graças a uma alegação de sessão anterior — a vítima não encontrou qualquer dificuldade além de clicar em "aprovar". 

Entrada 2: Não interativa (Consulta por cliente/lado do atacante)

Comparação lado a lado

O princípio de detecção é claro: ambas as entradas compartilham um ID de Correlação, mas o agente do usuário e, potencialmente, o endereço IP são diferentes. O registro do navegador mostra o Chrome no Mac; o registro de polling mostra o curl. Em um ataque real, esse par de registros com essas diferenças — especialmente uma divisão geográfica indicativa de possível impossibilidade de deslocamento ou de uma origem suspeita — é o sinal principal para a criação de alertas. 

Enriquecer o IP do lado de coleta de dados com base em feeds de inteligência de ameaças, listas de reputação de IP, valores suspeitos de agentes de usuário (como o exemplo "curl" nos logs) e metadados de ASN fortalece ainda mais a detecção: a infraestrutura do atacante frequentemente se origina de provedores de hospedagem, VPNs comerciais ou ASNs sem presença legítima em sua base de usuários. Um IP de coleta de dados que resolve para um ASN malicioso conhecido ou aparece em uma lista negra é um indicador de alta confiança, mesmo sem uma incompatibilidade de IP entre as pernas.

Detectando phishing de código de dispositivo em seu ambiente.

Para analistas de ameaças: copie e cole consultas KQL para o Azure Monitor, Microsoft Sentinel ou qualquer SIEM compatível com KQL. 

As seguintes consultas KQL podem ser usadas para detectar atividades de phishing de código de dispositivo em seu sistema. Entra ID Registros de entrada. Eles foram projetados para serem copiados e colados facilmente no Azure Monitor, Microsoft Sentinel ou qualquer SIEM compatível com KQL. 

O objetivo é detectar o uso indevido de códigos de dispositivo o mais próximo possível do momento T+0. Cada consulta abaixo visa um sinal diferente: padrões anormais de uso de códigos de dispositivo, incompatibilidades de IP ou agente do usuário entre as etapas interativa e de sondagem, e geração de código em alto volume que pode indicar uma campanha ativa. 

1. Exibir todos os eventos de fluxo de código do dispositivo para análise de correlação.

Esta consulta recupera ambas as partes (interativa e não interativa) do fluxo de código de cada dispositivo. Classifique ou una por CorrelationId para compará-las lado a lado e procurar incompatibilidades de IP ou agente do usuário — o sinal de detecção principal. 

SigninLogs 
| where AuthenticationProtocol == "deviceCode" 
    or OriginalTransferMethod == "deviceCodeFlow" 
| project CorrelationId, UserPrincipalName, IPAddress, UserAgent, 
          IsInteractive, TimeGenerated, AppDisplayName, 
          AuthenticationProtocol 
| order by CorrelationId, TimeGenerated asc

2. Detectar fluxos de código de dispositivo com incompatibilidade de endereço IP entre os segmentos.

Esta consulta combina as entradas interativas e não interativas de cada fluxo de código de dispositivo por CorrelationId e sinaliza fluxos onde os endereços IP diferem — um forte indicador de que o cliente que realiza a consulta não é o mesmo dispositivo ou local que o navegador de autenticação. Para alertas mais precisos, enriqueça o IP de consulta com pesquisas de ASN e feeds de inteligência de ameaças — sinalize fluxos onde o IP de consulta pertence a um provedor de hospedagem, VPN comercial ou a um intervalo de IPs bloqueados, mesmo que os IPs estejam no mesmo país. 

let interactive = SigninLogs 
| where AuthenticationProtocol == "deviceCode" 
    and IsInteractive == true 
| project CorrelationId, UserPrincipalName, BrowserIP = IPAddress, 
          BrowserUA = UserAgent, TimeGenerated; 
let polling = AADNonInteractiveUserSignInLogs 
| join kind=inner interactive on CorrelationId 
| project CorrelationId, PollingIP = IPAddress, PollingUA = UserAgent; 
interactive 
| join kind=inner polling on CorrelationId 
//| where BrowserIP != PollingIP 
| project TimeGenerated, UserPrincipalName, BrowserIP, BrowserUA, 
          PollingIP, PollingUA, CorrelationId 

3. Monitore a geração de código de dispositivo em alto volume a partir de um único aplicativo.

Um atacante que executa uma campanha de phishing de código de dispositivo gera muitos códigos em um curto período. Esta consulta revela aplicativos com um número excepcionalmente alto de fluxos de código de dispositivo entre usuários distintos nas últimas 24 horas. 

SigninLogs 
| where TimeGenerated > ago(24h) 
| where AuthenticationProtocol == "deviceCode" 
    or OriginalTransferMethod == "deviceCodeFlow" 
| summarize DistinctUsers = dcount(UserPrincipalName), 
            FlowCount = count() 
    by AppDisplayName, AppId 
| where DistinctUsers > 3  // adjust threshold to your environment 
| order by DistinctUsers desc

Ajuste os limites e os intervalos de tempo para corresponder à linha de base do seu ambiente. Organizações que utilizam fluxos de código de dispositivo de forma legítima (por exemplo, para a CLI do Azure ou integração de dispositivos IoT) devem estabelecer uma lista de IDs de cliente confiáveis ​​e excluí-los. 

Um par de toras suspeito foi encontrado — e agora?

Nem todo fluxo de código de dispositivo bem-sucedido com uma incompatibilidade de user-agent é malicioso — existem cenários legítimos (por exemplo, um desenvolvedor executando o comando `az login` em um servidor remoto e autenticando-se a partir de seu laptop). Investigue antes de escalar o problema. No entanto, se o par de logs apresentar indícios de abuso — um IP de polling desconhecido, um ASN de provedor de hospedagem, um usuário que não iniciou um fluxo de código de dispositivo — trate-o como um roubo de token confirmado e execute as seguintes etapas imediatamente: 

1. Revogue imediatamente todos os tokens de atualização. 

Revogue imediatamente o acesso do usuário (consulte Documentação da MicrosoftDesative o usuário comprometido e remova suas atribuições de função. Isso invalida todos os tokens de atualização ativos e impede que o invasor obtenha novos tokens de acesso silenciosamente. Faça isso antes de redefinir a senha — a redefinição de senha por si só não revoga os tokens de atualização do OAuth. 

2. Encerrar sessões ativas 

Revogar tokens de atualização não invalida os tokens de acesso já emitidos — eles permanecem válidos até expirarem. Se o seu tenant usa Avaliação Contínua de Acesso (CAE), force uma reavaliação de todas as sessões ativas do usuário para liberar os tokens em cache. Para cargas de trabalho que não usam CAE, revogue as sessões do usuário em Entra ID (Usuários → Revogar sessões) para invalidar quaisquer tokens armazenados em cache nos serviços do Microsoft 365. 

3. Verificar mecanismos de persistência 

Procure por dispositivos recém-registrados, regras de caixa de entrada, consentimentos de aplicativos OAuth e quaisquer outras ações realizadas na mesma sessão. Preste atenção especial aos registros de dispositivos (que geram Tokens de Atualização Primária), regras de caixa de entrada que encaminham, redirecionam ou excluem e-mails e alterações nos métodos de autenticação (por exemplo, um novo número de telefone adicionado para MFA). A revogação do token por si só não é suficiente — o invasor pode já ter estabelecido persistência; remova tudo o que o usuário não reconhecer. 

4. Conter movimento lateral 

Se o usuário comprometido possuir funções privilegiadas (Administrador Global, Administrador do Exchange, etc.) ou tiver acesso a recursos confidenciais, restrinja a conta por meio do Acesso Condicional enquanto a investigação estiver em andamento. Verifique se o invasor usou os tokens roubados para acessar recursos do SharePoint, Teams ou Azure — o Log de Auditoria Unificado e os logs de atividades do Microsoft Graph mostrarão o escopo do acesso. 

5. Preserve as evidências e alerte o SOC (Centro de Operações Especiais). 

Exporte as entradas relevantes do log de login (tanto as interativas quanto as não interativas, vinculadas pelo ID de Correlação), a atividade recente do log de auditoria do usuário e quaisquer regras da caixa de entrada ou registros de dispositivos que você tenha removido. Esses artefatos são essenciais para determinar o raio de impacto e para quaisquer requisitos subsequentes de relatório de incidentes.

Recomendações e melhores práticas

Recomendações estratégicas

Para executivos e líderes de segurança — as decisões políticas que mais importam. 

• Bloqueie o fluxo de autenticação por código de dispositivo para todos os usuários que não o exigem explicitamente. Essa alteração na política de Acesso Condicional elimina completamente a superfície de ataque para a maior parte da sua equipe.
• Atualize seu manual de resposta a incidentes para incluir a revogação do token OAuth como uma etapa obrigatória, juntamente com a redefinição de senha. A redefinição de senha por si só não revoga os tokens de atualização — o invasor mantém o acesso indefinidamente, a menos que os tokens sejam explicitamente revogados.
• Priorize a vinculação de tokens (proteção por token) para contas de alto valor — executivos, finanças e administradores. Essa funcionalidade está disponível para Windows (em versão prévia para iOS/macOS) e representa a defesa em profundidade mais robusta contra a replicação de tokens a partir de fluxos de código provenientes de dispositivos roubados.
• Analise quais aplicativos em seu locatário têm o fluxo de código do dispositivo ativado. Muitas organizações possuem aplicativos OAuth com permissões de código do dispositivo que nunca foram configuradas intencionalmente. Reduzir a superfície de ataque é uma solução rápida e eficaz.
• Garanta que sua equipe de operações de segurança esteja monitorando os registros de login não interativos, e não apenas os interativos. A atividade de atualização de token do invasor aparece somente nos registros não interativos, que muitos SOCs não revisam rotineiramente.

Recomendações táticas

Para engenheiros e administradores de segurança — orientações de nível de implementação: 

Restringir ou bloquear o fluxo de código do dispositivo por meio de Acesso Condicional.

Se sua organização não depende da autenticação por código de dispositivo para casos de uso legítimos (ferramentas de linha de comando, dispositivos IoT, equipamentos de salas de conferência), bloqueie o fluxo completamente usando políticas de Acesso Condicional. Entra IDCrie uma política que tenha como alvo Todos os usuários → Recursos de destino → Todos os recursos (anteriormente aplicativos em nuvem) → Condições → Fluxos de autenticação → Fluxo de código do dispositivo = Bloquear. Se algumas equipes precisarem, restrinja a política de permissão a usuários ou grupos específicos e apenas a plataformas de dispositivos conhecidas, mantendo-se dentro do escopo da política. princípio do menor privilégio. 

Defina as medidas relevantes para mitigar o roubo de tokens.

A simples redefinição de senha não revoga os tokens de atualização do OAuth. As etapas de resposta para uma conta comprometida devem incluir: (1) revogar o acesso do usuário e desativar a conta, (2) reavaliar todas as sessões ativas de Avaliação Contínua de Acesso (CAE) e (3) revisar os consentimentos do aplicativo OAuth do usuário e remover quaisquer entidades de serviço desconhecidas. Sem essas etapas, o invasor mantém o acesso por meio do token de atualização até que ele expire — até 90 dias para um token padrão. Entra ID configuração. 

Monitorar registros de login não interativos em busca de anomalias geográficas.

A aba de login não interativa em Entra ID É aqui que os eventos de atualização de token aparecem. Um invasor que usa um token de atualização roubado irá gerar logins não interativos a partir de um endereço IP e agente de usuário que provavelmente diferem da linha de base do usuário. Configure alertas para logins não interativos em que o IP de origem esteja em um país ou ASN diferente do último login interativo do usuário. Vá além, cruzando o IP de origem com feeds de inteligência de ameaças e bancos de dados de reputação de IP — atividades de polling ou atualização de IPs em listas negras, provedores de hospedagem conhecidos por sua segurança ou redes proxy residenciais são indicadores de alta confiabilidade, independentemente da localização geográfica. Essa combinação de fatores geográficos detecção de anomalia E a filtragem baseada em reputação é o sinal mais precoce e confiável para o roubo de tokens de código de dispositivo. 

Como se defender contra phishing de código de dispositivo

O phishing de código de dispositivo representa uma mudança fundamental no cenário de ameaças à identidade — um cenário em que o atacante não precisa de infraestrutura, a autenticação multifator (MFA) é cooptada em vez de contornada e o acesso persiste mesmo após a redefinição de senha. O ataque funciona justamente por ser legítimo: uma página de login real da Microsoft, uma solicitação real de MFA, uma tela de sucesso real. Os tokens simplesmente são enviados para a máquina errada. 

A resposta estratégica é simples: bloqueie o fluxo de código do dispositivo onde não for necessário, assegure-se de que seus manuais de resposta a incidentes incluam a revogação de tokens e monitore os logs de login não interativos que a maioria das organizações ignora. O aprofundamento técnico deste artigo — da análise de protocolo à captura de logs e consultas KQL — fornece à sua equipe de segurança tudo o que ela precisa para detectar essa atividade hoje mesmo. 

À medida que os ataques de identidade baseados em OAuth continuam a evoluir, a lacuna entre o que as ferramentas de perímetro tradicionais conseguem ver e o que acontece na camada de identidade só tende a aumentar. Organizações que investem em segurança de protocolo estão mais propensas a se proteger contra ataques de segurança em nível de protocolo. detecção e resposta—e não apenas o monitoramento de endpoints e de redes—serão eles que detectarão a próxima evolução dessa técnica antes que ela atinja a fase de pós-exploração. 

SilverfortA equipe de pesquisa da [nome da empresa] continua acompanhando a evolução das técnicas de ataque baseadas em OAuth.