The basics of Microsoft's Azure infrastructure

At the time of writing (late 2020–early 2021), the Azure platform consists of over 200 services and seems to be expanding all the time. It may feel that there is a lot of ground to cover here, but during a penetration test, you will typically only need to focus on a subset of the available services that you have in scope.

In general, it is important to understand how the environment is structured at the Azure platform level (subscriptions, RBAC, resources), and how the available services can be abused to gain additional privileges in the environment.

The lessons in this section will be fundamental to your understanding of how Azure functions as a platform, so pay close attention. For those with a solid Azure background, feel free to skim this chapter to refresh on the core principles.

In this section, we will gain an understanding of the Azure cloud platform and its regions, how Azure tenants are typically structured, and how the resources under the tenant are managed.

Azure clouds and regions

To be able to serve several distinct markets governed by different laws and regulations, Microsoft has built different Azure clouds that cater to different markets. These clouds all run on the same technologies and provide the same services, but they run in different data center environments that are isolated both physically and logically. This is important to keep in mind, as the application programming interface (API) endpoints for each platform and their services vary depending on the cloud platform that we are interacting with.

The following table highlights the four Azure cloud platforms and their main endpoints:

Since each of these clouds has different endpoints for accessing Azure services and we want to avoid confusion across regions, we will standardize on the Azure Commercial cloud for all the examples in the book. It is important to note that the examples are applicable to the other Azure clouds, but you may need to modify the target endpoints.

Azure resource management hierarchy

Before we get into the tactics, techniques, and procedures that can be used during penetration tests in Azure environments, we need a working understanding of how resources are structured in the Azure cloud. This knowledge will also give us the ability to follow an attack chain through an environment once we have obtained initial access.

The organization structure in Azure consists of the following levels: Azure AD Tenant, Root Management Group, Child Management Group, Subscription, Resource Group, and individual Resources. These different levels are shown in the following diagram:

Figure 1.1 – Azure resource hierarchy

Here are the descriptions of each level from the top down:

• Azure AD Tenant: In order to manage Azure subscriptions and resources, administrators need an identity directory to manage users that will have access to the resources. Azure AD is the identity store that facilitates the authentication and authorization for all users in an Azure tenant's subscriptions.

  Every Azure subscription has a trust relationship with one Azure AD tenant to manage access to the subscription. It is common for organizations to connect their on-premises AD to Azure AD using a tool called Azure AD Connect, as shown in the following diagram:

Figure 1.2 – Using Azure AD Connect to synchronize objects to Azure AD

As the core of authentication and authorization, Azure AD is a prime target for information gathering, as well as different identity-based attacks. We will be covering more of the authorization model for Azure subscriptions in the Understanding the Azure RBAC structure section in this chapter.

• Root Management Group: This is the top of the Azure resource organization hierarchy, if it's enabled. By default, the root management group is not enabled for an organization that is new to Azure, which means each subscription is managed as an individual entity. However, managing subscriptions individually creates a governance model that does not scale well. This is especially difficult for medium- to large-sized organizations with multiple subscriptions to manage.

  Many production Azure environments will have the root management group enabled. This is partly because Microsoft recommends enabling it as part of their Cloud Adoption Framework document (https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/decision-guides/subscriptions/). This document describes some of the best practices for adopting the Azure cloud and is a great source of information for those looking at building out an environment in Azure.

• Child Management Group: If an organization has enabled the root management group, they could create child management groups under the root to simplify the management of their subscriptions. Child management groups allow organizations to group subscriptions together in a flexible structure, mainly to centrally manage access and governance. Child management groups can be nested and can support up to six levels of depth.
• Subscription: To provision resources in Azure, we need an Azure subscription. An Azure subscription is the logical container where resources are provisioned. When we create a resource such as a Structured Query Language (SQL) database, the first thing we usually do is specify the subscription where the resource will be provisioned. The usage of that resource will also be billed to the subscription that is selected.

  As noted in the Child Management Group description, an organization will typically have multiple Azure subscriptions. It is quite common for organizations to set up multiple subscriptions for separate environments, such as development and production, or for separating application environments.

• Resource Group: Within subscriptions, there are resource groups. Resource groups are logical containers that can be used to group and manage Azure resources such as virtual machines (VMs), storage accounts, and databases.

  Resource groups are best used to collect and group resources that need to be managed together or share the same life cycle. Depending on the subscription architecture, this can result in large numbers of resource groups in individual subscriptions.

  From an access perspective, resource groups also allow us to segment access to different groups in the same subscription, but we will cover that in more detail in the Understanding the Azure RBAC structure section.

• Resources: Resources are the individual instances of Azure services that are deployed in an Azure subscription. The resource level is the bottom of the organization hierarchy. Outside of services with specific access policies (see the information about key vaults), we can't segment down the resources hierarchy any further than this.

We will get into the specifics of how access is managed using RBAC later in the chapter but in general, an Azure AD account can have specified access to any of the resource organization levels outlined previously. From a penetration-testing perspective, access granted at a higher level gives wider scope for an attacker to discover vulnerabilities in cloud-service configurations and to move laterally within the environment. This concept will be more important when we discuss privilege escalation.

In the next section, we will cover an overview of some of the commonly utilized Azure services. These individual instances of services fall under the Resources category listed previously.