If you’ve ever thought “we have MFA, we’re fine,” this alleged leak should unsettle you a bit. A threat actor using the alias “TheHatman” claims to be selling 3.64M Azure/Entra tenant account records pulled using compromised credentials, naming big targets like McDonald’s, Vodafone, Gap, TCS, HCL, IHG, and Kyndryl . Even if parts of the dataset turn out to be older or disputed, the risk is real: once employee directory data is out, attackers stop guessing and start aiming.
What’s allegedly leaked — and why it’s a big deal even without “secrets”
The claim here isn’t “we stole your source code” or “we grabbed your customer payment data.” It’s quieter than that, and that’s what makes it so dangerous.
A threat actor using the alias “TheHatman” has been advertising employee databases allegedly taken from Microsoft Azure / Microsoft Entra tenants using compromised credentials, naming big brands like McDonald’s, Gap, Vodafone, TCS, HCL, IHG, and Kyndryl. The actor claims a combined total of 3.64 million records, with one of the largest single postings described as 1.7 million McDonald’s employee records.
What the alleged Azure/Entra dumps contain
Based on what’s been reported, the dataset is described as classic corporate directory data:
- Full names
- Email addresses
- Job titles
- Phone numbers
- Postal addresses
- Employee IDs
- Service accounts and “other tenant account records”
Hudson Rock’s analysis goes a step deeper and calls out something that matters to defenders: the data reportedly shows tenant-specific .onmicrosoft.com structures and active domains, and may include service accounts plus the names of global administrators.
None of that looks like a “secret” on the surface. No passwords listed. No API keys. No database connection strings.
Still a big deal.
Why directory data is “attack fuel”
When attackers get real, internal identity data from an Entra ID / Azure tenant, they stop playing the numbers game.
They can run a much more targeted playbook:
- Spearphishing that doesn’t feel like phishing
If they know your title, manager chain, office location, and naming conventions, it’s easier to write emails that pass the sniff test (“Hey, can you review this vendor invoice before the EOD cut-off?”).
- Org-chart mapping for high-value targets
Titles and department patterns help attackers quickly find the people who approve payments, manage access, or sit near privileged systems.
- Helpdesk and HR fraud
Employee ID + address + phone = a convincing “identity packet” for social engineering. The goal is often a password reset, an MFA reset, or a new device enrollment.
- Service account abuse opportunities
Service accounts are frequently over-permissioned and under-monitored. Seeing them listed in a dump is a red flag because attackers can focus on “boring” identities that do powerful things.
- Targeted MFA fatigue attempts
If an attacker already has a username list that’s known-good, they can focus time on the humans most likely to approve an unexpected prompt—especially admins and IT staff.
This is why an Azure Entra tenant account records leak can hurt even when it looks like “just employee contact info.” Once the directory is exposed, the attacker’s job gets easier—and your people become the front line.
How attackers allegedly got in: password spraying + MFA fatigue (plain-English breakdown)
Once an attacker has a clean list of real employee accounts, the next step is getting one set of working credentials. TheHatman claimed the access came from password spraying and MFA fatigue.
Password spraying (what it is, and why it still works in Azure Entra)
Password spraying is when an attacker tries a small set of common passwords across a lot of users.
It’s the opposite of brute force. Brute force hammers one account until it locks. Spraying stays under the radar by moving slowly and spreading attempts out.
Why it works in enterprise Microsoft Entra ID environments:
- Password reuse is real
One employee reuses a password from an old breach, and the attacker doesn’t need to “hack Azure.” They just sign in like a user.
- Lockout policies are often tuned for “don’t break users,” not “stop sprays”
Some orgs avoid aggressive lockouts because it causes helpdesk tickets. Attackers count on that.
- Legacy auth and weird exceptions
If even a sliver of the tenant still allows older sign-in methods or has carve-outs for specific apps, that’s a common entry point.
- Uneven Conditional Access
It’s normal to see strong policies for admins but softer rules for regular employees, contractors, or older apps. Attackers go for the soft spots.
The important part: password spraying isn’t fancy. It’s patient.
MFA fatigue (push-bombing): turning “secure” into “annoying”
If spraying lands a correct password, MFA is supposed to stop the login.
MFA fatigue attacks try to break the person, not the technology. The attacker repeatedly triggers MFA prompts until the user hits Approve just to make the buzzing stop—or approves by mistake because they’re busy and the prompt looks routine.
This is why “we have MFA” can be a false comfort.
What “good MFA” looks like in practice (not theory)
If you’re running Azure AD / Microsoft Entra ID, strong MFA isn’t “turn it on and walk away.” It’s specific choices:
- Number matching instead of one-tap approve
If the prompt asks the user to match a number shown on-screen, accidental approvals drop fast.
- Phishing-resistant MFA for admins and high-risk roles
Methods like FIDO2 security keys or Windows Hello for Business are built to resist credential phishing and push fatigue games.
- Smarter prompts + user training that’s blunt
Teach one rule that people remember:
If you didn’t start a login, deny it and report it. Every time.
One more detail worth noting: TCS publicly stated the attacker claimed password spraying and MFA fatigue, and said it had safeguards against those techniques in place for more than two years. That kind of statement is common in incidents like this—and it’s also why defenders should focus less on “did it happen exactly like that?” and more on “could it happen to us next week?”
Conflicting signals: ‘No evidence of breach’ vs ‘high confidence the dataset is authentic’ — what to do with that
This is where a lot of teams freeze. One side says “nothing happened.” Another says “the data looks real.” Both can be true at the same time.
What companies are saying (and why they’d say it)
Two responses in the reporting are worth paying attention to:
- Gap’s position: a spokesperson said their preliminary investigation found the data was limited in scope, non-sensitive, and dated back to several years ago, with no evidence corporate systems were compromised.
- TCS’s position: in a notification, TCS said it found no credible evidence of a breach of its systems or customer environments, and that the details appear at least four years old and only basic employee information.
If you’re on the inside of a large org, that tone is familiar. Public statements tend to be narrow, careful, and based on what’s provable fast.
What threat intel is saying (and why that also matters)
Hudson Rock analyzed the dumps and said they contain foundational corporate directory attributes, a consistent structure that includes active domains and tenant-specific .onmicrosoft.com patterns. They also noted the presence of service accounts and global administrator names, and said they have high confidence the data is authentic. At the same time, they said the access vector and exfiltration method remain unknown.
BleepingComputer also noted it couldn’t independently verify authenticity.
How the dataset can look real while “no breach” still gets reported
A few common scenarios explain the mismatch:
- Old theft, new sale: data can be stolen months/years ago, sit quietly, then show up for sale later. The org’s current logs may not show an active compromise.
- Different path than expected: “Azure tenant” could mean multiple things operationally (apps, exports, synced directories). Your initial investigation might look in the wrong place.
- Mixed sources: a dump can be mostly legitimate directory records, with some enrichment from other sources. That still produces a dataset that “looks authentic.”
- Proof ≠ attribution: you can validate the structure and fields without knowing exactly how it was pulled. Hudson Rock basically says that out loud: authentic-looking data, unclear exfil route.
What to do with this ambiguity (the practical move)
Treat it like a credible exposure of Entra ID directory data until proven otherwise.
Action beats debate, because the attacker doesn’t need your internal verdict to start using the data. Even if it’s old, it’s still operationally useful for phishing, impersonation, and access attempts.
A simple internal stance that works:
- Assume the data is usable by attackers
- Assume your users will be targeted
- Assume at least one account will be tested
- Move fast on identity hardening and monitoring
A tactical hardening checklist for Entra/Azure: make this leak ‘boring’ for attackers
When a dataset like this allegedly includes service accounts and global administrator names, it’s a sign attackers will try the obvious next step: sign in, escalate, persist. Your goal is simple: make those attempts fail loudly and early.
Tenant-side: shut down the common Entra ID attack paths
- Put Conditional Access on rails (no “special cases” that quietly undo it)
- Require MFA for all users, then raise the bar for admins (stronger methods, tighter conditions).
- Add guardrails that shrink the attack surface:
- Block sign-ins from countries you don’t operate in
- Require compliant/managed devices for sensitive apps
- Step-up controls for risky sign-ins
- Block legacy authentication wherever you still can
Legacy auth is a spray-friendly gap because it often bypasses modern controls. If you can’t fully block it yet, quarantine it to the smallest possible set of accounts/apps and set an exit date.
- Tune protections specifically for password spraying
Spray attacks win when defenders rely on generic “bad password” rules and soft lockouts.
- Tighten lockout and detection behavior for repeated failures across many accounts.
- Watch for patterns like “same password attempted across dozens of users” and “low-and-slow attempts.”
- Make admin MFA phishing-resistant (not just “enabled”)
If the dataset really exposes admin identifiers, attackers will target those people hardest.
- For privileged roles, move to phishing-resistant MFA (FIDO2 security keys or Windows Hello for Business).
- Avoid one-tap push prompts for admins. They’re too easy to bully.
- Re-check privileged roles like you mean it
- Remove standing access where possible.
- Reduce role sprawl (too many people with too much power).
- Confirm that “break-glass” accounts exist, are protected, and are monitored.
- Watch service accounts like a hawk
This one’s not optional. The reporting notes dumps may include service accounts.
- Inventory every service account: owner, purpose, permissions, sign-in method, rotation plan
- Alert on:
- Interactive sign-ins (when they shouldn’t be interactive)
- Sign-ins from new locations/ASNs
- Sudden changes in token/app consent behavior
- Permission grants or role assignments tied to non-human identities
People-side: reduce how far social engineering can go
Helpdesk and IT: tighten the “human API”
Attackers with employee directory data will try resets and exceptions.
- Update helpdesk scripts so “I’m locked out” isn’t enough
- Require out-of-band verification for password resets and MFA resets
- Add a hard rule: no credential collection over email/chat, ever
Internal comms: one blunt message beats a long training
Here’s what a real attack feels like:
You’re in the middle of a meeting. Your phone buzzes with an MFA prompt. Then again. And again. A Teams message pops up: “IT here — we’re seeing unusual sign-ins on your account. Please approve the next prompt so we can confirm it’s you.”
That’s the trap. Your staff needs permission to be “difficult.”
- Don’t approve MFA prompts you didn’t trigger
- Report it immediately, even if it turns out to be nothing
If you implement even half of the above, a leaked employee directory stops being a launchpad and becomes background noise attackers move on from.
What employees can do this week (because they’re the target after directory leaks)
If employee directory data is out in the wild, attackers don’t have to guess who you are. They can call you by name, reference your team, and time their message to when you’re most likely to click. Hudson Rock flagged that these kinds of dumps can include service accounts and global admin names that can directly support social engineering and spearphishing.
Here’s a simple, do-this-now playbook you can send to staff.
1) Treat unexpected MFA prompts like a break-in
If you get an MFA prompt you didn’t trigger:
- Tap “Deny” (don’t ignore it and hope it stops).
- Report it right away using your company’s security channel (ticket, hotline, Slack/Teams channel).
- If prompts keep coming, turn on airplane mode for 60 seconds, then reconnect and report again. The goal is to stop the “Approve by accident” moment.
Rule that works under pressure: No login started by you = no approval from you.
2) Don’t trust “IT needs you to approve this” messages
Common pretexts after a directory leak:
- “We detected suspicious sign-ins. Approve the next prompt to confirm it’s you.”
- “Your mailbox will be disabled unless you re-verify.”
- “We’re upgrading Microsoft Entra/Azure. Sign in here.”
What to do:
- Don’t click the link.
- Don’t continue the chat thread.
- Call IT using a number you already know (intranet, badge, HR portal). Not the number in the message.
3) Handle “reset your password” lures with one check
Before you enter credentials anywhere:
- Open a new tab and go to the site the way you normally do (bookmark, typed URL, company portal).
- If the email claims urgency (“expires in 15 minutes”), assume it’s pressure tactics.
4) LinkedIn-style pretexting: assume the “new contact” did homework on you
If someone reaches out referencing your role, team, or tools you use, that doesn’t prove legitimacy. It often proves they had a data source.
Safe defaults:
- Don’t share org charts, internal processes, or vendor names in DMs.
- Don’t move a conversation to WhatsApp/Telegram “for speed.”
- If it’s a vendor request, route it through your normal intake process.
Where Cloaked fits (only when it actually helps)
A lot of employee exposure starts outside the tenant: webinars, vendor trials, conference registrations, partner portals. Those third parties get scraped, resold, or breached later.
For high-risk sign-ups and cold vendor outreach, using Cloaked identities (masked email/phone) can reduce how often your real contact details end up spread across systems you don’t control. It’s not a replacement for Entra security. It’s a practical way to cut down the “personal breadcrumb trail” attackers use to make scams feel personal.
.png)
