3.6 Million Records, Zero Exploits: Inside the TheHatman Entra Directory Dumps

Between July 31 and August 16, a seller calling themselves TheHatman posted nine separate enterprise directory dumps for sale. McDonald's, 1.7 million records. Tata Consultancy Services, 800,000. Vodafone, 425,000. HCL, 250,000. InterContinental Hotels, 185,000. Kyndryl, 170,000. Gap, 80,000. Hexaware, 20,000. Wyndham, 9,000. Total claimed: 3.64 million.

Seventeen days. Nine tenants. And by every account so far, not a single exploited vulnerability among them.

I've spent most of my career on the response side of incidents like this, and the pattern in these listings is the one I find hardest to explain to executives. There's no CVE to point at. No patch anybody skipped. The attacker's own description of the McDonald's set says it plainly: "internal employee dump downloaded directly from Azure Tenant using compromised credentials." Tata's statement identifies the entry method as password spray plus MFA fatigue.

That's it. That's the whole intrusion chain.

The disputes are a distraction

Two of the named companies pushed back fast. Tata said it found no credible evidence of a breach and described the data as at least four years old. Gap said there's no evidence its corporate systems were compromised. Both statements can be true and the underlying problem still exists.

Hudson Rock, which reviewed the dumps, found they contain authentic foundational corporate directory attributes with the structure you'd expect from a real export. Names, employee IDs, email addresses, job titles, phone numbers, postal addresses, service accounts, tenant account records. Whether a given set came out last week or in 2022 changes the freshness of the data. It doesn't change how it left.

And here's the part that should bother you: if a set really is four years old, that means the export happened four years ago and nobody noticed then either.

Nobody had to break anything

The mechanism is boring, which is exactly why it works. Entra ID gives tenant users the ability to read the directory. Group membership, org charts, manager chains, service principal names, phone numbers. A lot of that is readable by any authenticated account by default, and the rest opens up the moment the account you've stolen carries a directory-reader role or sits in a group somebody added to a role five years ago and never audited.

So the attacker signs in with credentials bought from a stealer log, or sprayed until something lands. Then they use the product the way the product is meant to be used. Graph queries, a directory export, a CSV. Nothing malicious executes. No EDR agent sees a process it dislikes, because there is no process. The traffic goes to Microsoft endpoints from a session that authenticated successfully.

The supply of credentials to make that first step work is not scarce. Flashpoint's 2026 midyear report counted 1.7 billion credentials harvested by infostealers in the first half of this year alone, from 7.4 million infected devices, a 27% jump over the previous six months. Vidar, StealC and Lumma did most of it. We wrote about how that infostealer supply chain routes around MFA back in March, and nothing about the economics has improved since.

Unit 42 has been tracking TheHatman's activity against Entra tenants across that same August 1-17 window, alongside a separate initial-access broker campaign that ran multi-stage password spraying against Fortinet, MSSQL and Sophos edge devices. Their detection advice is worth repeating because it's honest about the constraint: audit remote access logs for successful logins that arrive shortly after a spike in failures. That is a correlation you have to go looking for. It is not an alert your stack raises on its own.

Why a directory beats a password dump

Ask a CISO to rank a stolen credential list against a stolen employee directory and most will pick the credentials as the worse loss. In my experience running post-incident work, that's backwards.

A password dies when it's rotated. A directory doesn't rotate. What you get from an Entra export is the shape of the organisation: who reports to whom, which accounts are service accounts, which names carry "admin" or "svc" or "backup" in them, which offices exist, what the email convention is, and enough phone numbers to run a convincing helpdesk-reset call against any of them.

That's the input to the next attack, and it's the reason these listings sell. Every social engineering campaign that follows gets sharper. Every password spray gets narrower and more likely to land, because now the attacker sprays the twelve service accounts instead of the twelve thousand users. We covered the mechanics of that pivot in the service account lateral movement teardown, and a directory dump is the map that makes it efficient.

Four-year-old data still works for most of this. Org structures move slowly. Email conventions almost never change.

State the detection problem plainly

Put the whole chain next to your controls and the gaps are easy to name.

Attacker step	What fires	Honest verdict
Buys creds from a stealer log	Nothing	No event exists on your side
Password spray / MFA fatigue	Failed sign-in noise, maybe an alert	Buried in normal volume; MFA fatigue looks like a user fumbling
Successful sign-in with valid creds	A normal sign-in	Indistinguishable without device or location signal
Reads the directory via Graph	A read operation, if you log it	Legitimate API, legitimate token, legitimate user
Exports and leaves	Nothing	No transfer to a suspicious destination

