[]()
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 [[1]]() to enable persistent access to a Microsoft tenant.
This article demonstrates 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. Vectra AI has not observed the use of this technique in the wild but given the historical abuse of similar functionality â Vectra AI presents details for defenders to understand how the attack would present and how to monitor for its execution. In addition, the article will review how Vectra AI customers currently have coverage â and have had coverage from day one of the functionality being released for this technique through their 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. Read on for 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.
### Terminologies
**Source tenant** | Tenant from where users & groups are getting synced
—|—
**Target tenant** | Tenant with resources where users & groups are getting synced
**Resources** | Microsoft applications (Teams, SharePoint, etc.) and non-Microsoft applications (ServiceNow, Adobe, etc.)
**CTS** | Abbreviation to reference ‘Cross Tenant Synchronization’ in this document
**CTA** | Abbreviation to reference ‘Cross Tenant Access’ in this document
**Compromised Account** | Adversaries initial point of access
### The Facilitator
Important things to know about CTS configuration:
1. New users get synced into a tenant via push (not pull). [[2]]()
* Source tenant pushes new users to sync into the target tenant.
* Automatic Consent Redemption setup. [[3]]()
* 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 article 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. [[3]]()
**Action** | **Source Tenant** | **Target Tenant**
—|—|—
**Tenant License** | Azure AD Premium P1 or P2 | Azure AD Premium P1 or P2
**Configure CTA** | Security Administrator | Security Administrator
**Configure CTS** | Hybrid Identity Administrator | N/A
**Assign users to CTS configuration** | Cloud Admin or Application Admin | N/A
### 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.
[]()
—
Figure 1 : Lateral Movement Attack Overview
1. The attacker accesses the compromised tenant.
2. Attacker recons the environment to identify target tenants connected via deployed Cross Tenant Access policies.
[]()
3. 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.
[]()
4. 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.
5. 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.
* 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.
[]()
* 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.
### Scenario 2: Backdoor
An attacker operating in a compromised tenant can deploy a rogue Cross Tenant Access configuration to maintain persistent access.
[]()
—
Figure 2: CTS Backdoor Attack Overview
1. The attacker accesses the compromised tenant.
2. The attacker attempts to deploy a new Cross Tenant Access Policy in the victim tenant with the following properties.
* Add a new CTA policy with the source tenant defined as the attacker-controlled external tenant.
[]()
* Configure the new CTA policy to enable ‘_Inbound Sync_’.
[]()
* Enable ‘_Automatic User Consent’_ for inbound user sync.
[]()
* Simultaneously, the attacker also configures CTS on its external tenant.
* 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
1. 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.
2. 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. [[2]]()
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.
3. 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.
4. 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 operation’s 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.
[]()
—
Figure 3: Compromised Account deploying Cross Tenant Access Policy in compromised tenant
[]()
—
Figure 4: Compromised account enabling Inbound Sync into the tenant
[]()
—
Figure 5: Compromised account enabling Automatic User Consent Redemption
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.
Want to learn more?
Vectra AI is the leader in AI-driven threat detection and response for hybrid and multi-cloud enterprises. The Vectra AI Platform delivers the integrated signal powering XDR, SIEM, SOAR â whatever your pane of glass. This powerful platform equips SOC teams with hybrid attack surface coverage and real-time Attack Signal Intelligence, along with integrated, automated and co-managed response. Companies can choose the modules they need to achieve full coverage across identity, public cloud, SaaS and data center networks.
[**Contact Vectra AI**]() today.
**References:**
1. https://attack.mitre.org/techniques/T1484/002
2.
3.
4.
Found this article interesting? Follow us on [Twitter _ï_]() and [LinkedIn]() to read more exclusive content we post.Read More