On August 17, 2026, a threat actor operating under the alias “TheHatman” began offering data exfiltrated from the Azure and Entra ID tenants of nine large enterprises — including McDonald’s, Vodafone, Tata Consultancy Services, and Wyndham Hotels. The total haul: 3.6 million records containing employee IDs, job titles, departments, manager assignments, direct reports, active domains, and service account details.
No zero-day was exploited. No sophisticated malware was deployed against Azure infrastructure itself. The attacker used compromised credentials — likely harvested through infostealer malware — to authenticate into Azure tenants where multi-factor authentication was not consistently enforced.
This is not just an identity problem. It is not just a posture problem. It is both — and it exposes a fundamental gap in how most organizations think about cloud security.
What Was Stolen and Why It Matters
The exposed data goes far beyond email addresses:
- Full organizational hierarchies — who reports to whom, department structures, team sizes
- Service account details — non-human identities with potentially broad access
- Active domains and tenant attributes — the blueprint of an organization’s cloud infrastructure
- Employee IDs and job titles — enough to build convincing spear-phishing campaigns
Security leaders responding to the incident have recommended that affected companies immediately rotate credential stores, reset application registration secrets, audit service principal permissions, and review federated domain trust relationships.
The real danger is not the data itself — it is what comes next. With a complete organizational map and service account inventory, an attacker can craft highly targeted social engineering attacks, identify over-privileged accounts worth compromising, and map the fastest path to critical data.
The Attack Pattern: Simple, Repeatable, and Preventable
Here is how this attack likely unfolded:
- Credential harvesting — Infostealer malware (like ACR Stealer, which Microsoft flagged in increased activity from April–June 2026) captures browser-stored credentials from employee workstations
- Authentication without MFA — Stolen credentials are used to log into Azure/Entra tenants where MFA is either not enforced or bypassable for certain account types
- Directory enumeration — Once inside, the attacker queries Microsoft Graph API or Azure AD directory services to dump the entire tenant’s user and group data
- Exfiltration — Data is exported in bulk and offered for sale on underground forums
The critical failure point is not step 1 — credentials will always get stolen. The failure is that steps 2 through 4 were possible at all.
Why Traditional CSPM Misses This
If you run a standard CSPM scan against the Azure tenants that were breached, you would likely see findings like:
- “MFA not enforced for all users” — Severity: Medium
- “Service principal with broad directory read permissions” — Severity: Medium
- “Conditional access policy does not cover all authentication flows” — Severity: Low
Each finding is accurate. None of them, in isolation, sounds urgent. A security engineer triaging 2,000 findings will likely prioritize the “Critical” items — an exposed storage account, an open management port — and these identity findings sit in the backlog for weeks.
This is the core problem: traditional CSPM treats every misconfiguration with a flat severity per rule, disconnected from what the asset actually contains, who can access it, and what the blast radius of exploitation would be.
A service principal with Directory.Read.All permissions on a tenant containing 400,000 employee records and federated domain configurations is not a “Medium” finding. It is a critical exposure that, if exploited, gives an attacker the complete organizational blueprint of a Fortune 500 company.
But a flat-severity CSPM has no way to know that.
What Contextual Severity Would Have Caught
A CSPM that correlates posture with identity and data context would evaluate the same findings differently:
Finding: “MFA not enforced for privileged accounts”
| Dimension | Value |
|---|---|
| Standard CSPM severity | Medium |
| Contextual severity | Critical |
| Why? | These accounts have Directory.Read.All or Global Reader roles. The tenant contains 400K+ employee records. Conditional access gaps allow authentication from untrusted locations. Infostealer campaigns are actively targeting this sector. |
Finding: “Service principal with excessive directory permissions”
| Dimension | Value |
|---|---|
| Standard CSPM severity | Medium |
| Contextual severity | Critical |
| Why? | This service principal has no credential rotation in 180+ days. It can enumerate the entire directory. It is not scoped to a specific application. Combined with the MFA gap above, it represents a direct path to mass data exfiltration. |
The difference is not just the label. It is the reasoning. When a security engineer sees “Critical — because this identity can access 400K records and MFA is not enforced on the authentication path,” they act. When they see “Medium — MFA not enforced,” they queue it.
The Correlation That Matters: Posture + Identity + Data
This breach demonstrates why cloud security cannot live in silos:
Posture alone tells you there is a misconfiguration. It does not tell you whether anyone can exploit it or what they would get.
Identity alone tells you a service account has broad permissions. It does not tell you whether there is a compensating control (like MFA) protecting the authentication path.
Data context alone tells you that a tenant holds sensitive employee data. It does not tell you whether the access controls around it are adequate.
Only by correlating all three can you answer the question that actually matters: “What is the blast radius if this misconfiguration is exploited?”
In the case of the Azure/Entra breach, the blast radius was:
- 3.6 million employee records
- Complete organizational hierarchies of 9 Fortune 500 companies
- Service account inventories that could enable follow-on attacks
- Domain trust relationships that map the entire cloud footprint
A correlated view would have surfaced this risk weeks or months before TheHatman exploited it.
Practical Steps to Prevent This in Your Environment
Whether you are a security engineer at a growing SaaS company or an MSP managing 20+ customer tenants, here is what this breach teaches you:
1. Enforce MFA on every authentication path — no exceptions
This means:
- All user accounts, including break-glass accounts (use hardware keys)
- All conditional access policies covering sign-ins from untrusted networks
- Legacy authentication protocols disabled entirely (they bypass MFA)
AWS equivalent: Enforce MFA on all IAM users and root accounts. Use IAM Identity Center with mandatory MFA.
Azure:
# Check for users without MFA registered
az ad user list --query "[?!strongAuthenticationDetail]" --output table
# Review conditional access policies
az rest --method GET \
--uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies"2. Audit non-human identities (service principals, app registrations)
The Azure breach exposed service account details — meaning these accounts likely had excessive permissions that were never reviewed.
- Inventory all service principals and their permissions
- Remove
Directory.Read.Allfrom any service principal that does not absolutely require it - Implement credential rotation policies (90 days maximum)
- Monitor for anomalous Graph API queries from service accounts
# List all service principals with directory-level permissions
az ad sp list --all --query "[?appRoles[?value=='Directory.Read.All']]" --output table
# Check credential expiry for app registrations
az ad app list --all --query "[].{Name:displayName, CredExpiry:passwordCredentials[0].endDateTime}" --output table3. Implement just-in-time access for directory operations
No identity — human or non-human — should have standing access to read your entire tenant directory. Use just-in-time (JIT) access patterns where directory-level permissions are granted temporarily and with approval, rather than permanently assigned.
4. Monitor for bulk directory enumeration
Set alerts for:
- Graph API calls that enumerate large numbers of users or groups
- Service principals making directory queries outside normal business hours
- Any new application consent grants for directory read permissions
5. Correlate your findings across posture, identity, and data
Stop triaging CSPM findings in isolation. For every identity-related finding, ask:
- What data can this identity access?
- Is the authentication path protected by MFA?
- What is the blast radius if this credential is stolen?
If your current tool cannot answer those questions, you have a findings generator — not a security tool.
How Cloudanix Approaches This Problem
Cloudanix was built on the principle that a misconfiguration only matters in the context of the asset it sits on. Here is how that applies to a scenario like the Azure/Entra breach:
Contextual severity recomputation — When Cloudanix detects an MFA gap or an over-permissioned service principal, it does not assign a flat severity from a rulebook. It evaluates the finding against a security graph that includes: what data is accessible through this identity, whether the authentication path has compensating controls, what environment the asset is in (production vs. dev), and whether it is internet-facing. The result is a severity that reflects actual risk, not theoretical risk.
Correlated dashboard — Posture findings, identity findings (CIEM), data security findings, and code security findings appear in a single view. An MFA gap in Azure shows up correlated with the service principals it affects, the data those principals can access, and the compliance frameworks it violates. Your team sees the full picture, not fragments.
Auto-baseline drift detection — When a new service principal is created with broad directory permissions, or when MFA enforcement is weakened by a conditional access policy change, Cloudanix detects the drift from your secure baseline immediately — no manual configuration needed.
1,000+ pre-built checks mapped to compliance frameworks — SOC 2, HIPAA, ISO 27001, NIST, PCI, CIS all have controls around identity management and access control. Cloudanix maps your posture findings directly to these frameworks, so the audit team does not have to manually assemble evidence.
Multi-cloud coverage — Whether your identity layer is in Azure Entra ID, AWS IAM, or GCP IAM, the same correlated analysis applies. For organizations running multi-cloud (which is most of our customers), this means a single pane of glass across all cloud identity providers.
The Bigger Picture: Identity Is the New Perimeter
The Azure/Entra breach is not an isolated incident. It is part of a pattern:
- The Snowflake breach campaign (2024): Stolen credentials + no MFA = 165 companies compromised
- The Midnight Blizzard attack on Microsoft (2024): Legacy OAuth token + over-privileged test account = executive email access
- The Apollo Global Management breach (August 2026): Social engineering into cloud platforms = SSN and PII exfiltration
In every case, the attack succeeded because identity controls were insufficient and posture monitoring did not flag the gap as critical. The firewall did not fail. The endpoint protection did not fail. The identity layer failed — and the posture tool did not correlate that failure with the data at risk.
If your organization is growing fast, scaling cloud accounts, and handling sensitive data, this is the risk profile you carry. The question is whether your security tooling can surface it before an attacker does.
Key Takeaways
-
Credential theft is inevitable. Your security posture must assume credentials will be compromised and ensure that stolen credentials alone are not sufficient for mass data access.
-
Flat-severity CSPM creates dangerous blind spots. A “Medium” finding on an identity that can access millions of records is not medium risk. Your tooling must correlate identity permissions with data sensitivity to compute actual severity.
-
Posture and identity must be analyzed together. The Azure breach was preventable if either the MFA gap had been flagged as critical (because of the data accessible) or the service principal permissions had been scoped appropriately. A correlated view catches both.
-
Non-human identities are the expanding attack surface. Service principals, app registrations, and automated tokens are multiplying faster than human accounts. They need the same scrutiny — credential rotation, least privilege, and monitoring for anomalous behavior.
-
30 minutes of setup can prevent months of incident response. Modern CSPM tools like Cloudanix connect agentlessly, auto-create baselines, and begin correlating findings immediately. The time to deploy is a fraction of the time you will spend responding to a breach like this.
Want to see how Cloudanix correlates posture with identity and data for your cloud environment? Book a demo or explore the interactive product tour to see contextual severity in action.
