Az - Illicit Consent Grant
OAuth App Phishing
Azure Applications pedem permissões para acessar os dados do usuário (informações básicas, mas também acesso a documentos, envio de e-mails...).
Se permitido, um usuário normal pode conceder consentimento apenas para "permissões de baixo impacto". Em todos os outros casos, é necessário o consentimento do administrador.
GA
, ApplicationAdministrator
, CloudApplication
Administrator
e uma função personalizada incluindo permissão para conceder permissões a aplicativos
podem fornecer consentimento para todo o locatário.
Apenas permissões que não requerem consentimento do administrador são classificadas como baixo impacto. Estas são permissões necessárias para login básico são openid, profile, email, User.Read e offline_access. Se uma organização permite o consentimento do usuário para todos os aplicativos, um funcionário pode conceder consentimento a um aplicativo para ler as informações acima do seu perfil.
Portanto, um atacante poderia preparar um App malicioso e com um phishing, fazer o usuário aceitar o App e roubar seus dados.
2 Tipos de Ataques de Concessão de Consentimento Ilícito
Não autenticado: De uma conta externa, crie um aplicativo com as permissões
User.Read
eUser.ReadBasic.All
, por exemplo, faça phishing de um usuário e você poderá acessar informações do diretório.Isso requer que o usuário phished possa aceitar aplicativos OAuth de ambientes externos!
Autenticado: Tendo comprometido um principal com privilégios suficientes, crie um aplicativo dentro da conta e faça phishing de algum usuário privilegiado que possa aceitar permissões OAuth privilegiadas.
Nesse caso, você já pode acessar as informações do diretório, então a permissão
User.ReadBasic.All
não é mais interessante.Você provavelmente está interessado em permissões que exigem um administrador para concedê-las, porque o usuário comum não pode dar a aplicativos OAuth nenhuma permissão, por isso você precisa fazer phishing apenas desses usuários (mais sobre quais funções/permissões concedem esse privilégio mais tarde)
Verificar se os usuários estão autorizados a consentir
O seguinte comando PowerShell é usado para verificar a configuração de consentimento para usuários no Azure Active Directory (Azure AD) em relação à sua capacidade de consentir em aplicativos:
Desabilitar consentimento do usuário: Esta configuração proíbe os usuários de conceder permissões a aplicativos. Nenhum consentimento do usuário para aplicativos é permitido.
Usuários podem consentir com aplicativos de editores verificados ou da sua organização, mas apenas para permissões que você selecionar: Esta configuração permite que todos os usuários consintam apenas com aplicativos publicados por um editor verificado e aplicativos registrados no seu próprio tenant. Adiciona uma camada de controle permitindo consentimento apenas para permissões específicas.
Usuários podem consentir com todos os aplicativos: Esta configuração é mais permissiva e permite que todos os usuários consintam com quaisquer permissões para aplicativos, desde que essas permissões não exijam consentimento administrativo.
Política de consentimento de aplicativo personalizada: Esta configuração indica que uma política personalizada está em vigor, que pode ser adaptada a requisitos organizacionais específicos e pode envolver uma combinação de restrições baseadas no editor do aplicativo, nas permissões solicitadas pelo aplicativo e outros fatores.
Entendendo o Ataque de Concessão de Consentimento Ilícito
Em um ataque de concessão de consentimento ilícito, os atacantes enganam os usuários finais para que concedam permissões a um aplicativo malicioso registrado no Azure. Isso é feito fazendo o aplicativo parecer legítimo, levando as vítimas a clicarem inadvertidamente em um botão "Aceitar". Como resultado, o Azure AD emite um token para o site do atacante, permitindo que eles acessem e manipulem os dados da vítima, como ler ou enviar e-mails e acessar arquivos, sem precisar de uma conta organizacional.
Visão Geral do Fluxo do Ataque
O ataque envolve várias etapas direcionadas a uma empresa genérica. Veja como pode se desenrolar:
Registro de Domínio e Hospedagem de Aplicativo: O atacante registra um domínio que se assemelha a um site confiável, por exemplo, "safedomainlogin.com". Sob este domínio, um subdomínio é criado (por exemplo, "companyname.safedomainlogin.com") para hospedar um aplicativo projetado para capturar códigos de autorização e solicitar tokens de acesso.
Registro de Aplicativo no Azure AD: O atacante então registra um Aplicativo Multi-Tenant no seu Azure AD Tenant, nomeando-o com o nome da empresa alvo para parecer legítimo. Eles configuram a URL de Redirecionamento do aplicativo para apontar para o subdomínio que hospeda o aplicativo malicioso.
Configuração de Permissões: O atacante configura o aplicativo com várias permissões de API (por exemplo,
Mail.Read
,Notes.Read.All
,Files.ReadWrite.All
,User.ReadBasic.All
,User.Read
). Essas permissões, uma vez concedidas pelo usuário, permitem que o atacante extraia informações sensíveis em nome do usuário.Distribuição de Links Maliciosos: O atacante cria um link contendo o id do cliente do aplicativo malicioso e o compartilha com usuários alvo, enganando-os para que concedam consentimento.
Utilizando Ferramentas para o Ataque
O ataque pode ser facilitado usando ferramentas como 365-Stealer.
Preparação Pré-Ataque:
Se o atacante tiver algum nível de acesso a um usuário na organização da vítima, ele pode verificar se a política da organização permite que o usuário aceite aplicativos:
Para executar o ataque, o atacante precisaria criar um novo App em seu Azure Tenant (em Registros de Aplicativos), configurado com as permissões:
User.ReadBasic.All
está dentro de Microsoft Graph
em Delegated permissions
. (Permissões de Aplicação sempre precisarão de aprovação extra).
User.ReadBasic.All
é a permissão que permitirá ler informações de todos os usuários na organização, se concedida.Lembre-se de que apenas
GA
,ApplicationAdministrator
,CloudApplication
Administrator
e uma função personalizada incluindopermissão para conceder permissões a aplicativos
podem fornecer consentimento em todo o tenant. Portanto, você deve phish um usuário com um desses papéis se quiser que ele aprove um App que requer consentimento de administrador.
Você também pode criar um App via cli com:
Confira https://www.alteredsecurity.com/post/introduction-to-365-stealer para aprender como configurá-lo.
Note que o access token obtido será para o graph endpoint com os escopos: User.Read
e User.ReadBasic.All
(as permissões solicitadas). Você não poderá realizar outras ações (mas essas são suficientes para baixar informações sobre todos os usuários na organização).
Você também pode usar esta ferramenta para realizar este ataque.
Pós-Exploração
Uma vez que você tenha acesso ao usuário, pode fazer coisas como roubar documentos sensíveis e até mesmo fazer upload de arquivos de documentos com backdoor.
Referências
Last updated