Comment on page
Az - Basic Information
- If you want to see your company advertised in HackTricks or if you want access to the latest version of the PEASS or download HackTricks in PDF Check the SUBSCRIPTION PLANS!
If your organization has many Azure subscriptions, you may need a way to efficiently manage access, policies, and compliance for those subscriptions. Management groups provide a governance scope above subscriptions.
Note that 10,000 management groups can be supported in a single directory and a management group tree can support up to six levels of depth.
Each directory is given a single top-level management group called the root management group. The root management group is built into the hierarchy to have all management groups and subscriptions fold up to it. This root management group allows for global policies and Azure role assignments to be applied at the directory level. The Azure AD Global Administrator needs to elevate themselves to the User Access Administrator role of this root group initially. After elevating access, the administrator can assign any Azure role to other directory users or groups to manage the hierarchy. As administrator, you can assign your own account as owner of the root management group.
The root management group can't be moved or deleted, unlike other management groups.
Management groups give you enterprise-grade management at scale no matter what type of subscriptions you might have. However, all subscriptions within a single management group must trust the same Azure Active Directory (Azure AD) tenant.
An Azure subscription is a logical container used to provision related business or technical resources in Azure. It holds the details of all your resources like virtual machines (VMs), databases, and more. When you create an Azure resource like a VM, you identify the subscription it belongs to. It allows you to delegate access through role-based access-control mechanisms.
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.
Administrative units let you subdivide your organization into any unit that you want, and then assign specific administrators that can manage only the members of that unit. For example, you could use administrative units to delegate permissions to administrators of each school at a large university, so they could control access, manage users, and set policies only in the School of Engineering.
Only users, groups and devices and be members of an administrative unit.
Therefore, an Administrative unit will contain some members and other principals will be assigned permissions over that administrative unit that they can use to manage the members of the administrative unit.
It's important to note that Azure AD is a service inside Azure. Azure is Microsoft's cloud platform whereas Azure AD is enterprise identity service in Azure.
Moreover, Azure AD is not like Windows Active Directory, it's an identity service that works in a complete different way. If you want to run a Domain Controller in Azure for your Windows Active Directory environment you need to use Azure AD Domain Services.
Azure support different type of principals:
- User: A regular person with credentials to access.
- Group: A group of principals managed together. Permissions granted to groups are inherited by its members.
- Service Principal: It's 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.When creating a service principal you can choose between password authentication or certificate authentication.
- 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.
- Managed Identity: Managed identities provide an automatically managed identity in Azure Active Directory for applications to use when connecting to resources that support Azure Active Directory (Azure AD) authentication. Applications can use managed identities to obtain Azure AD tokens without having to manage any credentials. 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, an identity is created in Azure AD. The identity is tied to the lifecycle of that service instance. When the resource is deleted, Azure automatically deletes the identity for you. By design, only that Azure resource can use this identity to request tokens from Azure AD.
- User-assigned. You may also create a managed identity as a standalone Azure resource. You can create a user-assigned managed identity and assign it 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.
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.
Owner |
| All resource types |
Contributor |
| All resource types |
Reader | • View all resources | All resource types |
User Access Administrator |
| All resource types |
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:
Provides permission to backup vault to perform disk backup. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | |
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.
- 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.
Users with the Global Administrator role has the ability to 'elevate' to User Access Administrator Azure role to the root management group. This means that a Global Administrator will be able to manage access 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
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.
A basic user will have some default permissions to enumerate some parts of AzureAD:
- 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)
You can see the full list of default permissions of users in the docs. Moreover, note that in that list you can also see the guests default permissions list.
Remember that to enumerate Azure resources the user needs an explicit grant of the permission.
There are three types of tokens used in OIDC:
- ****Access Tokens: The client presents this token to the resource server to access resources. It can be used only for a specific combination of user, client, and resource and cannot be revoked until expiry - that is 1 hour by default. Detection is low using this.
- ID Tokens: The client receives this token from the authorization server. It contains basic information about the user. It is bound to a specific combination of user and client.
- Refresh Tokens: Provided to the client with access token. Used to get new access and ID tokens. It is bound to a specific combination of user and client and can be revoked. Default expiry is 90 days for inactive refresh tokens and no expiry for active tokens.
Information for conditional access is stored inside the JWT. So, if you request the token from an allowed IP address, that IP will be stored in the token and then you can use that token from a non-allowed IP to access the resources.
Check the following page to learn different ways to request access tokens and login with them:
The most common API endpoints are:
- Azure Resource Manager (ARM): management.azure.com
- Microsoft Graph: graph.microsoft.com (Azure AD Graph which is deprecated is graph.windows.net)
Import-Module 'C:\Users\Administrador\Desktop\Azure\Modulos ps1\donkeytoken' -Force
Test each portal if it's possible to login without MFA:
Test-MFA -credential $cred -Verbose -Debug -InformationAction Continue
Because the Azure portal is not constrained it's possible to gather a token from the portal endpoint to access any service detected by the previous execution. In this case Sharepoint was identified, and a token to access it is requested:
$token = Get-DelegationTokenFromAzurePortal -credential $cred -token_type microsoft.graph -extension_type Microsoft_Intune Read-JWTtoken -token $token.access_token
The token has the permission Sites.Read.All (from Sharepoint):
Even if you cannot access Sharepoint from the web because of MFA, it's possible to use the token to access the files with the generated token:
$data = Get-SharePointFilesFromGraph -authentication $token $data[0].downloadUrl
Get URL to download files:
- If you want to see your company advertised in HackTricks or if you want access to the latest version of the PEASS or download HackTricks in PDF Check the SUBSCRIPTION PLANS!