A marketplace listing brags about roughly 3.64 million Entra directory rows across nine logos. The only named live login claim is password spray plus push fatigue.
According to BleepingComputer, the alias TheHatman advertised employee-directory dumps allegedly pulled from Azure tenants with compromised credentials. Listings ran from 31 July through 16 August 2026, with coverage on 17 August 2026. The only attacker-claimed live login path on the public record 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. Everything after a completed login is blast radius, not another chance for push MFA to save you.
Password plus human Approve is still MFA 1.0. MFA 2.0 removes both the sprayable secret and the bombable push.
What TheHatman claimed, and what is still unproven
Treat the sale as an advertisement with limited corroboration, not as proven 2026 tenant takeovers at every logo.
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."
MFA type is known only through the TCS push-fatigue claim. It is unknown at the other named firms. Lateral movement is not documented. Persistence is not documented.
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 finishes workforce Entra
Take the claimed chain at face value for mechanics, not as proof every tenant fell the same way. 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.
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 |
The last row is the part login controls cannot change. 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.
How phishing-proof MFA 2.0 stops spray-and-fatigue before a session issues
For the claimed TCS path, the fix is prevention at login, not a cleverer fatigue dashboard 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 | Phishing-proof MFA 2.0 |
|---|---|---|
| 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. That is prevention of the exact login failure the TCS filing describes, not another detection rule on sessions that should never have been issued.
Passkeys and FIDO2 are phishing-resistant at the login act when private keys stay device-bound and origin-bound with no OTP or push fallback. Against the claimed Entra path, that already removes typed passwords and relayable codes from the ceremony. 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.
Phishing-proof MFA 2.0 goes further: registration, device onboarding, authorisation, authentication, and decommissioning use no phishable factor. Enrollment and recovery were not the documented vector in TheHatman’s TCS claim, which centered on spray and push fatigue at login. The next operator who switches to phishable re-enrollment is why the full lifecycle still matters.
It is not a claim about malware reading memory after a good login already happened. Closing the spray-and-fatigue login stops this path. What remains is malware on an already signed-in machine, a separate attack that costs far more to run. Tricking a tired user into Approve needs little more than a convincing lure; endpoint malware on a signed-in machine needs much more.
Classic SSO turns one fatigued login into a directory skeleton key
SSO multiplies damage when the first proof is weak. Classic federation issues one session many integrated apps trust. Mail, files, chat, and admin surfaces ride the same earlier success. Zero-trust language says never trust, always verify at each access boundary. Classic SSO does the opposite. It auto-signs the user into many workloads from one earlier proof. When that proof was a password plus a fatigued push, the blast radius is the federated surface, not a single login page.
Bolting more monitoring onto broken SSO is not the answer. Secure Explicit Sign-On keeps one-tap UX while authenticating each application independently with its own fresh, device-bound signature. No shared reusable federation cookie exists to replay across the estate after a single weak Entra login.
Residual risk after the login path is closed is different. Revoke, short token lifetimes, and continuous access evaluation remain hygiene for harder paths such as malware on an already-logged-in endpoint. Authorization limits and watching unusual Graph or admin-console directory pulls matter for post-auth export. Those controls do not replace removing transferable factors from workforce login. Hudson Rock listed cookie theft as an unproven possibility here, not a demonstrated path. The honest claim 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.
| Control | Against claimed spray + push | Against later directory read / cookie theft |
|---|---|---|
| Password + push MFA | Completes under fatigue | N/A after issue |
| Passkeys at login only | Stops spray/push if passwords and push are gone | Does not undo an already-good session |
| Phishing-proof MFA 2.0 | No password, no Approve prompt | Session never issued via that path |
| Secure Explicit Sign-On | Fresh proof per app | No shared SSO skeleton key |
| Revoke / CAE / Graph monitoring | Not the login ceremony | Residual hygiene after auth |
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.
If you want the control-side walkthrough of phishing-proof, device-bound authentication, start at prevention, not detection.
FAQ
Would phishing-proof MFA 2.0 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 MFA 2.0 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.
