CVE-2025-55241 Entra ID Actor Token Impersonation: Pode Comprometer Qualquer Global Admin

O Que Foi o CVE-2025-55241: a Falha de Impersonação de Actor Token do Entra ID

O CVE-2025-55241 é uma vulnerabilidade de Elevação de Privilégio no Microsoft Entra ID baseada na impersonação de Actor Token do Entra ID, descoberta pelo pesquisador de segurança independente Dirk-jan Mollema e reportada ao Microsoft Security Response Center (MSRC) em 14 de julho de 2025. A própria pontuação Common Vulnerabilities and Exposures (CVE) da Microsoft classificou-a como CVSS 10.0 (Crítica); o recálculo independente do NVD apontou 9.8 (Crítica), com classificação CWE-287 (Improper Authentication). A Microsoft atribuiu o CVE em 4 de setembro de 2025 e declarou que nenhuma ação do cliente era necessária, já que a correção já havia sido implantada em todo o tenant.

A falha combinava duas coisas: um tipo de token interno da Microsoft não documentado, chamado "Actor token", e uma lacuna de validação de tenant na API legada Azure AD Graph (graph.windows.net). Encadeados, eles permitiam que o portador de um Actor token do seu próprio tenant (controlado pelo atacante) se autenticasse como qualquer usuário — incluindo Global Administrators — em qualquer outro tenant do Entra ID, sem precisar das credenciais desse usuário, sem acionar MFA e sem gerar o rastro de auditoria com o qual os defensores normalmente contam. Mollema descreveu a exposição como capaz de comprometer "todo tenant do Entra ID no mundo", com exceção das clouds nacionais/soberanas.

🚨 Perigo: Não há evidências de exploração ativa, segundo a Microsoft e Mollema. Esta é uma explicação retrospectiva de uma vulnerabilidade que a Microsoft já corrigiu globalmente — não uma ameaça ativa que exija ação emergencial hoje.

Linha do Tempo da Divulgação

• 14 de julho de 2025 — Mollema reporta o problema ao MSRC; o MSRC abre um caso no mesmo dia.
• 17 de julho de 2025 — A Microsoft implanta uma correção em produção para a lacuna de validação de tenant na API Azure AD Graph.
• 23 de julho de 2025 — O MSRC confirma a Mollema que o problema central foi resolvido.
• 6 de agosto de 2025 — A Microsoft entrega mitigações adicionais, restringindo a emissão de Actor tokens para a API Azure AD Graph apenas a serviços internos da Microsoft.
• 4 de setembro de 2025 — A Microsoft atribui formalmente o CVE-2025-55241 e declara que nenhuma ação do cliente é necessária.
• 17 de setembro de 2025 — Mollema publica o relatório técnico completo, incluindo orientações de detecção.

Como Funcionava o Bypass do Actor Token

Actor tokens são emitidos pelo Access Control Service (ACS) da Microsoft para delegação serviço-a-serviço — o mecanismo que permite que backends first-party, como o Exchange Online, "ajam como" um usuário ao chamar outros serviços da Microsoft em nome desse usuário. Segundo a análise de Mollema, os Actor tokens carregam uma claim trustedfordelegation e, uma vez emitidos, efetivamente permitem a impersonação de qualquer usuário em um tenant por até 24 horas. Este é um mecanismo interno legítimo e de longa data — a vulnerabilidade estava em como um consumidor legado desses tokens os validava, não na existência do mecanismo em si.

Duas lacunas de design tornaram isso explorável entre tenants:

Origem de Tenant Não Validada

A API legada Azure AD Graph não verificava corretamente se o ID de tenant embutido nas claims de impersonação de um Actor token correspondia ao tenant que realmente estava sendo consultado. Como o payload de impersonação era transportado em um JWT não assinado, um atacante podia substituir o ID de tenant alvo pelo próprio, sem invalidar a assinatura do token — não havia assinatura para quebrar. Isso permitia que um token emitido para o próprio tenant do atacante fosse reproduzido como se tivesse se originado de qualquer outro tenant do planeta.

