Azure Pentesting

Theory

Azure is Microsoft's comprehensive cloud computing platform that offers various services including virtual machines, databases, artificial intelligence, storage, and more. It serves as the foundation for hosting applications and managing infrastructure.

Entra ID (formerly Azure Active Directory or AAD) is a cloud-based identity and access management service that handles authentication and authorization for Microsoft services like Office 365, Azure, and third-party applications. It provides features such as single sign-on (SSO), multi-factor authentication (MFA), and conditional access policies.

https://www.synacktiv.com/en/publications/azure-ad-introduction-for-red-teamers.html#azure-ad-overview

Entra Domain Services (formerly Azure AD DS) extends Entra ID by providing managed domain services compatible with traditional Windows Active Directory environments. It supports legacy protocols like LDAP, Kerberos, and NTLM, allowing organizations to run older applications in the cloud without deploying on-premises domain controllers.

Azure Organization Hierarchy

Understanding the hierarchical structure of Azure resources is critical for identifying potential attack paths:

1. Management Groups: Contains other management groups or subscriptions, allowing governance controls such as RBAC and Azure Policy to be applied and inherited by all subscriptions in the group.

   • A single directory can support up to 10,000 management groups

   • Management group trees can be up to 6 levels deep (excluding root level and subscription level)

   • Each management group and subscription can have only one parent

   • All subscriptions within a management group must trust the same Entra ID tenant

   
2. Subscriptions: Logical containers where resources are deployed and billed.

   • Parent is always a management group

   • Can only trust one Entra ID directory

   • Permissions applied at this level are inherited by all resources inside

3. Resource Groups: Containers holding related resources that share the same lifecycle.

   • All resources must be inside a resource group

   • Resources can only belong to one group

   • When a resource group is deleted, all resources inside are also deleted

   
4. Resources: Individual services (VMs, databases, storage accounts, etc.)

Azure Resource IDs

Every resource in Azure has a unique Resource ID with the format: /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}

Example for a VM named "myVM": /subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myV

Entra ID Principals and Identity Components

Identity Principals in Entra ID (Azure AD) are security entities that can be authenticated and authorized to access resources.

Principals are the cornerstone of Azure's security model as they represent "who" is trying to access "what" resources. Understanding principals is crucial for red teamers and pentesters as they often represent potential entry points, privilege escalation paths, and persistence opportunities.

Every principal in Azure can:

• Be assigned access rights through Azure RBAC roles and Entra ID roles

• Be authenticated through various mechanisms (passwords, certificates, tokens)

• Have their access restricted through Conditional Access Policies

• Leave audit trails in logs when accessing resources

Users

Users are the most basic type of principal, representing human identities in the system.

Types of Users

• Members – Regular users within the organization (employees, contractors).

• Guests – External users invited from other organizations or personal accounts.

Below is a quick overview of defult permissions for members and guest. More details can be found on this link: https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions

Category	Members	Guests (Default Limited Access)
Directory Read	Can read all users, groups, applications, devices, roles, subscriptions	Limited to own profile only
Group Management	• Create security groups • Read non-hidden group memberships • Add guests to owned groups	• Cannot create groups • Can only see owned group memberships
Application	• Create new applications (configurable) • Read all applications	Cannot create applications
Device	Can add up to 50 devices (configurable)	Cannot register devices
Guest Invitation	Can invite guests (configurable)	Cannot invite guests by default
Profile	Full access to own profile	Limited access to own profile
Portal Access	Access to admin portal (configurable)	Limited portal access
Resource Access	Requires explicit permissions	Requires explicit permissions

Note: All these permissions can be further restricted by administrators through organizational settings.

Groups

Groups are collections of users and other principals. There are 2 types of groups:

• Security: This type of group is used to give members access to aplications, resources and assign licenses. Users, devices, service principals and other groups an be members.

• Microsoft 365: This type of group is used for collaboration, giving members access to a shared mailbox, calendar, files, SharePoint site, and so on. Group members can only be users.

  • This will have an email address with the domain of the EntraID tenant.

There are 2 types of memberships:

• Assigned: Allow to manually add specific members to a group.

• Dynamic membership: Automatically manages membership using rules, updating group inclusion when members attributes change.

Service Principals

A Service Principal is an identity designed for applications, hosted services, and automated tools to access Azure resources. It functions similarly to service accounts in traditional Active Directory.

Service Principal access is controlled by the roles assigned to it, determining which resources can be accessed and their access levels.

It's possible to directly login as a service principal by generating it a secret (password), a certificate, or granting federated access to third party platforms (e.g. Github Actions) over it.

• If you choose password auth (by default), save the password generated as you won't be able to access it again.

