Privilege Escalation and Lateral Movement on Azure — Part 1
Written by Zur Ulianitzky & Hila Cohen — September 16,2020
Overview
XM Cyber features integrated support for Microsoft Azure. This support addresses attack techniques from on premises environments to Azure cloud environments and vice versa.
In this blog, we will show some techniques for how a red team can gain a foothold in an Azure environment. In addition, we will explore ways in which attackers escalate their privileges and move laterally inside Azure infrastructure by using the Azure RBAC (Role-Based Access Control) module. It is important to understand that these attacks do not leverage code vulnerabilities; rather they take advantage of misconfigurations by IT staff. At the end of this blog, we will describe ways to mitigate those misconfigurations.
Before showing the details on the attack technique, it is important to understand some basic Azure concepts.
Note
If you are already familiar with Azure Resource Manager, and the Azure permissions hierarchy, you can jump ahead to the “Attacking Azure Resources” section.
Azure Active Directory (AAD)
Azure AD is the identity and access management service used by Azure. This service allows users and applications to sign in and access resources, such as Office 365 and other Azure resources.
Let’s define some key terms on Azure AD:
- Azure Tenant — An instance of Azure AD. This tenant represents a single organization.
- Identity — A user or application.
- User — an actual user that has a username and password.
- Service Principal — an identity created for use with one or more applications. The relationship between application and service principal is one-to-many. If the application is multi-tenant, then a service principal representing the application will be created on each tenant. On a single tenant application, the tenant will have one service principal that represents that application. Service principals can be authenticated by using secrets or certificates.
- Managed Identities for Azure Resource — a logical object that can be attached to supported Azure resources to grant permissions over the Azure resource manager (detailed in the next section).
Azure Resource Manager
In order to create and manage access to resources, Azure implemented the Resource Manager. The Azure Resource Manager is a management layer that allows users to create, update and delete resources in an Azure account. In addition, the Resource Manager allows you to manage access control using the IAM permissions hierarchy. The Resource Manager governs access control for AAD identities, granting permissions to Users, Groups, Service Principals and Managed Identities.
Azure provides four levels of scope. Let’s examine each of them.
Management Groups
Management Groups, at the highest level in the hierarchy, control access and compliance to subscription policies. Management group permissions are inherited by management groups, subscriptions, resource groups and resources within the management group.
Subscriptions
Microsoft defines subscription as “an agreement with Microsoft to use one or more cloud platforms or services”. Subscription-level permissions are inherited by resource groups and resources within the subscription.
Resource Groups
Logical groupings of resources, whose permissions are inherited by all resource within the group.
Resources
A deployable, manageable item — virtual machines, databases, storage accounts, etc. All the other layers: management groups, subscriptions and resource groups are also resources.
Figure 3 shows the relationship between Azure AD and Azure Resource manager:
Storage Accounts
A Storage account is a resource that can contain any type of Azure data objects:
- Blobs
- Tables
- Queues
- Shared Folders
Containers are another object that resides inside storage accounts. Containers can store other containers or blobs (which are unstructured files).
Azure Roles
Role Definition
Role definition comprises a group of permissions. The permissions constrain identity activities and scope assignment.
There are 2 types of role definitions: Built-in Roles and Custom Roles.
Currently there are 50 built in roles configured by Azure.
If those roles are too permissive, or if they are missing needed permissions users can create a custom role.
The permissions are specified with a string in the following format:
{Company}.{ProviderName}/{resourceType}/{action}
The most important properties of a role definition are name, actions, notActions, dataActions, notDataActions.
An important note about role definitions properties is that the actual permissions on a role definition are calculated by subtracting the permissions on the notActions property from the actions property and subtracting the permissions on the notDataActions property from the dataActions property.
Scope
Scope is the set of resources (at any layer of the Resource Manager) to which the access applies.
Role Assignment
Role Assignment is the term for connecting all the dots together. It is the process of attaching a role definition to a specific identity at a particular scope.
For example, we can create a role assignment, for a user “Zur”, on a specific resource group and attach it to the “Test Role” role definition from figure 4., giving Zur the ability to perform anything except for running commands on virtual machines in that resource group.
Attacking Azure Resources
Gaining a foothold
The examples that follow assume that the Azure CLI is installed. The Azure CLI features a large set of commands to manage Azure resources and AAD.
Begin by logging into Azure:
az login -u <username> -p <password>
If a user previously logged in using the CLI on this machine, you can find the credentials used in the file C:\Users\[Name]\.Azure\accessTokens.json of the form (or comparable):
[
{
“tokenType”: “Bearer”,
“expiresIn”: 3599,
“expiresOn”: “2020–04–07T12:42:04.264Z”,
“resource”: “https://management.core.windows.net/”,
“accessToken”: “eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIs……”,
“refreshToken”: “AQABAAAAAAAm-06blBE1TpVMil8KPQ4…”,
“userId”: “victim@myorganization.onmicrosoft.com”,
“oid”: “abcdefgc-7732–4c20-be85–3703a70213a3”,
“isMRRT”: true,
“_clientId”: “04b07795–23ds-461a-bdsa-02f9e1bfds36”,
“_authority”: “https://login.microsoftonline.com/common”
}
]
The file contains the access token and refresh token given to the user. If the refresh token is still valid, you can use it to obtain a valid access token, use the permissions granted to the user associated with this access token and run commands on his or her behalf.
Moreover, if an authentication was made using a service principal, its secret will also be saved in this file. For example:
{
“servicePrincipalId”: “e158952f-eec3–4d7b-abc1-a7ye654fb517”,
“servicePrincipalTenant”: “m914fsde-f474–782c-8fbf-32df52ca942a”,
“accessToken”: “t_JjkAHcTYgNa1BR2..5244~zr1F_p454”
}
In this case, if a secret was used for authentication, it will be saved in cleartext and since it’s not an access token, it doesn’t have an expiration time!
We can login to Azure CLI using the credentials we found above using the command:
az login — service-principal -u <service principal id> -p <secret> — tenant <tenant>
Recon and compromise Azure resources
With have a foothold in the environment, you can try using the refresh tokens you discovered to attack. The next step is reconnaissance — collect data from the victim’s Azure environment to catalog available resources and potential attack paths. After reconnaissance, if you have the required permissions, you can attempt to move laterally in the environment or escalate your privileges.
Next, we will present some simple RBAC-based attacks targeting misconfiguration in the Azure environment.
Blobs and Containers
A common resource Azure provides is Storage Accounts containing “blobs”. Blob can contain massive amounts of unstructured data, and thus be a real asset for the attacker.
Recon
An attacker will begin by cataloguing organization storage accounts and containers. A stolen access token might have the permissions
- Microsoft.Storage/storageAccounts/read
and
- Microsoft.Storage/storageAccounts/blobServices/containers/read
Under the scope you have these permissions, you can run the following CLI commands using the stolen access token to list the storage accounts and containers:
az storage account list
az storage container list —-account-name <storage account name> —-auth-mode login
However for downloading blobs from the containers listed, you will need additional permission.
Compromise
Next, an attacker will attempt to download the listed blobs from the containers discovered in the previous step, facilitated by the permission
- Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
using the command:
az storage blob list -c <container name> —-account-name <storage account name> —-auth-mode login
An attacker can obtain all the blobs names in the container, and using the command:
az storage blob download -n <blob name> -c <container name> —-account-name <storage account name> —-auth-mode login -f <file path>
and be able to download the blobs he or she found interesting.
Additionally, the permission
- Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
allows uploading new blob to the container using the command:
az storage blob upload -f <local file path> -c <container name> —-account-name <storage account name> -n <blob name> —-auth-mode login -f <file path>
Virtual Machines
Recon
If a stolen access token has the permission
- Microsoft.Compute/virtualMachines/read
an attacker can obtain the properties of all virtual machines in the environment, under the scope of these permissions using the command:
az vm list
Compromise
Attackers can attempt to execute code on the virtual machine. For example, to run a Powershell script on a virtual machine discovered during recon and the attacker possesses the permission
- Microsoft.Compute/virtualMachines/runCommand/action
he or she can use the following command:
az vm run-command invoke —-command-id RunPowerShellScript —-name <virtual machine name> -g <resource group> —-scripts @script.ps1
After collecting all the information from the virtual machine of interest, an attacker can use this virtual machine in to continue the attack using the VM managed identity.
VM Identity Compromise
If a compromised virtual machine is configured with a managed identity, an attacker can employ the permissions given to it. An attacker can follow Microsoft documentation that illustrates how to obtain a token for a VM managed identity and then use this token to run commands on behalf of involved identity.
Note that every compromised resource with a managed identity can be abused in the same way. If an attacker compromises any resource with a managed identity, he or she can use the permissions given to this identity in order to continue the attack.
Create New Role Assignment
To escalate privileges, attackers can attempt creating role assignments. If the stolen access token has the permission
- Microsoft.Authorization/roleAssignments/write
an attacker can create role assignments at the same scope. For example, an attacker can create a role assignment with the “owner” role at the same scope using the command
az role assignment create —-assignee <user or service principal> —-role “owner”
and compromise all resources under this scope.
Remediations
So how can an IT manager prevent these types of attacks?
Grant permissions on an as-needed basis only
- Segregate duties within a team and grant only the amount of access to users needed to perform their jobs. Instead of giving out unrestricted permissions to an Azure subscription or resources, allow only specific actions at a particular scope.
- When assigning roles to users, group, or application, grant those security principals the minimum required permissions necessary to perform assigned tasks. Limiting access to resources helps prevent both unintentional and malicious misuse of data.
- Review the RBAC (Role-Based Access Control) built-in roles for appropriate role assignments. If built-in roles don’t meet your organization’s specific needs, you can create custom roles for Azure resources.
Also, consider using PIM (Privileged Identity Management). PIM is a service that enables managed access to important organization resources. It provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on critical resources. This service grants powerful (dangerous) permissions to users for specified duration only (2 hours by default) and thus prevents attacker from using them after expiration.
Summary
Microsoft Azure is an increasingly popular cloud hosting environment that boasts powerful management tools and capabilities. Understanding the security attributes of the Azure environment is key to securing Azure-based deployments and to remediating insecure configuration in Azure-resident assets and applications.
Look for future blogs discussing both privilege escalation and how to secure your Azure deployments.
References
- https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/overview
- https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-whatis
- https://docs.microsoft.com/en-us/powershell/azure/create-azure-service-principal-azureps?view=azps-4.6.1#:~:text=An%20Azure%20service%20principal%20is,accessed%20and%20at%20which%20level.
- https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview
- https://docs.microsoft.com/en-us/microsoft-365/enterprise/subscriptions-licenses-accounts-and-tenants-for-microsoft-cloud-offerings?view=o365-worldwide
- https://docs.microsoft.com/en-us/azure/governance/management-groups/overview
- https://docs.microsoft.com/en-us/azure/role-based-access-control/role-definitions
- https://docs.microsoft.com/en-us/azure/role-based-access-control/overview