Registro de Aplicativo Entra com Permissões Perigosas do Graph API: Detecção e Correção

Permissões perigosas do Graph API em registros de aplicativo Entra transformam um único clique de admin consent em uma credencial permanente e válida para todo o tenant. Directory.ReadWrite.All, Mail.ReadWrite, Files.ReadWrite.All e RoleManagement.ReadWrite.Directory são permissões de aplicativo (app-only) — concessões que permitem que um service principal atue em todo um tenant do Microsoft 365 sem usuário conectado e sem escopo por objeto. Este guia explica o que cada permissão realmente permite, uma cadeia de ataque documentada que as encadeia até o controle total de Administrador Global, e como detectar e corrigir essas concessões.

Permissões Perigosas do Graph API em Registros de Aplicativo Entra Explicadas

As quatro são permissões de aplicativo, também chamadas de permissões app-only. A própria documentação do Graph da Microsoft deixa a linha clara: permissões de aplicativo "funcionam no cenário de acesso somente-aplicativo, sem um usuário conectado presente", e o app "pode acessar qualquer dado associado à permissão". Uma permissão delegada é limitada pelo que o usuário conectado já pode ver; uma permissão de aplicativo não é limitada por ninguém.

As quatro permissões exigem admin consent, e a Microsoft restringe quem pode concedê-las a Privileged Role Administrator e Administrador Global. Esse único clique de consentimento — geralmente feito uma vez, durante o onboarding, por quem quer que estivesse na sala — é o que transforma um registro de aplicativo em uma concessão de acesso permanente e válida para todo o tenant, que ninguém mais revisita.

Fonte: Microsoft Graph Permissions Reference.

Como Funciona

Uma permissão de aplicativo se vincula a um service principal, a identidade local do tenant para um registro de aplicativo. Uma vez concedida, o service principal se autentica com sua própria credencial — um client secret ou certificado — usando o fluxo OAuth 2.0 client credentials. O access token resultante carrega a permissão na claim roles, e o Microsoft Graph aplica o controle de acesso somente com base nessa claim. Não há contexto de usuário para recorrer, nem limite de consentimento por recurso: um app com Files.ReadWrite.All pode acessar um arquivo que nunca foi compartilhado com ele, em um site com o qual não tem nenhuma outra relação.

RoleManagement.ReadWrite.Directory está em uma categoria ainda menor e mais perigosa. A própria documentação de permissões da Microsoft sinaliza uma classe de "permissões que permitem conceder autorização" — permissões que deixam um aplicativo distribuir privilégios adicionais a si mesmo, a outros aplicativos ou a qualquer usuário — como merecedoras de cuidado especial (Microsoft Graph Permissions Reference). RoleManagement.ReadWrite.Directory é exatamente esse tipo de permissão para as funções de diretório do Entra: um app que a possui pode atribuir qualquer função interna do Entra, incluindo Administrador Global, a qualquer principal de segurança — incluindo a si mesmo.

A Cadeia de Ataque: De uma Credencial Vazada ao Administrador Global

Isso não é uma composição teórica de duas permissões perigosas — é uma técnica documentada. A pesquisa da Semperis (publicada como "EntraGoat Scenario 2") percorre exatamente esse caminho de escalada do início ao fim.

Passo 1 — Exposição de Credencial

Um atacante recupera um certificado codificado em base64 e uma senha deixados em artefatos de pipeline de CI/CD.

Passo 2 — Atribuição

A impressão digital (thumbprint) do certificado é comparada com os metadados keyCredentials.customKeyIdentifier de um service principal, identificando a qual app ele pertence.

Passo 3 — Autenticação App-Only

O atacante se autentica como o service principal via fluxo OAuth 2.0 client credentials — sem prompt de MFA, sem política de Conditional Access de login a satisfazer, porque não há nenhum login interativo.

Passo 4 — Reconhecimento

O atacante inspeciona a claim roles do token e descobre que o service principal já possui AppRoleAssignment.ReadWrite.All — uma permissão que permite atribuir funções de app do Graph a qualquer service principal, incluindo a si mesmo.

Passo 5 — Auto-Escalada

Usando essa permissão, o atacante atribui RoleManagement.ReadWrite.Directory ao mesmo service principal.

Passo 6 — Atribuição de Função

Com um token novo carregando a nova permissão, o atacante adiciona o service principal à função de diretório Administrador Global — uma chamada tão simples quanto New-MgDirectoryRoleMemberByRef contra o ID de modelo de função conhecido do Administrador Global (62e90394-69f5-4237-9190-012177145e10).

Passo 7 — Controle Total

Como as funções de diretório do Entra são avaliadas dinamicamente em tempo de execução, em vez de embutidas no token, o service principal já é um Administrador Global totalmente privilegiado na próxima chamada — a partir daí, o atacante pode redefinir a senha de qualquer administrador.

AppRoleAssignment.ReadWrite.All (já concedida)
        |
        v
  atribuir RoleManagement.ReadWrite.Directory a si mesmo
        |
        v
  adicionar service principal à função Administrador Global
        |
        v
  redefinir senha do admin alvo -> controle total do tenant

