Red Teamer | Cilynx

Offensively Navigating Azure

With the rise of Azure adoption rates, the need for sufficient knowledge of this realm within Redteams rises. On the contrary, as in any modern technology, the knowledge sources usually consumed by Redteamers are still building up speed. On top of that, Azure itself has an overwhelming amount of ever-changing services, keeping the security community full of blind spots to its risks.

The main point of this article is to assist in navigating the Azure monstrosity, filtering out topics that go to less Redteam-relevant depths.

Azure Visualization — Figure 1: Minimal Visualization

Azure terms for Redteamers

We collected a minimal list of terms to provide a starting point of understanding Azure from an offensive standpoint. Hopefully, understanding these concepts will provide you enough leverage to adapt to the subject and understand how to look at things.

Advanced readers – quiz yourselves.

Enrollment

A simple one, basically describing how the first registrant chose to purchase an Azure plan:

Azure EA (Enterprise Agreement)
Azure CSP (Cloud Solutions Provider)

Further details aren’t as relevant for now. It is essentials to know that by default, the user that is first used for sign-in is assigned key default roles, which will be discussed later on (Account Admin, Service Admin, Global Administrator).

Tenant

A tenant is a boundary in Azure AD representing an organization, received upon signing up to any Microsoft cloud service (Azure, 365, etc.), usually comes in the format of tenant-id.onmicrosoft.com . Directory (an instance of the Azure AD Service) can only relate to one tenant. Hence, they are sometimes used interchangeably.

Subscription

The primary purpose of a subscription is to provide a standard billing paradigm for the use of Azure services. A subscription might be associated with one tenant, while a tenant can have multiple subscriptions. Subscriptions are usually split for business and budget considerations.

Azure AD vs. ARM

It makes a lot of sense to simplify Azure to two different views – an Azure AD view and an ARM view.

Azure AD (Azure Active Directory) is an identity and access management service that relates to managing Users, Groups, Devices etc.

While ARM (Azure Resource Manager) is a resource management service that relates to Subscriptions, Resource Groups, Resources (i.e., Virtual Machines, Web Applications, Storage Blobs etc.) and similar.

Roles

Roles in Azure are rather complicated, and are divided into three variants:

Azure AD Administrator roles

Used to create and edit users, assign admin rights to users, reset passwords etc.
Examples of these roles:

Global Administrator – can manage all aspects of Azure AD. Note – Azure AD roles do not grant access to Azure resources. However, a Global Administrator can assign himself to all Azure subscriptions and management groups in the same directory. This is referred to as Elevated access.
Billing Administrator (self-explanatory)

RBAC roles

Azure RBAC roles are used to control permissions for managing Azure resources such as Web Apps, SQL databases, Blobs, etc.

Examples:

Owner – full access to manage all resources and assign RBAC roles
User Access Administrator – manage all access to Azure resources (hint: this is the role you will want to “elevateAccess” to, as a Global Administrator)
Contributor – full access to manage resources, but not to assign RBAC roles
Service-specific roles (Website Contributor, Log Analytics Contributor, Key Vault Contributor, etc.)
Reader (self-explanatory)

Classic Roles

These are old Azure roles that are still around. The classical roles are:

Account Administrator – manage billing for subscriptions, create and cancel subscriptions, etc.
Service Administrator – owner-equivalent access at the subscription scope. In a new subscription, the Account Administrator is also the Service Administrator by default.
Co-Administrator – can be assigned by the Service Administrator to have the same level of access (owner-equivalent) but can not change the Service Administrator.

Azure AD Applications & Service Principals

An Azure AD application is used to delegate a resource’s Identity and Access Management functions to Azure AD.

When we create an application in Azure, we are also creating an Application Object and a Service Principal in Azure AD to represent that application in our tenant for various purposes.

Think of an Azure Web Application resource as an example. For such a resource to access another resource (e.g., an SQL database resource), it must have an entity representing it. This entity is called a Service Principal.

Understanding this is important from an offensive perspective due to the possible misconfigurations that may occur. Consider the following scenario:

Our current compromised user account has no special privileges, but he is an Owner of a specific application
Being the Owner of the application, we can add an additional password or certificate to the application’s existing Service Principal and use them to authenticate to Azure as the Service principal.
It happens to be that the Service Principal has higher privileges than our first user, i.e., Privilege Escalation (e.g. to Contributor, Global Administrator etc.)

Guests / Azure AD B2B

