Abusing Entra OAuth for Fun and Access to Internal Microsoft Applications

Consent and Compromise: Abusing Entra OAuth for Fun and Access to Internal Microsoft Applications

Speaker: Wouter Bernard — Chief Hacker & Co-Founder, AiSecurity

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=sWV_3k-_S7Y

Reading time: ~7 minutes

Type: Briefing

TL;DR

Wouter Bernard discovered a widespread misconfiguration in Microsoft Entra ID where applications are unintentionally registered as multi-tenant, allowing any external Microsoft account holder to authenticate and — by exploiting missing issuer validation — gain full access to internal Microsoft systems. By working through the vulnerability chain, Bernard accessed 22 sensitive internal Microsoft applications, including an emergency broadcast console, a Fortune 500 customer support portal, Microsoft's internal risk register, a responsible AI operations platform, and a Windows build system whose logs contained an ESD private key.

Introduction

The discovery began not with a methodical reconnaissance but with a moment of distraction. Wouter Bernard, chief hacker at Dutch security firm AiSecurity, was writing documentation when his eye caught an aka.ms link. Curiosity about eng.ms, a Microsoft subdomain, led him to a login screen — and to a consent prompt that should not have appeared for an external user.

"I did not get a message that my account did not exist in the Microsoft tenant. I got a consent prompt," Bernard told the Black Hat audience. That unexpected consent request was the tell. Understanding why it appeared required a tour through Entra ID's multi-tenancy model — and ultimately led to one of the broader Microsoft internal security exposure findings presented at Black Hat in recent years.

How Entra ID Multi-Tenancy Works

In Entra ID (formerly Azure AD), applications are registered as app registrations — templates describing permissions and roles. The live instantiation of that registration in a specific tenant is called an enterprise application or service principal. Applications can be registered as single-tenant (accessible only within the owning tenant) or multi-tenant (accessible from any Entra-connected tenant).

▶ Watch: Entra OAuth Fundamentals (04:00)

When a user authenticates via the standard authorization-code flow, they are directed to an Entra identity endpoint. Four endpoints exist: common, organizations, consumers, and the tenant-specific endpoint. A multi-tenant application should use the common endpoint; a single-tenant application should use the tenant endpoint. In practice, the two are often conflated by developers.

The critical security property: after authenticating, an application must validate that the iss (issuer) and tid (tenant ID) claims in the returned access token match the expected Microsoft tenant. If it does not, a user who authenticated against their own tenant — obtaining a token issued by their tenant — can present that token to an application expecting a Microsoft-tenant token.

This was precisely the flaw at rescue.eng.ms: the Microsoft Engineering Hub, an internal portal, accepted Bernard's access token even though it was issued by his own personal Entra tenant. No one at Microsoft had validated the issuer.

The Vulnerability: Unintentional Multi-Tenancy + Missing Issuer Validation

Bernard's methodology was straightforward: enumerate Microsoft's .ms and .microsoft.com subdomain space, identify applications using Entra ID for auth, and check whether the app registration was configured as multi-tenant.

▶ Watch: Scale of the Attack Surface (14:00)

From his enumeration of internal Microsoft subdomains:

• Over 70,000 resolved to an IP address
• Over 40,000 responded to HTTPS
• Over 1,400 used Entra ID for authorization
• 400 redirected to the common endpoint (indicating potential multi-tenant apps)
• 172 were confirmed multi-tenant via the Azure AD Graph API check

Critically, of those 172, most were using the tenant endpoint rather than the common endpoint in their redirect URLs, suggesting the developers were not aware the apps had been registered as multi-tenant. An attacker could still work around this by using a proxy to replace the Microsoft tenant ID in the URL with common, directing authentication to the common endpoint and receiving a token from their own tenant — which the application would then accept.

Bypassing User Assignments and Other Controls

Several defensive layers nominally block unauthorized access. Bernard bypassed each:

User assignment required: Normally, an enterprise application can enforce that only assigned users may log in. But with a multi-tenant app, user assignment is enforced in the tenant performing authentication — which is the attacker's own tenant. Bernard simply browsed to the enterprise application object in his own tenant, clicked Users, and assigned himself the Administrator role. That role claim then appeared in the access token used against Microsoft's application.

