How Misconfigured Multi-Tenant Apps Lead to Full Account Takeover

TLDR: Researchers discovered that many Azure Active Directory applications are misconfigured to allow any user from any tenant to authenticate, leading to potential account takeovers. By manipulating the tenant ID in OAuth requests, an attacker can bypass authorization checks and gain access to sensitive internal services. This research highlights the critical need for developers to implement robust, application-level authorization logic rather than relying solely on platform-provided authentication.

Authentication is the bedrock of cloud security, but it is also where developers make the most dangerous assumptions. We often treat the identity provider as the final arbiter of access, assuming that if a user has a valid token, they are authorized to be there. This assumption is exactly what allows attackers to pivot from a simple login to full account takeover. The recent research presented at Black Hat 2023 on Azure Active Directory misconfigurations proves that even the most sophisticated infrastructure can be compromised by a single, overlooked checkbox.

The Mechanics of the Multi-Tenant Flaw

When developers register an application in the Azure portal, they are presented with a choice regarding supported account types. Selecting the option for a multi-tenant application allows users from any Azure AD tenant to sign in. While this is necessary for SaaS products, it is frequently enabled by mistake for internal tools that should only be accessible to a specific organization.

The vulnerability arises because many developers assume that Azure will handle the authorization logic for them. They believe that if a user successfully authenticates, they must belong to the correct organization. However, Azure only validates that the user is a valid identity within the global Azure ecosystem. It does not automatically restrict access to users from a specific tenant unless the developer explicitly writes code to verify the tid (tenant ID) claim within the JSON Web Token.

If an application lacks this check, an attacker can perform a simple OAuth flow manipulation. By intercepting the authentication request and swapping their own tenant ID for the target organization's tenant ID, the attacker can often bypass the intended access controls.

Exploiting the Trust Gap

The research demonstrated a practical attack flow against internal Microsoft applications. By identifying applications that were incorrectly configured as multi-tenant, the researchers could authenticate using their own credentials. Because the application failed to validate the tenant ID, it treated the attacker as a legitimate user of the target organization.

Consider this simplified OAuth request structure:

POST /<MY_TENANT_ID>/oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

scope=<APP_ID>/.default&client_id=<CLIENT_ID>
&client_secret=<CLIENT_SECRET>&grant_type=client_credentials

An attacker who identifies a vulnerable application can modify the <MY_TENANT_ID> parameter. If the application does not verify that the incoming token belongs to the expected tenant, it will grant the attacker access to the application's resources. In the case of the Bing trivia portal shown in the demo, this access included the ability to modify live search results and, more critically, the ability to generate an Office 365 access token.

Once the attacker has a valid access token for the target's Office 365 environment, they can interact with the Microsoft Graph API to exfiltrate emails, calendar entries, and SharePoint documents. This is not a theoretical exploit; it is a direct consequence of trusting the identity provider to perform authorization tasks it was never designed to handle.

Real-World Impact for Pentesters

During a penetration test, your first step should be to identify the authentication mechanism of the target application. If you see an OAuth flow, check if the application is configured for multi-tenant access. You can often determine this by attempting to log in with an account from a different tenant. If the login succeeds, you have confirmed that the application is multi-tenant.

From there, the goal is to determine if the application performs any server-side validation of the user's tenant. If you can successfully authenticate and access features intended for the target organization's employees, you have a high-impact finding. This is a classic example of Broken Access Control, where the application fails to enforce the principle of least privilege.

Defensive Strategies

The fix is straightforward but requires discipline. Developers must never rely on the identity provider to enforce authorization. Every application must explicitly validate the tid claim in the token to ensure the user belongs to the authorized tenant. Furthermore, developers should use the WEBSITE_AUTH_AAD_ALLOWED_TENANTS configuration option to restrict access to a specific list of allowed tenant IDs.

For blue teams, the priority is visibility. You need to audit your Azure AD application registrations to ensure that multi-tenant settings are only enabled when absolutely necessary. Use tools like Azure AD PowerShell to list all applications and their supported account types. If you find an internal tool configured as multi-tenant, change it to single-tenant immediately.

Security is not about finding the perfect tool; it is about understanding the limitations of the tools you use. When you integrate with a platform like Azure, you are entering into a shared responsibility model. The platform secures the identity, but you are responsible for securing the access. If you forget that, you are just waiting for someone to find your "checkbox of doom."