Multi-factor Authentication (MFA) and Conditional Access (CA) policies are powerful tools to protect Azure AD users’ identities. For instance, one may allow access only from compliant devices and require MFA from all users.

However, because of Azure AD authentication platform architecture, users can bypass home tenant MFA and CA policies when logging in directly to resource tenants.

This blog post tries to shed some light on how Azure AD authentication works under-the-hood. We’ll introduce the issue, describe how to exploit it, show how to detect exploitation, and finally, how to prevent the exploitation.

The blog is co-authored with @SravanAkkaram and is based on his findings.

Introduction

This story, like many others, began after a tweet:

I replied to Sravan and asked him to DM me if he’d like me to have a look on his case. Luckily, he did 😉

Azure AD

Azure Active Directory (Azure AD) is Microsoft’s Identity and Access Management (IAM) service used by Microsoft 365 and Azure, but also by thousands of third party service providers. An instance of Azure AD is called tenant.

Home and resource tenants

Users can log in to the tenant using the authentication methods configured by the administrators. Microsoft is calling this to home tenant.

Users are also able to log in to other tenants, if they are invited there as guests. Microsoft calls these tenants resource tenants.

After user accepts the invitation, a corresponding user object is created to the resource tenant. The two objects are linked to each other. The resource tenant user object has an array of alternativeSecurityIds and one of them (of type 5) equals the PUID (aka LiveId) attribute of the home tenant user object.

eSTS

Based on our observations, when logging in to Azure AD tenant, you are actually logging in to eSTS. But what is eSTS? According to Microsoft Azure SOC 3 Report. October 1, 2017 - September 30, 2018:

Evolved Security Token Service (eSTS): eSTS provides a stateless service that accesses multiple principal and key stores. eSTS absorbs the roles of multiple STSs, so that users see one Azure AD STS. eSTS relies on MSODS to hold information required to complete the authentication. eSTS supports a number of protocols including OAuth 2.0, Open ID Connect, WS-Fed, and Security Assertion Markup Language (SAML) protocol.

MSODS: MSODS is Microsoft Online Directory Services, a feature of Azure Active Directory that also includes Azure Active Directory B2B.

Here is an example of a tenant using username and password. User goes to login.microsoftonline.com and provides username and password. eSTS then checks the provided credentials against home tenant Azure AD.

Multi-factor authentication (MFA) and Conditional Access (CA)

MFA can be applied either per user, with Security Defaults, or using Conditional Access (requires Azure AD Premium).

With Conditional Access one can grant or block access to services based on the user, device, application, user’s location, etc.

Both MFA and CA are applied post-authentication, i.e., after logging in to eSTS. Moreover, MFA and CA are configured per tenant.

Here is an example, where user is logging in to home tenant (login.microsoftonline.com):

1. eSTS checks the provided credentials against user’s home tenant.
2. Home tenant MFA is prompted and CA policies evaluated.

Sravan found out that when logging in directly to resource tenant, home tenant MFA and CA are not applied. Here is an example, where user is logging directly to resource tenant (login.microsoftonline.com/<resource tenant domain or id>):

1. eSTS checks the provided credentials against user’s home tenant.
2. Resource tenant MFA is prompted and CA policies evaluated.

Note: If the use tries to access home tenant services after logging in to resource tenant, home tenant MFA and CA policies are applied normally.

This kind of collaboration between two tenants is called B2B collaboration, and requires that the user is first invited to the resource tenant a guest. Depending on the resource tenant configuration, it may or may not have MFA and/or CA policies configured. Using

Sravan noticed that there are some resource tenants which allows users to log in without invitation. These tenants are using Azure AD B2C service:

Azure AD B2C is a separate service from Azure Active Directory (Azure AD). It is built on the same technology as Azure AD but for a different purpose. It allows businesses to build customer facing applications, and then allow anyone to sign up into those applications with no restrictions on user account.

Many well-known consumer brands are using Azure AD B2C. As I didn’t want to list those tenants here, I created one for demonstration purposes: https://portal.azure.com/b2c.aadinternals.com

You are able to log in to the tenant without MFA, regardles of your home tenant settings. You’ll be given the following error:

After clicking I acknowledge, you can pull down the user menu and select Switch directory:

This allows you to view all tenants you are member of and switch to them:

Room for abuse

Bypassing MFA and CA

Let’s see how we can exploit the authentication flow. First, we create a CA rule to block access for Nestor Wilke.

When trying to get an access token using AADInternals, we can see that the sign-in was succesful but due to CA, you don’t have permission to access this resource.

However, if we provide b2c.aadinternals.com as the tenant, home tenant CA is not evaluated!

Note: Resource tenant MFA and CA are still applied (if defined).

The returned access token shows that the issuer (iss) claim and identity provider (idp) claims are different. We can also see that there is no MFA included in authentication methods (amr) claim.

This means that home tenant administrators can’t block access to resource tenants using Conditional Access.

This is not very intuitive, as one would assume blocking access to home tenant would block access to all tenants too.

Exploiting

So, how would threat actors exploit this? To begin with, you’d need to have user’s credentials.

If you have those, you can log in to any resource tenant the user is member of, and do anything the user has permission to do. The most common scenario would be to access Teams.

But what if you don’t know any resource tenants the user is member of? Another Sravan’s finding will help on this. He noticed that B2C tenants allows you to log in, even when you’re not invited as guest:

Now you can use AADInternals to get list of user’s tenants. The last tenant is the one we logged in, and doesn’t have any other information besides the tenant id. The rest of the tenants are the ones the user can access.

