Microsoft tenant enumeration is ending, but domain discovery remains

At a glance

What this is: This is an analysis of Microsoft tenant discovery after the patching of major unauthenticated enumeration paths, and the key finding is that full tenant domain enumeration is gone while partial discovery still survives through other identity surfaces.

Why it matters: It matters because identity teams, cloud defenders, and IAM practitioners need to understand which tenant metadata is still exposed, how attackers can still chain partial signals, and where defensive visibility or hardening may now be missing.

By the numbers:

• Microsoft tested over 240 other endpoint surfaces looking for alternatives and came up empty.
• The scan indexed over 600 million domains against Microsoft ODC provider endpoints.

👉 Read Sprocket Security's analysis of Microsoft tenant enumeration and azmap.dev

Context

Tenant enumeration in Microsoft 365 has traditionally been a discovery problem, not an authentication problem: a small number of public endpoints exposed enough metadata to let an operator infer tenant IDs, tenant names, and related domains. Once those paths were patched, the problem did not disappear, but it fragmented across DNS, OpenID configuration, Graph, and branding lookups.

For IAM practitioners, that matters because discovery is often the first step in attack planning, tenant mapping, and downstream tooling. When an environment still leaks enough metadata to reconstruct identity topology from multiple sources, the control question shifts from whether one endpoint was fixed to whether the broader identity surface still reveals operationally useful data.

The article shows that Microsoft’s patched endpoints closed the single-request technique, but not every supporting building block. That is a typical outcome for platform identity ecosystems: one discovery channel closes, and another data source becomes the next best path.

Key questions

Q: What should security teams do when tenant enumeration endpoints are patched but related metadata still exists?

A: They should stop focusing on the retired endpoint and inventory every public surface that can still reveal tenant IDs, MOERA prefixes, or verified domains. Discovery often survives through combinations of DNS, OpenID, federation metadata, and mail configuration, so the control objective is reducing recoverable identity topology across the whole ecosystem, not just one API.

Q: Why does tenant name exposure still matter after unauthenticated enumeration is removed?

A: Because many recon workflows need the tenant’s MOERA prefix to build downstream URLs, validate domain guesses, or locate related Microsoft services. If an attacker can recover that prefix through DNS or configuration artifacts, they can still chain into useful follow-on discovery even without the original bulk enumeration endpoint.

Q: How can organisations tell whether identity metadata exposure is still operationally useful to attackers?

A: Look for whether public records can be combined into a complete tenant map in a few steps. If tenant IDs, naming conventions, and related domains can be reconstructed from different sources, the exposure is still actionable even if no single endpoint returns everything at once.

Q: What is the difference between fixing one identity endpoint and fixing discovery risk?

A: Fixing one endpoint removes a single route, while fixing discovery risk requires reducing the usefulness of all publicly reachable identity clues. Tenant IDs, mail-authentication records, federation outputs, and branding data can each contribute part of the picture, so the programme has to govern the whole set.

Technical breakdown

How tenant discovery worked through ACS metadata

The original ACS metadata path returned an allowedAudiences list that effectively exposed verified tenant domains in one unauthenticated response. That was not a directory lookup by design, but a trust artifact exposed through WS-Federation plumbing. Because the data sat inside token validation infrastructure, the response leaked enough structured identity context to make enumeration cheap and repeatable, even though the API was never intended as a tenant inventory service.

Practical implication: any public identity endpoint that returns trust metadata should be treated as a discovery surface, not just an availability component.

Why Autodiscover and Graph were different discovery paths

Autodiscover federation queries and the Graph findTenantInformationByDomainName endpoint solve different problems, which is why patching one path did not automatically remove the others. Autodiscover historically supported federation discovery, while Graph can return tenant information for a known domain when authenticated and authorized. The key architectural difference is that one path was unauthenticated and broad, while the other is authenticated and targeted, so the risk profile and abuse value are not the same.

Practical implication: defenders need to classify each identity endpoint by what it reveals, not by which product team owns it.

Why DNS still reveals tenant naming clues

DKIM CNAMEs can expose the MOERA prefix because the tenant name appears inside the target record used for Exchange Online signing. That makes DNS a viable fallback when public identity endpoints are no longer enough. The important detail is that this is a data relationship embedded in mail configuration, not a Microsoft tenant directory service, which is why it can survive endpoint patching and still assist recon.

Practical implication: identity discovery reviews should include DNS records and mail-authentication configuration, not only portal-visible account data.

Threat narrative

Attacker objective: The attacker wants to convert small identity clues into a usable tenant map that supports targeting, enumeration, and downstream abuse.

1. Entry begins with a public unauthenticated request to Microsoft identity endpoints, which returns tenant metadata without requiring credentials.
2. Escalation occurs when the attacker combines tenant IDs, MOERA prefixes, and related domain data to build a more complete identity map.
3. Impact is improved targeting for follow-on recon, phishing, tooling, and tenant-focused abuse because the operator can reconstruct business domains and identity structure more efficiently.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Twitter Source Code Breach — Twitter source code leaked to GitHub by insider including authentication systems and configuration credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity discovery is now a distributed control problem, not a single-endpoint problem. Closing one unauthenticated path does not eliminate discovery if other identity-adjacent systems still expose tenant IDs, naming clues, or related domains. The practical lesson is that IAM governance has to account for the full exposure map across OpenID, DNS, mail authentication, and federation metadata. Practitioners should treat discovery as a surface area to reduce, not a single setting to fix.

