OAuth Consent Phishing: como apps maliciosos contornam o roubo de senhas

OAuth consent phishing é um ataque de identidade em que um usuário ou administrador é induzido a conceder permissões a um aplicativo OAuth malicioso. Depois que o consentimento é aprovado, o atacante não precisa necessariamente da senha do usuário. O aplicativo pode acessar Microsoft 365 ou outros recursos protegidos conforme as permissões concedidas, o que torna esse cenário diferente de phishing de credenciais, password spraying ou fadiga de MFA.

O escopo deste artigo é Microsoft Entra ID, Microsoft 365 e consentimento de aplicativos baseado em OAuth. Nem todo login malicioso é consent phishing. O foco é o consent grant em si: o que o app recebe, como defensores podem enxergar isso, como remover e como evitar que o mesmo caminho volte a aparecer.

O que é OAuth Consent Phishing?

OAuth consent phishing abusa de um modelo legítimo de consentimento. A Microsoft descreve consent phishing como ataques que enganam usuários para conceder permissões a aplicativos cloud maliciosos. A tela de consentimento mostra as permissões que o aplicativo recebe, mas um nome crível, um logotipo familiar ou um pretexto de negócio convincente ainda podem levar um usuário ou administrador a aprovar um acesso que não deveria ser concedido.

Na Microsoft identity platform, OAuth permite que um aplicativo solicite acesso a um recurso protegido. A RFC 6749 define OAuth 2.0 como um framework que permite que um aplicativo de terceiros obtenha acesso limitado a um serviço HTTP, em nome do proprietário do recurso ou em nome próprio. O Microsoft Entra ID implementa esse modelo para recursos como Microsoft Graph, Exchange Online, SharePoint Online e outras APIs integradas à plataforma de identidade da Microsoft.

Limites de escopo

O ponto defensivo mais importante é que consent phishing mira autorização, não apenas autenticação. Em um incidente de phishing de senha, a equipe normalmente pergunta se credenciais foram roubadas, se MFA foi satisfeita e se existe uma sessão suspeita. Em OAuth consent phishing, também é necessário perguntar se um aplicativo recebeu um permission grant durável que continua relevante depois da sessão interativa inicial.

Esse risco é próximo do descrito em Azure App Registrations: Over-Privileged Tenant Apps, mas o caminho de ataque é diferente. Apps legítimos com privilégios excessivos geralmente são um problema de governança interna. OAuth consent phishing é um app malicioso ou enganoso obtendo acesso por meio de uma tela de consentimento.

Como OAuth Consent Phishing funciona

A cadeia de ataque começa com uma solicitação normal de autorização OAuth. Um usuário segue um link ou abre um aplicativo que o envia para a Microsoft identity platform. O usuário se autentica se necessário. Se as permissões solicitadas ainda não tiverem consentimento, o Microsoft Entra apresenta um prompt de consentimento. Esse prompt inclui as permissões solicitadas e as informações do publisher.

Estado de consentimento, não apenas estado de login

Se o usuário ou administrador aprova a solicitação, o Microsoft Entra registra um grant para o aplicativo. Para permissões delegadas do Microsoft Graph, o resultado do consentimento é representado como OAuth2PermissionGrant. Para permissões de aplicativo, o resultado é representado como appRoleAssignment. Esses dois objetos importam porque são eles que defensores precisam enumerar, revisar e remover durante a limpeza.

Um app malicioso não precisa pedir todas as permissões de uma vez. A Microsoft documenta consentimento dinâmico como um caso em que um aplicativo solicita novas permissões em tempo de execução. Isso torna a revisão de consentimento mais do que um controle inicial de onboarding. Um tenant pode estar limpo em uma revisão inicial e receber depois uma solicitação de acesso mais ampla se o app foi desenvolvido para pedir scopes adicionais.

Nuance sobre offline_access

