A 3.6-million "Azure records" theft: not a Microsoft breach, but tenant credential theft
by Claudiu Hulea · IT Management Consultant
An attacker calling themselves “TheHatman” has put up for sale, on a cybercrime forum, what they describe as 3.64 million employee records “stolen from Azure” belonging to large companies: McDonald’s, Vodafone, Tata Consultancy Services, HCL, Gap, InterContinental Hotels, Kyndryl. The headlines suggest a Microsoft breach. It isn’t. And Microsoft, so far, has said nothing — for a reason.
In brief
- The claim: ~3.64 million employee records (names, email, employee ID, job title, phone, address, service accounts), put up for sale by “TheHatman” between 31 July and mid-August 2026.
- Named companies: McDonald’s (~1.7M), TCS (~800K), Vodafone (~425K), HCL (~250K), plus Gap, IHG, Kyndryl and others.
- The vector, per the attacker: compromised credentials — password spray + MFA fatigue, likely infostealers too. No Microsoft platform vulnerability identified.
- Not an Azure breach: it is credential theft against the customers’ tenants, i.e. shared responsibility.
- Microsoft: no official position as of the reporting date.
- Unverified: BleepingComputer did not confirm the claim; Hudson Rock says the samples have an authentic directory structure, but the data appears old.
Why it isn’t an “Azure breach”
The phrase “stolen from Azure” does the reader a disservice. It suggests someone breached Microsoft’s infrastructure. Every source points elsewhere: no hole in the platform was found. The attacker says they used valid credentials to authenticate into the companies’ Azure/Entra tenants and export the employee directory.
The difference is fundamental in the cloud’s shared-responsibility model. Microsoft is responsible for the security of the platform. The customer is responsible for the identities and access inside their own tenant — passwords, MFA, access policies. When someone logs in with a valid username and password (whether guessed or stolen with an infostealer) and gets past weak MFA, the platform works exactly as intended. It wasn’t breached; it was used with a legitimate but stolen key.
Microsoft’s silence, explained
Hence Microsoft’s absence from the story. As of 17 August 2026 there is no Microsoft or MSRC statement on the subject — no confirmation, no denial. This isn’t a PR slip, it’s the logical consequence: if the platform wasn’t compromised, it isn’t Microsoft’s incident to report. Microsoft would comment only if evidence of a platform vulnerability emerged, which no one has shown.
The ones who did speak are the named companies, and they downplayed it: Gap said it has no evidence of a breach and that the data looks old and non-sensitive; TCS said the data appears to be more than four years old, with no credible evidence its systems were compromised. Prudent, given the claim is unverified, but also convenient. The truth is probably in between: real but old data, harvested from tenants via credentials, not from a spectacular break-in.
The weak link: MFA fatigue
The useful part for a defender isn’t the scandal, it’s how they get in. Two vectors do almost all the work:
- Password spray. Instead of attacking one account with thousands of passwords (and locking it), the attacker tries a few common passwords across thousands of accounts, slowly, to stay under the lockout and alert thresholds. They only need one account with a weak or reused password.
- MFA fatigue (push bombing). Once they have the password, if the second factor is a simple push notification (“Approve?”), the attacker spams it until the user, tired or confused, taps Approve. The second factor becomes useless exactly when it mattered most.
Both exploit the same thing: MFA that relies on a secret that can be guessed, stolen, or approved by mistake. Hence the direction of the defence.
Our recommendations
If you run identities in Entra/Azure (or any IdP), this incident doesn’t call for a patch; it calls for the identity hygiene that matters anyway:
- Phishing-resistant MFA: FIDO2 / passkeys, not simple push. A passkey can’t be sprayed or “approved by mistake” — there is no prompt to tap. It is the direct answer to MFA fatigue. Number matching on push is a useful stopgap, not the solution. See also Entra: passkeys over SMS and voice.
- Conditional access. Gate access on compliant device, location and risk score. A “successful” login from another country, at 3am, from an unknown device should be blocked or challenged, not accepted.
- Password-spray detection. Few but steady failed authentications, across many accounts, from the same source — a pattern centralised monitoring catches, if it has the identity logs and retention.
- Anti-infostealer hygiene. Session and token theft bypasses MFA entirely. EDR on endpoints, session invalidation on risk, and training on cracked software / hostile extensions.
- Don’t confuse the responsibility. The platform is Microsoft’s; the identity, credentials and access policies are yours. That is where this is won or lost.
Want to see how exposed your tenant is to password spray and MFA fatigue, and whether you’ve moved to phishing-resistant MFA? Get in touch and we start with an identity and access audit.
Sources
Frequently asked questions
Is it a breach of Microsoft or Azure?
No. No source has identified a vulnerability in the Microsoft platform. The attacker claims to have used compromised credentials (password spray, MFA fatigue, infostealers) to extract data from customers' Azure/Entra tenants. It is a shared-responsibility problem — the customer's identity, not the Microsoft platform.
Did Microsoft confirm or deny it?
As of the reporting date (17 August 2026), Microsoft issued no official position — no confirmation, no denial, no "we are investigating". That is expected: from Microsoft's standpoint, the platform was not breached, so it is not their incident to report. Only the named companies responded, disputing it (old data, no evidence of a breach).
How did the attackers get in?
Through valid credentials, not a platform exploit: password spray (common passwords tried low-and-slow to avoid lockout), MFA fatigue (spamming push notifications until someone approves) and, likely, infostealers that steal sessions and tokens. Authentication succeeds without triggering failed-login alerts.
How do I defend against it?
Phishing-resistant MFA (FIDO2/passkeys), not simple push — push falls to MFA fatigue. Add conditional access (compliant device, geo, risk), password-spray detection, and anti-infostealer hygiene on endpoints. The platform is Microsoft's; the identity and credentials are your responsibility.
