The challenge of securing IT environments has reached a new complexity level as a growing number of organisations are adopting cloud solutions. This trend increases even more the possibility of overseen attack paths in an organisation’s IT infrastructure.

Due to the criticality of the IT infrastructure, security analysis and hardening measures are seen as mandatory. Various methods exist to audit IT environments, such as scanning for vulnerabilities or in the form of security recommendations. However, the complexity and potential blind spots are a significant concern. They can lead to attack paths adversaries may abuse to compromise IT systems. In this article, we focus on identity-based attack paths. However, the attack paths method can also be applied to other scenarios such as weak firewall rules or software vulnerabilities.

What are Attack Paths?

Adversaries may use attack paths to pivot through an IT environment based on intended or unintended abusable IT entity-relationships. An attack path can be a construct of complex or simple sequences of relationships. A simplified IT organisation relationship pattern is depicted in the next figure.

An endpoint (1) such as a server, a client or a DevOps pipeline exposes an identity (2) such as a user account, service account or service principal. The identity is entitled to roles or groups (3), which can have various permissions (4). Where certain permissions can control the entire IT environment (5). These entities are usually governed by management systems such as Intune, SCCM, Hypervisors and IAM solutions. The next figure depicts these additional relationships (6-7).

Usually, IT organisations add further complexity by outsourcing a part of their IT environment or using Cloud solutions such as AWS, GCP, Microsoft Cloud, GitLab, GitHub, etc. The following figure depicts this argument.

With the newly added environment, new relationships are introduced. For example, as shown in the next figure, the same general pattern is repeated. Why? Because the pattern may exist likewise in the added environment, which can introduce new overarching attack paths to environment 1.

Why actively search for Attack Paths?

By now, we know that our environment may have a multitude of relationships which may be multiplied if we introduce service providers or new solutions to interact with our IT environment. Can we always know all the relationships? Probably not. Is it important to try? Definitely. To analyse attack paths effectively, we are depended on two facts. First, the collected IT data for the analysis and second, the knowledge of the relationships between the IT entities in our environments. The next figure shows a simplified example of known and unknown attack paths in an attack graph. Since it is difficult to know all attack paths, our goal should be to identify and eliminate as many as possible. This makes it all the more difficult for an attacker to exploit a new unknown path.

The examples used so far are a simplified abstraction to explain the relationship and attack path challenges in IT environments. The following figure shows an attack path that may actually exist in an Azure AD Tenant.

The figure incorporates the elements from before with two environments. Environment 1 is the Azure AD Tenant and Environment 2 is the on-premises Active Directory environment. An Azure AD user is logged in on a hybrid joined device from environment 2. The Azure AD user has owner permissions over a service principal. The service principal is a member of the Global Administrator role and, therefore, can, as the most powerful role in the Microsoft Cloud, control the Azure AD tenant. Finding and removing such a sequence of abusable privileges can measurably improve an environment’s security posture.

Great, but how do we start finding Attack Paths?

Everything starts with a defender’s mindset by being curious about how an IT system such as Active Directory, Microsoft Cloud, DevOps, Jump Servers, etc., works. One method to start is to screen IT entities and their privileges and by asking the question, how can this permission impact my IT environment? Finding the answer can be trivial or complex, but it will help categorise and map entities according to their priorities. With that approach, the journey to knowing your asset relationships has started. Graph theory can be an effective method to assist you on this journey, making complex relationships visible and remediation measurable. Multiple attack path analysis tools exist that utilise graph theory. Tools, such as BloodHound, BloodHound Enterprise, adalanche, Stormspotter and others, already have many IT entity relationships to commonly used IT services implemented and can therefore support you to conduct a first attack path analysis of your IT environment.

Technical Attack Path Example

The following attack path example demonstrates how a user can become a Global Administrator by exfiltrating credentials from Azure DevOps and abusing Azure AD app role permissions. The second part got his inspiration from Andy Robbins, who covers the app role abuse scenario more in detail.

From an Azure DevOps User to Global Administrator

The attack path depicted in the following figure is an extract from a Microsoft Cloud Tenant done with a modified version of AzureHound and BloodHound. We plan to release a blog series about how graph theory and tools such as BloodHound can help you to find attack paths in an environment.

