Microsoft Azure still stands as relatively uncharted territory for both attackers and defenders. In fact, the time elapsed between the launch of Microsoft Active Directory (AD) and the release of the Kerberoast, Mimikatz, and Responder attack techniques runs about the same as that between the release of Azure and today.
Both sides – attackers and defenders – are still working to figure out the mechanisms in Azure that create security flaws or vulnerabilities. I’m looking to present a primer on an area of this research that I’m working on: identity and access management (IAM) and identity Attack Paths. It explains the three primary identity systems in Azure, how they work, and how they create opportunities for adversaries, as well as steps toward securing them.
Identity Attack Paths, where an attacker abuses legitimate user credentials and privileges to move laterally or escalate privilege until they reach their target, are a significant issue in many Azure deployments. They’re a means to an end that can let adversaries exfiltrate sensitive information or deploy malware, and they’re difficult for defenders to detect and stop because they rely on abusing legitimate functions and credentials. Attack Paths can cross between the cloud and on-premises AD, and attackers can leverage flaws in one identity system to get around the security protections of another.
Azure Attack Paths are more difficult to secure and manage than on-premises Attack Paths because identities in Azure are lot more complicated. There are several parallel and intersection control mechanisms in Azure, so even just auditing which users have control over which objects gets very difficult very quickly. Moreover, the rapid rate of change in Azure, a relative lack of comprehensive knowledge about the system among admins (compared to on-premises AD, which has changed very little in two decades), and the limited information Azure provides all exacerbate the problem.
With that in mind, here’s a rundown of the three IAM systems in Azure:
- Azure Active Directory: Microsoft’s primary cloud-based identity and access management service, Azure AD covers users, security groups and admin roles. These are mostly one-to-many relationships. When a user gets assigned an Azure AD admin role (such as “Cloud App Admin”) they have access to everything that role has access over. Security teams can also configure some – but not all – of these admin roles in a “one to one” relationship. Apps, service principals, devices and groups also have an “Explicit Ownership” mechanism where the owner of those roles also has control over them. It’s separate from AD admin roles. These connections are often poorly understood and offer many opportunities for attackers.
- Azure Resource Manager: The deployment and management service for Azure, covering management groups, subscriptions, resource groups, virtual machines (VMs) and other compute resources. Azure Resource Manager has its own access management system called Azure Admin roles (different from Azure AD admin roles despite the similar name). Unlike Azure AD, these are always one-to-one relationships, where each admin has control over a single object. Individual VMs, blobs, databases and key vaults also have their own permissions systems (which can differ or conflict with Azure admin roles). As if that wasn’t confusing enough, permissions inherit down the hierarchy in Azure, so a permission scoped to a management group or subscription will be applied to all objects (like resource groups or VMs) underneath that. Admins cannot control this.
- Azure Graph API: Microsoft Graph operates as a RESTful web API that lets users access Microsoft Cloud service resources. Similar to Azure AD Admins, Graph API permissions are also usually a one-to-many relationship. There’s an older API called the Azure AD API (which Graph API replaces) that’s still active and works the same way. Adversaries have options here as well – an attacker may abuse the MS Graph API permission of "RoleManagement.ReadWrite.Directory", for example, to grant themselves Global Admin, even without having any AzureAD Admin roles assigned to them.
How Attack Paths are created
There are many ways an attacker could abuse one or more of these privileges. For example, to elevate themself to Global Administrator (which would give them full control of the Azure AD environment and let them grant themselves control over any object on the network), they could abuse the "Contributor" role scoped to a Virtual Machine to perform privileged commands on the Virtual Machine. Next, they would impersonate the Virtual Machine's System-Assigned Managed Identity, then use the managed identity's Privileged Role Administrator privilege to promote themselves to Global Admin. My colleagues and I have seen this Attack Path in more than one environment.
The root of the problem: the complexity of identity in Azure. It’s extraordinarily difficult to audit who has control over specific objects. While admins know they should grant the least privilege necessary, figuring out the least privilege actually requires a significant amount of continuous work. In practice, this complexity often leads admins to grant “most privilege” as a default so everything works.
Azure is also relatively new, and many insecure configurations are put into place simply because whoever does that function doesn’t know any better. Unfortunately, these insecure configurations aren’t going away – as abusable permissions stack up, admins are painting themselves into corners and making the task of securing their environments in the future much harder. Finally, Microsoft does not let Azure become static – it continuously develops Azure and constantly introducing new features. New abuse primitives are constantly being introduced – and even when something does get fixed, it doesn’t necessarily stay fixed for long.
How to secure Azure Attack Paths
In broad strokes, security teams can eliminate Attack Paths by identifying the most dangerous Attack Paths (usually the ones that lead to Tier Zero assets), find “choke points” where many high-risk paths go through a single object or user or misconfiguration, and then fix those choke points. This process requires auditing user, service principal, group and device privileges, which must get automated. Even small organizations will have too much complexity to do this by hand. Bear in mind that the output of this auditing will only tell which principals have which assignments, not their abuse potential. For example, Azure might report that a service principal has a particular MS Graph App Role Assignment, but it falls to the security or cloud admin to know if hackers can abuse that role assignment and elevate to Global Admin.
Security pros should focus on service principals before users, as they almost always have the largest impact on mitigating overall risk. Identify the service principals with highest privilege, and reduce that privilege as much as possible. Out of the three systems explained here, attackers target Azure AD the most, so start with that system.
Finally, more security researchers should look into Azure. The industry can still uncover a lot of intelligence about this system and there’s a great deal more work that needs to happen to better secure the cloud.
Andy Robbins, technical architect for BloodHound Enterprise, SpecterOps
