Defend Against Azure Cross-Tenant Synchronization Attacks

Originally published by CrowdStrike.

• Azure cross-tenant synchronization (CTS) was made generally available on May 30, 2023, and introduced a new attack surface on Microsoft Entra ID (formerly Azure Active Directory) where attackers can move laterally to a partner tenant or create a backdoor on an existing tenant.
• CrowdStrike showcases two observed attack paths to outline how adversaries can abuse CTS

As Microsoft Azure continues to gain market share in the cloud infrastructure space, it has garnered attention from adversaries ranging from hacktivist and eCrime threat actors to nation-state adversaries. Recent attacks on Microsoft by cloud-focused threat actors like COZY BEAR are becoming more frequent and garnering huge attention.

Adversaries are using novel cloud-focused techniques and tactics to achieve their goals. CrowdStrike has previously disclosed campaigns — for example, StellarParticle — that show the abuse of assets including Microsoft identities, Office 365 and more. Today, we will dive into one such adversary technique that abuses Microsoft Azure Active Directory (now called Entra ID) cross-tenant synchronization. We will show two observed attack paths to outline the impact. Let’s begin.

What Is Azure Cross-Tenant Synchronization?

Introduced by Microsoft in May 2023, cross-tenant synchronization (CTS) stands as a pivotal feature designed to streamline the automation of creating, updating and deleting B2B users/groups across tenants. This functionality empowers users and groups created through CTS to seamlessly access a spectrum of applications, ranging from Microsoft applications like Teams and SharePoint to non-Microsoft counterparts.

CTS uses a simple push operation on the “source” tenant to facilitate the synchronization of users/groups to the “target” tenant. Administrators in the target tenant retain control, with the ability to halt synchronization at their discretion or remove a source tenant by adjusting the configuration of their cross-tenant access (CTA) policy. This flexibility ensures efficient management and oversight over the cross-tenant synchronization process.

Abusing Cross-Tenant Synchronization

To abuse CTS within a Microsoft environment, attackers need specific roles that grant them the necessary privileges to create or modify CTS policy settings. Once attackers compromise a tenant, they can use existing CTS policies to move laterally to a partner tenant or add a backdoor into the tenant using CTS.

Access to the following roles is required to abuse CTS:

1. Each user being synchronized needs a Microsoft Entra ID P1 license in the source tenant
2. The attacker needs the following roles in the compromised tenant to establish persistent access:
   1. Global Administrator role to make all changes required for the attack
   2. Security Administrator role to configure CTA settings
   3. Hybrid Identity Administrator role to configure CTS
   4. Cloud Application Administrator or Application Administrator role to assign users to a configuration and delete a configuration

With the required access, attackers can take two attack paths to abuse the CTS feature:

1. A lateral movement using CTS
2. An identity backdoor on a compromised tenant using CTS

Figure 1 below delves into the details of both attack paths. Initially, an attacker compromises a (source) tenant and gains the necessary privileges. From there, the attacker can enumerate partner tenants with configured CTA and ensure CTS is enabled with the required inbound or outbound CTA policy. After enumeration, the attacker can leverage an already synchronized user identity to move laterally to the target tenant, thereby gaining access to the applications and services associated with that tenant.

If the attacker wants to establish persistence on a compromised tenant, they can add an attacker-controlled tenant as a partner in a compromised tenant by creating a CTA policy with automatic user invitation redemption and enabling inbound synchronization. Subsequently, an attacker-controlled tenant can initiate the push of user accounts to compromised tenants and establish persistence by abusing CTS. The following section will dive into each attack path in detail.

Figure 1. Attack path details

Attack Path 1: Lateral Movement Using Cross-Tenant Synchronization

Adversaries can achieve initial foothold by compromising Azure tenants in multiple ways, including but not limited to vulnerabilities in public-facing applications or APIs, leaked credentials, stolen identities and zero-day exploits. Once attackers acquire the necessary access and privileges defined in the earlier section, then attackers are positioned to abuse CTS.

Figure 2. Moving laterally using CTS

Figure 2 shows the general flow of the attack. The attacker takes the following steps to achieve lateral movement to the target tenant:

1. Initially, an attacker compromises a source tenant acquiring the necessary privileges. It enables an attacker to gather crucial information for lateral movement. This could be executed through various means, such as leveraging a command-line interface or console. For our purposes, this blog uses Microsoft Graph API endpoints to illustrate the attack.

2. Subsequently, the attacker uses Microsoft Graph API to enumerate the CrossTenantAccessPolicy to find the target tenants (partner tenants) already available on the compromised tenant. The attacker tries to locate target tenant IDs where AutomaticUserConsentSettings set to outboundAllowed: true. As shown in Figure 3, the found tenant ID can potentially be abused by the attacker.

Figure 3. Attacker enumerates the CTA policy to find target tenants (partner tenants)

3. Following the discovery of tenant IDs, the attacker proceeds to identify a synchronization application servicePrincipal that pushes users/groups to the target tenant. Fortunately, there is no readily available API to do this easily. This step can be broken into the following:

• List all servicePrincipals on compromised tenant

GET https://graph.microsoft.com/v1.0/servicePrincipals

• Use each servicePrincipal to find a synchronization application used for a target tenant. The following query can be used to automate this process. If the query is successful (200 OK), then that servicePrincipal is used to create a synchronization application for a given target tenant. Figure 4 shows a successful query

POST https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/jobs/validateCredentials
Content-Type: application/json

