From TXT Record to Tenant ID: DNS Recon Into Entra OAuth Abuse

The record is public. It always was. That is the point of DNS.

On July 14, 2026, The Hacker News described a technique that Proofpoint researcher Rachel Rabin calls OAuth client ID spoofing. An attacker submits a fake but syntactically valid client ID in a Resource Owner Password Credentials (ROPC) token request to Microsoft Entra ID, then reads the differing AADSTS error responses to enumerate valid usernames and check stolen passwords, all without ever logging a successful sign-in.

"When a spoofed client ID is used, no corresponding application name is recorded in the sign-in log."
— The Hacker News, July 14, 2026

In OAuth 2.0 the client_id is a unique string the authorization server issues to a registered client (RFC 6749 §2.2), and the redirect_uri must match a value pre-registered in the portal. The reported wrinkle: Entra does not reject a spoofed ID outright even when it is not a proper UUIDv4. There is no CVE and no Microsoft Security Response Center advisory in the coverage reviewed. Treat it as one link in a chain.

But spoofing needs a target. That is where DNS comes in.

The breadcrumb layer

You cannot use a custom domain in Microsoft 365 or Entra without proving you own it. Microsoft's add-custom-domain guide is straightforward: "Creating this TXT or MX record for your domain verifies ownership of your domain name." The Microsoft 365 admin docs spell out the value: "It looks like this: MS=msXXXXXXXX."

The admin doc tells you to remove that record once verification completes. Many organizations never do. It sits in the public zone, confirming which vendor runs the mailbox.

Microsoft 365 and Entra onboarding writes verification and service records straight into public DNS.

These are the patterns you find in the wild:

The MS=ms and ms-domain-verification tokens only prove domain control and Microsoft usage. The DirectFedAuthUrl record is worse: for SAML/WS-Fed direct federation, Microsoft's own instructions publish the real external login endpoint into public DNS. The Azure hostname leaks a resource-group name.

The pivot

Here is what people get wrong. None of those TXT records contains your tenant ID or an app’s client ID. But a verified domain is enough. That's it, just the domain. Microsoft's OpenID Connect documentation confirms the discovery authority "…can be the domain name of the Microsoft Entra tenant or the tenant ID in GUID format."

Unauthenticated. The response hands back the tenant's real authorization and token endpoints, the genuine login surface an attacker points consent phishing or spoofed ROPC requests at. DNS confirms the vendor; the OpenID endpoint resolves the tenant. Neither step requires a single credential.

None of this requires a specialist anymore. Point an AI assistant at that unauthenticated endpoint and it fetches the response and reports the tenant ID in a single turn. Recon that once took an operator now takes one sentence, so assume the path from your public domain to your live tenant is already mapped, at machine speed, by tooling that never sleeps.

The defense

Do not overcorrect. Microsoft's identity platform glossary is explicit: "The application (client) ID isn't a secret…" Tenant and app IDs are identifiers, not passwords. Hiding DNS is not the control, and mostly you cannot.

• Inventory your external DNS footprint the way an attacker enumerates it. This is MITRE ATT&CK T1590.002, a named recon technique.
• Remove stale verification records you no longer need; keep the ones tied to live services (DirectFedAuthUrl, DKIM, MX).
• Enforce exact redirect_uri allowlisting on your app registrations, and require a client secret or certificate for confidential clients. Paired with Conditional Access, those are the real boundary, not a secret ID.
• Monitor OAuth app consent and sign-in telemetry for the evasion pattern above. A spoofed client ID logs no application name at all.

Some of these records are temporary. Verification tokens can be pulled once a platform confirms the domain, though stale ones tend to linger for years, while others have to stay public to keep live services running. Either way the discipline is the same: every organization needs a pulse on exactly what its DNS publishes.

Sources

1. OAuth Client ID Spoofing Lets Attackers Evade Detection in Entra ID — The Hacker News, July 14, 2026. thehackernews.com
2. Add your custom domain — Microsoft Learn, June 18, 2026. learn.microsoft.com
3. Gather the information you need to create DNS records — Microsoft Learn, June 16, 2026. learn.microsoft.com
4. Add a SAML/WS-Fed identity provider (direct federation) — Microsoft Learn, April 8, 2026. learn.microsoft.com
5. OpenID Connect (OIDC) on the Microsoft identity platform — Microsoft Learn, June 30, 2026. learn.microsoft.com
6. Microsoft Identity Platform Glossary — Microsoft Learn, May 12, 2025. learn.microsoft.com
7. Gather Victim Network Information: DNS (T1590.002) — MITRE ATT&CK. attack.mitre.org
8. RFC 6749: The OAuth 2.0 Authorization Framework, §2.2 — IETF, October 2012. datatracker.ietf.org