AI
Stumbling Into Microsoft’s Internal Network
Vaisha Bernard was writing documentation when an aka.ms link caught his eye. He visited domain.ms on a whim, logged in with his personal Microsoft account, and ended up inside the Microsoft Engineering Hub, a portal marked for internal use only. His first move as a red teamer was to search the word “password.” He got 13,252 results. He reported it to MSRC. That accident raised one question: if one internal service had this misconfiguration, how many others did?
How Entra Multi-Tenant Applications Work
In Entra ID, an app registration is the template. The enterprise application (service principal) is the live instance. A single-tenant app can only be consented to inside the tenant where it was registered. A multi-tenant app can be consented to in any tenant, spinning up a service principal there. That service principal in the attacker’s tenant controls user assignment, role definitions, and conditional access independently. Once consent happens in the attacker’s tenant, the resulting access token is technically valid for the target application, because the app was never told to check which tenant issued it.
Why the 2023 Bing Bang Fix Left a Gap
At Black Hat 2023, Wiz showed that swapping the attacker tenant ID for the resource tenant ID during authentication produced a token signed by Microsoft’s own tenant, exposing 25% of tested applications. Microsoft patched that: it stopped issuing tokens when the client was not registered in the resource tenant. Bernard’s finding is different. The application at domain.ms used the common endpoint, so it sent him to his own tenant. His token was issued by his tenant, perfectly valid. The application never checked the issuer claim. Conditional access and user assignment both ran in his tenant and both passed.
The Attack: Six Steps From Stranger to Administrator
Bernard enumerated 102,672 Microsoft subdomains. Over 1,400 used Entra ID for authorization; 172 were registered as multi-tenant applications. For apps that hardcoded the Microsoft tenant endpoint, a single Burp match-and-replace rule swapped that tenant ID for “common,” redirecting the auth flow to his own tenant. He then consented to the app, assigned himself an administrator role in his own service principal, and received an access token with admin claims. When dependency apps blocked consent, he created service principals directly via the Graph API, bypassing the consent check entirely. See the Burp match-and-replace live demo (22:51) for the full flow.
Twenty-Two Vulnerable Microsoft Internal Services
22 of the 172 multi-tenant apps gave full backend access. The emergency broadcast system could message every Microsoft 365 admin center worldwide.
“I did not publish any post.” – Vaisha Bernard
The Fortune 500 support portal let Bernard read and close tickets mid-outage. A redacted risk register listed every unmitigated zero-day in Microsoft’s environment, filterable by severity. The Windows build pipeline exposed an ESD private key and a tool upload path likely enabling remote code execution. The Microsoft Rewards center had a payout button accepting any amount, currency, and PayPal identifier. All 22 cases closed within two months. Bug bounty paid:
“absolutely nothing” – Vaisha Bernard
Notable Quotes
absolutely nothing Vaisha Bernard · ▶ 25:53
hacking Microsoft still is an infinite money glitch. Vaisha Bernard · ▶ 27:13
I did not publish any post. Vaisha Bernard · ▶ 18:45
Key Takeaways
- 172 Microsoft subdomains were registered as multi-tenant apps; 22 exposed internal data to any authenticated outsider.
- Conditional access policies and user assignment requirements both failed because they applied inside the attacker’s own tenant.
- Check multi-tenant app registrations with a one-line PowerShell script and validate the issuer claim in application logic.