🚨 Perigo: O Passo 4 é a parte que os defensores mais deixam passar. O resultado perigoso aqui não é uma única permissão superprivilegiada — é a combinação. AppRoleAssignment.ReadWrite.All sozinha permite que um app conceda permissões do Graph a service principals; RoleManagement.ReadWrite.Directory sozinha permite que um app gerencie funções de diretório. Nenhuma revisão pega o par, a menos que alguém esteja procurando especificamente por permissões que concedem permissões.

Detecção

Concentre a detecção no momento em que uma permissão perigosa é concedida e no momento em que ela é usada para tocar em funções de diretório — ambos são registrados por padrão no log de auditoria do Microsoft Entra, sem necessidade de add-on premium.

Esta é a própria orientação documentada da Microsoft — veja Microsoft Entra security operations for applications, que também traz detecções prontas do Microsoft Sentinel exatamente para esse padrão de "função de app com acesso sensível" e para ServicePrincipalAssignedPrivilegedRole.

Faça o Baseline das Concessões Existentes

Para estabelecer uma base do que já foi concedido, consulte diretamente as atribuições de função de app existentes em vez de esperar o próximo evento de auditoria:

# Enumerar service principals com qualquer uma das quatro permissões perigosas
$dangerousRoleIds = @(
    "19dbc75e-c2e2-444c-a770-ec69d8559fc7", # Directory.ReadWrite.All
    "e2a3a72e-5f79-4c64-b1b1-878b674786c9", # Mail.ReadWrite
    "75359482-378d-4052-8f01-80520e7db3cd", # Files.ReadWrite.All
    "9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8"  # RoleManagement.ReadWrite.Directory
)
$graphSp = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"
Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $graphSp.Id -All |
    Where-Object { $_.AppRoleId -in $dangerousRoleIds }

Também observe os logs de atividade do Microsoft Graph em busca de um service principal que subitamente começa a chamar /roleManagement/directory/roleAssignments ou /servicePrincipals/{id}/appRoleAssignedTo — endpoints que uma integração normal (sincronização de e-mail, de arquivos, de diretório) não teria motivo para tocar.

Correção

1. Classifique as quatro permissões como alto impacto. Em Entra ID > Aplicativos empresariais > Consentimento e permissões > Classificações de permissão, marque Directory.ReadWrite.All, Mail.ReadWrite, Files.ReadWrite.All e RoleManagement.ReadWrite.Directory como alto impacto para que usuários comuns nunca possam consentir com elas, mesmo que o consentimento de usuário esteja habilitado (Configure how users consent to applications).
2. Direcione tudo o mais pelo fluxo de admin consent. Habilite o fluxo de admin consent para que um usuário bloqueado possa solicitar uma revisão em vez de a solicitação simplesmente desaparecer — mas combine com o passo 1, já que o fluxo só importa se os usuários não puderem simplesmente se autoconsentir por fora dele.
3. Prefira permissões mais restritas. Mail.ReadWrite e Files.ReadWrite.All frequentemente têm escopo maior do que a integração realmente precisa — uma application access policy pode restringir Mail.ReadWrite a caixas de correio específicas em vez de todas do tenant, e o resource-specific consent pode reduzir o acesso a arquivos abaixo de Files.ReadWrite.All.
4. Trate a credencial como um segredo Tier 0. Cada uma dessas permissões só é tão segura quanto o certificado ou client secret que a protege — veja rotação de credenciais de registro de aplicativo Entra para saber como são, na prática, secrets "obsoletos" e "compartilhados demais", e nunca deixe um em um artefato de CI/CD como descreve a pesquisa da Semperis.
5. Restrinja onde o service principal pode sequer se autenticar. Conditional Access para identidades de carga de trabalho aplica políticas de localização e risco de login às autenticações de service principal no Microsoft Graph, e a continuous access evaluation para identidades de carga de trabalho revoga um token quase em tempo real se o sinal de risco mudar durante a sessão.
6. Reexecute o relatório de concessões de consentimento de apps periodicamente, não apenas no onboarding — uma auditoria de concessão de consentimento revela permissões que ninguém mais lembra de ter aprovado, e uma permissão que fazia sentido duas reorganizações atrás raramente ainda faz.
7. Inclua atribuições de função de service principals na sua revisão de acesso privilegiado, junto com as atribuições humanas de PIM — um service principal como Administrador Global é exatamente tão perigoso quanto um Administrador Global humano permanente, e a CVE-2025-55241 é um lembrete de quanto alcance essa única função carrega.

Como o EtcSec Detecta Isso

A auditoria de Entra ID do EtcSec verifica exatamente essa exposição: APP_DANGEROUS_PERMISSION_DIR, APP_DANGEROUS_PERMISSION_MAIL, APP_DANGEROUS_PERMISSION_FILES e APP_DANGEROUS_PERMISSION_ROLE sinalizam cada um um service principal que possui uma das quatro permissões acima, e APP_CONSENT_GRANTED_TENANT_WIDE sinaliza concessões de consentimento com escopo para todos os usuários do tenant em vez de um grupo delimitado.