Identity Directories Have Become An Unmonitored Intelligence Source

Identity directory egress is the blind spot sitting inside almost every enterprise security program: the moment a valid session reads more than it should, and nothing notices, because reading was never the thing anyone built alarms for.

This week, a threat actor operating under the alias “TheHatman” began selling internal employee directories pulled from at least nine Fortune 500-level organizations — McDonald’s, Vodafone, Tata Consultancy Services, HCL Technologies, InterContinental Hotels Group, Kyndryl, Gap, Hexaware, and Wyndham Hotels — reportedly extracted from their Azure and Entra tenants. Researcher reporting attributes the access to compromised credentials, though the precise acquisition method has not been publicly confirmed across every affected organization. That detail matters for incident response. It is close to irrelevant to the architectural finding, because the thesis below survives regardless of whether the session originated from an infostealer, a phishing kit, a hijacked token, or a compromised delegated application. What matters architecturally is what happened after a valid session existed — not how it came to exist.

Identity Directory Egress Is Rarely Treated As An Infrastructure Risk

Security programs are built around a largely unstated hierarchy: writes are dangerous, reads are safe. Provisioning gets an approval workflow. Privilege escalation gets alerting. Deletion gets a confirmation step and an audit trail. Every one of those controls exists because something can be undone, broken, or stolen through a write — and because, for most of the history of enterprise IT, that assumption held. A compromised account browsing a handful of records was a privacy problem, not a cloud strategy control-plane problem.

The write side of this asymmetry has already had its reckoning. Cloud Governance Failure Domains: When Governance Becomes Infrastructure documents how identity, policy, and budget mechanisms stopped advising infrastructure and started executing directly against it — a policy engine that denies a deployment outright, an identity boundary that determines where a workload is allowed to run, a compliance rule that quarantines a resource with no human in the loop. That post’s diagnostic question is whether governance can change infrastructure behavior directly. Identity directory egress is the mirror case on the other side of the same control plane: not whether identity can act without review, but whether identity can be observed, at scale, without review — and almost nowhere has that question been asked with the same rigor the write side already received.

Identity directory egress is what happens when that assumption stops holding at scale. A full tenant directory export doesn’t look like an attack, because it isn’t architecturally distinguishable from one. The session is valid. The query is one the platform is explicitly designed to answer. The response is exactly what a legitimate administrator would receive running the same export for onboarding, an org-chart refresh, or a compliance audit. Researcher analysis of this week’s campaign is explicit on this point: the extraction itself occurred through legitimate directory-access mechanisms, not a platform vulnerability. Nothing about the request trips a wire, because nothing was ever wired to notice it.

This is the actual failure mode identity directory egress names: not a vulnerability, not a misconfiguration in the traditional sense, but a heavily governed write layer sitting on top of an almost entirely ungoverned read layer — in a system where the read layer can now return the entire organizational map in a single call, and where “the account was authenticated” is treated as a sufficient answer to a question it was never built to answer.

What a Directory Export Actually Contains

Mainstream coverage of this class of incident tends to frame it as an employee data leak — names, emails, job titles, phone numbers. That framing is accurate and also the least interesting thing about what actually left the building.

A full tenant directory export doesn’t just expose who works somewhere. It exposes:

None of that is employee PII in the conventional sense. It’s a labeled map of the organization’s control plane — who can act, what they can act on, and how the pieces connect to each other. Microsoft’s own framing of Entra positions identity as the control plane used to manage and secure access across an environment. Taken on those terms, large-scale directory enumeration isn’t a privacy incident. It’s control-plane reconnaissance, collected in one request, without the requester ever touching a single system the directory doesn’t already govern.

This is the same shift Identity Is Becoming the New Infrastructure Boundary — Framework #160, Identity Boundary Inversion — already named: identity, not network topology, is now the perimeter that actually determines whether an action is authorized. That framework closed the Evidence Gap series on the observation that most organizations still audit the old perimeter and not the one that replaced it. Identity directory egress is a direct extension of the same inversion, applied specifically to observation rather than action: if identity is the control plane of modern infrastructure, then the ability to enumerate that control plane in bulk is not a side effect of a privacy leak — it’s reconnaissance against the actual perimeter, gathered through a channel most Zero Trust programs were never built to watch, because they were built to govern what identity can do, not what a valid session can see.

The Pattern This Isn’t New To

Rack2Cloud has made a version of this argument twice before, in two different domains, and both are worth naming directly rather than pretending this is the first time the shape has appeared.

Your Monitoring Didn’t Miss the Incident. It Was Never Designed to See It. makes the case that threshold-based monitoring is built for systems that fail loudly — and that modern systems increasingly fail by drifting: latency doesn’t spike, it drifts; error rates don’t explode, they scatter. That’s a performance and cost argument, not a security one, but the underlying claim is identical to this post’s: the absence of an alert is not the absence of a problem. It’s evidence the monitoring model was never asked the right question.