Azure AD B2B (business-to-business) is a feature that lets you invite external guests to collaborate with your organization. This feature is used to share company applications and services with other organizations, while maintaining control over private corporate data.

A guest is created almost like a regular Azure AD user, but can be easily distinguished through the UPN (User Principal Name) of SomeGuest_HisOrg.com#EXT#@myorg.onmicrosoft.com .

Dynamic Group Membership Rules

In Azure AD (with Premium P1 license or above), administrators can define user (or device) attribute-based rules to add or remove users to groups automatically. These are often referred to as Dynamic Groups.

Figure 4: Dynamic membership rule builder

From an offensive perspective, the fact that a human factor configures these is concerning. Consider the following scenario:

A company hires a trusted vendor to perform maintenance in their tenant
They invite the vendor’s engineering team and assign them high privileges (e.g. Contributor to X) to do what they need
A week later, the previous engineers had all quit, and the vendor’s new hires need the same level of access assigned again
An administrator from the company figures out he can save a lot of overhead using Dynamic Groups and defines a custom rule to automatically add users from the vendor company to their privileged group
Without realizing the impact, the administrator creates a rule that checks if the user’s userPrincipalName contains “somvendor”, and if so – the user is added to the privileged vendor group
A malicious user within the tenant with “Global Reader” privileges or similar may catch up on this mistake and understand the rule is abusable
Suppose only the “somevendor” string is required to join the group, and the user can invite guest emails (using Azure AD B2B as discussed earlier). In that case, a user can set up an email containing that string (e.g., 123@somevendor@gmail.com) and invite the new email to the tenant

Dynamic membership rules will apply, and since only the userPrincipalName is validated, the user will be automatically joined to the group, resulting in a privilege escalation (in our case, from Global Reader to Contributor).

Azure Join Implementations

Azure AD Joined

Typically, the north star configuration. No On-premises setup at all. Joined devices belong to the company and are joined to Azure AD cloud service.

This means that any user will log in from any device, and logged-in users could access device resources via SSO. This kind of configuration eliminates the need for an enterprise network as we know it (no Domain Controller needed).

Hybrid Joined

A Windows device can have two states – “AzureAdJoined” and “DomainJoined”. Moreover, they can be both fulfilled simultaneously.

In this type of configuration, joined devices belong to the company, and the logged-in domain user has SSO access to both Azure AD and On-premises infrastructure. In this way, the device is managed both via Azure AD and Active Directory. Else is pretty much ad you’d expect.

This can be done with Azure AD Connect, which is a Microsoft tool that allows you to sync your On-premises Active Directory users, groups, etc., to Azure AD. Think DCSync, just to Azure AD.

With this setup, your tenant is exposed to several additional security risks that come from the On-premises network, for example:

I believe the Redteam field had already established that a threat actor has or will be within your organization at some point. From inside the On-premises environment, it’s a matter of querying a user with a “sAMAccountName” attribute that begins with “MSOL_” to compromise the ADSync user, in charge of the abovementioned synchronization process. If PHS(Password Hash Synchronization) is in use, getting to the ADSync account on the On-premises network will lead to compromising Azure AD. Refer to Dirk-jan’s post for further details.
RDP Hijacking seems to remain a thing for the foreseeable future; what about hijacking an administrative session with the Azure portal open on it?
Pass-the-PRT – Think Kerberos TGT, but for Windows SSO. As a Local Administrator in an Azure-joined or Hybrid-joined On-premise machine it’s possible to extract a PRT(Primary Refresh Token) from LSASS (CloudAP) and combine it with a few extra steps explained thoroughly here (or in a higher level here) to craft a JWT (JSON Web Token) that can be used to fully authenticate as the user, without MFA getting in the way.

Hybrid Joined seems to be the common case for big organizations at this time.

Workplace Joined

The device is not joined to anything, and users log in through a personal Microsoft account (MSA). Users with “Add a work or school account” can have SSO to Azure AD. Azure AD could manage a device this way, but the user could opt out (thus losing access to some resources).

This setup seems to be more popular on BYOD-style small organizations.

Summary

Hopefully, the content in this article has provided a solid ground for your future learning paths.

Not all topics are covered, and that’s intentional to reduce the overhead from trying to understand a world of things at a single session. I’d threat this article as an index to refer back to from time to time, to dig a bit deeper in different areas in each time. Please contact us for any consultation!

At the end of the day nothing beats hands-on experiment on your own vulnerable lab.