Entra cross tenant access change
A cross-tenant access or synchronization relationship with another Entra tenant was created or modified.
What it detects
A cross-tenant access or synchronization relationship with another Entra tenant was created or modified.
Cross-tenant sync exists so a group of companies can replicate users between tenants. Pointed at a tenant an attacker controls, it becomes persistence that survives everything done inside yours: accounts can be provisioned in from outside, and an external identity is trusted as though it were internal. Password resets, session revocation and MFA re-registration do not touch it, because the trust is a tenant-level configuration rather than anything about a user.
Partner relationships are established once, by agreement, and rarely edited. A change nobody can name is a serious finding.
MITRE ATT&CK mapping
False positives and triage
A merger, an acquisition or a genuine multi-tenant group makes these changes legitimately, and there is usually a project behind them that is easy to confirm. The question to answer is which tenant is on the other end: check the partner tenant id in the record against the organisations the business actually works with, and whether inbound USER SYNC was enabled rather than only access. Inbound sync from an unrecognised tenant should be treated as active persistence and removed, not merely reviewed.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 70%. Source: rules/cloud/entra_cross_tenant_access_change.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_cross_tenant_access_change
version: 1.1.0
status: stable
severity: critical
confidence: 0.7
platforms: [application]
mitre_techniques: [T1199, T1098.003]
description: |
A cross-tenant access or synchronization relationship with another Entra tenant
was created or modified.
Cross-tenant sync exists so a group of companies can replicate users between
tenants. Pointed at a tenant an attacker controls, it becomes persistence that
survives everything done inside yours: accounts can be provisioned in from
outside, and an external identity is trusted as though it were internal. Password
resets, session revocation and MFA re-registration do not touch it, because the
trust is a tenant-level configuration rather than anything about a user.
Partner relationships are established once, by agreement, and rarely edited. A
change nobody can name is a serious finding.
match:
event_action_any:
- "Add a partner to cross-tenant access setting"
- "Update a partner cross-tenant access setting"
- "Add cross-tenant identity sync policy"
- "Update cross-tenant identity sync policy"
- "Add partner to cross-tenant access setting."
# The Exchange-side spelling of the same trust. B2B "shared business" links
# establish the identical replication path under a different cmdlet, and
# listing only the directory spellings left that route unmatched.
- "New-InboundSharedBusinessTogetherRelationship"
- "New-OutboundSharedBusinessTogetherRelationship"
correlation_keys: [user_name]
false_positive_guidance: |
A merger, an acquisition or a genuine multi-tenant group makes these changes
legitimately, and there is usually a project behind them that is easy to confirm.
The question to answer is which tenant is on the other end: check the partner
tenant id in the record against the organisations the business actually works
with, and whether inbound USER SYNC was enabled rather than only access. Inbound
sync from an unrecognised tenant should be treated as active persistence and
removed, not merely reviewed.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.