Tenant naming is an identity control plane concern because it powers downstream tooling. The article shows that tenant IDs alone are not enough for many workflows, while MOERA prefixes enable SharePoint, OneDrive, and MDI-related follow-on techniques. That means the security value of a naming leak is not theoretical; it determines whether an operator can chain from one public signal into a larger recon workflow. Security teams should assume naming artifacts have operational value even when they look harmless in isolation.

Discovery fragility exposes an identity governance blind spot around configuration inheritance. Microsoft patched one code path, but mirrored hostnames and separate services continued to serve the same data until rollout completed. That pattern is common in large identity estates: controls are often inconsistent across legacy and modern surfaces. The governance takeaway is that consistency of exposure matters more than the presence of any single patch.

MOERA leakage is a named concept worth tracking because it bridges directory identity and infrastructure identity. The initial onmicrosoft.com domain is not just a branding artifact; it is part of how Microsoft tenant services and follow-on tooling find the right identity boundary. When that prefix can be recovered from DNS or federation metadata, identity scope becomes inferable without authenticating to the tenant. Practitioners should treat MOERA leakage as a recon signal, not a nuisance detail.

Unauthenticated tenant enumeration is a reminder that identity systems leak through trust relationships, not just accounts. The attacker does not need a password to benefit from metadata that reveals the structure of a tenant. That is why IAM, mail, federation, and DNS teams need shared ownership of identity exposure. The relevant question is not whether one endpoint was retired, but whether the identity ecosystem still discloses enough to support adversary planning.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• 85% lack of visibility is a governance signal, not just a monitoring gap, because identity exposure often sits outside the primary IAM console.
• For related lifecycle guidance, see NHI Lifecycle Management Guide and Top 10 NHI Issues.

What this signals

MOERA leakage is a recon problem that sits between IAM and infrastructure governance. When tenant naming and domain relationships can be inferred from DNS or federation artefacts, the organisation has not just a patching issue but an exposure mapping issue. Teams should add discovery surfaces to their identity risk register and check whether any public record can still be assembled into an operational tenant map.

The next maturity step is to treat identity metadata the way security teams already treat secrets and privileged credentials: as something to minimise, classify, and monitor for outward exposure. That means joining IAM, messaging, DNS, and cloud identity owners around one view of public identity leakage rather than chasing symptoms endpoint by endpoint.

Discovery surface sprawl: If one path is closed but mirrored hostnames, DNS records, or Graph-adjacent responses still reveal the same tenant information, the programme has not reduced exposure, only displaced it. Practitioners should use the NHI Lifecycle Management Guide to align ownership, review cadence, and offboarding for public identity artefacts that no longer need to exist.

For practitioners

• Inventory identity discovery surfaces Map every endpoint, DNS record, and mail-authentication artifact that can reveal tenant IDs, MOERA prefixes, or related domains. Include OpenID configuration, federation metadata, DKIM CNAMEs, MX records, and any public branding endpoints in the review.
• Classify public metadata as recon risk Treat tenant identifiers, verified domain lists, and branding values as security-sensitive metadata when they can be combined into usable enumeration paths. Tie that classification to exposure review, not just application ownership.
• Review mail and federation configuration together Check whether DKIM, Autodiscover, and Graph-related configuration can still be chained into a tenant discovery workflow. Where one control is removed, verify that the alternative path does not preserve the same outcome through another service.
• Reduce dependency on guessable tenant naming Assume attackers will use DNS and brute-force validation to infer MOERA prefixes when direct enumeration fails. Minimise public naming clues, document the tenant naming convention, and monitor for automated lookups against onmicrosoft.com records.

Key takeaways

• The article shows that tenant enumeration has not vanished as a problem, even though the classic unauthenticated paths have been patched.
• Discovery value now comes from chaining tenant IDs, MOERA prefixes, DNS records, and federation clues into one usable identity map.
• Security teams should govern public identity metadata as an exposure surface, not assume that closing one endpoint removes the recon risk.

Key terms

• MOERA domain: The Microsoft Online Email Routing Address domain is the initial onmicrosoft.com tenant domain assigned at creation. It is permanent and often reveals the tenant naming prefix used by Microsoft services and tooling, which makes it useful for recon when it can be recovered from DNS or federation artefacts.
• Tenant enumeration: Tenant enumeration is the process of discovering domains, tenant identifiers, and naming conventions associated with a cloud identity tenant. In Microsoft environments, it can be supported by public metadata, DNS records, and identity federation responses, even when no authentication is required.
• Discovery surface: A discovery surface is any public endpoint, record, or metadata source that reveals identity structure useful to an attacker or analyst. In identity programmes, these surfaces matter because they can expose relationships, naming patterns, or tenant boundaries before any authentication occurs.
• Federation metadata: Federation metadata is the signed information that tells other parties how an identity or application should be trusted. In NHI governance, it becomes a control surface because issuer values, claim rules, and entity details determine whether registration and authentication behave correctly.

What's in the full article

Sprocket Security's full blog post covers the operational detail this analysis intentionally leaves for the source:

• Step-by-step examples of the original ACS metadata technique and the exact responses it returned.
• Working command-line queries for DKIM, MX brute-force, OpenID configuration, and Graph-based tenant discovery.
• The full azmap.dev workflow for caching, correlating, and refreshing tenant-domain mappings at scale.
• Practical notes on where the patched paths failed first and which Microsoft hostnames lagged behind the rollout.

👉 The full Sprocket Security post covers the original ACS technique, fallback discovery methods, and updated lookup workflow.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI governance programme, it is worth exploring.