Preâmbulo

Membros da equipe de Engenharia de Detecção e Pesquisa de Ameaças (TRADE) da Elastic recentemente voltaram sua atenção para uma classe emergente de ameaças que têm como alvo fluxos de trabalho OAuth no Microsoft Entra ID (anteriormente Azure AD). Esta pesquisa foi inspirada no blog recente da Volexity, Phishing for Codes: Russian Threat Actors Target Microsoft 365 OAuth Workflows, que atribui uma sofisticada campanha de phishing OAuth contra ONGs ao agente de ameaça designado UTA0352.

A investigação da Volexity apresenta evidências forenses convincentes de como invasores abusaram de aplicativos confiáveis da Microsoft para contornar as defesas tradicionais. Usando fluxos OAuth legítimos e a ferramenta de código aberto ROADtools, os agentes criaram URLs de autenticação personalizadas da Microsoft, coletaram tokens de segurança e os utilizaram para representar usuários, elevar privilégios e exfiltrar dados via Microsoft Graph — incluindo o download de e-mails do Outlook e o acesso a sites do SharePoint.

Embora o relatório documente detalhadamente o porquê do ataque, nossa equipe na Elastic se concentrou em entender o como. Emulamos a cadeia de ataque em um ambiente controlado para explorar a mecânica do abuso de tokens, registro de dispositivos e enriquecimento de tokens em primeira mão. Essa experimentação prática gerou insights mais profundos sobre o funcionamento interno da implementação do OAuth da Microsoft, o uso prático do ROADtools, mitigações recomendadas e, mais importante, estratégias de detecção eficazes para identificar e responder a atividades semelhantes.

OAuth no ID de entrada da Microsoft

O Microsoft Entra ID implementa o OAuth 2.0 para permitir acesso delegado aos serviços da Microsoft 365 , como Outlook, SharePoint e Graph API. Embora a especificação OAuth seja padronizada (RFC6749), o Entra ID introduz comportamentos e tipos de token exclusivos que influenciam como o acesso delegado funciona e como os adversários os exploram.

No acesso delegado, um aplicativo é autorizado a agir em nome de um usuário conectado, limitado pelos escopos (permissões) solicitados pelo aplicativo e consentidos pelo usuário ou administrador. Esse modelo é comum em ambientes corporativos onde os aplicativos recuperam e-mails, arquivos ou dados de diretório de um usuário sem solicitar credenciais todas as vezes.

Um fluxo típico de autorização delegada inclui:

Solicitação de autorização (concessão de código de autorização OAuth 2.0): o aplicativo solicita acesso a um recurso (por exemplo, Graph) com escopos específicos (por exemplo, Mail.Read, offline_access). Eles são adicionados como parâmetros ao URI.

• client_id: O ID do aplicativo (por exemplo, VSCode)
• Response_type: determina o tipo de concessão do fluxo de trabalho OAuth (por exemplo código do dispositivo, código de autenticação)
• Escopo: Permissões solicitadas para o recurso de destino (por exemplo Mail.Read, acesso_offline)
• Redirect_uri: Para onde enviar nossos códigos de autorização
• Estado: proteção CSRF
• Dica de login: preenche previamente o nome de usuário

Autenticação do usuário (OpenID Connect): o Entra ID autentica o usuário por meio de política (senha, MFA, confiança do dispositivo).

• Autenticação de fator único (SFA)
• Autenticação multifator (MFA)
• Confiança do dispositivo (junção híbrida, conformidade com o Intune)
• Políticas de Acesso Condicional (CAP)
• Login único (SSO)

Consentimento: o consentimento determina se o aplicativo pode receber um código de autorização e quais escopos são permitidos.

• Escopos consentidos pelo usuário (por exemplo Mail.Read, acesso_offline)
• Escopos necessários para consentimento do administrador (por exemplo Directory.ReadWrite) requer aprovação elevada.

Emissão de token: O aplicativo recebe um código de autorização e o resgata por:

• Token de acesso – token de curta duração usado para chamar APIs como Graph.
• Token de atualização (RT) – token de longa duração para obter novos tokens de acesso silenciosamente.
• Token de identidade - descreve o usuário autenticado; presente em fluxos OpenID.
• (Opcional) Token de atualização primário: se o usuário estiver em um dispositivo registrado ou ingressado em um domínio, um Token de atualização primário (PRT) poderá habilitar SSO silencioso e fluxos de token adicionais sem interação do usuário.
• Declarações de token: Declarações são pares chave-valor incorporados em tokens JWT que descrevem o usuário, o aplicativo, o dispositivo, os escopos e o contexto da autenticação.

O que define uma URL de phishing MSFT OAuth

Antes de nos aprofundarmos nas principais descobertas do relatório da Volexity que ajudam a moldar nossa estratégia de detecção, é importante detalhar o que exatamente define uma URL de phishing do Microsoft OAuth.

Conforme descrito anteriormente, o Microsoft Entra ID depende dessas URLs para determinar qual aplicativo (cliente) está solicitando acesso, em nome de qual usuário principal, a qual recurso e com quais permissões. Grande parte desse contexto está incorporado diretamente nos parâmetros de consulta da solicitação de autorização do OAuth, tornando-os uma fonte crítica de metadados para adversários e defensores.

Aqui está um exemplo de uma URL de phishing alinhada ao fluxo de concessão de código de autorização, adaptado do blog da Volexity:

https://login.microsoftonline[.]com/organizations/oauth2/v2.0/authorize?state=https://mae.gov[.]ro/[REMOVED]&client_id=aebc6443-996d-45c2-90f0-388ff96faa56&scope=https://graph.microsoft.com/.default&response_type=code&redirect_uri=https://insiders.vscode.dev/redirect&login_hint=<EMAIL HERE>

Vamos analisar alguns dos principais componentes:

• login.microsoftonline.com – O ponto de extremidade global de autenticação do Microsoft Entra ID.
• /oauth2/v2.0/authorize - Ponto de extremidade MSFT Entra ID OAuth v2.0 para fluxos de trabalho de autorização
• estado – Valor opcional usado para evitar CSRF e manter o estado do aplicativo. Às vezes usado de forma abusiva para ofuscar redirecionamentos de phishing.
• client_id – O ID do aplicativo que faz a solicitação. Isso pode pertencer a aplicativos primários da Microsoft (como VSCode, Teams) ou a aplicativos maliciosos de terceiros registrados por adversários.
• escopo – Define as permissões que o aplicativo está solicitando (por exemplo, Mail.Read, offline_access). O escopo .default é frequentemente usado para fluxos de credenciais de cliente para obter permissões pré-consentidadas.
• response_type=code – Indica que o fluxo está solicitando um código de autorização, que pode ser posteriormente trocado por um token de acesso e/ou atualização.
• redirect_uri – Para onde o Entra ID enviará a resposta após a autenticação do usuário. Se um invasor controlar esse URI, ele obterá o código ou será um URI gerenciado pela MSFT que será válido.
• login_hint – Especifica o usuário de destino (por exemplo, alice @ tenant.onmicrosoft.com). Geralmente pré-preenchido para reduzir o atrito durante phishing.

Observação: embora este exemplo ilustre uma URL de phishing OAuth de ID Entra comum da Microsoft, há muitas variações. Os adversários podem ajustar parâmetros como ID do cliente, escopos, tipos de concessão ou URIs de redirecionamento dependendo de seus objetivos específicos, seja para obter acesso persistente, exfiltrar e-mails ou escalar privilégios por meio de concessões de consentimento mais amplas.

Por que isso importa?

Como esses parâmetros são personalizáveis, os adversários podem facilmente trocar os valores para adaptá-los à sua operação. Por exemplo:

• Eles podem usar um ID de cliente legítimo da Microsoft para se misturar a aplicativos benignos.
• Eles podem usar um .default escopo para ignorar solicitações de consentimento específicas.
• Eles apontarão o redirect_uri para um site sob seu controle para coletar o código de autorização.
• Eles podem ter como alvo usuários específicos que eles possam ter identificado durante o reconhecimento.
• Eles podem ajustar permissões para direcionar recursos com base em suas necessidades operacionais.

Depois que um alvo é autenticado, o objetivo é simples: obter um código de autorização. Esse código é então trocado (geralmente usando ferramentas como ROADtools) por um token de atualização e/ou token de acesso, permitindo que o invasor faça chamadas à Graph API ou faça pivot em outros serviços da Microsoft 365 , tudo isso sem interação adicional do usuário.

Abstração das principais descobertas da Volexity

Para detecção de ameaças, é fundamental entender protocolos como OAuth, implementação de fluxo de trabalho no Microsoft Entra ID e metadados contextuais sobre os comportamentos e/ou medidas tomadas pelo adversário em relação a esta operação.

A partir da investigação e pesquisa da Volexity, podemos destacar as diferentes variações de phishing OAuth relatadas. Decidimos dividi-los para facilitar o entendimento:

Phishing OAuth para acessar a Graph API como cliente VSCode em nome do principal do usuário alvo: essas URLs são semelhantes ao nosso exemplo "O que define uma URL de phishing OAuth da MSFT" — o objetivo final é um token de acesso à Graph API com permissões padrão.

• Os URLs de phishing do OAuth eram personalizados, apontando para o ponto de extremidade "autorizar"
• Os IDs do cliente eram especificamente VSCode ("aebc6443-996d-45c2-90f0-388ff96faa56")
• O recurso/escopo era MSFT Graph ("https://graph.microsoft.com/.default") com .default permissões
• Os fluxos de concessão de token eram código de autenticação (response_type=code)
• Os URIs de redirecionamento eram para domínios legítimos da MSFT (insiders[.]vscode[.]dev ou vscode-redirect[.]azurewebsites[.]net)
• As dicas de login eram o principal do usuário específico que estava sendo alvo (não os principais do serviço)
• O adversário exigiu que o alvo abrisse a URL, autenticasse e compartilhasse o código de autorização (1.AXg….)