{
  "useSavedCredentials": false,
  "templateId": "Azure2Azure",
  "credentials": [
    {
      "key": "CompanyId",
      "value": "{TargetTenantId}"
    },
    {
      "key": "AuthenticationType",
      "value": "SyncPolicy"
    }
  ]
}

Figure 4. Successfully locating the servicePrincipal used in a synchronization application

4. Now, the attacker employs the query depicted in Figure 5 to identify users/groups being synced to the target tenant using servicePrincipal found in an earlier step. Figure 5 also shows the username “abc” being synced to the target tenant.

Figure 5. User “abc” being synced to the target tenant

5. At this juncture, the attacker has a few options to move laterally to the target tenant:

• The attacker can opt for an existing user that is already synced to the target tenant. This is a very stealthy method, as the attacker doesn’t need to modify a compromised tenant to move laterally to the target tenant.
• The attacker can add a new user to sync into the target tenant and use the credentials associated with it to attack the target tenant if CTS is properly configured and operational.
• The attacker can also add a new user to a group that is already synced into the target tenant if CTS is properly configured and operational.

6. Upon successful login with the chosen user, the attacker gets access to the target tenant. Furthermore, this access extends to Microsoft or third-party applications associated with the target tenants, enhancing the attacker's potential for exploitation.

Attack Path 2: Identity Backdoor on Compromised Tenant Using Cross-Tenant Synchronization

Once an attacker successfully compromises a tenant and acquires the necessary privileges, the establishment of persistence becomes a paramount objective. Let's delve into the details on how an attacker might establish and maintain persistence within a compromised tenant.

Figure 6. Identity backdoor in compromised tenant using CTS

Figure 6 provides a visual representation of the attack flow for establishing persistent access to compromised tenants. We now break down the attack into two distinct steps:

• A. On Compromised Tenant
• B. On Attacker-Controlled Tenant

A. On Compromised Tenant

1. The attacker needs to obtain the required access as described in the earlier section.

2. Having obtained the necessary access, the attacker proceeds to create a new CTA incorporating the attacker-controlled tenant ID. Essentially, this action establishes the attacker-controlled tenant as a partner within the compromised tenant. Figure 7 shows Microsoft Entra ID audit logs for this maneuver.

Figure 7. Partner tenant ID addition in CTA

3. Subsequently, the attacker makes further modifications by adjusting the inbound CTA settings to enable AutomaticUserConsent. Specifically, by setting “inboundAllowed”:true. This enables automatic user invitation redemption, as shown in Figure 8.

Figure 8. CTA modification to allow inbound automatic user invitation redemption

4. Continuing with the attack sequence, the attacker proceeds to another modification of inbound CTA, but this time, setting “IsSyncAllowed”:true . This particular configuration allows the attacker to push user accounts into the compromised tenant, a critical step highlighted in Figure 9. With the successful completion of this step, the attacker effectively establishes a backdoor within the compromised tenant.

Figure 9. CTA modification to allow inbound synchronization

B. On Attacker-Controlled Tenant

In the realm of the attacker-controlled tenant, the actions orchestrated by the attacker remain beyond monitoring, as this tenant operates external to the organization. Consequently, we won’t add logs or API requests to show this activity. The general steps for an attacker to configure CTS are as following:

1. The attacker needs a tenant that has the required Microsoft Entra ID premium license.
2. Continuing the course, the attacker proceeds to create a new CTA policy within the attacker-controlled tenant. This involves the addition of a compromised Tenant ID, effectively integrating the compromised tenant as a partner within the attacker-controlled environment.
3. The attacker then modifies outbound CTA settings to enable AutomaticUserConsent by setting “outboundAllowed”:true. This enables an automatic user invitation redemption policy matching the compromised tenant.
4. Subsequently, the attacker creates a CTS synchronization application and proceeds to add chosen users or groups to the CTS synchronization application.
5. At this point, the attacker creates an automatic provisioning job to push these users and groups to the compromised tenant.
6. The synchronization job uses the push operation to achieve the objective. This job can be forced to run on demand to push chosen users/groups to compromised tenants.
7. With the successful push of malicious users and groups, the attacker gains an entry point into the compromised tenant. This access can extend beyond the compromised tenant, enabling the attacker to seamlessly log into Microsoft or third-party applications associated with the compromised environment.

Best Practice Recommendations

To safeguard your Azure tenant from potential abuse of CTA and maintain a robust security posture, it's imperative to adhere to best practices. Consider the following recommendations:

1. Monitor external identities invited or synced into your tenant. Limit the privileges on such identities to control the blast radius.
2. Monitor CTA policies being created on the tenant and validate any inbound or outbound settings that are modified to create exposure in the tenant.
3. Monitor partner accounts added into tenants using CTA policies, and use a naming convention to differentiate each user from different partners synchronized into the tenant.
4. Use secure default inbound and outbound access policies. Insecure default policies can create exposure to the tenant.
5. Don’t trust multifactor authentication (MFA) from the source tenant for identities.
6. Closely monitor administrator roles for any suspicious activities with respect to CTS.

Conclusion

The abuse of cloud provider services is a common technique utilized by many cloud-aware adversaries. New cloud provider features — like CTS — typically become unexplored attack surfaces for attackers as well as researchers. More often than not, new features need to gather feedback from users. This feedback often necessitates a change in design, visibility and security. This opens up a window of opportunity for adversaries to abuse the feature and find vulnerabilities.

Entra ID CTS is a feature that focuses on the ease of doing business and collaboration but is being abused by cloud-aware threat actors. Hence, cloud security practitioners need to be aware of the tactics, techniques and procedures used in this attack, where an attacker attempts to move laterally into different organization tenants or to create and maintain a backdoor in compromised tenants.