Blog

Privilege Escalation and Lateral Movement on Azure – Part 1

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:

  1. Azure Tenant – An instance of Azure AD. This tenant represents a single organization.
  2. Identity – A user or application.
  3. User – an actual user that has a username and password.
  4. 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.
  5. 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.

Figure 1: Resource Manager Scopes

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.

Figure 2: Root 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 resources 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:

Figure 3: Azure AD relationship with Azure Resources

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 definition 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:

If a user previously logged in using the CLI on this machine, you can find the credentials used in the file C:Users[Name].AzureaccessTokens.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”: “[email protected]”,
“oid”: “abcdefgc-7732–4c20-be85–3703a70213a3”,
“isMRRT”: true,
“_clientId”: “04b07795–23ds-461a-bdsa-02f9e1bfds36”,
“_authority”: “https://login.microsoftonline.com/common”
}
]

Moreover, if an authentication was made using a service principal, its secret will also be saved in this file.  For example-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.

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

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 cataloging 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

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

An attacker can obtain all the blobs names in the container, and using the command

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

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

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-

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 the 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 to create 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

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 the 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

  1. https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/overview
  2. https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-whatis
  3. 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.
  4. https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview
  5. https://docs.microsoft.com/en-us/microsoft-365/enterprise/subscriptions-licenses-accounts-and-tenants-for-microsoft-cloud-offerings?view=o365-worldwide
  6. https://docs.microsoft.com/en-us/azure/governance/management-groups/overview
  7. https://docs.microsoft.com/en-us/azure/role-based-access-control/role-definitions
  8. https://docs.microsoft.com/en-us/azure/role-based-access-control/overview

Related Topics

mxcyber

Find and fix the exposures that put your critical assets at risk with ultra-efficient remediation.

Watch Demo

See what attackers see, so you can stop them from doing what attackers do.