Written by Hai Vaknin

1. Introduction
2. The Discovery
3. Microsoft’s Stance
4. Why It Matters: The Integrity of Logs
5. Proof of Concept
6. Test Results & Telemetry
7. Conclusion

Introduction

During recent Entra ID research, we encountered an interesting issue within the ROPC (Resource Owner Password Credentials) flow. We discovered a method where an attacker with valid credentials for a victim user can authenticate against a completely unrelated tenant to evade the victim tenant’s Conditional Access Policies (CAP).

Specifically, if an attacker authenticates to a target “Tenant B” (where the user does not exist) using credentials from “Tenant A” (victim tenant), the authentication succeeds, a token is issued, and no Conditional Access Policies are applied by the home tenant.

This post serves as a research note on this behavior, detailing the flow, Microsoft’s response, and the implications for Blue Teams relying on CAPs.

The Discovery

The issue arises when using the ROPC flow to authenticate to a target tenant where the user is not a standard member.

We primarily targeted tenants where the user had absolutely no footprint. We also tested scenarios involving pre-existing Guest accounts, which yielded the same results regarding privileges: successful auth without no resource access (as far as we know).

We did not however explicitly evaluate established B2B relationships or cross-tenant trust configurations, leaving those areas open for other researchers.

The Scenario:

1. Attacker possesses valid credentials (Username & Password) for a user in Tenant A (Victim Tenant).
2. Attacker authenticates to Tenant B (Arbitrary/Attacker Tenant).
3. The user from Tenant A does not exist in Tenant B.

The Result:

• Authentication Succeeds: Microsoft validates the credentials against the home tenant (Tenant A).
• Token Issued: A valid Access Token is returned to the attacker.
• CAP Bypass: The Conditional Access Policies of the Victim Tenant (Tenant A) are NOT applied. Specifically, even if Tenant A explicitly blocks ROPC flows, this restriction is bypassed as long as the Target Tenant (Tenant B) does not enforce a similar block.
• Logging: A “Sign-in: Success” event is generated in the Victim Tenant’s logs.

While the issued token cannot be used to access resources in Tenant B (as the user has no permissions there), the attacker has successfully validated credentials and generated a success event while bypassing the victim organization’s CAP (such as MFA enforcement or location restrictions).

Microsoft’s Stance

We followed responsible disclosure protocols and reported this behavior to Microsoft. Microsoft acknowledged that this behavior exists today.

It was classified as low impact because, while the authentication succeeds and CAPs are bypassed, the resulting token does not grant access to resources in the target tenant, nor does it grant access to the home tenant’s resources.

Why It Matters: The Integrity of Logs

Even without direct resource access, this behavior is significant for two reasons:

1. Conditional Access Evasion: Defenders rely on CAPs to block logins based on risk, location, or device compliance. This technique allows an attacker to bypass those checks during the authentication phase.
2. Operational Confusion: The sign-in log appears in the Victim Tenant with a status of “Success.” An analyst seeing this might assume the user successfully passed all security controls (MFA, Device Trust), when in reality, those controls were never evaluated.

Proof of Concept

The following PowerShell snippet demonstrates the flow. Note that the username belongs to the victim tenant, but the request is sent to an unrelated tenant_id.

# Tenant ID of an unrelated tenant (Tenant B)
# NOTE: The victim user does NOT have a member account in this tenant
$target_tenant_id = "00000000-0000-0000-0000-000000000000"
# Azure CLI public client ID (well-known Microsoft first-party app)
$client_id = "1950a258-227b-4e31-a9cf-717495945fc2"
# Request Microsoft Graph permissions
$scope = "https://graph.microsoft.com/.default"
# User credentials (belong to the VICTIM tenant)
$username = "victim@company.com"
$password = "CompromisedPassword123!"
# OAuth2 ROPC request body
$body = @{
    client_id  = $client_id
    grant_type = "password"
    username   = $username
    password   = $password
    scope      = $scope
}
# Token request sent to the UNRELATED Tenant B
$tokenUrl = "https://login.microsoftonline.com/$target_tenant_id/oauth2/v2.0/token"
$resp = Invoke-RestMethod `
    -Method POST `
    -Uri $tokenUrl `
    -Body $body `
    -ContentType "application/x-www-form-urlencoded"
# Result: A valid Access Token is issued
$resp

Test Results & Telemetry

After executing the Proof of Concept, we verified the behavior by inspecting the Victim Tenant’s Sign-in logs.

Log Details in Victim Tenant:

This confirms the anomaly: The attacker successfully authed using the victim’s identity, and the victim tenant recorded the event, but the security policies that should have protected the sign-in were skipped because of the cross-tenant routing.

Conclusion

We are sharing this research note to document a nuanced edge case in the ROPC flow.

For defenders, it is critical to understand that Conditional Access Policies may not always apply if the authentication request is routed through an unrelated tenant where the user is not a standard member. If you observe successful ROPC sign-ins in your logs where the “Resource Tenant” is unfamiliar and no CAPs were applied, you may be witnessing this specific bypass technique.

We hope this aids other researchers and Blue Teams in understanding the edges of Entra ID authentication.