Identificadores de Usuário Previsíveis (netId)

O alvo da impersonação dentro do tenant de destino era resolvido via netId, um identificador legado do Microsoft Passport ainda presente em alguns componentes internos do Entra. Diferente de um Entra object ID (um GUID aleatório), valores de netId incrementam de forma previsível. Mollema descobriu que podiam ser obtidos por força bruta em "minutos a horas" para um tenant alvo, e também podiam ser coletados diretamente dos atributos alternativeSecurityIds de usuários guest em relações de confiança B2B, ou de tokens vazados em logs, tickets de suporte e capturas de tela públicas.

Juntando tudo: um atacante que conseguisse solicitar um Actor token de qualquer tenant que controlasse — incluindo um tenant gratuito ou de avaliação — podia reescrever o ID do tenant alvo e combiná-lo com um netId resolvido, e a API legada Azure AD Graph aceitava a impersonação resultante. Isso concedia acesso de leitura e escrita a dados de diretório, a capacidade de criar service principals, alterar atribuições de função e modificar políticas de Conditional Access como qualquer usuário que o token alegasse ser, até e incluindo um Global Administrator.

Por Que MFA, Conditional Access e Logging Não Conseguiram Detectar

Esta é a parte que tornou a falha crítica, e não apenas grave: o bypass ficava abaixo dos controles nos quais os tenants confiam para detectar o comprometimento de contas.

• MFA e Conditional Access não se aplicam. Actor tokens são um mecanismo de delegação serviço-a-serviço, não um login interativo — eles não passam pelo mecanismo de políticas de Conditional Access de forma alguma, então requisitos de MFA por usuário, risco de sign-in e conformidade de dispositivo simplesmente não são avaliados. Um lembrete de que o MFA sozinho nunca foi um controle completo — ele só cobre os caminhos de autenticação aos quais está de fato conectado.
• Solicitar o token não gera log. Segundo o relatório de Mollema, obter um Actor token não produz nenhuma entrada de log visível ao tenant — um atacante podia preparar o ataque com pegada zero no tenant alvo.
• A API Graph legada sub-registra. graph.windows.net é anterior à profundidade de logging que o Microsoft Graph e o pipeline de auditoria moderno do Entra oferecem, então mesmo ações realizadas com o token de impersonação eram apenas parcialmente capturadas.
• O token era, na prática, irrevogável dentro da sua janela. Sendo um JWT não assinado e autocontido, válido por até 24 horas, um Actor token vazado ou forjado não podia ser invalidado em pleno voo, como acontece com um token de sessão comprometido.

Detecção: O Que Procurar

Como a correção da Microsoft fechou o caminho de acesso subjacente, a detecção aqui é retrospectiva — revisar o histórico de auditoria do Entra em busca de sinais de que a técnica foi usada contra o seu tenant antes do patch — em vez de um controle de monitoramento ao vivo. Mollema publicou uma consulta KQL exatamente para isso: mudanças impulsionadas por Actor token ainda aparecem em AuditLogs, mas com uma incompatibilidade reveladora entre o nome de exibição do serviço que age e o contexto real que iniciou a ação.

AuditLogs
| where not(OperationName has "group")
| where not(OperationName == "Set directory feature on tenant")
| where InitiatedBy has "user"
| where InitiatedBy.user.displayName has_any (
    "Office 365 Exchange Online", "Skype for Business Online", "Dataverse",
    "Office 365 SharePoint Online", "Microsoft Dynamics ERP")

O Que a Consulta Não Captura

Esta consulta, adaptada do relatório publicado por Mollema, sinaliza modificações de diretório feitas via impersonação por Actor token. Ela não captura reconhecimento apenas de leitura — enumeração de usuários ou grupos, coleta de secrets, revisão de políticas — que a API legada não registrava em detalhe suficiente para reconstrução posterior. Trate um resultado limpo desta consulta como evidência de que nenhuma atividade de escrita foi encontrada por esse caminho, não como prova de que o tenant nunca foi lido.

