Microsoft Entra ID’s cross tenant synchronization feature allows an attacker the ability to laterally move to a partner tenant – opening an attack path for tenant-to-tenant lateral movement. This feature was released in March 2023 and the “legitimate” purpose of the feature was to allow automation of creation, deletion and updating of Entra B2B collaboration. In short, it allows collaboration for a multitenant organisation.
By abusing cross tenant synchronisation maliciously, (and depending on how it’s abused) a threat actor can:
Persist in a victim’s tenant by commissioning a new account every time they are locked out.
Laterally move from one tenant to another tenant.
This blog post will cover how the attack works, and how to approach the detection methodology.
Attack Methodology
As there are two methods of abusing this technique (persistence and lateral movement) – we will focus on the persistence attack path to demonstrate how to leverage this feature maliciously to perform the lateral movement. Hopefully this helps elucidate some of the more “confusing” aspects of the various features and names.
At a high-level, the attacker sets up cross-tenant synchronisation between the attacker tenant and the victim tenant. Once the attacker has been detected by the blue team, and has had their account locked out, they can leverage the cross-tenant synchronisation feature to provision another malicious account inside the victim tenant. From the perspective of a legitimate cross-tenant synchronisation set-up, an attacker can leverage the existing set-up to hop from the first victim, to the second victim tenant.
Pre-Requisites
To abuse cross tenant synchronisation, the tenant requires a P1 or a P2 license. Since this is a persistence/lateral movement technique – it requires the attacker to have already compromised an account and gained a foothold into the victim environment. The attacker needs to have compromised or elevated the compromised account to have the permissions:
- microsoft.directory/crossTenantAccessPolicy/partners/identitySynchronization/basic/update
- microsoft.directory/crossTenantAccessPolicy/partners/create
The first permission allows the attacker the ability to “create” cross-tenant access policies for partners. The second permissions allowing them the ability to update basic settings relating to cross-tenant sync.
To summarise the pre-requisites of this attack:
P1 or P2 license
Compromised account with the above permissions OR Global Administrator / Security Administrator
There are other roles that allow some “reading” or “enabling” of cross-tenant synchronisation but do not have enough permission to modify, create or change settings.
Skip steps 1 to 3 if you just want to laterally move from one tenant to another without leveraging cross tenant synchronisation as a persistence technique.
Step 1: Allow inbound access from attacker tenant (Victim Tenant)
Using the compromised account, an attacker needs to allow inbound access from the attacker by updating the cross-tenant access settings. This is accessible in entra.microsoft.com:
- Identity > External Identities
- Cross-tenant Access Settings
The attacker needs to “+ Add organisation” and type in the organisation tenant that they want to grant access from.
Then the attacker needs to make sure inbound access from the attacker tenant is allowed by the victim tenant. This is done by editing the ‘inbound’ access settings and ensuring that under Cross-tenant sync, the checkbox for “Allow users sync into this tenant” is selected.
Step 2: Set-up cross-tenant synchronisation (Attacker’s Tenant)
The attacker needs to create a cross-tenant synchronisation configuration granting access to the victim tenant. This will then be used by the attacker to actively provision new users inside the victim’s tenant when the attacker account gets burned by the defenders.
Step 3: Allow outbound access to the victim tenant (Attack Tenant)
Similar to what we’ve done in the victim tenant, we need to do the inverse in the attacker’s tenant to allow outbound access to the victim tenant. This is done by completing the same steps as Step 1, but typing in the victim tenant name and modifying just the “outbound” settings.
Step 4: Provision users in the victim tenant (Attack Tenant)
There are two reasons why an attacker would leverage this step. Either their compromised account got burned and they want to issue a new account to persist in the compromised tenant OR they have discovered the victim tenant has cross tenant synchronisation with another tenant the attacker wants to laterally move to. The next step is the same despite whichever reason.
To perform the lateral movement, the attacker first needs to provision a new account to access the victim tenant.
After provisioning, the attacker can select an account that exists in the current tenant to be “provisioned” into the victim’s tenant. In this instance, we have just selected an account called “EvilUser” to make things obvious for the post.
Once this has successfully provisioned, the victim tenant will automatically have a new user present in Entra ID – as you can see here, in the victim tenant (neurathinkorg.onmicrosoft.com) there is an attacker account named “EvilUser” from a different tenant appearing.
Step 5: Laterally move using the newly provisioned account
At this point, the attacker just needs to laterally move into the tenant with the newly provisioned account. Here, we have signed into portal.azure.com with the account EvilUser and you can see the option to switch directories into the victim’s directory.
Detection Methodology
To detect either the abuse of this technique as a persistence or lateral movement method, you need to focus on the following three steps. Please note, the first two steps are not relevant if this is purely being leveraged as a lateral movement technique with an existing cross tenant synchronisation.
- Creation of an inbound/outbound external identity to a different tenant
- Editing a cross-tenant synchronisation setting (allowing in or outbound access)
- Creation of a provisioned malicious user account
- Logons and subsequent actions taken
Step 1: Detect creation of external identity
These will always show up inside the audit logs. The audit logs will show the following events with the following details:
- Category: CrossTenantAccessSettings
- Activity: Add/Update a partner cross-tenant access setting
If you drill down under modified properties, it will reveal the tenant id of the tenant that access is granted to or from. In this instance this is the tenant ID of the attacker’s tenant.
Step 2: Editing of inbound/outbound cross-tenant synchronisation settings
Each time a new inbound or outbound cross-tenant synchronisation setting has been modified, a correlating event will be created inside the audit logs. These will have the details:
- Category: Policy
- Activity: Add Policy
To ensure that the “policy” is related to a cross tenant synchronisation policy, you need to further confirm by looking under Target(s) and verifying that it’s a cross tenant synchronisation related policy.
Step 3: Provisioning attack users
Each time a user has been provisioned inside a tenant as a part of an attacker abusing cross-tenant synchronisation. This can be seen under the audit logs as well. Three events will be generated per EACH invited user. Look for the following details:
- Category: UserManagement
Activity: Update User / Redeem external user invite / Invite external user
To drill down into which user was invited, you will see details under the Target(s) section of the log where you will see exactly which user was invited and from which tenant.
Step 4: Identifying the lateral movement
Now that we have identified the provisioned account and the setup of the cross tenant synchronisation feature (if relevant), it’s time to actually tie this with the lateral movement.
Logons that come via cross tenant synchronisation will have a specific setting called “B2B Collaboration” which we mentioned earlier was the legitimate purpose of cross tenant synchronisation.
Look for sign-in logs showing signs where:
- Cross tenant access type: B2B Collaboration
- The username is the eternally invited user (that was provisioned)
By tying together these four detection events, you will be able to determine the malicious abuse of the cross tenant synchronisation abuse.
Happy hunting!
Previous Work and Further Reading
Microsoft Entra ID Cross Tenant Synchronisation
CrowdStrike Defends Against Azure Cross Tenant Synchronization Attacks
Incident Response in Azure