The attack path depicts in the upper-left corner a user called Rabban. The assumption is that an adversary has compromised the user. The adversary aims to become a Global Administrator to gain full control over the Azure AD tenant. The following six steps describe the attack path from the adversary’s viewpoint.

1. The adversary activates the security group called “DevOpsRole-Build Administrators” in Azure PIM for the user Rabban.
   
2. The Group “DevOpsRole-Build Administrators” with its members is synchronised to Azure DevOps,. Azure DevOps is a SaaS platform from Microsoft that provides an end-to-end DevOps toolchain for developing and provisioning. The “DevOpsRole-Build Administrators” group is a direct member of three built-in DevOps groups. According to the description of the Microsoft documentation, the memberships should allow the user Rabban to create and modify pipelines. In Azure DevOps, pipelines are generally used for deployments. The deployments use service principals or other types of key material to authenticate to a target system. This makes the Azure DevOps platform particularly interesting for adversaries.
   
3. By opening the pipeline configuration, the adversary notices that a service principal is used to deploy resources to the targeted Azure AD tenant. This is also shown by the edge RunsAs in the attack path figure. The adversary decides to dump the password of the service principal by modifying the pipeline to print the password to the terminal. By default, Azure DevOps prevents the output of credentials in plain text. Converting the credentials to hex circumvents these preventive measures, and the credentials can be retrieved.
   
4. The following three steps are using the AttackPath_DevOps-Sp-AppRole-GA.ps1 PowerShell script, which automates the second part of the attack. The gained service principal key is converted to ASCII, and the adversary connects with the service principal to Azure AD.
   
5. The figure shows that the service principal has the app role AppRoleAssignment.ReadWrite.All assigned. This role allows the service principal to request a new app role called RoleManagement.ReadWrite.Directory. Per documentation of Microsoft, the newly granted app role allows the service principal to manage Azure AD role memberships.
   
6. In the last step, a new token, which includes the new app role, is requested for the service principal. The adversary decides to add the user Rabban to the Global Administrator role and achieves the goal of becoming a Global Administrator.
   

Different security controls such as MFA, role approval requests or detection rules could have been implemented to make it more difficult for an attacker to abuse the above described multistage attack path. But would it not be better to start by solving the root cause? The root cause in the example is the overprivileged service principal, controlled indirectly by a standard user. This misconfiguration is challenging to find and, even with enabled security solutions, is abuse not always preventable.

Conclusion

Attack path analysis can be a suitable method for finding indirect access paths and implementing tangible preventive measures. We learned that attack path analysis requires a defender’s mindset by being curious about how IT systems such as Active Directory, Microsoft Cloud, DevOps, Jump Servers or others function. Based on this knowledge, the necessary IT data for analysis and the relationships between the IT entities can be assembled to conduct an attack path analysis. Tools like BloodHound, BloodHound Enterprise, adalanche or Stormspotter can be used to find attack paths in commonly used IT services such as Active Directory or the Microsoft Cloud. Ultimately, attack path analysis can set you ahead of adversaries who may try to abuse existing attack paths in your IT environment.

About the Author

Marius Elmiger is a security professional since the early 2000’s. He worked in various IT roles such as an administrator, engineer, architect, and consultant. His main activities included the implementation of complex IT infrastructure projects, implementation of security hardening concepts, and compromise recoveries. Later he transitioned to the offensive side. As a foundation, in addition to numerous IT certificates, Marius graduated with an MSc in Advanced Security & Digital Forensics at Edinburgh Napier University. (ORCID 0000-0002-2580-5636)

Links

• https://bloodhoundenterprise.io
• https://docs.microsoft.com/en-us/azure/devops/organizations/security/permissions?view=azure-devops&tabs=preview-page
• https://docs.microsoft.com/en-us/graph/permissions-reference
• https://gist.github.com/m8r1us/5babd1d63c25c0199520a0a2f8e4f2e4
• https://github.com/Azure/Stormspotter
• https://github.com/BloodHoundAD/AzureHound
• https://github.com/BloodHoundAD/BloodHound
• https://github.com/lkarlslund/adalanche
• https://go.neo4j.com/rs/710-RRC-335/images/Knowledge-Graphs-Data-in-context-responsive.pdf
• https://posts.specterops.io/azure-privilege-escalation-via-azure-api-permissions-abuse-74aee1006f48