Egress Audit Framework: How to Find Unbounded Movement Paths — anchored to Framework #127, Movement Authority Boundary — names a specific category, unknown egress, as the traffic class standard monitoring cannot detect, precisely because nobody classified it as a path worth watching in the first place. That’s a network and data-transfer cost argument. Same shape again: an entire category of movement exists outside the model of what “suspicious” looks like, not because it’s hidden, but because nobody drew the boundary around it.

Identity directory egress is the third instance of the same pattern, now applied to identity: monitoring optimized around an expected failure class, producing a structural blind spot the moment reality moves outside the class the model was built to catch. Three domains, one architectural lesson — the question isn’t whether your monitoring is good. It’s whether anyone ever defined the shape of the thing it’s supposed to be watching for.

Domain	Monitoring Assumption	Blind Spot
Observability	Systems fail loudly	Slow drift
Egress (network)	Data leaves through known, classified paths	Unbounded movement paths
Identity	Writes are dangerous, reads are safe	Reads at scale

A pattern that recurs across three unrelated domains stops being a coincidence and starts being a property of how monitoring gets designed in the first place: teams instrument the failure mode they can already imagine, and the instrumentation stops exactly where the imagination did.

Why “Just Add MFA” Doesn’t Close This

The instinct after a credential-theft-adjacent story is to reach for identity hardening — stronger MFA, conditional access policies, shorter session lifetimes. Those controls matter, and none of them address identity directory egress specifically, because the premise of this failure mode is that the session is already valid at the moment the export happens. Hardening how a session gets created doesn’t constrain what an already-valid session is permitted to read in one action.

It’s worth being precise about what this post is not arguing, and where it differs from the closest thing Rack2Cloud has already published on identity failure. Your Identity Controls Passed. Your Authorization Chain Failed. asks whether a specific credential’s entire chain — creation, elevation, validation — can be reconstructed and proven legitimate after the fact. That’s an origin-of-authority question: should this credential have ever reached this level of privilege, and can the organization prove the chain that got it there? Identity directory egress asks a different question entirely: once a session is valid, regardless of how legitimately it was issued, what can it observe at scale before anyone notices? A credential can pass every stage of that post’s three-stage model — legitimately created, legitimately elevated, fully logged — and still walk out with the entire tenant directory in one call, because nothing in the chain-of-custody model constrains observation volume. The two failure modes are not competing explanations for the same incident. They’re adjacent gaps in the same identity plane, and an organization can close one completely while leaving the other wide open.

The architectural question identity directory egress actually raises — the question this entire post exists to ask — is a volume and rate question, not an authentication question: does anything in the environment distinguish an administrator pulling twelve records for onboarding from a session pulling the entire tenant directory in one call? For most organizations, today, the honest answer is no. Both operations use the same API, the same permission model, and the same absence of any rate boundary on read volume.

Closing the identity directory egress gap means treating bulk-read operations against identity directories the way write operations have been treated for years: volume-aware, rate-limited, and scored against a baseline of what normal administrative access actually looks like — not just whether the access was authenticated. A single account exporting a full directory in one session is not, by itself, evidence of a credential problem. It’s evidence of a missing control on an operation nobody classified as one that needed a control in the first place.

What Instrumenting the Read Layer Actually Requires

Naming the gap is the easy part. Closing it means answering three questions most identity platforms were never configured to answer, because nobody asked them at deployment time.

What does a normal export look like, by volume and by actor? Most organizations can answer “who has access to run a directory export” but very few can answer “what does a routine one actually return, in record count, on an average week.” Without that baseline, there’s no way to distinguish a bulk enumeration from an unusually large but legitimate HR pull — the alerting model needs a shape to compare against, and most environments have never built one.

Is read volume rate-limited independently of read permission? Permission answers whether an action is allowed at all. It says nothing about whether ten thousand records returned in one call should trigger a different response than ten. Most identity platforms today conflate the two: if the account is permitted to read the directory, it’s permitted to read all of it, at any volume, in a single request, with no distinction between the two cases.

Does the platform log query scope, not just query success? A successful authentication event and a successful full-tenant export produce the same class of log entry in most environments — a valid session performed an authorized action. Closing this gap requires logging what was actually returned, not just that a request succeeded, and treating a disproportionate response volume as a signal worth its own alert path rather than a detail buried in a request log nobody reviews unless an incident has already been declared.

None of this requires replacing an identity platform. It requires treating the read layer with the same architectural seriousness the write layer has had for years — because the incident that actually happens is rarely the one the monitoring model was built to catch. It’s the one nobody thought to define as a category at all.

Additional Resources