Modern enterprises run on trust. Azure Active Directory (now Microsoft Entra ID) operationalizes that trust through B2B collaboration, cross-tenant synchronization, and federated identity. These features are powerful, productive, and deeply misunderstood from a security standpoint. Attackers have noticed. Cross-tenant abuse has quietly become one of the most underrated pivot techniques in cloud intrusions, and most organizations have no idea it is happening to them.
This post breaks down exactly how these attacks work, what commands adversaries run, and what defenders need to watch. If you want to know whether your Azure environment is actually hardened against these vectors, the penetration testing team at Redfox Cybersecurity can find out before an attacker does.
Azure B2B collaboration allows organizations to invite external users, guest accounts typically ending in #EXT#, into their tenant. Cross-tenant access policies (XTAP) control inbound and outbound trust between tenants. Cross-tenant synchronization pushes identities across organizational boundaries automatically.
This architecture was built for productivity. A supplier, contractor, or partner can be granted access to SharePoint, Teams channels, or Azure resources without needing a separate managed account. The problem is that every trust relationship is a potential lateral movement path. When a guest account is overprivileged, when outbound trust policies are misconfigured, or when a compromised partner tenant has access to yours, the blast radius of a single breach expands dramatically.
From a red team perspective, these paths are gold. From a blue team perspective, they are nearly invisible in default logging configurations.
Before exploiting anything, an attacker who has gained an initial foothold, even with a low-privileged account, will enumerate what tenants are connected to the environment. The Microsoft Graph API and Azure CLI make this trivial.
Enumerating cross-tenant access policies:
# Using Azure CLI to list cross-tenant access policy partners
az rest --method GET \
--url "https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners"
[cta]
This returns a JSON object listing every partner tenant ID that has been explicitly configured, including inbound and outbound trust settings. Even a read-only user can run this query.
Enumerating guest users in the tenant:
# Get all guest users using Microsoft Graph
Connect-MgGraph -Scopes "User.Read.All"
Get-MgUser -Filter "userType eq 'Guest'" -All | Select-Object DisplayName, Mail, UserPrincipalName, CreatedDateTime
[cta]
A large number of guest accounts with old creation dates and no sign-in activity is a significant misconfiguration. These are dormant but valid identities that can be targeted.
Finding guest accounts with elevated permissions:
# Check role assignments for guest users
Get-MgRoleManagementDirectoryRoleAssignment -All | Where-Object {
(Get-MgUser -UserId $_.PrincipalId -ErrorAction SilentlyContinue).UserType -eq "Guest"
} | Select-Object PrincipalId, RoleDefinitionId
[cta]
If this returns results, there are guest accounts with directory roles. This is almost always unintentional and represents a direct privilege escalation path for an attacker who compromises that guest identity in their home tenant.
This is where cross-tenant abuse becomes genuinely dangerous. The attack chain looks like this:
The key insight is that authentication happens from Tenant A's identity provider. If Tenant B has configured inbound trust to honor multi-factor authentication (MFA) claims from Tenant A, and Tenant A's MFA posture is weaker, the attacker can satisfy Tenant B's MFA requirements by completing a weaker challenge in Tenant A.
Simulating cross-tenant authentication to enumerate access:
# Using az cli with a guest account to check accessible resources in target tenant
az login --tenant <TARGET_TENANT_ID> --allow-no-subscriptions
# List subscriptions visible to the guest identity
az account list --output table
# List resource groups accessible
az group list --output table
[cta]
If the guest account has Contributor or Reader on any subscription, the attacker now has cloud resource visibility into a tenant they do not formally belong to.
If your environment has never been tested for this type of lateral movement, the expert pentesters at Redfox Cybersecurity specialize in exactly this class of attack scenario.
Cross-tenant synchronization (CTS) is a newer feature that automatically pushes user objects from a source tenant into a target tenant. It is used heavily in post-merger integrations and large enterprise structures. It is also deeply abusable.
The attack scenario: If an attacker gains write access to the source tenant's synchronization configuration or the service principal used for synchronization, they can inject or modify user objects that propagate into the target tenant. Depending on the attribute mappings configured, they may be able to set group memberships, job titles, or extension attributes that trigger downstream access decisions.
Enumerating CTS configurations:
# List cross-tenant synchronization policies (requires Global Reader or higher)
Invoke-MgGraphRequest -Method GET `
-Uri "https://graph.microsoft.com/v1.0/servicePrincipals?`$filter=tags/any(t:t eq 'WindowsAzureActiveDirectoryIntegratedApp')&`$select=displayName,id,appId" `
| Select-Object -ExpandProperty value `
| Where-Object { $_.displayName -like "*sync*" }
[cta]
Checking synchronization service principal permissions:
# Find the app role assignments of the sync service principal
$spId = "<SERVICE_PRINCIPAL_ID>"
Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $spId
[cta]
If the sync service principal holds Directory.ReadWrite.All or User.ReadWrite.All, an attacker with control over that service principal can manipulate the target tenant's directory objects at scale.
Access tokens in Azure are tenant-scoped, but refresh tokens can sometimes be exchanged across tenants when the application is registered as a multi-tenant app. This opens the door to token replay attacks.
Extracting cached tokens from a compromised endpoint:
# Dump tokens from MSAL cache on a compromised Windows host
$tokenCache = [System.IO.Path]::Combine($env:LOCALAPPDATA, "Microsoft", "TokenCache")
Get-ChildItem -Path $tokenCache -Recurse -Filter "*.bin" | ForEach-Object {
Write-Output "Found token cache: $($_.FullName)"
}
[cta]
Using ROADtools to extract and analyze Azure token caches:
# Install roadtools
pip install roadtools
# Authenticate and dump token info
roadrecon auth -t <TENANT_ID> --as-app
# Run full tenant recon
roadrecon gather
roadrecon gui
[cta]
ROADtools is widely used by red teams to map out the full Azure AD object graph, including B2B relationships, app registrations, service principals, and conditional access gaps.
Conditional Access Policies (CAP) are the primary enforcement mechanism for Zero Trust in Azure. When cross-tenant trust is misconfigured, CAP can be effectively bypassed.
A common misconfiguration is setting "Trust MFA from Microsoft Entra tenants" in the inbound trust settings. This means if a guest user from a partner tenant claims they completed MFA, your tenant accepts that claim without re-challenging. If the partner tenant does not enforce phishing-resistant MFA, an adversary-in-the-middle attack against the partner can yield a token that satisfies your tenant's MFA requirement.
Checking inbound trust settings via Graph:
# Inspect inbound trust configuration for a specific partner tenant
$partnerTenantId = "<PARTNER_TENANT_ID>"
Invoke-MgGraphRequest -Method GET `
-Uri "https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners/$partnerTenantId" `
| ConvertTo-Json -Depth 10
[cta]
Look for "isCompliantDeviceAccepted": true or "isMfaAccepted": true in the inboundTrust object. Each of these represents a trust decision your tenant is outsourcing to an external organization whose security posture you may not control.
Getting an independent review of your Conditional Access configuration is one of the highest-value investments a security team can make. Redfox Cybersecurity's cloud penetration testing service includes a full Conditional Access policy audit as part of every Azure engagement.
Once an attacker establishes a presence in a target tenant via a compromised guest identity, the post-exploitation phase mirrors traditional internal network compromise but in the cloud plane.
Enumerating Azure resources the guest can access:
# List all resources visible to the current authenticated identity
az resource list --output table
# List Key Vaults (high-value targets for secrets)
az keyvault list --output table
# Attempt to list secrets in accessible Key Vaults
az keyvault secret list --vault-name <VAULT_NAME> --output table
[cta]
Enumerating Storage Accounts:
# List storage accounts accessible to the current identity
az storage account list --output table
# List containers in a storage account
az storage container list --account-name <STORAGE_ACCOUNT_NAME> --auth-mode login
[cta]
Enumerating App Registrations and Service Principal Secrets:
# Find app registrations with expiring or long-lived credentials
Get-MgApplication -All | Select-Object DisplayName, AppId, @{
Name="PasswordCredentials"; Expression={$_.PasswordCredentials | Select-Object DisplayName, EndDateTime}
} | Where-Object { $_.PasswordCredentials }
[cta]
Long-lived application secrets are a persistent backdoor. An attacker who identifies one can maintain access to the tenant indefinitely, even after the initial compromised account is remediated.
Defending against cross-tenant abuse requires knowing what to log and where to look. Most organizations have Microsoft Entra audit logs enabled but are not ingesting the specific event categories that reveal cross-tenant activity.
Key log sources to enable and monitor:
In Microsoft Entra Diagnostic Settings, ensure you are streaming the following to your SIEM:
crossTenantAccessType is not none)crossTenantAccessPolicy and servicePrincipals)KQL query for detecting cross-tenant sign-ins to your tenant:
SignInLogs
| where TimeGenerated > ago(7d)
| where CrossTenantAccessType == "b2bCollaboration" or CrossTenantAccessType == "b2bDirectConnect"
| where ResultType == 0
| summarize SignInCount = count(), UniqueResources = dcount(ResourceDisplayName) by UserPrincipalName, HomeTenantId, bin(TimeGenerated, 1h)
| where SignInCount > 50 or UniqueResources > 10
| order by SignInCount desc
[cta]
This surfaces guest accounts or cross-tenant identities with anomalously high activity, a strong indicator of automated enumeration or active exploitation.
Remediation is straightforward once you know where to look. The following controls address the majority of cross-tenant attack surface:
Review and restrict cross-tenant access policies. Navigate to Entra ID > External Identities > Cross-tenant access settings. For each partner tenant, disable automatic inbound MFA and device compliance trust unless explicitly required and verified.
Audit guest account permissions quarterly. No guest user should hold any Entra directory role. No guest user should be a member of privileged groups. Run the enumeration commands above and remediate findings immediately.
Restrict guest user default permissions. In Entra ID > External Identities > External collaboration settings, set "Guest user access" to the most restrictive option available. Guests should not be able to enumerate your directory.
Enforce Conditional Access on all B2B sign-ins. Create a dedicated Conditional Access policy targeting guest and external users. Require phishing-resistant MFA, compliant devices, and restrict access to only approved applications.
Rotate service principal credentials regularly. Any service principal used for cross-tenant synchronization should have short-lived credentials and its permissions should follow the principle of least privilege.
If you want to validate whether these controls are actually working in your environment, that is precisely what Redfox Cybersecurity's penetration testing engagements are designed to answer.
Cross-tenant attacks represent a fundamental shift in how cloud environments are compromised. Perimeter defenses, endpoint controls, and even strong identity hygiene within your own tenant can all be rendered insufficient when a trusted partner's environment is the entry point.
The attack paths detailed here, from guest enumeration to CTS abuse to Conditional Access bypass, are not theoretical. They appear in real-world red team engagements with regularity. The organizations that discover them through a controlled pentest are far better positioned than those that discover them through an incident.
If you are managing an Azure environment with B2B collaboration enabled, the questions you should be asking are not hypothetical. They are operational: Who has guest access to your tenant right now? What can they reach? What trust decisions have you outsourced to organizations whose security posture you have never assessed?
Redfox Cybersecurity's cloud security team provides adversary-focused assessments built around exactly these questions. Whether you need a targeted Azure B2B attack simulation, a full cloud penetration test, or a red team engagement spanning cloud and on-premises infrastructure, the team is equipped to deliver findings that drive real security improvement.
Get in touch with Redfox Cybersecurity to scope your next cloud penetration test.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