Remediação

A própria correção da Microsoft não exigiu ação do cliente: o MSRC confirmou que o problema de validação de tenant foi resolvido até 23 de julho de 2025, e até 6 de agosto de 2025 restringiu ainda mais a emissão de Actor tokens para a API Azure AD Graph apenas a serviços internos da Microsoft. Isso fecha essa cadeia específica. A remediação duradoura para os tenants é reduzir a dependência da superfície legada e dos padrões de privilégio que essa falha explorou:

1. Elimine dependências do Azure AD Graph. Audite suas app registrations e service principals em busca de qualquer um que ainda chame o Azure AD Graph e migre-os para o Microsoft Graph; cada dependência removida é uma superfície a menos exposta ao próximo bug de validação de uma API legada.
2. Elimine atribuições permanentes de Global Administrator. O pior cenário desta falha foi a impersonação completa de um Global Admin. Mover funções administrativas para ativação just-in-time via Privileged Identity Management (PIM) reduz o número de contas que uma impersonação bem-sucedida poderia realmente usar de forma significativa.
3. Exija MFA resistente a phishing em toda função privilegiada, não apenas no sign-in interativo em geral — isso não impede um bypass de token serviço-a-serviço como os Actor tokens, mas fecha o caminho muito mais comum que os atacantes realmente usam para chegar a contas admin.
4. Bloqueie a legacy authentication em todo o tenant via Conditional Access. A legacy auth não suporta validação moderna de tokens nem a aplicação de Conditional Access, e tenants que ainda permitem legacy auth ou deixam lacunas no Conditional Access ampliam a mesma classe de exposição que tornou esta vulnerabilidade tão grave: caminhos de autenticação que o plano de controle moderno não consegue ver.
5. Revise a retenção e os alertas dos AuditLogs do Entra para o padrão de iniciador anômalo descrito acima, para que qualquer futuro bypass de impersonação de serviço first-party gere um alerta em vez de silêncio. Uma auditoria de segurança do Entra ID mais ampla cobre isso junto com o restante da postura do tenant, incluindo as configurações padrão com que novos tenants são entregues.

Por Que a API Legada Importava Além Deste CVE

A Microsoft vem aposentando o graph.windows.net em estágios desde o anúncio de depreciação de 2019: novas aplicações foram bloqueadas de primeiro uso a partir de 31 de agosto de 2024, e o opt-in de acesso estendido é obrigatório em todo o tenant desde 1º de fevereiro de 2025, com apps que não optarem perdendo o acesso por completo. A Microsoft afirmou claramente que não faz mais nenhum investimento no Azure AD Graph além de correções de segurança, e que toda nova capacidade vai para o Microsoft Graph. O CVE-2025-55241 é uma ilustração concreta de por que essa migração importa além do item de compliance: uma superfície de API depreciada, sub-registrada e sub-mantida é exatamente onde uma lacuna de validação como esta passa despercebida por mais tempo.

Como a EtcSec Detecta Isso

A auditoria de Entra ID da EtcSec não tem visibilidade sobre a infraestrutura interna de Actor token da Microsoft — esse plano de controle está inteiramente dentro da infraestrutura da Microsoft e nunca foi algo que uma auditoria do lado do tenant pudesse observar ou corrigir diretamente. O que a EtcSec verifica, continuamente, é o conjunto de condições do lado do tenant que determinam quanto dano qualquer bypass da classe impersonação (este ou o próximo) pode causar: atribuições permanentes de Global Administrator (PA_TOO_MANY_GLOBAL_ADMINS, PA_PERMANENT_ADMIN_ASSIGNMENTS), contas admin sem MFA forte (PA_GLOBAL_ADMIN_NOT_MFA) e tenants que ainda permitem caminhos de legacy authentication fora da aplicação do Conditional Access (CA_NO_LEGACY_AUTH_BLOCK).