Skip to content

Latest commit

 

History

History
414 lines (296 loc) · 29.9 KB

README.md

File metadata and controls

414 lines (296 loc) · 29.9 KB
Raw

Az - Basic Information

{% 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
{% endhint %}

Organization Hierarchy

https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png

Management Groups

  • It can contain other management groups or subscriptions.
  • This allows to apply governance controls such as RBAC and Azure Policy once at the management group level and have them inherited by all the subscriptions in the group.
  • 10,000 management groups can be supported in a single directory.
  • A management group tree can support up to six levels of depth. This limit doesn’t include the root level or the subscription level.
  • Each management group and subscription can support only one parent.
  • Even if several management groups can be created there is only 1 root management group.
    • The root management group contains all the other management groups and subscriptions and cannot be moved or deleted.
  • All subscriptions within a single management group must trust the same Entra ID tenant.

https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png

Azure Subscriptions

  • It’s another logical container where resources (VMs, DBs…) can be run and will be billed.
  • Its parent is always a management group (and it can be the root management group) as subscriptions cannot contain other subscriptions.
  • It trust only one Entra ID directory
  • Permissions applied at the subscription level (or any of its parents) are inherited to all the resources inside the subscription

Resource Groups

From the docs: A resource group is a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group. Generally, add resources that share the same lifecycle to the same resource group so you can easily deploy, update, and delete them as a group.

All the resources must be inside a resource group and can belong only to a group and if a resource group is deleted, all the resources inside it are also deleted.

https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1

Azure Resource IDs

Every resource in Azure has an Azure Resource ID that identifies it.

The format of an Azure Resource ID is as follows:

  • /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}

For a virtual machine named myVM in a resource group myResourceGroup under subscription ID 12345678-1234-1234-1234-123456789012, the Azure Resource ID looks like this:

  • /subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM

Azure vs Entra ID vs Azure AD Domain Services

Azure

Azure is Microsoft’s comprehensive cloud computing platform, offering a wide range of services, including virtual machines, databases, artificial intelligence, and storage. It acts as the foundation for hosting and managing applications, building scalable infrastructures, and running modern workloads in the cloud. Azure provides tools for developers and IT professionals to create, deploy, and manage applications and services seamlessly, catering to a variety of needs from startups to large enterprises.

Entra ID (formerly Azure Active Directory)

Entra ID is a cloud-based identity and access management service designed to handle authentication, authorization, and user access control. It powers secure access to Microsoft services such as Office 365, Azure, and many third-party SaaS applications. With features like single sign-on (SSO), multi-factor authentication (MFA), and conditional access policies among others.

Entra Domain Services (formerly Azure AD DS)

Entra Domain Services extends the capabilities of Entra ID by offering managed domain services compatible with traditional Windows Active Directory environments. It supports legacy protocols such as LDAP, Kerberos, and NTLM, allowing organizations to migrate or run older applications in the cloud without deploying on-premises domain controllers. This service also supports Group Policy for centralized management, making it suitable for scenarios where legacy or AD-based workloads need to coexist with modern cloud environments.

Entra ID Principals

Users

  • New users
    • Indicate email name and domain from selected tenant
    • Indicate Display name
    • Indicate password
    • Indicate properties (first name, job title, contact info…)
      • Default user type is “member”
  • External users
    • Indicate email to invite and display name (can be a non Microsft email)
    • Indicate properties
      • Default user type is “Guest”

Members & Guests Default Permissions

You can check them in https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions but among other actions a member will be able to:

  • Read all users, Groups, Applications, Devices, Roles, Subscriptions, and their public properties
  • Invite Guests (can be turned off)
  • Create Security groups
  • Read non-hidden Group memberships
  • Add guests to Owned groups
  • Create new application (can be turned off)
  • Add up to 50 devices to Azure (can be turned off)

{% hint style="info" %} Remember that to enumerate Azure resources the user needs an explicit grant of the permission. {% endhint %}

Users Default Configurable Permissions

  • Members (docs)
    • Register Applications: Default Yes
    • Restrict non-admin users from creating tenants: Default No
    • Create security groups: Default Yes
    • Restrict access to Microsoft Entra administration portal: Default No
      • This doesn’t restrict API access to the portal (only web)
    • Allow users to connect work or school account with LinkedIn: Default Yes
    • Show keep user signed in: Default Yes
    • Restrict users from recovering the BitLocker key(s) for their owned devices: Default No (check in Device Settings)
    • Read other users: Default Yes (via Microsoft Graph)
  • Guests
    • Guest user access restrictions
      • Guest users have the same access as members grants all member user permissions to guest users by default.
      • Guest users have limited access to properties and memberships of directory objects (default) restricts guest access to only their own user profile by default. Access to other users and group information is no longer allowed.
      • Guest user access is restricted to properties and memberships of their own directory objects is the most restrictive one.
    • Guests can invite
      • Anyone in the organization can invite guest users including guests and non-admins (most inclusive) - Default
      • Member users and users assigned to specific admin roles can invite guest users including guests with member permissions
      • Only users assigned to specific admin roles can invite guest users
      • No one in the organization can invite guest users including admins (most restrictive)
    • External user leave: Default True
      • Allow external users to leave the organization

{% hint style="success" %} Even if restricted by default, users (members and guests) with granted permissions could perform the previous actions. {% endhint %}

Groups

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 created for use with applications, hosted services, and automated tools to access Azure resources. This access is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at which level. For security reasons, it's always recommended to use service principals with automated tools rather than allowing them to log in with a user identity.

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

An App Registration is a configuration that allows an application to integrate with Entra ID and to perform actions.

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

