Detecting Entra ID Cross-Tenant Synchronization Abuse

Cross-tenant synchronization (CTS) was introduced in Entra ID to solve a real enterprise problem: organisations with multiple Azure tenants — through M&A, subsidiary structures, or geographic separations — needed a way to synchronise user identities across those tenants without manual provisioning. A user in Tenant A appears as a guest account in Tenant B, and the sync configuration keeps that account updated automatically.

The security implication is straightforward and underappreciated: if an attacker compromises a source tenant’s Global Administrator or an account with sufficient Entra ID permissions, they can configure cross-tenant sync to push accounts into target tenants that have established a trust relationship. The accounts created in the target tenant are controlled by the attacker’s infrastructure, and they persist even after the source tenant is re-secured — because cross-tenant sync continues to push updates until explicitly disabled.

This is a T1136 (Create Account) technique enabled by abusing T1098 (Account Manipulation) at the tenant configuration level. It’s been observed in post-compromise persistence chains following Business Email Compromise and cloud identity platform attacks.

Understanding Cross-Tenant Sync Architecture

Entra CTS operates on two tenant sides:

Source tenant: Holds the users to be synchronised and configures an outbound sync policy. A service principal (the sync application) handles the sync operations.

Target tenant: Must explicitly enable an inbound configuration from the source tenant — this is a trust decision. The inbound configuration specifies which users from the source are allowed to be provisioned as guest or member accounts.

For CTS to function, the target tenant must configure an inbound trust allowing the source tenant’s service principal. The critical security point: once this trust is established and inbound sync is enabled, accounts pushed from the source tenant are automatically provisioned in the target. If an attacker controls the source tenant (or can modify the source tenant’s sync configuration), they control what gets provisioned.

Attackers have exploited this in two patterns:

Pattern A — Source tenant compromise: Attacker compromises a source tenant, creates a user in the source, and that user syncs into all tenants the source has outbound CTS configurations with.

Pattern B — Rogue outbound configuration: Attacker with sufficient permissions in the target tenant adds a new inbound trust pointing to an attacker-controlled tenant, then provisions accounts from the malicious tenant into the victim tenant.

High-Value Detection Opportunities

1. New Cross-Tenant Sync Configuration Created

Any new inbound or outbound CTS configuration is a high-fidelity signal in environments where CTS configurations don’t change frequently. This appears in the Entra ID Audit Log under the category CrossTenantIdentitySyncPolicyTenant.

KQL (Microsoft Sentinel / Defender XDR):

AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName in (
    "Add a partner to cross tenant access policy",
    "Create inbound cross-tenant sync configuration",
    "Update inbound cross-tenant sync configuration",
    "Add cross-tenant access policy"
)
| extend InitiatedByUser = tostring(InitiatedBy.user.userPrincipalName)
| extend InitiatedByApp = tostring(InitiatedBy.app.displayName)
| extend TargetTenantId = tostring(TargetResources[0].id)
| project TimeGenerated, OperationName, InitiatedByUser, InitiatedByApp, TargetTenantId, Result, AdditionalDetails
| where Result == "success"

Sigma rule (Entra ID Audit Log):

title: Entra ID Cross-Tenant Sync Configuration Created or Modified
id: a7f2c3d4-8e91-4b02-a1c3-d4e5f6789012
status: experimental
description: Detects creation or modification of Entra ID cross-tenant synchronization configurations, which can be abused for persistent access across Azure tenants.
references:
  - https://learn.microsoft.com/en-us/entra/identity/multi-tenant-organizations/cross-tenant-synchronization-overview
author: SOC Analyst Hub
date: 2026-07-20
tags:
  - attack.persistence
  - attack.t1136.003
  - attack.t1098
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    OperationName|contains:
      - "cross tenant access policy"
      - "cross-tenant sync"
      - "inbound cross-tenant"
      - "partner to cross tenant"
  filter_known_admin:
    InitiatedBy.user.userPrincipalName|endswith:
      - "@yourdomain.com"  # adjust to known admin UPNs
  condition: selection and not filter_known_admin
falsepositives:
  - Legitimate CTS configuration by authorised IT administrators during approved change windows
level: high

2. User Provisioned via Cross-Tenant Sync

When CTS provisions a new account in your tenant, the audit log records the account creation with a specific provisioning source. These accounts should be reviewed — particularly if the source tenant ID is unexpected.

KQL:

AuditLogs
| where TimeGenerated > ago(24h)
| where OperationName == "Synchronize a user"
| where Category == "UserManagement"
| extend SyncSource = tostring(AdditionalDetails[0].value)
| extend NewUPN = tostring(TargetResources[0].userPrincipalName)
| extend SourceTenantId = tostring(AdditionalDetails[1].value)
| project TimeGenerated, OperationName, NewUPN, SourceTenantId, SyncSource, Result
// Alert on sync from unexpected source tenants
| where SourceTenantId !in ("known-tenant-id-1", "known-tenant-id-2")