O scope offline_access também muda o modelo defensivo. A Microsoft documenta offline_access como acesso a recursos em nome do usuário por um período estendido. Na página de consentimento, esse scope aparece como manter acesso aos dados aos quais o app já recebeu acesso. A Microsoft também observa que, se qualquer permissão delegada for concedida, offline_access é concedido implicitamente, e que refresh tokens são de longa duração. Isso não significa que o atacante tem acesso permanente. Significa que a resposta a incidente deve incluir remoção de grants e limpeza de tokens ou sessões, não apenas reset de senha.

Por isso OAuth consent phishing fica próximo, mas separado, de outros ataques de identidade Entra. Device Code Phishing: How OAuth Device Flow Compromises Entra ID Accounts abusa de um fluxo OAuth diferente. Ambos os ataques são centrados em OAuth, mas device code phishing autoriza uma sessão via device code flow, enquanto consent phishing concede permissões a um aplicativo.

Permissões delegadas vs permissões de aplicativo

A separação técnica mais importante é entre permissões delegadas e permissões de aplicativo.

Acesso delegado

Permissões delegadas são usadas quando um aplicativo age em nome de um usuário conectado. A Microsoft as descreve como permissões que permitem ao aplicativo agir em nome do usuário, sem acessar algo que o usuário conectado não poderia acessar. Se um usuário concede uma permissão delegada para ler email, o acesso do app depende do que esse usuário pode ler. Se um administrador privilegiado concede permissões delegadas enquanto está conectado, o impacto pode ser muito maior porque os privilégios do usuário são maiores.

Acesso app-only

Permissões de aplicativo, também chamadas de app roles ou permissões app-only, são usadas quando não há usuário conectado. A Microsoft descreve acesso app-only como o aplicativo agindo com sua própria identidade. Permissões de aplicativo podem permitir amplo acesso a dados do tenant via Microsoft Graph ou outra API de recurso. A Microsoft indica que, em geral, apenas um administrador ou o proprietário do service principal de uma API pode consentir às permissões de aplicativo expostas por essa API.

Triagem por tipo de permissão

A distinção orienta a prioridade de investigação. Um grant delegado suspeito de um usuário pouco privilegiado pode expor caixa de correio, arquivos ou recursos acessíveis por esse usuário. Uma permissão de aplicativo suspeita pode ter alcance tenant-wide, dependendo da permissão e da API de recurso. A Microsoft usa Files.Read.All para ilustrar a diferença: Files.Read.All delegado permite que o app leia arquivos que o usuário pode acessar pessoalmente, enquanto Files.Read.All como permissão de aplicativo pode ler qualquer arquivo no tenant via Microsoft Graph depois de concedida.

Não reduza os dois casos a um risco genérico de app OAuth. O objeto de limpeza, blast radius, caminho de aprovação e validação são diferentes.

Por que MFA não bloqueia sozinha o abuso de consentimento

MFA continua importante. Ela reduz a chance de um atacante conseguir entrar como usuário, aprovar prompts como esse usuário ou concluir outras ações interativas. O problema é mais específico: MFA não torna automaticamente inofensivo um permission grant OAuth já concedido.

Quando um app malicioso tem um grant delegado válido, ele pode solicitar tokens conforme esse grant e o contexto usuário/recurso. Quando um app tem permissões de aplicativo, ele pode operar sem usuário conectado para os dados cobertos por essa permissão. Conditional Access e políticas MFA ainda podem influenciar como tokens são emitidos em cenários específicos, mas a existência de um consent grant precisa ser investigada diretamente.

É a mesma lição geral coberta em Azure Identity Security: Why MFA Alone Is Not Enough. MFA é um controle. Ela não substitui governança de app consent, revisão de permissões, monitoramento de audit logs, avaliação de publisher ou revogação de grants suspeitos. Se sua equipe também acompanha engenharia social baseada em notificações push, MFA Fatigue: Detection and Prevention for Microsoft Entra ID cobre um padrão separado que pode ocorrer antes ou junto do abuso de consentimento.

O erro prático é encerrar o incidente depois de redefinir uma senha ou confirmar que MFA estava habilitada. Em um caso de consent phishing, isso é incompleto. A resposta precisa determinar se existe um service principal, quais grants estão associados, quais usuários consentiram, se houve admin consent e se o app foi desabilitado, removido ou bloqueado para receber novos grants.

A cadeia de ataque

Uma cadeia realista de OAuth consent phishing tem várias fases. O lure exato pode variar, mas os pontos de controle permanecem consistentes.

1. O atacante prepara ou controla um aplicativo capaz de solicitar permissões da Microsoft identity platform.
2. Um usuário ou admin recebe uma URL de autorização que apresenta uma experiência de login e consentimento hospedada pela Microsoft.
3. O prompt de consentimento lista permissões e informações do publisher. O usuário ou admin aprova a solicitação.
4. O Microsoft Entra registra o grant. Permissões delegadas aparecem como OAuth2PermissionGrant; permissões de aplicativo aparecem como appRoleAssignment.
5. O app usa access tokens, e potencialmente refresh tokens quando disponíveis, para chamar APIs como Microsoft Graph conforme as permissões concedidas.
6. O atacante mantém acesso até que defensores revoguem grants, desabilitem ou removam o service principal malicioso quando apropriado, bloqueiem re-consentimento, invalidem sessões/tokens relevantes ou a Microsoft desabilite um aplicativo que viola termos de serviço.

O que isso não é

Essa cadeia não é password spraying, em que o atacante testa credenciais contra muitas contas. Não é Kerberoasting, em que o alvo é material de ticket de serviço Kerberos no Active Directory. Também não é OAuth device code phishing normal, em que o atacante persuade o usuário a concluir uma autorização via device code. Essas distinções importam porque telemetria e remediação são diferentes.

Para defensores, o objetivo da cadeia é identificar estado durável. Um login suspeito é investigado por sign-in logs. Um consent grant suspeito é investigado por objetos de aplicação, permission grants, audit logs e controles de app governance.

Detecção

Nenhum evento único do Microsoft Entra prova OAuth consent phishing sozinho. Um administrador legítimo pode consentir a um app legítimo. Um usuário legítimo pode aprovar uma permissão delegada de baixo risco. Detecção exige correlação entre atividade de consentimento, metadados do app, permissões, contexto de usuário e comportamento API posterior.

Pivôs em audit logs

Comece pelos audit logs do Microsoft Entra. A Microsoft documenta estas atividades de permissões de aplicativo no serviço Core Directory e categoria ApplicationManagement:

Perguntas de correlação

Use esses eventos como pivôs, não como veredictos finais. Uma detecção útil pergunta:

• O app foi recém-adicionado ao tenant?
• O publisher é verificado e corresponde ao propósito de negócio?
• Quais permissões foram solicitadas, e são permissões de baixo risco ou de alto impacto em dados?
• O ator era usuário comum, admin, conta break-glass ou conta fora do comportamento normal?
• O consentimento foi concedido pouco depois de login suspeito, sinal de impossible travel, risky user ou relato de phishing?
• O aplicativo começou a chamar Microsoft Graph, Exchange, SharePoint ou outras APIs de forma incompatível com um workflow aprovado?
• Vários usuários autorizaram o mesmo aplicativo incomum?

Defender for Cloud Apps pode adicionar outra camada quando disponível. A Microsoft documenta OAuth app policies que podem alertar sobre aplicativos com alto nível de permissão, muitos usuários autorizadores, uso incomum, nomes enganosos, nomes de publisher enganosos ou consentimento OAuth potencialmente malicioso. Trate esses alertas como sinais de priorização e ainda inspecione o service principal e os grants subjacentes.

Uma detecção madura também observa deriva de governança. Se user consent settings são relaxados, app consent policies mudam ou reviewers são removidos do admin consent workflow, o tenant se torna mais fácil de abusar. Essas mudanças não provam sozinhas um app malicioso, mas reduzem a força de controle sobre futuras solicitações de consentimento. Combine esse monitoramento com How to Audit Microsoft Entra ID Security para revisar app consent junto com Conditional Access, funções privilegiadas, usuários de risco e configurações tenant-wide.