User consent for applications

  • Do not allow user consent
    • An administrator will be required for all apps.
  • Allow user consent for apps from verified publishers, for selected permissions (Recommended)
    • All users can consent for permissions classified as "low impact", for apps from verified publishers or apps registered in this organization.
    • Default low impact permissions (although you need to accept to add them as low):
      • User.Read - sign in and read user profile
      • offline_access - maintain access to data that users have given it access to
      • openid - sign users in
      • profile - view user's basic profile
      • email - view user's email address
  • Allow user consent for apps (Default)
    • All users can consent for any app to access the organization's data.

Admin consent requests: Default No

  • Users can request admin consent to apps they are unable to consent to
  • If Yes: It’s possible to indicate Users, Groups and Roles that can consent requests
    • Configure also if users will receive email notifications and expiration reminders

Managed Identity (Metadata)

Managed identities in Azure Active Directory offer a solution for automatically managing the identity of applications. These identities are used by applications for the purpose of connecting to resources compatible with Azure Active Directory (Azure AD) authentication. 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.

Managed Identities don't generate eternal credentials (like passwords or certificates) to access as the service principal attached to 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 allows to give permissions from a role over a specific portion of an organization.

Example:

  • Scenario: A company wants regional IT admins to manage only the users in their own region.
  • Implementation:
    • Create Administrative Units for each region (e.g., "North America AU", "Europe AU").
      • Populate AUs with users from their respective regions.
        • AUs can contain users, groups, or devices
        • AUs support dynamic memberships
        • AUs cannot contain AUs
      • Assign Admin Roles:
        • Grant the "User Administrator" role to regional IT staff, scoped to their region's AU.
  • Outcome: Regional IT admins can manage user accounts within their region without affecting other regions.

Entra ID Roles

Roles & Permissions

Roles are assigned to principals on a scope: principal -[HAS ROLE]->(scope)

Roles assigned to groups are inherited by all the members of the group.

Depending on the scope the role was assigned to, the role cold be inherited to other resources inside the scope container. For example, if a user A has a role on the subscription, he will have that role on all the resource groups inside the subscription and on all the resources inside the resource group.

Classic Roles

Owner
  • Full access to all resources
  • Can manage access for other users
 All resource types
Contributor
  • Full access to all resources
  • Cannot manage access
 All resource types
Reader • View all resources All resource types
User Access Administrator
  • View all resources
  • Can manage access for other users
 All resource types

Built-In roles

From the docs: 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. Role assignments are the way you control access to Azure resources. If the built-in roles don't meet the specific needs of your organization, you can create your own Azure custom roles.

Built-In roles apply only to the resources they are meant to, for example check this 2 examples of Built-In roles over Compute resources:

Disk Backup Reader Provides permission to backup vault to perform disk backup. 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24
Virtual Machine User Login View Virtual Machines in the portal and login as a regular user. fb879df8-f326-4884-b1cf-06f3ad86be52

This roles can also be assigned over logic containers (such as management groups, subscriptions and resource groups) and the principals affected will have them over the resources inside those containers.

Custom Roles

  • It’s also possible to create custom roles
  • They are created inside a scope, although a role can be in several scopes (management groups, subscription and resource groups)
  • It’s possible to configure all the granular permissions the custom role will have
  • It’s possible to exclude permissions
    • A principal with a excluded permission won’t be able to use it even if the permissions is being granted elsewhere
  • It’s possible to use wildcards
  • The used format is a JSON
    • actions are for control actions over the resource
    • dataActions are permissions over the data within the object

Example of permissions JSON for a custom role:

{
    "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

  • In order for a principal to have some access over a resource he needs an explicit role being granted to him (anyhow) granting him that permission.
  • An explicit deny role assignment takes precedence over the role granting the permission.

https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10

Global Administrator

Global Administrator is a role from Entra ID that grants complete control over the Entra ID tenant. However, it doesn't grant any permissions over Azure resources by default.

Users with the Global Administrator role has the ability to 'elevate' to User Access Administrator Azure role in the Root Management Group. So Global Administrators can manage access in all Azure subscriptions and management groups.
This elevation can be done at the end of the page: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties

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.

Key Concepts

  1. Policy Definition: A rule, written in JSON, that specifies what is allowed or required.
  2. Policy Assignment: The application of a policy to a specific scope (e.g., subscription, resource group).
  3. Initiatives: A collection of policies grouped together for broader enforcement.
  4. Effect: Specifies what happens when the policy is triggered (e.g., "Deny," "Audit," or "Append").

Some examples:

  1. Ensuring Compliance with Specific Azure Regions: This policy ensures that all resources are deployed in specific Azure regions. For example, a company might want to ensure all its data is stored in Europe for GDPR compliance.
  2. Enforcing Naming Standards: Policies can enforce naming conventions for Azure resources. This helps in organizing and easily identifying resources based on their names, which is helpful in large environments.
  3. Restricting Certain Resource Types: This policy can restrict the creation of certain types of resources. For example, a policy could be set to prevent the creation of expensive resource types, like certain VM sizes, to control costs.
  4. Enforcing Tagging Policies: Tags are key-value pairs associated with Azure resources used for resource management. Policies can enforce that certain tags must be present, or have specific values, for all resources. This is useful for cost tracking, ownership, or categorization of resources.
  5. Limiting Public Access to Resources: Policies can enforce that certain resources, like storage accounts or databases, do not have public endpoints, ensuring that they are only accessible within the organization's network.
  6. Automatically Applying Security Settings: Policies can be used to automatically apply security settings to resources, such as applying a specific network security group to all VMs or ensuring that all storage accounts use encryption.

Note that Azure Policies can be attached to any level of the Azure hierarchy, but they are commonly used in the root management group or in other management groups.

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.

References

{% 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
{% endhint %}