▶ Watch: Bypassing Controls (16:01)

Missing service principal: When an application declares dependencies on other app registrations, the consent flow breaks if those registrations are single-tenant or unavailable. Bernard bypassed this by directly creating service principals via PowerShell (New-AzureADServicePrincipal or New-MgServicePrincipal) — a mechanism that creates a service principal without triggering consent checks.

Conditional access policies: Like user assignments, these are evaluated against the authenticating tenant — the attacker's own. They provide no protection against this class of misconfiguration.

What Was Inside

Twenty-two of the identified multi-tenant applications — 12.5% of those confirmed vulnerable — exposed internal data after Bernard authenticated. A selection:

• Emergency Broadcast System: A console capable of broadcasting a message to every Microsoft 365 admin center in the world.
• ACE Command Center: The support portal for Microsoft's top-tier (Fortune 500) customers. Bernard could view, close, and edit every open support ticket.
• Responsible AI Operations Platform: A dashboard for administering large language models, including "probably the parents of Copilot."
• Microsoft's Internal Risk Register: A list of organizational risks Microsoft faced at the time of access. Redacted from the presentation at Microsoft's request.
• Security Intelligence Platform ("Sipi"): Contained all datasets from the entire Microsoft organization — VPN logs, AD users, device history. Featured an embedded AI agent that, when asked for the admin portal URL to approve access requests, provided it. Also exposed an inadvertent 40 MB Burp log containing authorization codes (single-use, so not redeemable).
• Windows Build System: Log files from Windows edition client builds. Those logs contained an ESD (Electronic Software Distribution) private key — effectively the volume license key infrastructure for Windows. Bernard also had the ability to upload new tools to the build system, which "would probably have given me RCE."
• Microsoft Rewards Center: Bernard assigned himself the Administrator role and found a rebate interface where he could enter any amount, any currency, a PayPal identifier, and click "Skip risk" → "Payout." The audience laughter was audible.

▶ Watch: Application Access Examples (18:01)

Disclosure and Fix

Bernard submitted four cases to Microsoft's Security Response Center (MSRC) in November 2024, then — "briefly distracted" — submitted eighteen more in January 2025. Microsoft scaled up a project team; Bernard reports he was first on 17 of the 18 January cases. Microsoft has remediated the vulnerable applications and implemented monitoring; Bernard confirmed that when he attempted to reproduce findings while preparing slides, he received an immediate email from Microsoft.

The specific methods demonstrated are no longer effective against the reviewed applications. Bernard published a detection script and blog post at consentandcompromise.com alongside this talk.

Notable Quotes

"I did not get a message that my account did not exist in the Microsoft tenant. I got a consent prompt, and it requested my permission to sign in."

— Wouter Bernard ▶ 02:00

"User assignments now also happen in my own tenant, so I could simply browse to the enterprise application object, click on Users, assign my user a role — for example, administrator."

— Wouter Bernard ▶ 16:01

"Hacking Microsoft was supposed to be an infinite money glitch, right? Well, I'm not done yet."

— Wouter Bernard ▶ 26:04

"I've seen things you people wouldn't believe."

— Wouter Bernard, on the Windows source lookup interface ▶ 22:01

Key Takeaways

• Unintentional multi-tenancy is common: Of ~1,400 Microsoft internal apps using Entra auth, 172 were multi-tenant — most apparently by accident. Check your own environment with the PowerShell one-liner at consentandcompromise.com.
• Issuer validation is mandatory for multi-tenant apps: If your application uses the common endpoint or is registered as multi-tenant, explicitly validate the iss and tid claims in the received access token. Absence of this check nullifies all other authorization controls.
• User assignments and conditional access don't help: Both are evaluated in the authenticating tenant, not the resource tenant. Against this attack, they are irrelevant.
• The misconfiguration is still common in enterprise environments: Bernard notes it is "quite common still" outside Microsoft. Pen testers and bug bounty hunters should routinely check for unintentional multi-tenancy in engagements.
• Detection script available: A PowerShell one-liner at consentandcompromise.com identifies multi-tenant applications with defined redirect URIs in your Entra environment.

Slides PDF not available for this talk.