• 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
• CrowdStrike Falcon® Cloud Security protects against cloud-aware hacktivists, eCrime adversaries and nation-state actors that might use these techniques to compromise your organization.

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.

Ready to get instant visibility into your Active Directory? Set up a complimentary CrowdStrike AD Risk Review and stop identity-based threats today.

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.

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 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.

 

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:
   1. List all servicePrincipals on compromised tenant

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

   2. 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"
    }
  ]
}

 

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.

 

5. At this juncture, the attacker has a few options to move laterally to the target tenant:
   1. 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.
   2. 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.
   3. 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 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:

1. On Compromised Tenant
2. 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.

 

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.

 

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.

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.

CrowdStrike Falcon Cloud Security Detections

CrowdStrike Falcon Cloud Security unifies cloud security in a single unified platform to deliver comprehensive protection to customers against attacks on public cloud infrastructure. Falcon Cloud Security monitors attacker behavior in Azure tenants and uncovers indicators of attack (IOAs) showing abuse of Azure services and features. In this attack, Falcon Cloud Security monitors the addition of vulnerable CTS policies where an attacker either tries to move laterally or uses them as a backdoor in a tenant. Figure 10 shows a triggered IOA where a CTS policy was added with inbound user sync.

 

Additionally, Falcon Cloud Security provides the following IOAs and identifies misconfigurations affecting CTA policies, which helps users identify and remediate any security risks.

Cross-tenant partner given inbound access	Behavior	A cross-tenant partner was configured in Microsoft Entra ID to support automatic user consent for inbound access.
Cross-tenant partner user syncing enabled	Behavior	A cross-tenant policy was configured in Microsoft Entra ID that enabled automatic user sync.
Default cross-tenant synchronization policy allows outbound automatic user consent	Configuration	A cross-tenant access policy was configured with automatic outbound user consent.
Partner cross-tenant synchronization policy allows inbound user sync	Configuration	A cross-tenant access policy was configured with automatic inbound user consent.

CrowdStrike Best Practice Recommendation

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. CrowdStrike Falcon Cloud Security provides the necessary visibility to protect users from adversaries who might utilize these techniques to abuse CTS.

Is your cloud secure? A FREE CrowdStrike Cloud Security Risk Review quickly enables you to determine how to protect your cloud environment with a lightweight assessment that shows full threat visibility, misconfigurations and vulnerability risks, and how to detect and stop breaches from endpoint to cloud.

Additional Resources

• Forrester named CrowdStrike a Leader in The Forrester Wave: Cloud Workload Security, Q1 2024, stating “CrowdStrike shines in agentless CWP [cloud workload protection] and container runtime protection.” Read more in this blog post.
• Learn why Commercial Bank of California trusts CrowdStrike to meet compliance regulations while going above and beyond to secure client data in the cloud.
• Check out more CrowdStrike customer case studies and videos on cloud security. 
• See for yourself how the industry-leading CrowdStrike Falcon platform protects against modern threats. Start your 15-day free trial today.

• CrowdStrike’s Incident Response team has seen a recent increase in cases involving adversaries that abuse identity provider federation to gain access to protected services by adding and authorizing rogue domains to federation. From these cases, patterns have emerged that indicate a common attack structure.
• Monitoring for identity provider abuse can be difficult, given that adversaries do so by leveraging legitimate cloud services, often using compromised accounts for initial access — a reminder that securing identity and authentication services is critical in preventing these attacks.
• In a recent expansion of CrowdStrike Falcon® Cloud Security detections, CrowdStrike is noting these attacks are prevalent and significant enough to warrant establishing visibility over identity provider management. The indicators of attack discussed in this blog should be considered early indicators that require analysis in context to determine a final verdict on their nature.
• Since observed attack scenarios predominantly target Microsoft Azure as an identity provider, this blog and the referenced detections focus on that domain.

What Is a Federated Identity Provider? 

A federated identity provider is an outside service provider that has been entrusted by an organization as an authority regarding user authentication and identity management. In the context of a service that leverages single sign-on (SSO), when an individual user requests access to the service, the service contacts the identity provider (IdP) to validate the user’s identity.

This capability enables different identity domains (organized groups of users) to partner with one another in validating users and granting their access to a downstream service, domain or cloud environment without having to replicate or maintain multiple instances of user identities. In this way, if an organization provides a service that has a user population outside of its authentication domain, it can extend access to those outside users by defining a trust relationship with the IdP for that outside user group.

The service provider is trusting that the IdP has performed all relevant authentication actions and verifications, and any subsequent access requests by the user to the service should be considered as authorized.

Okta provides details on federated identity and the role of identity providers in SSO.

The Attack

Adversaries are taking advantage of this architecture by compromising IdPs and modifying them to extend the umbrella of trust to include domains and users controlled directly by the attacker and to expand cross-tenant authentication partnerships. An example attack sequence is depicted in Figure 1.

Initial Access

The first step in the attack involves establishing access to the IdP’s cloud service provider (CSP) environment at the Control Plane layer with a user account that has permissions to administer resources.

While there are numerous methods that can be used to compromise a user account, CrowdStrike has noted the use of social engineering to obtain credentials as well as using a self-service password reset to take control of an existing account. Some CSPs also add risk analysis indicators to sign-in activity that can also be leveraged to spot signs of initial access.

Once credentials are obtained and authentication is verified, the adversary has been noted to use the CSP command line interface for initial login.

Reconnaissance

Reconnaissance in observed attacks has been focused on obtaining information that can be specifically leveraged to facilitate adding a new domain to federation settings. Observed behaviors during reconnaissance have included:

• Download users (bulk operation)
• Download role assignments (bulk operation)
• Download groups (bulk operation)
• Get API connectors
• Get authentication flows policy
• Get available output claims
• Get customAuthenticationExtensions
• Get identity providers
• Get tenant details
• Get user flows

It should be noted that CrowdStrike has observed the “get authentication flows policy” action to be extremely common, and by itself, it is not a strong indicator of an attack. It is listed here for reference and is included as part of CrowdStrike Falcon® Cloud Security detection logic as a contributing behavior.

Persistence and Backdoors

Once an attacker has completed their reconnaissance, they move to perform the necessary changes to federation settings to add the domains and user accounts under their control. Actions specifically related to creating a backdoor are listed below:

• Add unverified domain
• Add verified domain
• Verify domain
• Set domain authentication
• Update user
• Set directory feature on tenant

Some attacks may include establishing backdoor access via cross-tenant synchronization, which would be observable via the following:

• Add a partner to cross-tenant access setting
• Update a partner cross-tenant access setting
• Create a partner cross-tenant identity sync setting

Additional actions that have been observed in conjunction with those listed above include the following: 

• Update named location
• Add policy
• Add application
• Add service principal
• Add service principal credentials
• Update application
• Update service principal
• Update provisioning setting or credentials
• Update authorization policy
• Update authentication flows policy
• Set company information

As with the behaviors listed as signs of reconnaissance, some of the behaviors CrowdStrike has categorized as persistence and backdoor may also occur in large volume in the normal course of cloud operations. CrowdStrike detections attempt to account for this and only elevate scenarios that resemble a sequence of behaviors that indicate abuse. It is important to evaluate all detections in context before reaching a final verdict.

Actions on Objectives

The primary goal of abusing federated identity providers is to gain access to resources or services that trust the IdP. Abuse of one IdP is likely used to access resources in an external domain, so this scenario should be viewed largely as a method to establish access and maintain persistence via the IdP. 

Some observed actions on objectives related to these attacks include:

• Creating cloud compute resources or VMs
• Accessing cloud compute resources and exfiltrating data by exporting virtual disks
• Obtaining user information from the IdP
• Accessing data in applications that rely on the IdP access controls
• Leveraging the Azure run command to deploy other tooling

Why Is It Important to Monitor Changes to Identity Provider Configurations?

Organizations delegate user access controls to outside IdPs, which means the outside IdP is entrusted with maintaining the confidentiality, integrity, and availability of downstream services and data. Identity management and user access control are paramount to information security.

Monitoring for the scenarios outlined above provides customers with early indications of sensitive behaviors — or sequences of behaviors — that CrowdStrike believes warrant awareness and validation. This will give Falcon Cloud Security customers the opportunity to detect these attacks quickly and also obtain evidence that could be useful in incident response activities.  

Falcon Cloud Security Detections

In response to the observed patterns in these attacks, the Falcon Cloud Security team analyzed the prevalence of the noted behaviors and has worked to build detections that attempt to elevate awareness when a matching pattern of activity has occurred. These detections represent a combination of perspectives that warrant awareness and response by security teams.

1. Configuration changes that rarely occur and have potential for significant abuse
2. Behaviors that rarely occur in combination with others and may resemble a known attack sequence
3. Specific behaviors leveraged in these attacks

Detection Name	Type	Description
User accounts exported from Active Directory	Behavior	A bulk export was performed of all user accounts in Active Directory. While this could be legitimate Admin behavior, it could also indicate a threat actor is performing reconnaissance of user accounts in an attempt to elevate privileges and move laterally in your tenant. It is recommended this behavior be reviewed to validate the user’s need to export all user accounts and ensure this data is not improperly shared.
User groups exported from Active Directory	Behavior	A bulk export was performed of all user groups in Active Directory. While this could be legitimate Admin behavior, it could also indicate a threat actor is performing reconnaissance of user groups in an attempt to elevate privileges and move laterally in your tenant. It is recommended this behavior be reviewed to validate the user’s need to export all user groups and ensure this data is not improperly shared.
Role assignments exported from Active Directory	Behavior	A bulk export was performed of all role assignments in Active Directory. While this could be legitimate Admin behavior, it could also indicate a threat actor is performing reconnaissance of role assignments in an attempt to move laterally and escalate privileges in your tenant. It is recommended this behavior be reviewed to validate the user’s need to export all role assignments and ensure this data is not improperly shared.
New unverified domain added to tenant	Behavior	A custom domain was added to the Azure Active Directory (Azure AD) tenant. This is often the first step in configuring federated domain authentication. Federated domain authentication is a legitimately used configuration to support using on-premises passwords. Adversaries also leverage this Azure AD feature to create Azure AD persisted backdoors by configuring new federated domains with resources/infrastructure that they control.
Guest users given same permissions to Azure AD resources as member users	Behavior	Azure Active Directory was updated to give guest users the same access to Azure AD resources as member users. This setting gives guest users the ability to view and interact with Active Directory resources that they may not need access to and should be reviewed to ensure the access is appropriate.
Cross-tenant partner given inbound access	Behavior	A cross-tenant partner was configured in Azure Active Directory to support automatic user consent for inbound access. Cross-tenant synchronization is a legitimately used configuration to automate creating, updating and deleting Azure AD B2B users across different tenants. Adversaries also leverage this Azure AD feature to create persisted backdoors by adding new cross-tenant partners (controlled by the adversaries) to environments they have compromised.
Cross-tenant partner user syncing enabled	Behavior	A cross-tenant partner was configured in Azure Active Directory to support inbound user syncing/creation. Cross-tenant synchronization is a legitimately used configuration to automate creating, updating and deleting Azure AD B2B users across different tenants. Adversaries also leverage this Azure AD feature to create persisted backdoors by adding new cross-tenant partners (controlled by the adversaries) to environments they have compromised.
New federated domain added to Azure Active Directory	Behavior	A domain was configured in Azure Active Directory to support federated authentication. Integrating Azure AD with on-premises Active Directory using Active Directory Federation Services (AD FS) is a legitimately used configuration to support using on-premises passwords. Adversaries also leverage this Azure AD feature to create Azure AD persisted backdoors by configuring new federated domains with resources/infrastructure that they control.
Virtual machine disk exported by user	Behavior	A virtual machine disk was made available for download/export by a user account. Review the activity and validate the user’s need to export the disk, as this may be a way for an attacker to collect and exfiltrate data stored on the disk.
Default cross-tenant synchronization policy allows outbound automatic user consent	Configuration	In a breach scenario, an attacker can utilize automatic outbound user consent within a cross-tenant synchronization policy to sync the compromised user account into a partner tenant and grant attacker access using the same initially compromised credentials. It is not recommended to allow automatic outbound user consent.
Partner cross-tenant synchronization policy allows inbound user sync	Configuration	In a breach scenario, an attacker can utilize inbound identity synchronization within a cross-tenant synchronization policy to sync the compromised user account into a partner tenant and grant attacker access using the same initially compromised credentials. It is not recommended to automatically sync identities into tenants you are not in control of.

Response Recommendations

Because the behaviors outlined in this attack sequence take advantage of normal features of identity provider federation, it is possible that initial setup or routine administrative maintenance may trigger detections. CrowdStrike has considered the potential for producing false positive detections and has concluded that it is worthwhile to maintain vigilant monitoring of these sensitive functions. CrowdStrike recommends that organizations review all changes to IdP settings to verify that:

1. The user account used to perform the changes is authorized by role and policy to do so.
2. The user account performing the changes has not been compromised, and endpoints associated with the user are not exhibiting signs of malware.
   1. This should include a review of recent actions performed by the user account to determine if it is being used in an unusual manner.
   2. Consider signs of phishing, social engineering or recent password resets related to the user account.
   3. Consider authentication details for the user account, including source IP address, region and user-agent strings to look for signs it is being accessed from an unusual source.
   4. Review endpoint detections for suspicious activity involving the user account in question.
3. The observed changes to IdP configurations were authorized through existing governance, risk and compliance (GRC) review and performed in compliance with change management policies and procedures. 
   1. Consider the domains added and their validity in relationship to the business and service context in which they are being used.
   2. Consider the reputation and threat history of new domains.
   3. For suspect domains, review any future login and service access activity originating from the new IdP.

Conclusion

Abuse of federated identity providers appears to be on the rise and represents a significant threat to downstream services, applications and data. 

CrowdStrike has released detections in Falcon Cloud Security that are designed to shed light on administrative behaviors that could represent attempts to compromise this trust architecture so that customers have early warnings an attack may be occurring.

While the attack outlined in this blog shows that adversaries are leveraging legitimate cloud services and configurations to perform their attacks, CrowdStrike’s detections are designed to differentiate normal administrative functions from those with suspect attributes that could indicate an attack in progress.

Due to the nature of this compromise, a timely response is prudent. CrowdStrike recommends taking immediate steps to validate the observed behaviors are authorized and to remediate them if they are not authorized by reversing any changes made. By quickly cutting off access established by an adversary, CrowdStrike customers can disrupt the attack and stop the breach.

Additional Resources

• Learn more about how you can stop cloud breaches with CrowdStrike unified cloud security for multi-cloud and hybrid environments — all in one lightweight platform.
• Learn how CrowdStrike’s Proactive Services can help you prepare for cybersecurity incidents. 
• Learn how the powerful CrowdStrike Falcon® platform provides comprehensive protection across your organization, workers and data, wherever they are located.
• See for yourself how the industry-leading CrowdStrike Falcon platform protects against modern threats. Start your 15-day free trial today.