Emerging Attacker Exploit: Microsoft Cross-Tenant Synchronization by Arpan Sarkar

Senior Technical Marketing Engineer

and

August 1, 2023

Please note that this is an automated translation. For the most accurate information, refer to the original version in English.

Vectra Research recently discovered a method for leveraging functionality newly-released by Microsoft to perform lateral movement to another Microsoft tenant.

‍

Executive Summary

Vectra Research identified a new attack vector against Azure Active Directory that enables lateral movement to other Microsoft tenants.
Vectra also demonstrates the technique to maintain persistent access in an Azure tenant, first outlined here.
The underlying functionality for the execution of this attack vector exists in every Microsoft deployment.
This attack vector follows similar attack vectors known to be in use like the abuse of domain federation or adding a partner company, which requires active monitoring for detection and response.
Vectra has published a POC for security testing within the open-source MAAD Attack Framework.
Vectra has validated that Vectra’s AI detections provide coverage for this operation prior to the documentation of the techniques in this report.

‍

Introduction

Attackers continue to target Microsoft identities to gain access to connected Microsoft applications and federated SaaS applications. Additionally, attackers continue to progress their attacks in these environments, not by exploiting vulnerabilities, but by abusing native Microsoft functionality to achieve their objective. The attacker group Nobelium, linked with the SolarWinds attacks, has been documented using native functionality like the creation of Federated Trusts ^[4] to enable persistent access to a Microsoft tenant.

In this Blog post, we will demonstrate an additional native functionality that when leveraged by an attacker enables persistent access to a Microsoft cloud tenant and lateral movement capabilities to another tenant. This attack vector enables an attacker operating in a compromised tenant to abuse a misconfigured Cross-Tenant Synchronization (CTS) configuration and gain access to other connected tenants or deploy a rogue CTS configuration to maintain persistence within the tenant.

We have not observed the use of this technique in the wild but given the historical abuse of similar functionality — we present details for defenders to understand how the attack would present and how to monitor for its execution. In addition, this blog will review how Vectra customers currently have coverage — and have had coverage from day one of the functionality being released for this technique through our AI-driven detections and Vectra Attack Signal Intelligence^TM.

‍

Cross-Tenant Synchronization

CTS is a new feature from Microsoft that enables organizations to synchronize users and groups from other source tenants and grant them access to resources (both Microsoft and non-Microsoft applications) in the target tenant. CTS features build on previous B2B trust configurations enabling automated and seamless collaboration between different tenants and is a feature that many organizations will look to adopt. ^[2]^[3]

‍

‍

CTS is a powerful and useful feature for organizations like business conglomerates with multiple tenants across affiliated companies, but also opens potential reconnaissance, lateral movement and persistence attacks by bad actors if not configured and managed correctly. We’ll discuss the potential risks and attack paths that adversaries can leverage to exploit CTS to abuse trust relationships from a potentially compromised tenant to any other tenant configured with a CTS trust relationship.

CTS allows users from another tenant to be synced (added) into a target tenant.
A loosely configured CTS configuration can be exploited to move laterally from a compromised tenant to another tenant of the same or different organization.
A rogue CTS configuration can be deployed and used as a backdoor technique to maintain access from an external adversary-controlled Microsoft tenant.

‍

Assumed compromise!

The exploitation techniques follow Assumed Compromise philosophy. The techniques used in these exploits assume that an identity has been compromised in a Microsoft cloud environment. In a real-world setting, this could originate from a browser compromise on an Intune-managed endpoint with a Microsoft-managed identity.

‍

Terminology

‍

‍

The Facilitator

Important things to know about CTS configuration:

New users get synced into a tenant via push (not pull). ^[2]
1. Source tenant pushes new users to sync into the target tenant.
Automatic Consent Redemption setup.^[2]
1. Enabling this eliminates the need to consent anytime new users are synced into a target tenant.
Users in scope for synchronization are configured in the source tenant.^[2]

‍

The Attack

The attack techniques described in this blog require certain licenses and a privileged account compromise or privilege escalation to certain roles in the compromised tenant. A Global Admin role can perform all these actions in a tenant. ^[2]

‍

‍

Technique 1: Lateral Movement

An attacker operating in a compromised environment can exploit an existing CTS configuration tenant to move laterally from one tenant to another connected tenant.

‍

Lateral movement attack schematics — *Figure 1: Lateral Movement Attack Overview*

‍

The attacker accesses the compromised tenant.
Attacker recons the environment to identify target tenants connected via deployed Cross Tenant Access policies.

‍

‍