• If you choose certificate authentication, make sure the application will have access over the private key.

App Registrations

App registrations are the configurations that allow applications to integrate with Entra ID. They are the "blueprint" from which service principals are created.

Key Components:

1. Application ID (Client ID): A unique identifier for your app in Azure AD.

2. Redirect URIs: URLs where Azure AD sends authentication responses.

3. Certificates, Secrets & Federated Credentials: It's possible to generate a secret or a certificate to login as the service principal of the application, or to grant federated access to it (e.g. Github Actions).

   1. If a certificate or secret is generated, it's possible to a person to login as the service principal with CLI tools by knowing the application ID, the secret or certificate and the tenant (domain or ID).

4. API Permissions: Specifies what resources or APIs the app can access.

5. Authentication Settings: Defines the app's supported authentication flows (e.g., OAuth2, OpenID Connect).

6. Service Principal: A service principal is created when an App is created (if it's done from the web console) or when it's installed in a new tenant.

   1. The service principal will get all the requested permissions it was configured with.

Default Consent Permissions

Consent permissions define how users and administrators approve applications to access organizational data.

Organizations can control whether users can consent to applications requesting permissions to access their data. There are three main settings:

Setting	Description	Security Level
Do Not Allow User Consent	Only administrators can grant consent for applications. This ensures maximum control but increases administrative overhead.	🔒 High
Allow User Consent for Verified and Low-Impact Apps (Recommended)	Users can consent to apps from verified publishers, internal applications, and apps requesting only low-impact permissions.	🟠 Medium
Allow User Consent for All Applications (Default)	Any user can consent to any application requesting access to organizational data. This provides flexibility but increases risk.	🔴 Low

Low-Impact Permissions (Must Be Accepted as Low Impact)

Permission	Purpose
User.Read	Sign in and read user profile
offline_access	Maintain access to granted data
openid	Enable user authentication
profile	View basic user profile information
email	Access the user's email address

Admin Consent Requests

Setting	Description
Default (No Admin Consent Requests Allowed)	Users cannot request administrator approval for apps they are unable to consent to.
Admin Consent Requests Enabled	Organizations can allow users to request admin consent for restricted apps. Admins can define who can approve requests (specific users, groups, or roles) and configure email notifications and expiration reminders for pending requests.

Managed Identities (Metadata)

Managed identities are Azure's solution for secure service-to-service authentication without storing credentials. It's a solution for automatically managing the identity of applications.

This allows to remove the need of hardcoding cloud credentials in the code as the application will be able to contact the metadata service to get a valid token to perform actions as the indicated managed identity in Azure.

There are two types of managed identities:

• System-assigned. Some Azure services allow you to enable a managed identity directly on a service instance. When you enable a system-assigned managed identity, a service principal is created in the Entra ID tenant trusted by the subscription where the resource is located. When the resource is deleted, Azure automatically deletes the identity for you.

• User-assigned. It's also possible for users to generate managed identities. These are created inside a resource group inside a subscription and a service principal will be created in the EntraID trusted by the subscription. Then, you can assign the managed identity to one or more instances of an Azure service (multiple resources). For user-assigned managed identities, the identity is managed separately from the resources that use it.

Enterprise Applications

It’s just a table in Azure to filter service principals and check the applications that have been assigned to.

It isn’t another type of “application”, there isn’t any object in Azure that is an “Enterprise Application”, it’s just an abstraction to check the Service principals, App registrations and managed identities.

Administrative Units

Administrative Units (AUs) enable organizations to delegate role-based permissions over a specific subset of users, groups, or devices within an organization. This allows for granular administrative control without granting broad tenant-wide permissions.

Entra ID Roles & Permissions

Entra ID provides built-in roles that can be assigned to Entra ID principals to manage various identity-related functionalities.

• Privileged Roles: Some roles are marked as PRIVILEGED, meaning they can lead to elevation of privileges if not properly secured. The most privileged role is Global Administrator.

• Granular Permissions: Roles group specific permissions, which are listed in their descriptions.

• Custom Roles: Administrators can create custom roles with specific permissions, although not all granular permissions are available.

• Independence from Azure Roles: Entra ID roles are entirely separate from Azure roles. However, a Global Administrator in Entra ID can elevate to User Access Administrator in Azure.

• Wildcard Usage: Wildcards cannot be used in Entra ID roles.

Refer to the official documentation for a full list of roles.

Azure Roles & Permissions

Role Assignment Model

• Roles are assigned following the pattern: principal -[HAS ROLE]->(scope)

• Principals can be users, groups, service principals, or managed identities

• Group role assignments are inherited by all group members

Inheritance Structure

• Roles inherit downward through the Azure hierarchy:

• Management Groups → Subscriptions → Resource Groups → Resources

• Example: A role assigned at subscription level applies to all contained resource groups and resources

Types of Roles

Built-In Roles

Azure role-based access control (Azure RBAC) has several Azure built-in roles that you can assign to users, groups, service principals, and managed identities.

Custom Roles

Organizations can define custom roles in and Azure. Custom roles are created within a scope, such as management groups, subscriptions, or resource groups. They can include or exclude specific permissions. Azure roles support wildcards (*) for broad permission assignments. Permissions are categorized into :

• actions: Manage resources (e.g., create, update, delete configurations).

• dataActions: Control access to actual resource data.

• notActions / notDataActions: Explicitly exclude specific permissions.

• assignableScopes: Defines where the role can be applied.

Example Custom Role JSON

{
  "properties": {
    "roleName": "",
    "description": "",
    "assignableScopes": ["/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f"],
    "permissions": [
      {
        "actions": [
          "Microsoft.DigitalTwins/register/action",
          "Microsoft.DigitalTwins/unregister/action",
          "Microsoft.DigitalTwins/operations/read",
          "Microsoft.DigitalTwins/digitalTwinsInstances/read",
          "Microsoft.DigitalTwins/digitalTwinsInstances/write",
          "Microsoft.CostManagement/exports/*"
        ],
        "notActions": [
          "Astronomer.Astro/register/action",
          "Astronomer.Astro/unregister/action",
          "Astronomer.Astro/operations/read",
          "Astronomer.Astro/organizations/read"
        ],
        "dataActions": [],
        "notDataActions": []
      }
    ]
  }
}

Permissions Order

Access to a resource requires an explicit role assignment. Deny assignments take precedence over role assignments, preventing access even if a role grants permission.

Deny Assignments

Just like role assignments, deny assignments are used to control access to Azure resources. However, deny assignments are used to explicitly deny access to a resource, even if a user has been granted access through a role assignment. Deny assignments take precedence over role assignments, meaning that if a user is granted access through a role assignment but is also explicitly denied access through a deny assignment, the deny assignment will take precedence.

Just like role assignments, deny assignments are applied over some scope indicating the affected principals and the permissions that are being denied. Moreover, in the case of deny assignments, it's possible to prevent the deny to be inherited by children resources.

Global Administrator

This role grants complete control over the Entra ID tenant but does not provide default permissions over Azure resources. A Global Administrator can elevate to User Access Administrator in the Azure Root Management Group, allowing them to manage access across all Azure subscriptions. Elevation can be performed here.

Azure Policies

Azure Policies are rules that help organizations ensure their resources meet specific standards and compliance requirements. They allow you to enforce or audit settings on resources in Azure. For example, you can prevent the creation of virtual machines in an unauthorized region or ensure that all resources have specific tags for tracking.

Azure Policies are proactive: they can stop non-compliant resources from being created or changed. They are also reactive, allowing you to find and fix existing non-compliant resources.

A Policy Definition specifies compliance requirements in JSON format. Policies are applied at a scope, such as a subscription or resource group.

• Initiatives group multiple policies for broader enforcement.

• Effects define policy actions, such as Deny, Audit, or Append.

Azure policy json example

{
  "policyRule": {
    "if": {
      "field": "location",
      "notIn": ["eastus", "westus"]
    },
    "then": {
      "effect": "Deny"
    }
  },
  "parameters": {},
  "displayName": "Allow resources only in East US and West US",
  "description": "This policy ensures that resources can only be created in East US or West US.",
  "mode": "All"
}

Permissions Inheritance

In Azure permissions are can be assigned to any part of the hierarchy. That includes management groups, subscriptions, resource groups, and individual resources. Permissions are inherited by contained resources of the entity where they were assigned.

This hierarchical structure allows for efficient and scalable management of access permissions.

Azure RBAC vs ABAC

RBAC (role-based access control) is what we have seen already in the previous sections: Assigning a role to a principal to grant him access over a resource. However, in some cases you might want to provide more fined-grained access management or simplify the management of hundreds of role assignments.

Azure ABAC (attribute-based access control) builds on Azure RBAC by adding role assignment conditions based on attributes in the context of specific actions. A role assignment condition is an additional check that you can optionally add to your role assignment to provide more fine-grained access control. A condition filters down permissions granted as a part of the role definition and role assignment. For example, you can add a condition that requires an object to have a specific tag to read the object. You cannot explicitly deny access to specific resources using conditions.

Resources

Az - Basic Information - HackTricks Cloud

Azure AD introduction for red teamersSynacktiv