Em investigações híbridas, mantenha a fronteira clara: este artigo foca atividade de auditoria Entra, mas Active Directory Monitoring: Security Event IDs That Matter pode ajudar incident responders a correlacionar atividade de identidade on-premises quando o mesmo usuário ou admin está envolvido.

Remediação

A remediação tem duas linhas: remover o acesso malicioso confirmado e fechar o caminho de consentimento que permitiu isso.

Remover grants existentes

Primeiro identifique o objeto de aplicação e o service principal em Enterprise Applications. Revise as abas Admin consent e User consent para permissões concedidas. A Microsoft documenta que administradores podem revogar permissões organization-wide na aba Admin consent, enquanto grants de user consent podem exigir Microsoft Graph API ou PowerShell. Para limpeza completa, enumere permissões delegadas e permissões de aplicativo.

Para permissões delegadas, remova objetos OAuth2PermissionGrant suspeitos. Para permissões de aplicativo, remova entradas appRoleAssignment suspeitas. A documentação da Microsoft sobre revisão de permissões fornece caminhos Graph e PowerShell para ambos os casos. Se usuários ou grupos foram atribuídos ao aplicativo, revise e remova essas atribuições como parte da contenção.

Conter o service principal

Depois desabilite ou remova o service principal quando o aplicativo for confirmado como malicioso ou não autorizado. Tenha cuidado com aplicativos que têm uso suspeito e legítimo ao mesmo tempo; remover um service principal pode quebrar workflows de negócio. Se a Microsoft desabilitou um aplicativo OAuth por violar termos de serviço, a Microsoft documenta que novas solicitações de token e refresh token são negadas, mas access tokens existentes continuam válidos até expirar. Por isso a resposta não deve depender de uma única ação.

Depois trate tokens e sessões. Para abuso delegado, revogue refresh tokens ou invalide sessões de usuário quando apropriado. Para abuso app-only, concentre-se em remover app role assignments, remover credenciais do service principal se ele for tenant-owned, desabilitar o service principal e validar que não resta nenhum grant app-only. Reset de senha pode ser relevante se o usuário também foi phished, mas não remove um grant OAuth sozinho.

Reforçar consentimentos futuros

Por fim, reforce a governança de consentimento:

• Revise user consent settings e evite consentimento amplo de usuários para aplicativos e permissões que deveriam exigir revisão admin.
• Use app consent policies para restringir ao que usuários podem consentir com base em critérios como verified publisher e risco de permissão.
• Habilite e configure admin consent workflow para que usuários solicitem acesso a apps que exigem aprovação em vez de usar canais informais.
• Limite quem pode conceder tenant-wide admin consent. A Microsoft recomenda funções de menor privilégio e alerta que Global Administrator é altamente privilegiado.
• Avalie publisher verification como um sinal, não como aprovação completa de segurança. A Microsoft afirma explicitamente que um badge de verified publisher não implica critérios de qualidade, certificações, compliance ou security best practices.
• Use OAuth app policies do Defender for Cloud Apps quando disponíveis para alertar sobre apps arriscados, incomuns, com alto nível de permissão ou potencialmente maliciosos.

Não crie uma regra global que bloqueia todos os apps de terceiros sem processo de exceção. Isso geralmente leva usuários a workarounds não gerenciados. A abordagem mais forte é um caminho controlado de consentimento: permissões delegadas de baixo risco permitidas, revisão admin para scopes delegados sensíveis e permissões de aplicativo, e revisão periódica de apps já aprovados.

Validação após limpeza

Validação é onde muitas respostas a consent phishing falham. Um ticket não deve ser encerrado porque o app desapareceu de uma página visível do portal. Ele deve ser encerrado porque os caminhos duráveis de autorização foram verificados.

