The claim and the method
A threat actor operating under the alias TheHatman began advertising a set of stolen Azure tenant databases on July 31, 2026, with the story becoming widely reported by August 17. The seller claims to have obtained access using compromised credentials combined with password spray attacks and MFA fatigue tactics, repeatedly triggering authentication push notifications until a user approves one by mistake or by sheer exhaustion, a technique that has become a standard part of the identity attacker's playbook against large enterprise tenants over the past several years.
The advertised haul totals 3.64 million records drawn from nine organizations. Individual breakdowns include more than 1.7 million records attributed to McDonald's, over 800,000 to Tata Consultancy Services, and more than 425,000 to Vodafone, with the remainder spread across Gap, HCL Technologies, InterContinental Hotels, Kyndryl, Hexaware, and Wyndham Hotels. The data reportedly includes employee names, email addresses, job titles, phone numbers, physical addresses, employee IDs, and in some cases service account credentials tied directly to internal systems.
Two denials, one authentication service
Tata Consultancy Services investigated the claim and stated it found no credible evidence of a breach of TCS systems or customer environments after reviewing the specifics of what was circulating. Gap Inc. reached a similar conclusion, finding no evidence its corporate systems had been compromised, and characterized the specific data circulating publicly as non-sensitive and years old rather than freshly exfiltrated from a recent intrusion. Both companies framed their statements narrowly around their own environments rather than disputing the broader claim outright.
Those denials do not necessarily contradict the seller's underlying claim, even though they read that way at first glance. Employee directory data that is years old and non-sensitive by Gap's own description is still consistent with a real, if stale, prior exposure being repackaged and resold as something fresh. The pattern of old breach data being recycled, relabeled, and sold again as new is common enough in the stolen credential marketplace that a company's denial of a recent breach and a seller's claim of authentic data can both be technically accurate at the same time.
Why identity infrastructure attacks are hard to deny cleanly
Password spray and MFA fatigue attacks are credential-based rather than exploit-based, meaning there is often no clean forensic signature like a patched vulnerability or a recovered malware sample to point to as definitive proof either way. A company can accurately say its systems were not exploited in the traditional sense while a threat actor accurately says they walked straight in through a compromised employee account, because both statements simply describe the same underlying event from two different vantage points, each technically correct within its own framing.
That ambiguity is precisely why identity-layer attacks against cloud tenants are so difficult to communicate about clearly in public. Verifying whether authentication logs show anomalous sign-in patterns, unusual MFA prompt volumes, or access originating from unexpected geographies takes real forensic time, time that rarely fits inside the fast-moving news cycle a leak site claim generates within hours of going live and being picked up by outlets around the world. Enterprises that lack long retention windows for that log data often cannot even attempt the verification at all, leaving them stuck restating a denial without evidence to back it.
The verification firm in the middle
Cybersecurity firm Hudson Rock said it confirmed the data's authenticity with high confidence based on its own independent analysis, while noting that outside reporters were unable to verify the underlying claim themselves through separate means. That leaves enterprises and readers largely dependent on one third party's confidence assessment for a claim that directly implicates nine large, well known organizations by name in a public breach narrative that continues to develop in real time.
This is an increasingly common structure in modern breach reporting: a seller's claim, a security firm's authenticity assessment, then a victim's denial, with no single party positioned to give a fully authoritative final answer quickly. CISOs evaluating whether their own organization might appear in a similar dump should not wait for that public resolution process to play out. Internal log review of authentication anomalies in the relevant window should start immediately, regardless of how the public narrative eventually settles.
The MFA fatigue problem enterprises still have not fixed
MFA fatigue attacks work because push-based multi-factor authentication was originally designed for convenience first and phishing resistance a distant second. Repeated prompts wear down even security-conscious employees over time, and the attack technique has been well documented in real incidents going back several years now, yet simple push notification MFA remains the default configuration at a large share of enterprises because it is cheaper and considerably easier to deploy than phishing-resistant alternatives like hardware security keys or number matching.
The organizations named in this claim, several of them large systems integrators and IT services firms that presumably advise their own clients on security posture as part of their business, illustrate how widespread the gap between known best practice and actual internal deployment remains even among firms that sell security expertise. Number matching and phishing-resistant MFA are not new recommendations by any measure, they are simply still nowhere close to universally implemented across the enterprise landscape.
The decision this puts on your desk
For any CIO or CISO running Microsoft Entra ID or a comparable identity platform at scale, this incident is a prompt to audit two things independent of whether your own organization was named in the claim: whether your MFA deployment has actually moved past simple push notifications to number matching or hardware keys, and whether your authentication logging retention window is long enough to investigate a claim about activity that occurred weeks or months before it ever became public knowledge.
The build versus buy question underneath this is really a prioritization question. Identity infrastructure hardening competes for budget against flashier AI and product initiatives every planning cycle, but it is the layer that both this incident and a large share of enterprise breaches over the past several years have actually run through. A claim like this one, contested and unresolved as it may well remain, is a reasonable trigger to move that hardening up the queue rather than waiting for a fully confirmed breach of your own to force the issue.