Detecting

Log ins to resource tenants are also logged in sign-ins log. Here we can see the events of the examples above:

Details of the first event shows the resource and home tenant ids.

The User type and Crosstenant access type depends on the resource tenant type:

Preventing

Cross-tenant access settings

Cross-tenant access settings is way to control both outbound and inbound collaboration. Outbound settings are configured by home tenant administrators and inbound settings by resource tenants.

Note: Any tenant can be home tenant, resource tenant, or both at the same time.

With outbound settings, home tenant administrators can configure default settings to either block or allow access to all resource tenants:

This works in a similar way than the “Default Deny” and “Default Allow” rules in firewalls.

Home tenant admins can also customise settings for each resource tenant:

This means that home tenant admins can block access but can’t enforce home tenant MFA & CA to allow access to resource tenants.

As much as I like this kind of “default deny” access settings, it can have severe consequences to business-critical applications as Microsoft also warns:

Changing the default inbound or outbound settings to Block access could block existing business-critical access to apps in your organization or partner organizations. Be sure to use the tools described in Cross-tenant access in Azure AD External Identities and consult with your business stakeholders to identify the required access.

Moreover, blocking all external access just to make sure that users (or adversaries) can’t bypass home tenant MFA & CA sounds a bit overkill.

Communication with Microsoft

Correspondence

Date	Case ID	Description
Jul 18th 2021	66317	Original submission “Bypass MFA & Cross-tenant data tampering or access”
Aug 7th 2021	66317	Closed as “by-design”
Aug 27th 2022	67233	Resubmit with POC. “Bypass MFA / Cross-tenant data tampering or access”
Feb 21st 2022	70402	Separated from case 67233: “Azure management API exposes user’s guest and home tenant regardless of home tenatns security policies”
Mar 11th 2022	67233	MFA part closed as “by-design”. Response: “The resource tenant is always responsible for Azure AD Multi-Factor Authentication for users, even if the guest user’s organization has Multi-Factor Authentication capabilities” Documentation updated: Tutorial: Enforce multi-factor authentication for B2B guest users Authentication and Conditional Access for External Identities
Jun 17th 2022	70238	Cross-tenant access (opened internally by MSRC, status unknown). Microsoft implemented a Limited or No Access pop-up when signing in to Azure AD Portal of resource tenants where the guest user has limited or no permissions:
Aug 22nd 2022	70402	Closed as “by-design”.
Oct 27th 2022	*	Final response from MSRC

Final response from Microsoft Security Response Center (MSRC):

As always, your excellent research is always valuable to us for flagging potential concerns. We took the time to carefully review your finding.

In this case, we have made a considered decision to allow end users to see their list of tenants in the tenant switching experience independent of the individual policies of a particular tenant. The applicable tenant list is part of system metadata, and not subject to a specific tenant’s user policies. The current approach is critical for usability for tenant switching, which customers consider a critical feature.

Evaluation of login for authorization of a guest is done at the resource tenant unless customers choose to leverage cross-tenant access settings, which would allow delegation of evaluation to the user’s home tenant, but the resource tenant’s policies are always applied. Furthermore, if an admin would like to control where their users are able to access and be a guest user, they can leverage cross-tenant access settings to block outbound collaboration to limit access to only approved resource tenants.

While the balance of user experience and resource-dominant policy has led us to the current design (which works as intended), we do understand your concerns and will look for opportunities to enhance the model in this area.

Summary

User’s home tenant Conditional Access (CA) policies and MFA are not evaluated when the user is logging in directly to the resource tenant.

As such, home tenant administrators do not have full control of the authentication flow of their users and to protect their tenant membership data.

B2B resource tenant administrators can enforce home tenant MFA & CA with resource tenant CA and cross-tenant settings. This is not possible for B2C resource tenants.

However, home tenant administrators can block access to all or specific resource tenants using cross-tenant access settings.

Summary of the home tenant control options

Recommendations

We recommend administrators to block access to all resource tenants (where plausible) and to allow access to only those resource tenants that enforce home tenant MFA and CA policies.

We have suggested to Microsoft that home tenant MFA & CA policies should always be evaluated.

Credits and references

• Microsoft: How it works: Azure AD Multi-Factor Authentication
• Microsoft: What is Conditional Access?
• Sravan Akkaram: Tweet: Discrepancy in handling the MSRC Case 67233
• Microsoft: What is Azure Active Directory?
• Microsoft: Multi-tenant user management
• Microsoft: Microsoft Corporation - Microsoft Azure (Azure & Azure Government). SOC 3 Report. October 1, 2017 - September 30, 2018
• Microsoft: Enable per-user Azure AD Multi-Factor Authentication to secure sign-in events
• Microsoft: Security defaults in Azure AD
• Microsoft: Tutorial: Secure user sign-in events with Azure AD Multi-Factor Authentication
• Microsoft: Azure Active Directory plans and pricing
• Microsoft: What is Conditional Access?
• Microsoft: Configure cross-tenant access settings for B2B collaboration
• Microsoft: Tutorial: Enforce multi-factor authentication for B2B guest users
• Microsoft: Authentication and Conditional Access for External Identities

About Sravan Akkaram (@SravanAkkaram)

Sravan Akkaram is a tech enthusiast, a security researcher and a Blue Teamer by profession. He works as a Senior Cyber Security Analyst at Accenture. His core skills include Incident Response, Malware Analysis and threat hunting. He is also interested in learning how applications work to find bugs and vulnerabilities.