The SourceTenantId field is the key discriminator. Maintain a list of expected source tenant IDs (from your IT asset inventory or Azure AD cross-tenant configuration records) and alert on any provisioning from unlisted tenants.

3. Entra ID Service Principal Created for Sync

CTS requires a service principal in the source tenant to perform outbound sync. The creation of a new service principal with names matching known sync applications (or newly created enterprise applications with sync-related scopes) warrants investigation.

KQL:

AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName in ("Add service principal", "Add application")
| extend AppDisplayName = tostring(TargetResources[0].displayName)
| extend InitiatedByUser = tostring(InitiatedBy.user.userPrincipalName)
| where AppDisplayName contains "Sync" or AppDisplayName contains "Provisioning" or AppDisplayName contains "CrossTenant"
| project TimeGenerated, AppDisplayName, InitiatedByUser, Result, AdditionalDetails

4. Global Administrator Performing Unusual Configuration Changes

Because CTS configuration requires high-privilege access, monitoring for Global Admin or Privileged Role Admin accounts performing identity infrastructure changes outside of change windows is valuable for the broader attack chain.

KQL:

AuditLogs
| where TimeGenerated > ago(24h)
| where OperationName in (
    "Add a partner to cross tenant access policy",
    "Update cross tenant access policy settings",
    "Add cross-tenant access policy",
    "Set company information"
)
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(24h)
    | where UserType == "Member"
    | extend IsNewLocation = (LocationDetails.countryOrRegion !in ("United Kingdom", "United States"))  // adjust
    | where IsNewLocation
    | project UserPrincipalName, IPAddress, Location, IsNewLocation
) on $left.InitiatedBy == $right.UserPrincipalName
| project TimeGenerated, OperationName, UserPrincipalName, IPAddress, Location

Hunting: Baseline Your CTS Configuration

The most reliable defence against CTS abuse is knowing what your legitimate configuration looks like and detecting any deviation. Run this KQL to enumerate all current CTS configurations in your tenant:

// Run against Microsoft Entra data in Defender XDR
AuditLogs
| where OperationName contains "cross tenant"
| summarize LastModified=max(TimeGenerated), ConfigCount=count() by OperationName
| order by LastModified desc

For a point-in-time inventory, use the Microsoft Graph API or PowerShell:

# List all cross-tenant access policies (requires GlobalReader or Security Reader)
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgPolicyCrossTenantAccessPolicy | ConvertTo-Json -Depth 5

# List inbound sync configurations
Get-MgPolicyCrossTenantAccessPolicyPartner | Select-Object TenantId, InboundTrust, B2BCollaborationInbound, SyncSettings

Export this output and store it as a baseline in your CMDB. Any additions or modifications to the partner list should trigger a review.

Attack Simulation for Detection Validation

Before declaring your detections effective, validate them. The following PowerShell simulates the configuration changes that would trigger alerts (in a non-production test tenant):

# Requires Global Administrator in test tenant
Connect-MgGraph -Scopes "Policy.ReadWrite.CrossTenantAccess"

# Simulate adding a new cross-tenant access policy partner
$params = @{
    tenantId = "attacker-controlled-tenant-id"
    inboundTrust = @{
        isMfaAccepted = $true
        isCompliantDeviceAccepted = $false
    }
}
New-MgPolicyCrossTenantAccessPolicyPartner -BodyParameter $params

Run this in a test tenant, confirm your KQL and Sigma rules fire, then remove the test configuration.

Response Playbook

When CTS alerts fire:

1. Immediately enumerate all CTS-provisioned accounts in your tenant — check both existing accounts (via UserType == "Member" and CreationType == "Invitation" patterns in Entra) and audit logs for recent sync events.

2. Identify the source tenant — contact the source tenant’s administrators to verify whether the configuration is legitimate. If the source tenant is compromised or unknown, treat all synced accounts as malicious.

3. Disable inbound sync from the suspicious source tenant — in Entra ID → External Identities → Cross-tenant access settings, disable inbound sync for that tenant.

4. Revoke sessions and credentials for all affected accounts — including revoking refresh tokens and invalidating any API keys or secrets those accounts may have generated.

5. Review access granted to synced accounts — synced accounts may have been added to security groups, assigned roles, or given app consents. Audit these assignments.

6. Preserve audit logs — export Entra ID audit logs for the relevant period before they rotate (default retention is 30 days for Entra ID Audit Logs without a Log Analytics workspace configured).

Detection Coverage Summary

Cross-tenant synchronization abuse is a relatively low-volume, high-impact technique. The detection surface is well-defined, the log sources are available to any organisation using Microsoft Sentinel or Defender XDR, and false positive rates are manageable in most environments. Add these rules to your identity detection layer now.