Attacker reviews Cross Tenant Access policy configuration for each connected tenant to identify one with ‘Outbound Sync’ enabled. CTA policy with Outbound Sync enabled allows users and groups from the current tenant to be synchronized into the target tenant.

‍

From the CTA policy configuration analysis, the attacker finds a connected tenant with Outbound Sync enabled and sets the tenant as the target for lateral movement.

The attacker then recons the compromised tenant to find CTS sync application that runs the job of synchronizing users and groups to the target tenant.
1. There is no straight forward way to find the CTS sync application linked to the target tenant. The attacker can enumerate through service principals in the tenant attempting to validate credentials with the target tenant to ultimately find the application that hosts the sync job to the target tenant. It can be done through a simple module like this.

‍

After identifying the CTS sync application, the attacker can modify its configuration to add the currently compromised user account to the application sync scope. This will sync the compromised user account into the target tenant and grant attacker access to the target tenant using the same initially compromised credentials.

‍

Alternatively, the attacker can also inspect the CTS sync application configuration to identify configured sync scope and act accordingly.
1. For example, if the object in sync scope is a group, then the attacker can attempt to add the compromised user account directly or indirectly to the group which will automatically allow the compromised account to be synced into the target tenant.

If there are no explicit CTA inbound conditions blocking the sync in the target tenant, the compromised account will sync into the target tenant.
The attacker moves laterally into the target tenant using the same initially compromised account.

‍

Technique 2: Backdoor

An attacker operating in a compromised tenant can deploy a rogue Cross Tenant Access configuration to maintain persistent access.

‍

backdoor attack schematics — *Figure 2: CTS Backdoor Attack Overview*

‍

The attacker accesses the compromised tenant.

The attacker attempts to deploy a new Cross Tenant Access Policy in the victim tenant with the following properties.
1. Add a new CTA policy with the source tenant defined as the attacker-controlled external tenant.
2. Configure the new CTA policy to enable ‘Inbound Sync’.
3. Enable ‘Automatic User Consent’ for inbound user sync.
Simultaneously, the attacker also configures CTS on its external tenant.
1. The external tenant CTS setup is out of scope for this article and hence not covered here. The process of setting CTS in a source tenant is well defined by Microsoft here.

The attacker can now sync new users from its tenant via push to the target victim tenant anytime in future. This grants the attacker future access to resources on the target tenant using the externally controlled account.

‍

Defense

The attack techniques in this document follow assumed compromise. Businesses must continue to implement and enforce security best practices to reduce the risk of account compromise.
CTS Target tenants must:
1. Avoid implementing a default inbound CTA configuration which permits all users/groups/applications from the source tenant to sync inbound. ^[1]
2. Deploy less inclusive inbound CTA configuration such as explicitly defining accounts (if possible) or groups that can get access through CTS.
3. Combine CTA policy with additional Conditional Access Policies to prevent unauthorized access.
CTS Source tenants must:
1. Ensure groups allowed to access other tenants via CTS (and all privileged groups in general) are properly regulated and monitored.
Detect and respond at scale and speed.

‍

Vectra Customers:

Vectra’s existing portfolio of alerts are capable of detecting this activity even prior to understanding this operations implication as well as the expected actions that would occur prior to this event.

The fact that there is no actual vulnerability exploited in this technique makes it harder to prevent once an adversary is in the environment with sufficient privileges. However, Vectra’s AI-driven detections have been designed to detect these types of privilege abuse scenarios without having to rely on signatures or lists of known operations.

Vectra’s Azure AD Privilege Operation Anomaly monitors for the underlying value of every operation in the environment and every user. The AI continuously creates a baseline of the types of actions that should be occurring in the environment and identifies cases of cloud-based privilege abuse. By focusing on the behavior of privilege abuse, Vectra is able to identify emerging techniques like the one documented here.

‍

Attacker actions that would occur prior to the attack such as the account access following a token theft or other forms of account compromise, would be alerted on by Vectra detections like Azure AD Unusual Scripting Engine Usage, Azure AD Suspicious Sign-on or Azure AD Suspicious OAuth Application.

‍

Microsoft Cloud Security Testing

Testing environments regularly and effectively is the best way to be confident in the ability to defend against cyberattacks. MAAD-Attack Framework is an open-source attack emulation tool that combines the most commonly used attacker techniques and allows security teams to quickly and effectively emulate them in their environments via a simple interactive terminal. Check out MAAD-AF on GitHub or learn more about it here.

Security teams can use MAAD-AF module “Exploit Cross Tenant Synchronization” to emulate and test against the CTS exploitation techniques in their environment.

References: