Azure OpenAI DNS Flaw: How a Misconfiguration Exposed Cloud Data to Risks

The discovery of a major Domain Name System (DNS) resolution flaw in Microsoft Azure’s OpenAI service, as documented by Unit 42 researchers in late 2024, cast light on a pivotal but often overlooked aspect of cloud security: the profound risk introduced by misconfigurations—even in managed, enterprise-grade environments. The flaw was not dramatic in complexity, but its effects could have been catastrophic, highlighting how mistakes in the seemingly routine administrative machinery of the cloud can expose organizations to widespread, cross-tenant data leaks and meddler-in-the-middle (MitM) attacks.

Anatomy of the Azure OpenAI DNS Resolution Issue​

An Unexpected Faultline in a Trusted Platform​

Microsoft Azure, as one of the world’s leading cloud service providers, invests significantly in the security of its Azure OpenAI offering. According to Microsoft’s official literature, the service is designed to deliver the leading AI models from OpenAI while incorporating Azure’s robust networking and security—including private networking, regional availability, and built-in content filtering. Customers expect a secure perimeter for their data and API traffic, especially when employing powerful AI tools for sensitive and regulated workloads.
Unit 42 researchers, however, uncovered a misconfiguration so basic that it defied expectation: the Azure OpenAI API allowed multiple instances (tenants) to share a single custom domain under particular circumstances, bypassing the enforcement found in the web user interface (UI). This aberration opened the door to a range of downstream attacks—most notably, the possibility that API traffic intended for an Azure-managed service could inadvertently be routed to an untrusted, external IP address under the control of a potential attacker.

UI Versus API: Enforcement Gaps and Oversights​

The crux of the issue lay in the divergent enforcement of domain uniqueness between the Azure OpenAI UI and its corresponding API:

• When creating an OpenAI instance through the Azure portal UI, users must specify a unique custom domain (e.g., margol.openai.azure.com). The portal promptly rejects any duplicate domain name requests.
• Conversely, the API allowed account creation without requiring unique custom domains. Accounts registered via the API could default to generic domains or, importantly, could specify the same custom domain as other tenants.

One such domain, test.openai.azure.com, was not uniquely assigned; as a result, multiple services—possibly belonging to entirely separate organizations—could share it. Any requests to this domain resolved, via public DNS, to a non-Azure IP address (66.66.66.66). This means API calls, data, and credentials could be sent to infrastructure outside Microsoft’s control, potentially exposing sensitive information and authentication secrets.

How the Flaw Exposed Organizations​

The DNS “Cross-Tenant” Hazard​

At the heart of cloud computing is the concept of secure multi-tenancy: many organizations using shared infrastructure, but always logically and physically segregated. This flaw effectively broke that model for any Azure OpenAI user whose instance referenced test.openai.azure.com.

What Could Go Wrong?​

• Data Leakage: Sensitive API requests, including data payloads and keys, could be intercepted at the external IP address, without attacker compromise of any victim tenant.
• MitM Attacks: An attacker aware of the flaw could listen on the external IP, intercepting and potentially manipulating traffic, credentials, or returned model results.
• Service Disruption: API calls could be dropped, redirected, or altered, causing loss of service integrity.
• Reputational & Regulatory Fallout: Unintentional data exposure, especially across customer boundaries (cross-tenant), can result in severe regulatory consequences.

Verifying the Impact​

Unit 42’s investigation demonstrated that popular DNS resolvers—including Google and Cloudflare—correctly pointed test.openai.azure.com to 66.66.66.66. Crucially, this address was not owned or operated by Microsoft. Individual tenants, believing they were operating within a secure, Microsoft-guarded context, might inadvertently be communicating with an entirely unknown entity. According to WHOIS records and network traces confirmed by external researchers, 66.66.66.66 was never associated with legitimate Azure resources at the time the flaw was live.

Visualizing the Attack​

A malicious actor could register for an Azure OpenAI instance via the API, specify the problematic custom domain, and set up a server at the external IP. Any other tenants, unwittingly referencing this domain in code or configuration, would direct traffic straight to this malicious service—even without any further compromise of Microsoft’s or the user’s infrastructure.

Microsoft’s Patch and Rapid Response​

Timeline of Discovery and Remediation​

The disclosure and subsequent remediation of the DNS flaw followed a rapid, well-documented process:

Date	Milestone
October 28, 2024	Unit 42 submitted a confidential report to Microsoft Security Research Center (MSRC)
October 29, 2024	Microsoft acknowledged and opened a tracking case (ID MSRC 92222)
October 30, 2024	Palo Alto Networks/Unit 42 confirmed remediation of the misconfiguration
November 22, 2024	Microsoft formally closed the case, confirming the issue was resolved

Microsoft’s remediation was multi-pronged:

• The offending DNS A record for test.openai.azure.com was deleted, rendering the domain either non-resolvable or rerouted to a legitimate production environment.
• All instances of the flawed domain assignment were corrected in the platform’s back end, preventing future recurrence.
• Microsoft reiterated that its authentication controls prevented further escalation of the flaw (although this would not mitigate all aspects of the data interception risk).

Researchers were unable to confirm through public evidence whether any exploitations occurred before the fix; security professionals are thus urged to conduct forensics if they suspect exposure in affected timeframes.

Implications for Cloud Security​

Why “Simple” Misconfigurations Matter​

