Apr 18 2023 |
Introducing BloodHound 4.3 — Get Global Admin More Often
Introducing BloodHound 4.3 — Get Global Admin More Often
Discover new attack paths traversing Microsoft Graph and seven new Azure Resource Manager objects.
Checking out BloodHound for the first time? Here are some handy resources:
- Get the latest version of BloodHound on GitHub
- Read our official documentation
- Come hang out with us in the BloodHound Slack
Major Contributions from BloodHound Users
Shoutouts to the following folks for making material contributions to this release:
Thank you to Hugo Vincent for his AzureHound contribution which adds app role assignment enumeration, enabling the MS Graph attack path feature. Thank you to Hugo as well for his BloodHound PR to implement this feature — we went with a different implementation for the GUI and database structure but wish to credit Hugo as a co-author for BloodHound 4.3.
Thank you to Cristian M for his AzureHound PR and BloodHound PR to bring support for attack paths traversing Automation Accounts, Logic Apps, Web Apps, and Function Apps. Cristian’s PRs also add support for Storage Accounts, which we will be including in a future update. We would like to credit Cristian M as a co-author of BloodHound 4.3.
Thank you to Simon Décosse for his two contributions to this release: a BloodHound PR making AZResetPassword edges more accurate, and another BloodHound PR and corresponding SharpHoundCommon PR for introducing attack paths traversing Standalone Managed Service Accounts (SMSAs). The SMSA work didn’t quite make it in time for the BloodHound 4.3 release but will be introduced in a fast follow-up. We would like to credit Simon Décosse as a co-author of BloodHound 4.3.
New Features in BloodHound 4.3
Microsoft Graph Attack Paths
MS Graph app roles are commonly used by third-party applications to perform various tasks in Azure Active Directory, such as managing user group memberships, creating service principals, and managing Azure AD admin role assignments. Despite their power, MS Graph app roles can be challenging for admins to audit effectively.
BloodHound 4.3 makes it easy to find attack paths traversing abusable MS Graph app role assignments by modeling not only the app role assignments themselves, but the relevant outcomes of those configurations, as well.
For instance, if a Service Principal is granted the ServicePrincipalEndpoint.ReadWrite.All app role, it gains the ability to add new owners to all other Service Principals in the tenant. BloodHound 4.3 models this outcome by creating post-processed edges labeled as AZMGAddOwner, linking to every Service Principal. This simplifies the process of discovering attack paths, as you no longer need to manually track each app role assignment and remember their significance.
More Attack Paths in Azure Resource Manager
Microsoft continuously adds new services to Azure Resource Manager, and we strive to keep pace by researching abuse primitives across the AzureRM landscape. BloodHound 4.3 now supports seven additional AzureRM services, including:
- Automation Accounts
- Container Registries
- Kubernetes Service Managed Clusters
- Function Apps*
- Logic Apps
- Virtual Machine Scale Sets
- Web Apps*
*Function Apps and Web Apps are technically part of the same service, but they have distinct functionalities that warrant separate modeling.
These seven services are commonly used in customer environments and while AzureRM roles are generally easier to audit compared to AzureAD roles, we often encounter attack paths that traverse through these services as well.
How do those attack paths work? I’m glad you asked! Let’s talk about:
More Managed Identity Attack Paths
The seven AzureRM services mentioned above share a common feature: they all support managed identity assignments.
As a defender, I appreciate Managed Identities. They eliminate the need for compute resources to store or fetch credentials by associating a privileged identity with specific resources. The resource can authenticate as its associated service principal, as Azure validates the Managed Identity assignment between the two objects.
However, as an attacker, I find Managed Identities even more appealing. The configuration and mechanics of a Managed Identity assignment provide reliable data collection and abuse primitives. With certain privileges, one can extract JSON Web Tokens (JWTs) from Azure Resources and impersonate their Managed Identity-associated service principals.
Conclusion
We’re excited to get this release out there. This is a huge release and is the culmination of several months of hard work from many people, including not only people within the BloodHound Enterprise team, but also several people in the BloodHound users community.
We are continuing to work hard to introduce more attack paths into the product, including attack paths enabled by ADCS and attack paths enabled by on-prem/cloud hybrid configurations. Stay tuned for that.
Below you will find the full details of all new nodes and edges added in this release
New Nodes
AZAutomationAccount
Automation Accounts are one of several services falling under the umbrella of “Azure Automation”. Azure admins can use Automation Accounts to automate a variety of business operations, such as creating and configuring Virtual Machines in Azure.
Automation Accounts offer different process automation services, but at the core of all those services are what are called Runbooks.
Read more about how attackers abuse Automation Accounts in this blog post:
https://medium.com/p/82667d17187a
AZContainerRegistry
Azure Container Registry (ACR) is Microsoft’s implementation of the Open Container Initiative’s (OCI) Distribution Spec, which itself is based on the original Docker Registry protocol. In plain English: ACR stores and manages container images for you. ACR serves those images, making them available to run locally, on some remote system, or as an Azure Container Instance. You can think of ACR as being somewhat analogous to your very own Docker Registry.
Read more about how attackers abuse Container Registries in this blog post:
https://medium.com/p/1f407bfaa465
AZFunctionApp
Functions are one of several services falling under the umbrella of “Azure Automation”. Azure admins can create functions using a variety of language (C#, Java, PowerShell, etc.), then run those functions on-demand in Azure. Functions are hosted and grouped together in Azure using Function Apps.
Read more about how attackers abuse Function Apps in this blog post:
https://medium.com/p/300065251cbe
AZLogicApp
Logic Apps are another Azure service falling under the general umbrella of “Azure Automation”. Admins can use Logic Apps to construct what are called “workflows”. Workflows are comprised of triggers and actions that occur as a result of those triggers.
Read more about how attackers abuse Logic Apps in this blog post:
https://medium.com/p/52b29354fc54
AZManagedCluster
Azure Kubernetes Service Managed Clusters provide Azure admins an easy way to create and maintain Kubernetes clusters.
Read about how attackers abuse AKS Managed Clusters in this blog post:
AZVMScaleSet
Azure Virtual Machine Scale Sets are used by AKS Managed Clusters to spin up and spin down compute nodes. They can also by used by admins to spin up and manage virtual machines outside of the AKS use-case.
Read about how attackers abuse Virtual Machine Scale Sets in this blog post:
AZWebApp
Azure App Service is a Platform-as-a-Service product that promises to improve web application deployment, hosting, availability, and security. Web Apps hosted by Azure App Service are organized into Azure App Service Plans, which are Virtual Machines that the Web Apps in that plan all run on.
Read more about how attackers abuse Web Apps in this blog post:
https://medium.com/p/c3adefccff95
New Edges
AZMGGrantRole
This edge is created during post-processing. It is created against all AzureAD admin roles when a Service Principal has the following MS Graph app role assignment:
- RoleManagement.ReadWrite.Directory
This privilege allows the Service Principal to promote itself or any other principal to any AzureAD admin role, including Global Administrator.
AZMGGrantAppRoles
This edge is created during post-processing. It is created against AzureAD tenant objects when a Service Principal has one of the following MS Graph app role assignments:
- RoleManagement.ReadWrite.Directory
- AppRoleAssignment.ReadWrite.All
A Service Principal with this edge directed at an AzureAD tenant can grant itself any app role, including RoleManagement.ReadWrite.Directory, which will then allow the Service Principal to promote itself to Global Administrator.
AZMGAddSecret
This edge is created during post-processing. It is created against all Azure App Registrations and Service Principals when a Service Principal has one of the following MS Graph app roles:
- RoleManagement.ReadWrite.Directory
- Application.ReadWrite.All
With the ability to add new secrets to existing Apps and Service Principals, a Service Principal can impersonate any Service Principal in the tenant and potentially gain higher privileges.
AZMGAddOwner
This edge is created during post-processing. It is created against all App Registrations and Service Principals within the same tenant when a Service Principal has the following MS Graph app role:
- Application.ReadWrite.All
It is also created against all Azure Service Principals when a Service Principal has the following MS Graph app role:
- ServicePrincipalEndpoint.ReadWrite.All
It is also created against all Azure security groups that are not role eligible when a Service Principal has one of the following MS Graph app roles:
- Directory.ReadWrite.All
- Group.ReadWrite.All
Finally, it is created against all Azure security groups (including role-assignable groups) and all Azure App Registrations when a Service Principal has the following MS Graph app role:
- RoleManagement.ReadWrite.Directory
A Service Principal that can add itself as an owner against any of the above-mentioned objects can potentially elevate its privilege by impersonating a target Service Principal or adding itself to a group.
AZMGAddMember
This edge is created during post-processing. It is created against non role assignable Azure AD security groups when a Service Principal has one of the following MS Graph app role assignments:
- Directory.ReadWrite.All
- Group.ReadWrite.All
- GroupMember.ReadWrite.All
It is created against all Azure AD security groups, including those that are role assignable, when a Service Principal has the following MS Graph app role:
- RoleManagement.ReadWrite.Directory
A Service Principal that can add itself to a group may be able to elevate its privilege. Be aware that even non-role assignable groups can be granted privileged roles against Azure Resource Manager objects.
AZAddOwner
This edge is created during post-processing. It is created against all App Registrations and Service Principals within the same tenant when an Azure principal has one of the following Azure Active Directory roles:
- Hybrid Identity Administrator
- Partner Tier1 Support
- Partner Tier2 Support
- Directory Synchronization Accounts
A Service Principal may be able to elevate its privilege by adding itself as an owner to an App or Service Principal, then impersonating the relevant Service Principal.
AZAutomationContributor
The Azure Automation Contributor role grants full control of the target Azure Automation Account. This includes the ability to execute arbitrary commands on the Automation Account.
AZKeyVaultKVContributor
The Key Vault Contributor role grants full control of the target Key Vault. This includes the ability to read all secrets stored on the Key Vault.
AZLogicAppContributor
The Logic Contributor role grants full control of the target Logic App. This includes the ability to execute arbitrary commands on the Logic App.
AZWebsiteContributor
The Website Contributor role grants full control of the target Function App or Web App. Full control of either of those types of resources allows for arbitrary command execution against the target resource.
AZAKSContributor
The Azure Kubernetes Service Contributor role grants full control of the target Azure Kubernetes Service Managed Cluster. This includes the ability to remotely fetch administrator credentials for the cluster as well as the ability to execute arbitrary commands on compute nodes associated with the AKS Managed Cluster.
AZNodeResourceGroup
This edge is created to link Azure Kubernetes Service Managed Clusters to the Virtual Machine Scale Sets they use to execute commands on.
The system-assigned identity for the AKS Cluster will have the Contributor role against the target Resource Group and its child Virtual Machine Scale Sets.
AZMGRoleManagement_ReadWrite_Directory
This edge is created against the Microsoft Graph Service Principal when a Service Principal has been granted the RoleManagement.ReadWrite.Directory edge. You can use this edge to audit which Service Principals have been granted the app role; however, this edge is not abusable and will not show up in attack paths.
This edge is analyzed during post-processing to model the effective outcome of the app role assignment, which is to create the post-processed “AZMG_____” edges mentioned above. Those edges WILL show up in path finding.
AZMGApplication_ReadWrite_All
This edge is created against the Microsoft Graph Service Principal when a Service Principal has been granted the Application.ReadWrite.All edge. You can use this edge to audit which Service Principals have been granted the app role; however, this edge is not abusable and will not show up in attack paths.
This edge is analyzed during post-processing to model the effective outcome of the app role assignment, which is to create the post-processed “AZMG_____” edges mentioned above. Those edges WILL show up in path finding.
AZMGAppRoleAssignment_ReadWrite_All
This edge is created against the Microsoft Graph Service Principal when a Service Principal has been granted the AppRoleAssignment.ReadWrite.All edge. You can use this edge to audit which Service Principals have been granted the app role; however, this edge is not abusable and will not show up in attack paths.
This edge is analyzed during post-processing to model the effective outcome of the app role assignment, which is to create the post-processed “AZMG_____” edges mentioned above. Those edges WILL show up in path finding.
AZMGDirectory_ReadWrite_All
This edge is created against the Microsoft Graph Service Principal when a Service Principal has been granted the Directory.ReadWrite.All edge. You can use this edge to audit which Service Principals have been granted the app role; however, this edge is not abusable and will not show up in attack paths.
This edge is analyzed during post-processing to model the effective outcome of the app role assignment, which is to create the post-processed “AZMG_____” edges mentioned above. Those edges WILL show up in path finding.
AZMGGroup_ReadWrite_All
This edge is created against the Microsoft Graph Service Principal when a Service Principal has been granted the Group.ReadWrite.All edge. You can use this edge to audit which Service Principals have been granted the app role; however, this edge is not abusable and will not show up in attack paths.
This edge is analyzed during post-processing to model the effective outcome of the app role assignment, which is to create the post-processed “AZMG_____” edges mentioned above. Those edges WILL show up in path finding.
AZMGGroupMember_ReadWrite_All
This edge is created against the Microsoft Graph Service Principal when a Service Principal has been granted the GroupMember.ReadWrite.All edge. You can use this edge to audit which Service Principals have been granted the app role; however, this edge is not abusable and will not show up in attack paths.
This edge is analyzed during post-processing to model the effective outcome of the app role assignment, which is to create the post-processed “AZMG_____” edges mentioned above. Those edges WILL show up in path finding.
AZMGServicePrincipalEndpoint_ReadWrite_All
This edge is created against the Microsoft Graph Service Principal when a Service Principal has been granted the ServicePrincipalEndpoint.ReadWrite.All edge. You can use this edge to audit which Service Principals have been granted the app role; however, this edge is not abusable and will not show up in attack paths.
This edge is analyzed during post-processing to model the effective outcome of the app role assignment, which is to create the post-processed “AZMG_____” edges mentioned above. Those edges WILL show up in path finding.
Thank you Jonas Bülow Knudsen, Justin Kohler, and Stephen Hinck for reviewing this blog post
Introducing BloodHound 4.3 — Get Global Admin More Often was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.