The chain end to end. Steps 3 and 4 are the ones no signature covers, because both are the platform working as designed. The decoy layer produces a signal at step 2 and again at step 4.

Every row is an activity your platform is designed to permit. The controls people reach for after an incident like this, tighter Conditional Access, stricter MFA, quarterly role reviews, all reduce the odds of step two. None of them produce a signal for steps four and five. If the attacker gets one valid session, the read looks like work.

That is a design gap, not a tuning problem. You can't threshold your way out of it, because there's no threshold that separates a diligent HR analyst pulling an org export from an intruder pulling the same export.

Make the directory itself the sensor

Here's the shift that actually closes it, and it doesn't require a new agent anywhere.

Plant identities in your directory that no human being should ever touch. Decoy user objects with plausible names, plausible titles, a plausible manager chain, and mailboxes that receive nothing. Decoy service accounts with names that sit exactly where an attacker's eye goes: svc-backup-prod, azbackup-admin, sql-svc-legacy. Give them credentials that are weak enough to be attractive and useless enough to be harmless.

Now the arithmetic changes. There is exactly one way those objects can end up in front of an attacker: somebody enumerated the directory. There is exactly one way anyone can attempt to authenticate as one: somebody read a dump. Legitimate users never see them, because nothing in your business process ever points at them.

This is what we build as Credential Mines and Digital Mines, and the property that matters isn't the cleverness, it's the false positive rate. A decoy account with zero legitimate purpose generates zero benign hits. When it fires, you don't triage. You respond.

The signal comes in two waves, and both are useful:

Wave one, at enumeration. Decoy objects configured with alerting on read return a hit the moment a bulk directory query touches them. That's your earliest possible warning, and it lands during the export rather than months later when the data shows up on a forum.

Wave two, at use. Deliberately weak decoy credentials get sprayed early, because they're weak, and they'll be tried against your own tenant, against your VPN, against anything that shares the naming convention. That attempt is unambiguous. Nobody guesses a decoy account by accident.

For the wave-two case specifically, the decoy is where a password spray reveals itself before Conditional Access policy nuances even come into play. We walked through that timing in detail in the ROPC password spray analysis from last month, and the same logic applies here with the directory read added on top.

Seeding a tenant, practically

If you want to try this on your own Entra tenant this week, the shape is straightforward.

1. Pick your bait tiers. A handful of decoy standard users, a handful of decoy service accounts, and one decoy account whose name implies elevated access. Attackers sort by apparent privilege, so the privileged-looking one gets touched first.
2. Match your real conventions exactly. If your accounts are firstname.lastname@, so are the decoys. A decoy that reads as fake gets skipped, and a skipped decoy is a wasted trap. Copy department codes, office fields, and employee ID formats from real records.
3. Give them a manager chain. Orphaned objects with no manager and no group membership look synthetic in an export. Attach them to real-looking org structure.
4. Disable interactive use, keep the object readable. The account should appear in every enumeration and succeed at nothing.
5. Wire the alert to your on-call, not your SIEM backlog. This is the mistake I see most often. Teams deploy deception, route the alerts into the same queue as their noisy detections, and the one high-fidelity signal they own gets triaged three days late. A honeytoken hit deserves a page.
6. Re-seed after any org change. If you restructure and the decoys still reference a department that no longer exists, they stop blending.

One caution from doing this in anger: keep a documented register of every decoy object and tell your identity team it exists. I've watched an IAM engineer spend an afternoon investigating a "ghost account" that was our own trap, and I've watched an access review flag decoys for deletion. Deception that surprises your own staff burns goodwill you'll need later.

What to check before the weekend

Independent of whether you deploy decoys, three things are worth pulling now:

• Directory read volume by principal, last 90 days. You're looking for any single account whose read count is orders of magnitude above its peers. Bulk export patterns stand out clearly when you rank them, and almost nobody looks.
• Successful sign-ins within 30 minutes of a failure spike, per account. Unit 42's advice, and the cheapest correlation you can build. If your SIEM can't express it, a scheduled query over sign-in logs will do.
• Who can actually read the whole directory. Not who has Directory Reader assigned today, but every group that nests into a role that grants it. Legacy nesting is where these permissions hide, and the answer is usually larger than the identity team expects. The same audit habit applies to insider-adjacent access patterns, where the risk is the same read from a different motive.

The uncomfortable summary of this campaign is that nine large enterprises with real security programs had their employee directories exported by someone using a login. If your answer to "how would we know" is a role review schedule, you don't have an answer yet. You have a policy.

Decoy identities are the cheapest way I know to convert an invisible read into a page at 3am. If you want to see what a seeded tenant looks like against your own directory, book a walkthrough with the Mine2 team.