A marketplace listing that brags about multi-company Entra directory exports is not subtle. According to BleepingComputer, the alias TheHatman advertised roughly 3.64 million employee-directory records across nine firms and claimed the dumps came from Azure tenants with compromised credentials. The only named live login story is the one Tata Consultancy Services reported in its NSE filing: password spray and MFA fatigue. That combination is a credential-phase failure on workforce Entra. Device-bound, phishing-proof authentication removes the password-plus-push surface so spray and approval spam cannot complete the login in the first place.
What TheHatman Claimed About Azure and Entra Directory Access
Listings ran from 31 July through 16 August 2026, with coverage on 17 August 2026. The seller’s pitch was consistent. One line captured by BleepingComputer reads: "I'm selling McDonald's Corporation internal employee dump downloaded directly from Azure Tenant using compromised credentials." The same framing covered McDonald's, Tata Consultancy Services (TCS), Vodafone, HCL Technologies, InterContinental Hotels (IHG), Kyndryl, Gap Inc., Hexaware, and Wyndham Hotels.
Claimed volumes, attributed only to TheHatman via that reporting, include McDonald's 1.7M+, TCS 800k+, Vodafone 425k+, HCL 250k+, IHG 185k+, Kyndryl 170k+, Gap 80k+, Hexaware 20k+, and Wyndham 9k+. Those figures sum near the ~3.64 million seller total in the article text. A URL slug that says "36 million" is not the verified count.
Advertised fields were directory export material: names, emails, titles, phones, addresses, employee IDs, service accounts, and in some listings Global Administrator names. Hudson Rock judged samples highly likely authentic directory exports but could not confirm how access was obtained. Infostealer-stolen Microsoft cloud credentials existed for most named firms in broader telemetry, yet those infections were not tied to this sale. Session-cookie theft and weak or missing MFA remain unproven for these dumps.
TCS and Gap both dispute a recent compromise and say the advertised data appears years old. TCS stated it found "no credible evidence of a breach of TCS systems or customer environments." A Gap spokesperson said preliminary investigation indicated limited, non-sensitive, years-old data with "no evidence to suggest that our corporate systems have been compromised." Treat the sale as an advertisement with limited corroboration, not as proven 2026 tenant takeovers at every logo.
If you want the full attack-chain write-up, read the related post on legacymfa.sucks: TheHatman’s Entra directory listings and the TCS filing.
Why Password Spray Plus Push Fatigue Still Completes Workforce Entra Logins
The useful prevention analysis starts with the only attacker-claimed path on the public record. According to TCS’s NSE filing as reported by BleepingComputer, "The attacker claims to have used password spray and Multi-Factor Authentication (MFA) fatigue as the attack vector." TCS also said it has had strong safeguards against those techniques for more than two years and found those defenses still effective. MFA type is known only through that push-fatigue claim. It is unknown at the other named firms.
Take the claimed chain at face value for mechanics, not as proof every tenant fell the same way. Password spray is low-and-slow guessing of common passwords across many accounts so lockouts stay quiet. When a guess hits a still-valid password on a workforce Entra login, the second factor becomes the only gate. MFA fatigue, also called push bombing, is the pattern where the attacker already has the password and floods the user’s phone with approval prompts until one tap goes through.
Authentication has not finished when that spam starts. What was abused is still a credential-phase surface: a shared secret plus a remote consent the attacker can solicit at scale. The transferable factor is the approval itself. Soft OTP and SMS fail for different transfer reasons. Push fails here because a human can be worn down into saying yes.
| Control in the claimed path | What fails | Login-time outcome |
|---|---|---|
| Password on Entra | Spray finds weak or reused secret | First factor is guessable |
| Push approval MFA | Prompts spam until one is accepted | Second factor is transferable consent |
| Directory export later | Uses an already-authenticated identity | Not an MFA-at-login problem |
That last row matters for honesty. Lateral movement is not documented. Persistence is not documented. Once an already-authenticated cloud identity can read directory objects, exporting people rows, service accounts, and admin labels is ordinary tenant work. No second factor undoes a live session that already passed authentication. Login cryptography does not rewrite history after a good session exists. The prevention question stays upstream: how did that identity become authenticated?
SSO and Entra raise the stakes when the upstream answer is spray-plus-fatigue. One workforce login that completes against the corporate IdP is enough to unlock the directory surface the seller bragged about. Classic federation is built so many apps trust that single proof. When the proof is a password plus a fatigued push, the blast radius is every integrated workload that accepts the resulting session, not just the login page.
Closing Spray-and-Fatigue With Device-Bound, Phishing-Proof Login
For the claimed TCS path, the fix is prevention at login, not cleverer revoke after the fact. Phishing-proof MFA 2.0 replaces passwords and approvable prompts with device-bound public-key credentials. The private key never leaves the enrolled hardware. Each authentication is a fresh, origin-bound signature. There is no password to spray across the tenant, and there is no push prompt to bomb until someone taps Approve.
That is a different strength class than "add another code." On the control ladder, password sits below OTP and SMS, which sit below push, which sit below phishing-resistant login factors such as FIDO2 and passkeys, which sit below phishing-proof coverage across the identity lifecycle. Push is still a phishable, fatigueable factor. Removing it from the ceremony is the point.
| Attack step (claimed path) | Passwords + push | Device-bound phishing-proof MFA |
|---|---|---|
| Password spray | Can hit reused secrets | No password surface to spray |
| MFA fatigue / push bombing | User can approve under pressure | No approvable prompt exists |
| Completing Entra login remotely | Session issues after Approve | Origin-bound key proof required on device |
| Later directory read | Possible after auth succeeds | Never reached if login never completes |
If spray-plus-fatigue cannot finish authentication, the attacker never holds the Entra session used to export directory objects. Revoke, short token lifetimes, and continuous access evaluation remain residual hygiene for harder paths such as malware on an already-logged-in endpoint. Those controls do not replace removing transferable factors from workforce login. Prevention, not detection is the design goal when the failure is still in front of authentication.
Passkeys and FIDO2 are phishing-resistant at the login act. A key pair lives on the device, the private key never leaves hardware, and signatures are bound to the real origin of the enterprise identity provider. Against the claimed Entra path, that already removes typed passwords and relayable OTP codes from the ceremony. On a generic enterprise IdP that issues only hardware-bound signatures, a remote attacker who only has a guessed password still cannot complete a cryptographic proof they do not hold. That hardens authentication. It is not yet the full lifecycle story.
FIDO2 and passkeys harden authentication only. Enrollment, device onboarding, and recovery can still reintroduce email OTP, SMS, or helpdesk-driven re-enrollment unless policy forbids it. An attacker who controls a phishable recovery channel can register their own authenticator, then produce signatures that look legitimate. Full phishing-proof coverage means no phishable factor appears at registration, device onboarding, authorisation, authentication, or decommissioning. Enrollment and recovery were not the documented vector in TheHatman’s TCS claim, which centered on spray and push fatigue at login. Full-lifecycle coverage still matters so the next incident does not simply move from fatigued push to phishable re-enrollment. The enrolment model is where resistant login becomes proof across the lifecycle.
SSO deserves a separate architectural note. Zero trust says never trust, always verify at each access boundary. Classic SSO does the opposite: one proof auto-opens many apps. A stolen or fatigued-through workforce session becomes a skeleton key across mail, files, chat, and admin surfaces that trust the IdP assertion. Bolting more monitoring onto that shared cookie model does not fix the design. Secure Explicit Sign-On keeps the same one-tap user experience while authenticating each application independently with its own fresh, device-bound signature. No shared, reusable federation token exists to replay across the estate after a single weak login.
If someone later steals a live session cookie with endpoint malware after a legitimate login, that is post-authentication token theft. Login MFA does not stop local malware from reading memory or browser storage. Hudson Rock listed cookie theft as an unproven possibility here, not a demonstrated path. The honest claim for this story is narrower and stronger where it applies: phishing-proof, non-approvable, device-bound authentication closes the spray-and-fatigue login path the TCS filing describes. It does not claim to have stopped every possible way directory rows could ever leave a tenant.
Key Takeaways for Defenders
- Retire user-approvable push as the primary second factor on workforce Entra and other cloud IdP logins where password spray remains possible.
- Prefer device-bound, non-approvable cryptographic MFA so there is no prompt to bomb after a password hit.
- Treat directory export risk as a post-auth problem: reduce standing read access for broad identities, and watch unusual Graph or admin-console directory pulls, without confusing that with login MFA.
- Do not rely on classic SSO auto-login as a zero-trust control when one weak workforce session unlocks many apps; prefer per-app, device-bound proof.
- Keep claims honest when marketplace dumps appear: verify freshness, access method, and tenant impact before treating every logo as a confirmed live breach.
Workforce Entra will keep attracting spray tooling for as long as passwords remain the first factor and humans remain the second. The durable answer is not a better fatigue dashboard. It is authentication that never offers a transferable secret or an approvable prompt to abuse.
FAQ
Would phishing-proof MFA have stopped the password spray and MFA fatigue path claimed against TCS?
Yes, for the login-time path Tata Consultancy Services said the attacker claimed. Password spray needs a password surface, and MFA fatigue needs an approvable push prompt. Phishing-proof, device-bound MFA removes both: there is no shared secret to spray across Entra accounts, and there is no remote consent prompt to spam until someone accepts. That prevents authentication from completing. It does not undo directory export after some other path has already produced a live tenant session.
Why is directory export after sign-in not something login MFA can reverse?
Directory export in TheHatman’s story is described as work done with an already-authenticated Azure or Entra identity. Once authentication has succeeded, reading people objects, service accounts, and admin labels does not present another MFA challenge at the login boundary. Login MFA’s job is to stop illegitimate authentication. Containment after a good session exists needs authorization limits, monitoring of unusual directory reads, and session revocation. Those are separate from replacing passwords and push at sign-in.
Are passkeys enough to stop Entra push bombing, or is full-lifecycle phishing-proof MFA required?
Passkeys and FIDO2 are phishing-resistant at login and would already block password spray plus push bombing if push and passwords are fully removed from the authentication ceremony. They do not automatically protect enrollment, device onboarding, or recovery if those stages still use email OTP, SMS, or helpdesk re-enrollment. MFA 2.0 is phishing-proof because no phishable factor appears at any lifecycle stage. For TheHatman’s TCS claim the documented failure was login-time spray and fatigue, but durable workforce design should close enrollment gaps too.
Why avoid classic SSO when Entra multi-app sessions are in play?
Classic SSO issues one session or federation token that many applications trust, so a single completed workforce login becomes a skeleton key across integrated apps. That design conflicts with zero trust’s never-trust, always-verify requirement. Secure Explicit Sign-On keeps one-tap user experience while authenticating each application independently with a fresh, device-bound signature. No shared, reusable SSO cookie exists to replay across mail, files, chat, and admin tools after one weak Entra authentication.
Did investigators prove infostealer cookies caused these Entra directory dumps?
No. Hudson Rock found infostealer-stolen Microsoft cloud credentials for most named firms but could not tie those infections to TheHatman’s access. Session-cookie theft and weak or missing MFA were listed as unproven possibilities. If cookies had been stolen after a legitimate login, that would be post-authentication token theft, a different problem from password spray and MFA fatigue. Nobody has demonstrated the cookie path for these listings.
