Offensively Navigating Azure
Table of Contents
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 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.
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).
Azure AD vs. ARM
Azure AD Administrator roles
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)
- 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)
- 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
- 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
Dynamic Group Membership Rules
- 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@email@example.com) and invite the new email to the tenant
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.
A Windows device can have two states – “AzureAdJoined” and “DomainJoined”. Moreover, they can be both fulfilled simultaneously.
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.
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.