A breach with no CVE: how nine enterprise directories ended up for sale
Between July 31 and mid-August 2026, a threat actor operating under the handle “TheHatman” began advertising internal employee directories on cybercrime forums, claiming each set was exfiltrated directly from the victim organization’s Microsoft Azure tenant. According to BleepingComputer’s reporting on the campaign, the actor claims a total of about 3.64 million records spread across nine major enterprises — a set of listings that SecurityWeek tallied at roughly 3.5 million.
The per-company breakdown reported by BleepingComputer is striking in its spread: McDonald’s tops the list at more than 1.7 million records, followed by Tata Consultancy Services (TCS) at over 800,000, Vodafone at over 425,000, and HCL Technologies at over 250,000. InterContinental Hotels Group (IHG) accounts for over 185,000, Kyndryl over 170,000, Gap Inc. over 80,000, Hexaware over 20,000, and Wyndham Hotels roughly 9,000. The exposed fields, per the same report, include full names, email addresses, employee IDs, job titles, phone numbers, postal addresses, service accounts, and tenant account records.
What makes this incident distinct from the usual breach headline is what is absent: there is no CVE, no zero-day, no patch to apply. This was not a broken product — it was, allegedly, valid credentials used against a correctly functioning cloud identity system.
The likely vector: infostealers, not exploits
The exact intrusion method has not been conclusively established, and the affected companies dispute the severity. But the security firm that analyzed the dumps points to a familiar culprit. Hudson Rock, whose researchers examined the data, assessed that credentials compromised in a targeted infostealer campaign were most likely used to exfiltrate the directory data, while flagging phishing, weak multi-factor-authentication (MFA) enforcement, and over-privileged third-party API integrations as additional plausible paths.
TheHatman’s own forum claims describe the data as “exfiltrated from Azure/Entra instances using leaked credentials,” and separately reference password-spray and MFA-fatigue techniques — both of which are exactly the low-effort, high-volume tactics that thrive when tenants lack phishing-resistant MFA and conditional-access controls. Password spraying is among the most common attack patterns against cloud identity providers, and MFA-fatigue attacks — where a user is bombarded with push prompts until they approve one — are effective precisely because they exploit human impatience rather than any technical flaw.
Infostealers matter here because they defeat the mental model most organizations still hold about MFA. Token-theft malware such as the RedLine and Raccoon families lifts browser cookies and refresh tokens straight off an infected disk, letting an attacker replay an already-authenticated session without ever facing the login prompt or the second factor. The takeaway for defenders is uncomfortable: a single compromised laptop belonging to one over-privileged employee can be enough to walk out with the entire org chart.
Advertisement
Why an org chart is a weapon, not a nuisance
Several named companies have moved quickly to downplay the leak, and their pushback deserves fair weight. TCS told the Bombay Stock Exchange it had found “no credible evidence of a breach,” noting the data appeared to be at least four years old and contained only basic employee details, and that safeguards against password-spray and MFA-fatigue attacks had been in place for two years. Gap Inc. similarly stated it found no evidence of a breach and that the data was non-sensitive and dated back several years.
Those responses miss the point that makes directory data dangerous. This is not payment-card data that expires or passwords that can be reset — it is the structural map of an organization. As Hudson Rock warned, the exposure of service accounts and Global Administrator names is particularly concerning because it provides a direct roadmap for subsequent social engineering, spear-phishing, or targeted privilege-escalation attacks. The directory tells an attacker who reports to whom, which mailboxes belong to finance, which accounts are non-human service principals worth targeting, and — most valuably — the literal names of the Global Administrator accounts that control the tenant.
That is the raw material for convincing business email compromise (BEC) and targeted phishing. An attacker who knows the CFO’s assistant’s name, manager, and internal email format does not need to guess; they can impersonate the right person to the right target on the first try. Directory data ages gracefully as an attack asset precisely because reporting lines and admin structures change slowly — which undercuts the “it’s four years old” defense.
What this means for security leaders
The incident is a clean case study in a shift that has been building for two years: identity, not the network perimeter, is now the primary battleground, and the credential is the new exploit. Here is how to act on it.
1. Enforce phishing-resistant MFA on privileged and service accounts first
Push-notification MFA is what MFA-fatigue attacks are designed to defeat, and it does nothing against a stolen session token. Move Global Administrators, privileged roles, and any human-owned break-glass accounts to phishing-resistant methods (FIDO2 security keys or passkeys) before you worry about the general population. If TheHatman’s dumps contain your admin account names, assume those identities are now on a target list and harden them this week, not next quarter.
2. Treat infostealer infections as tenant-level incidents, not endpoint cleanups
When an endpoint agent flags RedLine, Raccoon, or a similar stealer, the standard response — reimage the machine — is only half the job. Any session tokens, refresh tokens, and saved credentials on that device must be assumed stolen and forcibly revoked in Entra ID. Rotate the affected user’s credentials, revoke active sessions, and review what that account could reach. A reimaged laptop with a still-valid stolen token is a solved endpoint problem and an open cloud one.
3. Audit and cap third-party API and service-principal privileges
Hudson Rock explicitly named over-privileged third-party API integrations as a plausible exfiltration path. Enumerate every application registration and service principal with directory-read permissions, and strip any that do not strictly need them. Non-human identities rarely trigger MFA and are frequently forgotten in access reviews — which is exactly why attackers hunt for them in a stolen directory.
4. Assume your org chart is already public and rebuild BEC defenses accordingly
If directory data can leak this quietly, defenders should stop treating internal reporting structures as a secret and instead harden the workflows that exploit them. Require out-of-band verification for payment changes and sensitive requests, flag lookalike and newly registered sender domains, and train finance and executive-assistant staff specifically on the spear-phishing patterns this data enables.
The structural lesson: cloud shared-responsibility cuts both ways
The most important line in this entire episode is that there was nothing for Microsoft to patch. Azure and Entra ID behaved as designed; the credentials were real. That is precisely how the cloud shared-responsibility model is supposed to work — and precisely why it is so unforgiving. The provider secures the platform; the customer secures identity, configuration, and privilege. When an attacker logs in rather than breaks in, no vendor advisory will save a tenant that shipped weak MFA, over-broad service-principal grants, and unmanaged infostealer exposure.
For the wider market, TheHatman’s listings are a preview of how enterprise data theft increasingly works: not a dramatic exploitation chain against a named product, but the quiet monetization of credentials harvested at scale from infected endpoints, cashed out against cloud tenants that assumed a second factor was enough. The organizations that weather this shift will be the ones that already treat every identity — human and machine — as a perimeter of one.
Frequently Asked Questions
Was there a Microsoft or Azure vulnerability behind this breach?
No. According to the reporting and Hudson Rock’s analysis, there is no CVE and nothing for Microsoft to patch — Azure and Entra ID functioned as designed. The likely vector was valid credentials, most plausibly harvested by infostealer malware and possibly aided by phishing, weak MFA enforcement, or over-privileged third-party API integrations. In cloud shared-responsibility terms, the failure sits on the customer side (identity and configuration), not the platform.
The stolen data is years old and “non-sensitive” — why does it still matter?
Directory data is not like payment cards or passwords that can be reset or expire. It is the structural map of an organization: reporting lines, service accounts, and Global Administrator names. Those change slowly, so an “old” directory remains an accurate targeting map for years. Hudson Rock warned that exposing service-account and admin names gives attackers a direct roadmap for spear-phishing, business email compromise, and privilege-escalation attacks — which is why the “it’s four years old” defense understates the risk.
What is the single most effective control against this class of attack?
Phishing-resistant MFA (FIDO2 security keys or passkeys) on privileged and service accounts, combined with treating infostealer infections as tenant-level incidents. Push-notification MFA is defeated by MFA-fatigue attacks and does nothing against a stolen session token, so replaying an already-authenticated session bypasses it entirely. Rolling phishing-resistant methods to admins first, then revoking sessions and tokens whenever a stealer is detected, closes the two paths this campaign relied on.














