Why a Hacker's Stolen Directory Data Claims Matter More Than You Think

In August 2026, a threat actor named TheHatman attracted attention after advertising about 3.6 million stolen employee records from major global organizations, allegedly obtained from companies’ Microsoft Azure and Entra environments. Microsoft's disclosure of a maximum-severity Entra ID vulnerability the same month heightened concern for some organizations, though Microsoft says it was patched server-side, never exploited, and unrelated to these listings. 

At first glance, the story looks like a straightforward corporate breach: steal cloud identities, read corporate directories, and exfiltrate millions of records. Our own analysis indicates the records are legitimate, though the evidence doesn’t necessarily support intrusions into nine separate cloud tenants as the attacker claims. 

For defenders, the validity of the seller's claims matters less than the underlying question: how could ordinary identities reach data like names, reporting lines, service accounts, and admin identities? None of it is what security teams would traditionally classify as “sensitive” data, but it’s enough to craft convincing phishing attacks. This incident spotlights the need for security teams to know what an account can reach once someone gets in, not just how to keep attackers out.

What Data Showed Up in These Listings?

Between July 31 and August 16, TheHatman published a series of underground listings advertising employee datasets attributed to nine organizations. Collectively, the actor claimed the datasets contained approximately 3.64 million records.

At the same time, Microsoft disclosed CVE-2026-69836, a maximum-severity (CVSS 10.0) remote-code execution vulnerability in Microsoft Entra ID that could allow an unauthenticated attacker to execute code over the network. That temporarily raised flags, even though it now just seems coincidental. 

‍

Cyera Research analyzed these records and found employee or directory information containing fields such as names, corporate email addresses, telephone numbers, job titles, office locations, identifiers, group membership information, service accounts, and privileged accounts. BleepingComputer reported that the seller claimed they obtained the information from Azure infrastructure using compromised credentials.

‍

Our sample analysis indicates that the employee information is genuine, so the datasets seem to contain legitimate corporate data. It does not establish when the hacker got the information, precisely where it originated, or whether TheHatman personally compromised the organizations' Azure or Entra environments.

Where the Claims and the Evidence Diverge

Several organizations named by TheHatman have disputed the suggestion that they had recent compromises.

Tata Consultancy Services (TCS) said that it found no credible evidence of a breach and that the material appears to be more than four years old. Gap similarly reported it found no evidence its corporate systems had been compromised. Vodafone characterized the material as resembling address-list or business-card information and said customer data was not affected. These responses point to several plausible explanations.

The simplest is that some of the material is older data being repackaged and resold. This is extremely common in underground markets. Authenticity and freshness are separate questions: a dataset can contain entirely genuine records while the seller exaggerates or misrepresents how recently they were obtained.

Another possibility is a shared third-party or application-level exposure. Organizations increasingly grant SaaS applications, integrations, service accounts, and enterprise applications permissions across their cloud environments. A sufficiently privileged application with directory-reading permissions could potentially provide broad visibility without requiring nine independent compromises.

A third possibility is the credential-based scenario described in public reporting. Malware company Hudson Rock has argued that compromised credentials associated with the affected organizations facilitated access, pointing to substantial evidence that the hacker used stolen credentials from infostealer logs. Within the cybercrime ecosystem, specialized actors known as initial access brokers (IABs) identify fresh and potentially valid credentials or sessions within the vast volume of underground data. IABs then validate and package that access and offer it to other threat actors. Ransomware operators can subsequently purchase or leverage this access as an entry point for network compromise, data theft, and ultimately double-extortion attacks (when attackers both encrypt and steal an organization’s data and threaten to release it unless the victim pays).

The existence of compromised credentials demonstrates opportunity, but not causality. No publicly available analysis currently ties a specific stolen credential to a specific directory export attributed to TheHatman.

Why Directory Data Matters Even Without Passwords

The advertised material does not appear to contain passwords or customer information, but that does not mean it’s without value.

Corporate directories like the ones in these listings are increasingly valuable reconnaissance resources because they describe how an organization is structured. Names, titles, departments, reporting structures, email addresses, group memberships, service accounts, and administrator identities can collectively provide an attacker with something resembling an organizational map.

This information can fuel more effective attacks. A directory identifying executives, IT personnel, service accounts, security groups, and privileged administrators lets cybercriminals tailor the attack to a specific employee. An attacker could use a directory to identify who likely staffs the help desk, who holds privileged roles, and who reports to whom. That’s the context that can drive convincing executive impersonation, internal phishing messages, or targeted phone calls for an MFA reset.

The Bigger Azure and Entra Security Question

The case with TheHatman highlights a broader issue for organizations operating in Microsoft cloud environments. Security teams focus on preventing an attacker from obtaining an account, but authentication is only one part of the security equation. The other critical piece: What can that identity reach once it is compromised?‍

• A legitimate account may be able to enumerate substantial portions of a corporate directory. 
• Application registrations can possess Microsoft Graph permissions allowing automated access to directory information. 
• Service accounts may accumulate permissions over time. 
• Enterprise applications may retain access long after the original business requirement ends.

The resulting problem is an intersection between identity security and data security. AI makes this particularly important for non-human identities. AI agents increasingly require persistent access to multiple applications, APIs, databases, and cloud resources to perform tasks autonomously. Unlike traditional service accounts with narrowly defined functions, AI agents often hold broad access, potentially giving a compromised or over-permissioned agent a much broader and less predictable blast radius.

Applications, automation, service accounts, integrations, and increasingly AI agents can operate with persistent permissions that are difficult for traditional IAM reviews to contextualize. An account with broad access is concerning; an account with broad access to highly sensitive data is far more concerning. 

What Defenders Should Take from the Campaign

TheHatman disclosures should serve as a reminder to organizations that information beyond passwords and customer records is still a real threat and to assess if they’re prepared for such events. 

Treat this campaign as an opportunity to validate several controls:

1. Review access to directory information to understand how much directory data ordinary identities can reveal and whether that visibility is actually required.
2. Examine directory-read permissions to Microsoft Graph held by application registrations and enterprise applications, particularly application-level permissions capable of operating without an interactive user.
3. Reduce standing privilege for global administrators and other privileged identities, which should use phishing-resistant authentication and just-in-time privileged access wherever possible.
4. Investigate unusual directory-enumeration behavior like large numbers of Microsoft Graph requests, bulk user enumeration from a single principal, unusual application consent, or unexpected directory exports. These are all potential signals of bad actors.
5. Assume that organizational information is already public, meaning help desks and identity-recovery workflows should not treat knowledge of an employee's manager, department, title, telephone number, or administrator name as true proof of identity.

Security teams increasingly need to think about how they’re protecting not just data but identities. AI will only make this more critical as employees give an ever-growing number of agentic identities sweeping access to automate more of their daily work. With that shift comes a new urgency.

Practitioners can't un-publish a directory that's already on a dark web forum. They can decide how much any single identity within the company — employee, service account, or agent — is able to see, and whether they have a way to spot suspicious actions. Every agent someone stands up is another identity that question applies to.

‍