The Azure/OpenAI DNS case exemplifies a growing trend where the most consequential cloud vulnerabilities are not due to novel exploits, but simple errors in platform policies or controls. Some takeaways:

• Basic Settings, High Stakes: It is often assumed that managed cloud offerings have “secure by default” settings. Unit 42’s work underscores that even fundamental DNS or domain enforcement rules can slip through the cracks, impacting thousands of customers.
• UI vs API Discrepancies: Modern cloud services are often managed through both graphical portals and programmable APIs. Gaps between the two, as seen here, introduce confusion and risk.
• Cloud Provider Assumptions Are Risky: Organizations must validate assertions (such as DNS records or who owns a given IP) even when dealing with trusted providers.

Potential for Widespread Impact​

• Shared Infrastructure, Shared Risk: When a custom domain is allowed to traverse tenant boundaries, any misrouted traffic potentially exposes all data handled by that endpoint. Attackers don't need tenant-specific credentials; the design flaw itself is the vector.
• Security Teams’ Role: Security operations must regularly audit DNS resolutions, IP ownership, and API-driven changes to ensure all endpoints are within their cloud provider’s infrastructure.

Prevention and Best Practices: Lessons from the Azure OpenAI DNS Flaw​

For Security Researchers​

• Scrutinize Defaults: Examine not just obvious vulnerabilities, but also basic, default settings for misconfigurations that could affect shared environments.
• Automate Configuration Audits: Use tools that continuously monitor public and internal DNS records, confirming IPs are within expected ranges.
• API as a Separate Attack Surface: Ensure that workflows achievable via the API are subjected to the same (or stricter) controls as those in the customer-facing UI.

For Cloud Security Practitioners​

• Validate DNS and IP Ownership Regularly: Confirm that all custom domains in use actually resolve to IPs owned by the cloud service provider. Tools such as nslookup, dig, or platform APIs can assist.
• Monitor for Cross-Tenant Issues: Adopt controls that detect when tenant resources see unexpected overlap—especially regarding naming or network assignment.
• Review API Workflows Continuously: Assume that even “approved” workflows may have unvetted logic; create security tests that mirror both UI and API use cases.
• Incident Response Readiness: Maintain clear lines of escalation with CSPs. If a vulnerability like this one is discovered internally, reporting through formal channels, as Unit 42 did, is essential for rapid response.

Critical Analysis: Strengths and Weaknesses​

Strengths in Response​

• Rapid Remediation: Microsoft’s corrective measures were swift and thorough, with major issues resolved in under 72 hours of disclosure.
• Transparency: The company confirmed the scope of remediation and clarified the landscape for impacted customers, helping restore trust in Azure OpenAI security.
• Authentication Controls in Place: Authentication was consistently enforced, limiting the potential for complete account compromise (though not preventing data leakage).

Underlying Risks Remain​

• Gaps in Configuration Consistency: Disparities between API and UI enforcement are not unique to Azure; similar flaws can and have arisen on other cloud platforms.
• Overreliance on “Managed” Label: Customers must recognize that “managed service” does not equate to “invulnerable” service. Even basic DNS or networking mistakes can lead to large-scale operational risks.
• Limited Public Forensics: No evidence was produced verifying that the flaw was not exploited; thus, organizations must proactively check logs and audit for abnormal traffic, particularly towards the queried external IP.

SEO-Focused Q&A for Practitioners​

What is the Azure OpenAI DNS vulnerability?​

The Azure OpenAI DNS vulnerability was a misconfiguration that allowed multiple tenants to share a single, non-unique custom domain, specifically test.openai.azure.com. Traffic to this domain resolved to an external IP not owned by Microsoft, exposing sensitive data to potential interception and MitM attacks.

Who was affected by the Azure OpenAI DNS issue?​

Any Azure OpenAI customers who referenced the affected custom domain could have experienced data leakage. While the rapid fix limited exposure, organizations should review API endpoint usage between late October and early November 2024.

How can businesses protect against cloud DNS misconfigurations?​

• Audit custom domain assignments
• Use automation for DNS verification
• Conduct regular risk assessments with tools like the Unit 42 Cloud Security Assessment
• Track CSP case advisories for latest vulnerabilities

Why is API parity with UI security controls important?​

Inconsistencies can enable attackers or misconfigured services to bypass safeguards, as was the case here. Security validation should span all access points—graphical or programmatic.

Integrating the Lessons: The Need for Cloud Vigilance​

The Azure OpenAI DNS debacle is instructive well beyond the particulars of AI or DNS. It echoes a foundational truth in the cloud era: the shape of risk is constantly evolving, often in quiet, unseen corners. As organizations harness managed AI and cloud platforms for more core functions, the margin for error narrows. Seemingly trivial oversights—like a custom domain policy gap—can cascade into systemic threats.
Ultimately, as the cloud becomes more complex and its platforms more programmable, both customers and vendors must establish feedback loops of continuous testing, validation, and incident response. Security is neither set-and-forget nor solely the vendor’s responsibility. Instead, cloud security is a collaborative, iterative process—where basic configuration errors deserve as much scrutiny as cutting-edge attack vectors.
By internalizing the takeaways from this incident, stakeholders across the IT security spectrum can safeguard the integrity, availability, and confidentiality of their cloud-hosted services, not just in Azure OpenAI, but across all shared, API-driven infrastructures.

---

Source: Unit 42 Lost in Resolution: Azure OpenAI's DNS Resolution Issue