Checklist de encerramento

Use esta sequência de validação:

1. Confirmar que o service principal suspeito está desabilitado ou removido quando o app for confirmado como malicioso.
2. Confirmar que nenhum OAuth2PermissionGrant delegado suspeito permanece para o client service principal.
3. Confirmar que nenhum appRoleAssignment suspeito permanece para permissões app-only.
4. Confirmar que atribuições de usuários e grupos ao aplicativo foram removidas se contribuíam para acesso.
5. Confirmar que audit logs mostram os eventos de remoção esperados, como remoção de delegated permission grants ou app role assignments.
6. Confirmar que user consent settings, app consent policies e admin consent workflow correspondem ao modelo de controle pretendido.
7. Confirmar que usuários relevantes tiveram sessões/tokens revogados quando acesso delegado esteve envolvido.
8. Confirmar que Defender for Cloud Apps ou app governance, se implantados, não mostram mais o app como autorizado ou ativo.
9. Confirmar que novas tentativas de conceder o mesmo caminho de permissões exigem o admin workflow esperado ou são bloqueadas por policy.

Para investigações tenant-wide, combine isso com Azure Identity Protection: Blocking Leaked Credentials. Consent phishing não é o mesmo que credenciais vazadas, mas sinais de risky user e risky sign-in podem ajudar a decidir se o usuário que concedeu consentimento também estava comprometido.

Como a EtcSec detecta exposição relacionada

A EtcSec deve tratar OAuth consent phishing como um padrão de exposição entre inventário de aplicativos, governança de identidade e prontidão de monitoramento. O check útil não é apenas se existe um app malicioso. O check útil é se o tenant tornaria consentimento malicioso fácil de obter, difícil de detectar ou lento de revogar.

Sinais de exposição

Checks relevantes incluem:

• Enterprise Applications com permissões delegadas amplas ou permissões app-only amplas de Microsoft Graph.
• Aplicativos autorizados por muitos usuários sem owner claro ou justificativa de negócio.
• Aplicativos sem verified publisher, especialmente quando solicitam permissões sensíveis.
• User consent settings que permitem aos usuários aprovar mais do que permissões delegadas de baixo risco.
• Admin consent workflow ausente ou fraco.
• Falta de revisão recorrente para admin consent e user consent grants.
• Permissões de aplicativo incoerentes com o propósito declarado do app.
• Usuários privilegiados que consentiram apps de terceiros a partir de dispositivos ou contextos de menor confiança.
• Lacunas de monitoramento em Consent to application, Add delegated permission grant e Add app role assignment to service principal.

Este tema é adjacente a Azure Conditional Access: MFA Bypass With Stolen Passwords, mas a remediação é diferente. Conditional Access continua parte da defesa de identidade, mas hardening de OAuth consent exige app governance, revisão de permissões, consent policies e limpeza de service principals.

Controles relacionados

OAuth consent phishing é melhor gerenciado como um conjunto de controles, não como um único botão.

Esses controles também reduzem exposição causada por aplicativos legítimos com permissões excessivas. A governança de consentimento passa a fazer parte das operações normais de segurança Entra, não apenas da resposta após relato de phishing.

Referências primárias

As afirmações técnicas deste artigo se baseiam em documentação primária e padrões:

• Microsoft Learn: Protect against consent phishing
• Microsoft Learn: Permissions and consent overview
• Microsoft Learn: Scopes and permissions in the Microsoft identity platform
• Microsoft Learn: Configure the admin consent workflow
• Microsoft Learn: Manage app consent policies
• Microsoft Learn: Review permissions granted to enterprise applications
• Microsoft Learn: View activity logs of application permissions
• Microsoft Learn: Microsoft Entra audit log activity reference
• Microsoft Learn: Publisher verification
• Microsoft Defender for Cloud Apps: Create policies to control OAuth apps
• RFC 6749: The OAuth 2.0 Authorization Framework
• RFC 6819: OAuth 2.0 Threat Model and Security Considerations