A partir daqui, o adversário poderia fazer uma solicitação ao ponto de extremidade do token OAuth da MSFT (https://login.microsoftonline.com/[tenant_id]/oauth2/v2.0/token) e trocar o token de atualização por um token de acesso. Isso é suficiente para permitir que o adversário acesse a Graph API e acesse recursos normalmente disponíveis para o usuário. Esses indicadores serão cruciais para planejar nossas estratégias de detecção e caça mais adiante neste blog.

Phishing OAuth para registro de dispositivo como MSFT Auth Broker: essas URLs são exclusivas, pois são encadeadas com o uso subsequente do ROADtools para registrar um dispositivo virtual, trocar um RT por um PRT e exigir enriquecimento de PRT para obter acesso a e-mails por meio da Graph API e do acesso ao SharePoint.

• Os URLs de phishing do OAuth eram personalizados, apontando para autorização (https://login.microsoftonline.com/[tenant_id]/oauth2/v2.0/authorize) ponto final
• Os IDs do cliente eram especificamente MSFT Authentication Broker ("29d9ed98-a469-4536-ade2-f981bc1d605e")
• O recurso/escopo era o Serviço de Registro de Dispositivos (DRS) ("01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9")
• Os fluxos de concessão de token eram código de autenticação (response_type=code)
• O URI de redirecionamento inclui ponto de extremidade de ingresso no domínio baseado em nuvem (normalmente usado durante a configuração do Windows ou no Autopilot)
• A dica de login contém o endereço de e-mail principal do usuário (destino)
• A solicitação final é para um token ADRS

Se o usuário for vítima de phishing e abrir a URL, a autenticação fornecerá um token ADRS necessário para que o adversário registre um dispositivo e, posteriormente, obtenha um PRT com a chave privada e o arquivo PEM do dispositivo.

O blog da Volexity também inclui informações adicionais sobre o rastreamento da atividade da identidade comprometida por meio do ID do dispositivo registrado, bem como a atividade pós-comprometimento após uma solicitação 2FA aprovada ter sido identificada, permitindo que o adversário baixe o e-mail do alvo com uma sessão vinculada ao dispositivo recém-registrado.

Com esse entendimento de cada tentativa de phishing, nosso próximo objetivo é replicar isso em nosso próprio locatário da MSFT com a maior precisão possível para coletar dados para detecções plausíveis.

Nossos esforços de emulação

Certo – então, neste ponto, abordamos os fundamentos do OAuth e como o Microsoft Entra ID o implementa. Analisamos o que define uma URL de phishing do Microsoft OAuth, decodificamos seus parâmetros críticos e extraímos insights importantes da excelente investigação da Volexity para identificar indicadores alinhados a esses fluxos de trabalho de phishing.

Mas a teoria e uma olhada no caderno de Volexity só nos levam até certo ponto.

Para entender verdadeiramente a perspectiva do invasor, toda a cadeia de execução, peculiaridades das ferramentas, armadilhas sutis e oportunidades de abuso, decidimos colocar a mão na massa com testes de caixa branca. Recriamos o processo de phishing do OAuth em nosso próprio locatário, emulando tudo, desde a coleta de tokens até o acesso a recursos. O objetivo? Ir além dos indicadores estáticos e revelar as migalhas comportamentais que os defensores podem detectar com segurança.

Vamos começar.

Pré-requisitos

Para começar, é bom compartilhar alguns detalhes sobre nosso ambiente de pesquisa e detecção de ameaças no Azure.

• Locatário do Azure estabelecido: TENANT.onmicrosoft.com
• Domínio SharePoint estabelecido: DOMAIN.sharepoint.com
• IdP nativo Microsoft Entra ID – Habilitando nosso IAM
• Licenças Microsoft 365 (P2) para todos os usuários
• Transmissão de logs de atividades do Azure para o EventHub
• Transmissão de logs de login do Microsoft Entra ID para o EventHub
• Transmissão de logs de auditoria do Microsoft Entra ID para o EventHub
• Transmissão de logs de auditoria do Microsoft Graph para o EventHub
• Transmissão de logs de auditoria do Microsoft 365 para o EventHub
• Integração do Elastic Azure e M365 habilitada para resumo de log do EventHub
• Usuário administrador básico habilitado com CAP exigindo MFA
• Aplicativo MSFT Authenticator para dispositivos móveis para emulação 2FA
• Windows 10 Desktop com NordVPN (Adversary Box)
• Ponto de extremidade do macOS (caixa de vítima)

Observe que, embora possamos acompanhar os fluxos de trabalho de um único ponto de extremidade, muitas vezes precisamos de dados que reflitam endereços de origem separados para que o desenvolvedor possa detectar variações de viagens impossíveis.

Cenário 1: Phishing OAuth como cliente VSCode

Emulação

Para emular a técnica de phishing documentada pela Volexity, criamos um script Python para gerar uma URL de autorização OAuth 2.0 usando o Microsoft Entra ID. A URL inicia um fluxo de concessão de código de autorização, representando o aplicativo Visual Studio Code primário para solicitar acesso delegado à API do Microsoft Graph.

Configuramos a URL com os seguintes parâmetros:

{
  "client_id": "aebc6443-996d-45c2-90f0-388ff96faa56",
  "response_type": "code",
  "redirect_uri": "insiders.vscode.dev/redirect",
  "scope": "https://graph.microsoft.com/.default",
  "login_hint": "user @ tenant.onmicrosoft.com",
  "prompt": "select_account",
  "state": "nothingtoseehere"
}

Figura 1: Parâmetros para URL de phishing OAuth

Esta URL é compartilhada com o alvo (no nosso caso, um usuário de teste do MacOS). Quando aberto, ele autentica o usuário e conclui o fluxo de trabalho do OAuth. Usando ferramentas de desenvolvedor de navegador, capturamos o código de autorização retornado no URI de redirecionamento, exatamente o que os invasores pediram que suas vítimas enviassem de volta.

Após receber o código, emitimos uma solicitação POST para:

{token_url: "https://login.microsoftonline.com/organizations/oauth2/v2.0/token"}

Esta troca usa o tipo de concessão authorization_code, passando o código, o ID do cliente e o URI de redirecionamento. A Microsoft retorna um token de acesso, mas nenhum token de atualização. Você pode perguntar por que isso acontece?

O escopo https://graph.microsoft.com/.default instrui a Microsoft a emitir um token portador para todas as permissões do Graph já concedidas ao aplicativo VSCode em nome do usuário. Este é um escopo estático, extraído do registro do aplicativo, não inclui escopos dinâmicos como Mail.Read ou offline_access.

A documentação da Microsoft afirma:

““Os clientes não podem combinar consentimento estático (.default) e consentimento dinâmico em uma única solicitação.””

Portanto, tentar incluir offline_access junto com .default resulta em um erro. Se o invasor quiser um token de atualização, ele deve evitar .default e, em vez disso, solicitar explicitamente offline_access e os escopos delegados necessários (por exemplo, Mail.Read) – assumindo que o registro do aplicativo oferece suporte a eles.

Com o token de acesso em mãos, passamos para um segundo script para interagir com a API do Microsoft Graph. O objetivo é extrair mensagens de e-mail da conta da vítima — exatamente como o invasor faria.

Para fazer isso, incluímos o token de acesso como um Bearer JWT no cabeçalho de autorização e fizemos uma solicitação GET para o seguinte endpoint:

{graph_url: "https://graph.microsoft.com/v1.0/me/messages"}

A resposta retorna uma matriz JSON de objetos de e-mail. A partir daqui, simplesmente iteramos pelos resultados e analisamos metadados úteis, como remetente, assunto e hora de recebimento.

Para testar os privilégios mais amplos do token, também tentamos enumerar sites do SharePoint usando:

{graph_search_url: "https://graph.microsoft.com/v1.0/sites?search=*"}

A solicitação falhou com um erro de acesso negado, o que nos leva a uma pergunta importante: por que o acesso ao e-mail funcionou, mas o acesso ao SharePoint não? O motivo é que o cliente primário (VSCode: aebc6443-996d-45c2-90f0-388ff96faa56) não tem permissões delegadas padrão com o Graph para SharePoint, conforme predefinido pela Microsoft. Portanto, sabemos que o adversário tem acesso limitado.

Para garantir que isso fosse preciso, decodificamos o token de acesso para identificar o SCP associado ao VSCode com .default permissões para Graph – Verificando nenhum Site.* autorizado pela Microsoft.

Esta é uma das variações descritas pela Volexity, mas nos ajuda a entender mais sobre os processos nos bastidores do adversário, bem como recursos, OAuth e muito mais para o Microsoft Entra ID.

Com a emulação concluída, agora nos voltamos para a identificação de sinais de alta fidelidade que são viáveis para detecção de SIEM e busca de ameaças. Nosso foco está em observáveis de comportamento nos logs do Microsoft Entra ID e do Microsoft Graph.

Detecção

Sinal 1 - Phishing de OAuth do Microsoft Entra ID como cliente do Visual Studio Code

Um fluxo bem-sucedido de OAuth 2.0 (autorização) e OpenID Connect (autenticação) foi concluído usando o aplicativo Microsoft Visual Studio Code (VSCode). O login ocorreu em nome do usuário principal phishing, resultando em acesso delegado ao Microsoft Graph com .default permissões.

event.dataset: "azure.signinlogs" and
event.action: "Sign-in activity" and
event.outcome: "success" and
azure.signinlogs.properties.user_type: "Member" and
azure.signinlogs.properties.authentication_processing_details: *Oauth* and
azure.signinlogs.category: "NonInteractiveUserSignInLogs" and
(
  azure.signinlogs.properties.resource_display_name: "Microsoft Graph" or
  azure.signinlogs.properties.resource_id: "00000003-0000-0000-c000-000000000000"
) and (
  azure.signinlogs.properties.app_id: "aebc6443-996d-45c2-90f0-388ff96faa56" or
  azure.signinlogs.properties.app_display_name: "Visual Studio Code"
)

Sinal 2 - Reutilização de sessão do Microsoft Entra com acesso a gráfico suspeito

Embora linguagens de consulta tradicionais como KQL sejam excelentes para filtrar e visualizar eventos de log individuais, elas têm dificuldades quando uma detecção depende da correlação de vários registros em conjuntos de dados, tempo e identificadores. É aqui que o ES|QL (Elasticsearch Query Language) se torna essencial. Esses tipos de correlações de múltiplos eventos, lógica temporal e normalização de campo são difíceis ou totalmente impossíveis em linguagens de consulta baseadas em filtros estáticos, como KQL, sem escrever várias consultas desconexas e correlacioná-las manualmente após o fato.

Essa detecção depende da correlação de vários eventos que ocorrem próximos um do outro, mas de diferentes fontes de dados, ou seja, logs de login e atividades do Microsoft Graph. O objetivo é encontrar reutilização suspeita do mesmo ID de sessão em vários IPs, potencialmente indicando sequestro de sessão ou abuso de token. Para economizar espaço nesta publicação, você pode visualizar a regra de detecção real na seção Regras de Detecção. Para ilustrar melhor o fluxo da consulta e o significado, abaixo está um diagrama para ilustrar em um nível mais alto.

[ FROM logs-azure.* ]
        |
        |  ← Pulls events from all relevant Microsoft Cloud datasets:
        |     - azure.signinlogs (authentication)
        |     - azure.graphactivitylogs (resource access)
        ↓
[ WHERE session_id IS NOT NULL AND IP NOT MICROSOFT ASN ]
        |
        |  ← Filters out Microsoft-owned infrastructure (e.g., internal proxy,
        |     Graph API relays) using ASN checks.
        |  ← Ensures session ID exists so events can be correlated together.
        ↓
[ EVAL session_id, event_type, time_window, etc. ]
        |
        |  ← Normalizes key fields across datasets:
        |     - session_id (from signin or Graph)
        |     - user ID, app ID, event type ("signin" or "graph")
        |  ← Buckets events into 5-minute windows using DATE_TRUNC()
        ↓
[ KEEP selected fields ]
        |
        |  ← Retains only what's needed:
        |     session_id, timestamp, IP, user, client ID, etc.
        ↓
[ STATS BY session_id + time_window ]
        |
        |  ← Groups by session and time window to compute:
        |     - unique IPs used
        |     - apps involved
        |     - first and last timestamps
        |     - whether both signin and graph occurred
        ↓
[ EVAL time_diff + signin_to_graph_delay ]
        |
        |  ← Calculates:
        |     - time_diff: full session duration
        |     - delay: gap between signin and Graph access
        ↓
[ WHERE types_count > 1 AND unique_ips > 1 AND delay <= 5 ]
        |
        |  ← Flags sessions where:
        |     - multiple event types (signin + graph)
        |     - multiple IPs used
        |     - all occurred within 5 minutes
        ↓
[ Output = Suspicious Session Reuse Detected ]

Sinal 3 - Logins simultâneos do Microsoft Entra ID com propriedades suspeitas

Essa detecção identifica logons suspeitos no Microsoft Entra ID, em que um usuário se autentica usando o fluxo de código do dispositivo sem MFA ou logons usando o cliente VSCode. Quando a mesma identidade faz login em dois ou mais IPs distintos em um curto período de tempo usando qualquer um dos métodos, isso pode indicar repetição de token, phishing OAuth ou atividade de adversário no meio (AitM).

[ FROM logs-azure.signinlogs* ]
        |
        |  ← Pulls only Microsoft Entra ID sign-in logs
        ↓
[ WHERE @timestamp > NOW() - 1h AND event.outcome == "success" ]
        |
        |  ← Filters to the last hour and keeps only successful sign-ins
        ↓
[ WHERE source.ip IS NOT NULL AND identity IS NOT NULL ]
        |
        |  ← Ensures the sign-in is tied to a user and IP for correlation
        ↓
[ KEEP fields: identity, app_id, auth_protocol, IP, etc. ]
        |
        |  ← Retains app/client, IP, auth method, and resource info
        ↓
[ EVAL detection flags ]
        |
        |  ← Labels events as:
        |     - device_code: if MFA not required
        |     - visual_studio: if VS Code client used
        |     - other: everything else
        ↓
[ STATS BY identity ]
        |
        |  ← Aggregates all sign-ins per user, calculates:
        |     - IP count
        |     - Device Code or VSCode usage
        |     - App/client/resource details
        ↓
[ WHERE src_ip >= 2 AND (device_code_count > 0 OR vsc > 0) ]
        |
        |  ← Flags users with:
        |     - Sign-ins from multiple IPs
        |     - And either:
        |         - Device Code w/o MFA
        |         - Visual Studio Code app
        ↓
[ Output = Potential OAuth Phishing or Token Misuse ]

Embora essa variação de phishing OAuth não tenha a persistência total oferecida por tokens de atualização ou PRTs, ela ainda fornece aos adversários acesso único e valioso a dados confidenciais do usuário — como e-mails — por meio de canais legítimos. Este exercício nos ajuda a entender as limitações e capacidades do .default estático escopos, a influência dos registros de aplicativos e como o Microsoft Graph desempenha um papel fundamental na pós-autenticação. Isso também reforça uma lição mais ampla: nem todos os ataques de phishing OAuth são criados iguais. Alguns visam a longevidade (como veremos mais tarde) por meio de tokens de atualização ou registro de dispositivos, enquanto outros se concentram no roubo imediato de dados por meio de clientes primários. Entender as nuances é essencial para uma lógica de detecção precisa.

Cenário 2: Phishing OAuth para registro de dispositivo

Como dissemos anteriormente, a Volexity também relatou um manual de phishing separado direcionado às vítimas, desta vez com o objetivo de registrar um dispositivo virtual e obter um PRT. Embora essa abordagem exija mais etapas do adversário, a recompensa é um token que concede um token que oferece muito mais utilidade para concluir suas operações. Para nossos esforços de emulação, precisávamos expandir nosso conjunto de ferramentas e confiar no ROADtools, assim como o adversário fez para permanecer precisos. No entanto, vários outros scripts Python foram criados para phishing inicial e ações pós-comprometimento.

Emulação

Começando com o phishing inicial, ajustamos nosso script Python para criar uma URL OAuth diferente que seria enviada à nossa vítima. Desta vez, o foco estava em nosso ID de cliente primário, o Microsoft Authentication Broker, solicitando um token de atualização com offline_access e redirecionando para o URI de ponto de extremidade de ingresso do dispositivo de domínio de nuvem do Entra ID.

{
  "client_id": "29d9ed98-a469-4536-ade2-f981bc1d605e",
  "response_type": "code",
  "response_mode": "query",
  "redirect_uri": "https://login.microsoftonline.com/WebApp/CloudDomainJoin/8",
  "resource": "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9",
  "state": "nothingtoseehere"
}

Se for bem-sucedido e nossa vítima for autenticada, o fluxo de trabalho do OAuth será concluído e o usuário será redirecionado para o URI especificado com um código de autorização anexado nos parâmetros da consulta. Novamente, esse código é a parte crítica e deve ser compartilhado com o adversário para que ele possa ser trocado por tokens. No nosso caso, depois que a URL de phishing é aberta e o alvo é autenticado, capturamos o código de autorização incorporado no redirecionamento e o usamos para solicitar tokens do ponto de extremidade do token Microsoft Entra ID.

Agora é aqui que fica interessante. Em resposta à solicitação de token, recebemos três tipos de tokens: um token de acesso, um token de atualização e um token de ID. Você pode estar se perguntando: por que recebemos mais do que apenas um token de acesso? A resposta está nos escopos que solicitamos inicialmente: openid, offline_access e profile.

• O openid nos concede um token de ID, que faz parte da camada OpenID Connect e confirma a identidade do usuário — este é seu artefato de autenticação (authN).
• offline_access fornece um token de atualização, permitindo-nos manter uma sessão e solicitar novos tokens de acesso sem exigir reautenticação. Isso oferece suporte ao acesso persistente, mas é essencial para nosso uso com o ROADtx.
• E o próprio token de acesso é usado para autorizar solicitações a APIs protegidas, como o Microsoft Graph, o que representa autorização (authZ).

Com esses três tokens, temos tudo: autenticação, autorização e continuidade de sessão de longo prazo. Isso é suficiente para mudar de uma simples estratégia de phishing OAuth para uma abordagem mais persistente — como registrar um novo dispositivo no Microsoft Entra ID.

Agora vamos conectar os pontos. Um PRT exige o registro de um dispositivo válido, que o Entra ID reconheça por meio de um certificado de dispositivo e uma chave privada. É aqui que o ROADtx entra em ação. Como nosso phishing OAuth inicial personificou um fluxo de dispositivo unido, e o cliente usado foi o Microsoft Authentication Broker (um cliente primário que interage com o Device Registration Service), já temos o token de acesso correto em mãos para interagir com o DRS. Observe que em nosso objeto retornado o escopo é adrs_access , que indica acesso ao Azure DRS e é importante para detecções posteriores.

A partir daqui, simplesmente colocamos o objeto JSON recebido de nossa troca de tokens no .roadtool_auth arquivo. Este arquivo é consumido nativamente pelo ROADtools, que usa os tokens armazenados para executar o registro do dispositivo, concluindo a mudança do adversário para a persistência e preparando o cenário para a obtenção de um PRT válido.

Depois de obter os tokens, nós os preparamos para o ROADtx reformatando o JSON. O ROADtx espera chaves em camelCase, e também devemos incluir o ID do cliente do Microsoft Authentication Broker como _clientId. Essa configuração nos permite executar o comando refreshtokento , que pega nosso token de atualização e o troca por um novo JWT com escopo no DRS — especificamente, o principal de serviço urn:ms-drs:enterpriseregistration.windows.net.

Uma vez feito isso, usamos o comando device para simular um novo registro de dispositivo. Esta operação não requer nenhuma máquina virtual ou host físico porque é um registro de backend que simplesmente cria uma entrada no Entra ID. Em caso de sucesso, recebemos um ID de dispositivo válido, um certificado codificado em PEM e uma chave privada — todos necessários para simular um dispositivo híbrido válido no ecossistema da Microsoft.

Com a identidade do nosso dispositivo estabelecida, invocamos o comando prt . Isso usa o token de atualização, o certificado do dispositivo e a chave privada para criar um novo PRT — uma credencial altamente privilegiada que efetivamente vincula a confiança do usuário e do dispositivo no Microsoft Entra ID.

E assim, de repente — uhu! — temos um PRT.

Mas por que passar por tudo isso? Por que registrar um dispositivo, gerar um certificado e obter um PRT quando já temos um token de acesso, um token de ID e um token de atualização?

Porque o PRT é a chave para a emulação completa da identidade do usuário e do dispositivo. Pense nisso como um token de concessão de tíquetes semelhante ao Kerberos no mundo da Entra ID, mas, em vez disso, um token de concessão de tokens. Com um PRT válido:

• Um adversário pode solicitar novos tokens de acesso e ID para aplicativos primários, como Outlook, SharePoint ou Teams, sem precisar de interação do usuário.
• O PRT permite logon único SSO contínuo em vários serviços, ignorando MFA e outras políticas de acesso condicional (CAP) que normalmente solicitariam novamente ao usuário. Isso é crucial para a persistência, pois CAP e MFA costumam ser grandes barreiras para os adversários.
• Ele oferece suporte à persistência de longa duração, pois o PRT pode ser silenciosamente renovado e aproveitado em todas as sessões, desde que a identidade do dispositivo permaneça confiável.

E talvez o mais perigoso: o PRT permite que adversários imitem uma combinação de dispositivo e usuário totalmente compatível e vinculado ao domínio, ignorando efetivamente a maioria dos controles convencionais de detecção e resposta, tornando a linha entre o que é benigno e o que é suspeito extremamente tênue para caçadores e analistas.

Isso torna o PRT um recurso incrivelmente valioso, que permite movimentação lateral secreta, escalonamento de privilégios e acesso profundo aos serviços da Microsoft 365 . Não se trata mais apenas de entrar — trata-se de permanecer indetectável.

Não nos esqueçamos da atividade pós-compromisso…

O ROADtx oferece alguns comandos poderosos frequentemente usados por adversários – prtenrich e browserprtauth. Por exemplo, podemos acessar a maioria dos serviços de interface de usuário baseados em navegador no pacote da Microsoft fornecendo nosso PRT, que inclui os metadados necessários para autenticação e autorização — que originalmente pertenciam à nossa vítima de phishing (eu), mas na verdade é o Microsoft Authentication Broker agindo em seu nome.

A Volexity também relatou que, após o registro do dispositivo e a aquisição do PRT, uma solicitação 2FA foi enviada à vítima inicial, aprovada e então usada para acessar e-mails via SharePoint. Embora não especifiquem exatamente como as solicitações foram feitas, é razoável supor que o adversário usou o PRT para autenticar por meio de um cliente Microsoft primário, com o acesso real aos dados acontecendo por meio do Microsoft Graph. O Graph continua sendo um alvo popular após o comprometimento porque serve como um hub de API central para a maioria dos recursos do Microsoft 365 .

Para começar, vamos aproveitar o ROADtx para autenticar com nosso PRT, onde o Microsoft Teams é nosso cliente e o Microsoft Graph é nosso recurso. Ao usar o comando prtauth com nosso PRT, podemos obter um novo token de acesso e um token de atualização, demonstrando claramente a utilidade do PRT como um token de concessão de tokens dentro da estrutura de identidade da Microsoft.

Depois que nosso token de acesso é obtido, o conectamos a um script Python personalizado para começar a enumerar nossos sites, unidades e itens do SharePoint, o que nos permite identificar arquivos de interesse e baixar seus conteúdos.

Com esta emulação, mostramos como os adversários podem encadear o phishing OAuth com o Microsoft Authentication Broker e obter o material de credencial necessário para aproveitar o ROADtx para adquirir um PRT. Este PRT é um utilitário importante após o comprometimento para acessar arquivos confidenciais, enumerar recursos de locatários e muito mais.

Agora, vamos mudar o foco: quais são os sinais plausíveis e precisos para detectar essa atividade?

Detecção

Sinal 1 - Phishing OAuth do Microsoft Entra ID como corretor de autenticação da Microsoft

Identifica instâncias em que um usuário principal inicia um fluxo de código de autorização OAuth usando o Microsoft Authentication Broker (MAB) como cliente e o Device Registration Service (DRS) como recurso de destino. Essa detecção se concentra em casos em que um único ID de sessão é reutilizado em dois ou mais endereços IP distintos dentro de um curto período de tempo, e pelo menos uma solicitação se origina de um navegador — comportamento comumente associado ao phishing.

[ FROM logs-azure.signinlogs-* ]
        |
        |  ← Pulls all Microsoft Entra ID sign-in logs
        ↓
[ WHERE app_id == MAB AND resource_id == DRS ]
        |
        |  ← Filters to OAuth auth code requests targeting
        |     Microsoft Authentication Broker + Device Reg Service
        ↓
[ EVAL session_id + is_browser ]
        |
        |  ← Extracts session ID and flags browser-based activity
        ↓
[ STATS BY 30-minute window, user, session_id ]
        |
        |  ← Groups logins within same session and time window,
        |     then aggregates:
        |       - user/session/token identifiers
        |       - distinct IPs and geo info
        |       - user agent, browser presence
        |       - app/resource/client info
        ↓
[ WHERE ip_count ≥ 2 AND session_id_count == 1 ]
        |
        |  ← Identifies reuse of a single session ID
        |     across ≥ 2 different IP addresses
        ↓
[ AND has_browser ≥ 1 AND auth_count ≥ 2 ]
        |
        |  ← Requires at least one browser-based request
        |     and at least two total sign-in events
        ↓
[ Output = Suspicious OAuth Flow with Auth Broker for DRS ]

Sinal 2 - Solicitação suspeita de token ADRS pelo Microsoft Auth Broker

Identifica eventos de login do Microsoft Entra ID em que um usuário principal se autentica usando um token de atualização emitido para o cliente Microsoft Authentication Broker (MAB), direcionando o Device Registration Service (DRS) com o escopo OAuth adrs_access . Esse padrão pode indicar acesso baseado em token ao DRS após um fluxo inicial de phishing de código de autorização ou registro de dispositivo.

event.dataset: "azure.signinlogs" and azure.signinlogs.properties.app_id : "29d9ed98-a469-4536-ade2-f981bc1d605e" and azure.signinlogs.properties.resource_id : "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" and azure.signinlogs.properties.authentication_processing_details.`Oauth Scope Info`: *adrs_access* and azure.signinlogs.properties.incoming_token_type: "refreshToken" and azure.signinlogs.properties.user_type: "Member"

Sinal 3 - Registro de dispositivo incomum no Entra ID

Detecta uma sequência de eventos de log de auditoria do Entra ID indicando possível atividade maliciosa de registro de dispositivo usando um token de atualização, comumente visto após phishing OAuth. Esse padrão imita o comportamento de ferramentas como o ROADtx, em que um dispositivo Windows recém-registrado (com uma versão de sistema operacional codificada 10.0.19041.928) é adicionado pelo Serviço de Registro de Dispositivos, seguido por atribuições de usuário e proprietário. Todos os eventos devem compartilhar o mesmo ID de correlação e ocorrer dentro de uma janela de um minuto, sugerindo fortemente automação ou registro orientado por script em vez de comportamento legítimo do usuário.

sequence by azure.correlation_id with maxspan=1m
[any where event.dataset == "azure.auditlogs" and azure.auditlogs.identity == "Device Registration Service" and azure.auditlogs.operation_name == "Add device" and azure.auditlogs.properties.additional_details.value like "Microsoft.OData.Client/*" and (
  azure.auditlogs.properties.target_resources.`0`.modified_properties.`1`.display_name == "CloudAccountEnabled" and 
azure.auditlogs.properties.target_resources.`0`.modified_properties.`1`.new_value: "[true]") and azure.auditlogs.properties.target_resources.`0`.modified_properties.`3`.new_value like "*10.0.19041.928*"]
[any where event.dataset == "azure.auditlogs" and azure.auditlogs.operation_name == "Add registered users to device" and azure.auditlogs.properties.target_resources.`0`.modified_properties.`2`.new_value like "*urn:ms-drs:enterpriseregistration.windows.net*"]
[any where event.dataset == "azure.auditlogs" and azure.auditlogs.operation_name == "Add registered owner to device"]

Sinal 3 - Transição de Entra ID RT para PRT do mesmo usuário e dispositivo

Essa detecção identifica quando um usuário do Microsoft Entra ID se autentica pela primeira vez usando um token de atualização emitido para o Microsoft Authentication Broker (MAB), seguido logo pelo uso de um Primary Refresh Token (PRT) do mesmo dispositivo. Essa sequência é rara no comportamento normal do usuário e pode indicar que um adversário registrou um dispositivo com sucesso e escalou para acesso persistente usando ferramentas como o ROADtx. Ao filtrar a atividade vinculada ao Serviço de Registro de Dispositivo (DRS) na segunda etapa, a regra se concentra no uso pós-registro do PRT para acessar outros serviços da Microsoft 365 .

Esse comportamento sugere fortemente comprometimento baseado em tokens e emulação de sessão de longo prazo, principalmente quando a confiança do dispositivo é estabelecida silenciosamente. Capturar essa transição do token de atualização para o PRT é essencial para revelar sinais de alta fidelidade de phishing de OAuth e persistência pós-comprometimento.

sequence by azure.signinlogs.properties.user_id, azure.signinlogs.properties.device_detail.device_id with maxspan=1d
  [authentication where 
    event.dataset == "azure.signinlogs" and
    azure.signinlogs.category == "NonInteractiveUserSignInLogs" and
    azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e" and
    azure.signinlogs.properties.incoming_token_type == "refreshToken" and
    azure.signinlogs.properties.device_detail.trust_type == "Azure AD joined" and
    azure.signinlogs.properties.device_detail.device_id != null and
    azure.signinlogs.properties.token_protection_status_details.sign_in_session_status == "unbound" and
    azure.signinlogs.properties.user_type == "Member" and
    azure.signinlogs.result_signature == "SUCCESS"
  ]
  [authentication where 
    event.dataset == "azure.signinlogs" and
    azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" and
    azure.signinlogs.properties.resource_display_name != "Device Registration Service" and
    azure.signinlogs.result_signature == "SUCCESS"
  ]

Sinal 4 - Uso incomum de PRT e dispositivo registrado para o usuário principal

Essa detecção surge quando um usuário do Microsoft Entra ID registra um novo dispositivo não visto anteriormente nos últimos 7 dias – comportamento frequentemente associado a campanhas de phishing OAuth que se encadeiam no registro de dispositivos baseado em ROADtx. Nesses ataques, os adversários induzem os usuários a autorizar o acesso ao Microsoft Authentication Broker (MAB) direcionado ao DRS, obtêm um RT e, em seguida, usam o ROADtx para registrar silenciosamente um dispositivo Windows falso e criar um PRT. Esta regra alerta quando um usuário principal é autenticado a partir de um ID de dispositivo recém-observado, principalmente se a sessão não estiver vinculada, o que é característico de repetição de token ou falsificação de dispositivo. Como os PRTs exigem um dispositivo registrado e confiável, esse sinal desempenha um papel fundamental na identificação de quando um adversário passou de um abuso básico de token para um acesso persistente e furtivo, alinhado ao comprometimento de longo prazo.

event.dataset: "azure.signinlogs" and
    event.category: "authentication" and
    azure.signinlogs.properties.user_type: "Member" and
    azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: "unbound" and
    not azure.signinlogs.properties.device_detail.device_id: "" and
    azure.signinlogs.properties.user_principal_name: *

Novos Termos Valores:

• azure.signinlogs.propriedades.nome_principal_do_usuário
• azure.logs de login.propriedades.detalhes do dispositivo.id do dispositivo

Essa emulação nos ajudou a validar o fluxo de trabalho completo do invasor, desde a tentativa de phishing para consentimento até o estabelecimento de confiança no dispositivo e a criação de um PRT para persistência de longo prazo. Ao encadear o abuso do OAuth com o registro do dispositivo, os adversários podem satisfazer CAPs, representar endpoints compatíveis e mover-se lateralmente pelos ambientes de nuvem, geralmente sem acionar os controles de segurança tradicionais.

Essas nuances são importantes. Quando vistos isoladamente, eventos individuais como emissão de tokens ou registro de dispositivos podem parecer inofensivos. Mas quando correlacionados entre registros de login, dados de auditoria e metadados de token, eles expõem um rastro distinto de comprometimento de identidade.

Detalhes importantes de telemetria para detecção e abuso

Ao longo de nossos esforços de emulação e detecção, artefatos de telemetria específicos se mostraram essenciais para separar a atividade benigna do OAuth do abuso malicioso. Entender como esses campos aparecem nos logs do Microsoft Entra ID – e como os invasores os manipulam – é essencial para uma engenharia de busca e detecção eficaz. Desde IDs de clientes e tipos de concessão até conformidade de dispositivos, tipos de tokens e resultados de acesso condicional, esses sinais contam a história de ataques baseados em identidade. Abaixo, selecionamos uma lista dos mais importantes e como eles podem nos ajudar.

IDs do aplicativo cliente (client_id): identifique o aplicativo que inicia a solicitação OAuth. Clientes primários (por exemplo VSCode, Auth Broker) podem ser usados de forma abusiva para se misturar. Clientes terceirizados podem ser maliciosos ou não revisados, o que geralmente representa ataques de concessão de consentimento. Usado principalmente para identificar uso arriscado ou inesperado de aplicativos.

Recurso de destino (resource_id / resource_display_name): define qual serviço MSFT está sendo acessado (por exemplo MSFT Graph ou Teams). Os alvos de alto valor incluem – Graph API, SharePoint, Outlook, Teams e Serviços de Diretório. O direcionamento de recursos geralmente é definido pelos objetivos do invasor.

Tipo principal (user_type): indica se o login foi feito por um membro (usuário) ou principal de serviço. As campanhas de phishing quase sempre têm como alvo as contas dos membros. Isso permite uma filtragem fácil na lógica de detecção, mas ajuda a parear solicitações incomuns de clientes primários em nome de entidades de usuários.

Tipo de concessão OAuth (authentication_processing_details): essencial para entender como o token foi obtido – códigos de autorização, tokens de atualização, códigos de dispositivo, credenciais de cliente, etc. Enquanto tokens de atualização e reutilização de código de dispositivo são sinais de alta fidelidade de pós-comprometimento.

Geolocalização: permite-nos identificar logins atípicos (por exemplo país raro visto) ou viagem impossível (mesmo usuário de locais distantes em um curto espaço de tempo). Combinados com IDs de sessão e IDs de correlação, eles podem revelar sequestro de token, comprometimento de identidade posterior ou movimento lateral.

Metadados do dispositivo (device_detail, trust_type, compliance_state): inclui IDs do dispositivo, sistema operacional, tipos de confiança, conformidade, estado gerenciado e muito mais. O registro do dispositivo e a emissão do PRT estão vinculados a esses metadados. Muitas vezes, o objetivo dos adversários é satisfazer o CAP e obter acesso confiável e persistente.

Protocolos e tipos de autenticação (authentication_protocol / incoming_token_type): revela se a sessão foi baseada em OAuth ou se MFA foi usado. As fontes de token de entrada são aquelas usadas para esta solicitação que fornecem authN ou authZ. Útil para detectar reutilização de tokens e logins não interativos.

Material de autenticação e contexto de sessão: os tokens usados podem ser inferidos por meio do tipo de token de entrada, do status de proteção do token e do ID da sessão. Reutilização de sessão, longa duração de sessão ou múltiplos IPs vinculados a uma única sessão geralmente indicam abuso.

Status da Política de Acesso Condicional: Avaliado durante a emissão do token – no entanto, influencia muito se o acesso foi concedido. Isso ajuda a identificar a evasão da PAC, resultados políticos inesperados ou pode ser um fator de risco.

Escopos e comportamento de consentimento: os escopos solicitados aparecem nos parâmetros SCP ou OAuth capturados nos logs de login. Os indicadores de abuso incluem offline_access, .default, ou escopos amplos como Mail.ReadWrite. A telemetria de consentimento pode ajudar a direcionar ou correlacionar se o usuário aprovou um aplicativo suspeito.

Conclusão

A implementação do OAuth do Microsoft Entra ID apresenta uma faca de dois gumes: ela permite experiências de autenticação poderosas e contínuas, mas também expõe novas oportunidades para adversários explorarem caminhos de ataque de confiança, persistência de sessão e registro de dispositivo.

Ao replicar as técnicas de phishing OAuth observadas pela Volexity, nossa equipe conseguiu validar como os invasores abusam de aplicativos legítimos da Microsoft, fluxos de tokens e ferramentas de código aberto para obter acesso furtivo a dados confidenciais. Ampliamos esse trabalho por meio de emulação prática, aprofundando-nos na mecânica de phishing e fluxos de trabalho do OAuth, metadados e aquisição de tokens de segurança, ajudando a revelar indicadores comportamentais que os defensores podem detectar.

Nossas descobertas reforçam um ponto-chave: o abuso do OAuth não depende de malware ou execução de código. Ele transforma identidade, consentimento e reutilização de tokens em armas, tornando os controles de segurança tradicionais um desafio, e é por isso que a detecção baseada em log, correlação e análise comportamental são tão essenciais.

Esperamos que os artefatos de emulação, as regras de detecção e as lições compartilhadas aqui ajudem os defensores em toda a comunidade a entender melhor – e detectar/caçar – essa classe em evolução de ameaças de identidade baseadas na nuvem.

Se você estiver usando o Elastic, disponibilizamos de código aberto todas as regras de detecção discutidas neste blog para você começar. E se você estiver caçando em outro SIEM, encorajamos você a adaptar a lógica e ajustá-la ao seu ambiente adequadamente.

A identidade é o novo perímetro – e está na hora de tratá-la dessa forma. Fique seguro e divirta-se caçando!

Regras de detecção

• Reutilização de sessão do Microsoft Entra ID com acesso suspeito ao gráfico
• Phishing de OAuth do Microsoft Entra ID via cliente do Visual Studio Code
• Fluxo suspeito do Microsoft OAuth via Auth Broker para DRS
• Solicitação suspeita de token ADRS pelo Microsoft Auth Broker
• Registro de dispositivo incomum no Entra ID
• Transição de Entra ID RT para PRT do mesmo usuário e dispositivo
• Dispositivo registrado incomum para o usuário principal

Referências:

• https://www.volexity.com/blog/2025/04/22/phishing-para-códigos-atores-ameaça-russos-alvo-fluxos-de-trabalho-do-microsoft-365-oauth/
• https://dirkjanm.io/abusando-do-azure-ad-sso-com-o-token-de-atualização-primário/
• https://posts.spectrops.io/solicitando-tokens-de-solicitação-de-anúncios-do-Azure-em-máquinas-associadas-aos-Anúncios-do-Azure-para-navegador-sso-2b0409caad30
• https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token
• https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens
• https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow
• https://learn.microsoft.com/en-us/entra/identity-platform/scopes-oidc#the-default-scope