Azure Tenant Security Breach Case Studies

Just finished piecing together one of the oddest Entra ID intrusions we’ve seen so far. It started with a burst of sign-ins from IP ranges that practically announced themselves as shady once you looked up the ASNs. The attacker’s first move after landing was to create a new Global Administrator. Minutes later every legitimate user in the tenant was hard-deleted, and an application registration appeared out of nowhere. Using that app, the actor pumped almost 50 000 guest accounts into the directory—effectively replacing the entire workforce with their own random identities. If you needed yet another reason to lock MFA onto (privileged) roles and tighten Conditional Access, here it is. Global Admin creation, mass user deletion, and surprise app registrations are all low-volume, high-signal events; they should additionally trigger alarms. In this case another giveaway was the user-agent string behind the bulk-user import: python-requests/2.32.3. Not exactly something your help-desk scripts run. #EntraID #AzureAD #IncidentResponse #CloudSecurity #MFA #ConditionalAccess #DFIR

⚠️ Another month, another critical vulnerability? Definitely not as critical as the recent findings by Dirk-jan Mollema, but still a significant finding due to the simplicity of exploitation. I'm extremely proud of our team at The Collective Consulting (and Bob Bracke in particular) that discovered this flaw, and worked with MSRC on reporting it and getting it fixed. ⚡️TLDR; due to a (lack of) verification flaw, cross-tenant access to Azure Event Grids was possible -- no authentication required. Microsoft has fixed the vulnerability -- no action required. ❓What happened: While building a multi-tenant event-capture service, The Collective spotted that creating an Event Grid System Topic scoped at a management group level let them see event subscriptions from other tenants if the management-group ID was reused. √ At the root: Management Group IDs are not globally unique (unlike subscription IDs). Microsoft’s filtering logic assumed uniqueness and failed to isolate tenants properly. 👀 What could be seen: number of events, error counts, types of Azure Policy events being tracked, delivery endpoints (webhooks, function apps), authentication headers and related settings. ⚠️ Impact: All tenants using Event Grid subscriptions on management-group scope were potentially exposed. Because there was no telemetry or alerts for this kind of cross-tenant visibility, it’s unclear if and how this was exploited. Based on feedback of MSRC, no signs of active abuse were reported. The practical exploitation “reach” may have been limited (since an Event Grid subscription had to be configured at that scope), but the design flaw is significant. 👉🏻 Takeaways Be careful with constructs that assume global uniqueness but rely on values that are only locally unique. This is true for everything, not just Azure, of course! Keep an eye on vendor/patch disclosures—here, Microsoft’s MSRC responded quickly after disclosure. Why this matters (especially for my network, given our focus on security)? If you’re managing or designing services that span tenants (e.g., service providers, ISVs, MSPs), this kind of flaw demonstrates how subtle configuration-or-scope assumptions can lead to cross-tenant visibility. In regulated environments (finance, insurance, high-security), extra scrutiny of event-streaming, telemetry, and subscription isolation is critical. It reinforces the notion that even “built-in” cloud mechanisms (like Event Grid) require careful architecture and threat modelling—especially when they touch multi-tenant boundaries. Fore more information, check out our blog with more details: https://lnkd.in/eGKBH3av #microsoft #security #azure

✨ I deployed a public-facing Azure Windows VM and watched what happened next. ⏱️ Within hours, it began receiving tens of thousands of authentication attempts. (around 60k+ attempts in first two hours after deployment) 🔐 I connected Windows Security Events to Microsoft Sentinel and analyzed the activity using KQL — not to “catch hackers,” but to understand how these attacks actually look in real logs. 🔍 What I observed: ⚠️ High-volume automated authentication attempts shortly after exposure 🧪 Clear credential spraying behavior from individual source IPs 📈 Hundreds of different account names targeted per minute 🎯 Strong focus on common usernames (administrator, admin, user, test, service-style accounts) 🛡️ No evidence of successful compromise or post-authentication exploitation ✨ This lab reinforced a simple but critical lesson: Exposed infrastructure is discovered fast. And most attacks rely on weak credentials — not sophistication. 📁 Full analysis, KQL queries, and screenshots are documented in my GitHub: https://lnkd.in/eghBZWez

A security researcher uncovered a quiet way to walk into any Microsoft Entra tenant—no alerts, no logs, no noise. By chaining Microsoft’s internal “Actor tokens” with a validation flaw in the Azure AD Graph API, an attacker could pose as any user, even Global Admins, for 24 hours across tenants. That’s a big deal because identity is the key we trust most. If changes show up under a real admin’s name, how quickly would your team catch it? Here’s the simple version of how it worked: Actor tokens weren’t documented, didn’t follow normal security policies, and requests for them weren’t logged. The Azure AD Graph API also lacked API-level logging. With a token, an attacker could read user and group details, conditional access policies, app permissions, device info, and even BitLocker keys synced to Entra. If they impersonated a Global Admin, they could change those settings—and it would look like a normal change made by a trusted account. The researcher reported the issue in July 2025. Microsoft moved fast, rolled out fixes and mitigations, and issued a CVE on September 4 saying customers don’t need to take action. There’s no evidence it was exploited in the wild. Still, this is a wake-up call: even the biggest platforms can hide deep, quiet risk. Build for resilience, assume silent failure modes, and consider reducing single-vendor dependence where it makes sense. Identity is your front door, treat it like mission-critical. #EntraID #IdentitySecurity #CloudSecurity #ChangeYourPassword Follow me for clear Microsoft identity security breakdowns and practical takeaways your team can use right away.

An AI provisioning script touched 62,000 identity records  over 9 days inside a client's Azure tenant. Every permission was technically valid. Zero SIEM alerts. Full policy compliance. The access review flagged it 6 weeks later, $220K in remediation costs. This is not a permission failure. It's a governance failure. ━━━━━━━━━━━━━━━━━━━━━━ 🔴 𝗧𝗛𝗘 𝗞𝗜𝗟𝗟 𝗖𝗛𝗔𝗜𝗡: → The script was provisioning contractor accounts and managing nested group memberships → It ran under a service principal with Contributor + User Administrator → No time-bound scope. No approval gate after day 1. → Every action was logged, but nobody had configured alerts or was watching the logs → It ran correctly, within policy, for 9 days straight → The access review caught it. Six weeks later. ━━━━━━━━━━━━━━━━━━━━━━ 💰 𝗧𝗪𝗢 𝗖𝗟𝗜𝗘𝗡𝗧𝗦. 𝗦𝗔𝗠𝗘 𝗤𝗨𝗔𝗥𝗧𝗘𝗥: → Client A: Provisioning agent, no scope review, no watchdog process. Result: 62K records touched, $220K remediation. → Client B: Same use case. Service principal scoped via PIM, 4-hour token lifetime, human review gate on any new group assignment.  Caught a scope drift on day 3. Remediation cost: $0. Same use case. Same stack. Different architecture. ━━━━━━━━━━━━━━━━━━━━━━ 🔴 𝗧𝗛𝗘 𝗕𝗥𝗨𝗧𝗔𝗟 𝗧𝗥𝗨𝗧𝗛: The script didn't do anything wrong. The architecture did. A technically valid permission and a governed permission are not the same thing. Your SIEM won't tell you the difference. Your access review will, eventually. ━━━━━━━━━━━━━━━━━━━━━━ What would have caught this at your org? Drop a number: 1 = A SIEM rule I already have configured 2 = An access review cadence 3 = PIM scoping on the service principal 4 = None of the above, we'd have missed it too __________ 🔖 Save this before your next AI agent deployment review ♻️ Repost if your team is shipping agents without a governance layer ➕ Follow Mohammad Syed for AI & Cybersecurity insights