English Threat Research Center Threat Research DNS DNS DNS OverDoS: Are Private Endpoints Too Private? 10 min read RELATED PRODUCTS Cortex Cortex Cloud Unit 42 Incident Response By: Golan Myers Published: January 20, 2026 Categories: Cloud Cybersecurity Research DNS Threat Research Tags: Microsoft Azure Networking Share Executive Summary We discovered an aspect of Azure’s Private Endpoint architecture that could expose Azure resources to denial of service (DoS) attacks. In this article, we explore how both intentional and inadvertent acts could result in limited access to Azure resources through the Azure Private Link mechanism. We uncovered this issue while investigating irregular behavior in Azure test environments. The risk is present in three scenarios: Accidental - internal: A network administrator deploys Private Endpoints to improve network security within an Azure environment. Accidental - vendor: A third-party vendor deploys Private Endpoints as part of its solution, for example to enable resource scanning by a security product. Malicious - attacker: A threat actor who gained access to an Azure environment intentionally deploys Private Endpoints as part of a DoS attack. Our research indicates that over 5% of Azure storage accounts currently operate with configurations that are subject to this DoS issue. In most environments, at least one resource in each of the following services is susceptible: Key Vault CosmosDB Azure Container Registry (ACR) Function Apps OpenAI accounts This issue has the potential to affect organizations in multiple ways. For example, denying service to storage accounts could cause Azure Functions within FunctionApps and subsequent updates to these apps to fail. In another scenario, the risk could lead to DoS to Key Vaults, resulting in a ripple effect on processes that depend on secrets within the vault. Microsoft provides fallback to internet advice that partially addresses this and other known issues associated with Private Endpoints. We discuss these issues, provide potential solutions and suggest ways that defenders can scan environments for resources that are susceptible to DoS attacks. Palo Alto Networks customers are better protected from the threats discussed in this article through the following products: Cortex Cloud Unit 42 Cloud Security Assessment is a strategic evaluation service that reviews your organization's cloud infrastructure to identify misconfigurations and security gaps, enabling teams to strengthen their posture against cloud-based threats. If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Related Unit 42 Topics Microsoft Azure, Cloud Research Azure Private Link Key Components, Concepts and Flows As part of Azure’s networking offering, Microsoft created Azure Private Link. This mechanism offers a private, secure way to connect to supported Azure resources and Azure-hosted custom services using Azure’s backbone network. Definitions To understand the solution and the secure connection process of resources using it, let’s first define the key components and concepts. Service: Destination to which a connection is made Private Link: Azure implementation that allows and handles the connections Private Endpoint: A network interface within a customer’s virtual network that allows connectivity to the service Private DNS zone: The default Domain Name System (DNS) service that is used with Private Endpoints Virtual network link: The link created by default between a Private DNS zone and a virtual network DNS A record: A DNS record that maps a domain or hostname to an IP address Network ACL: Network access control lists (ACLs) define rules that allow or restrict traffic to a service, separate from the Private Link solution Azure resources expose public endpoints by default. These endpoints resolve through standard DNS infrastructure — either public Azure DNS, or customer-managed DNS resolvers. When a client queries a service name such as mystorageaccount.blob.core.windows[.]net, the DNS resolver returns a public IP address owned by Microsoft. The IP address allows connectivity over the public internet or Azure service endpoints, depending on the network access controls that are applied. When Azure Private Link is introduced, DNS resolution behavior changes. A Private DNS zone — for example, privatelink.blob.core.windows[.]net — can be linked to one or more virtual networks. If a virtual network has a link to a Private DNS zone for a given service type, Azure’s DNS resolution logic prioritizes that zone when resolving matching service names. If a matching record exists, the name resolves to the private IP address of the Private Endpoint, instead of the public endpoint. Organizations commonly deploy one of the following architectures: Public-only architecture: Resources are accessed using their public endpoints and standard DNS resolution. Network ACLs, firewalls or service endpoints restrict access. Private-only architecture: All access to the resource occurs through Private Endpoints. Public network access is disabled, and DNS resolution is fully controlled through Private DNS zones. Hybrid architecture (public and private): Some virtual networks or workloads access the resource through Private Endpoints, while others continue using the public endpoint. This model is frequently used during migrations, phased rollouts, third-party integrations, or shared service environments. We use the example of storage accounts to demonstrate how Private Endpoints are used in Azure networking. However, the same concepts apply to any Private Link-supported service. By default, when a network administrator or a user with appropriate Azure Role-Based Access Control (RBAC) permissions creates a Private Endpoint linked to a resource, a Private DNS zone is created with a virtual network link to the same virtual network as the Private Endpoint. The DNS zone’s name has a predetermined structure that is based on the Private Endpoint’s destination service (e.g., privatelink.blob.core.windows[.]net for blob storage). Additionally, an A record is created in the DNS zone, linking the name of the destination resource and the IP address of the Private Endpoint. There are two ways to connect between a virtual machine VM and a storage account with a Network ACL: Without a Private Endpoint (using public or service endpoints) With a Private Endpoint Connection Flows Figure 1 shows how a connection is made to a resource that does not use the Private Link solution. Figure 1. Connection flow without the Private Link solution. The flow in this case is as follows: When trying to access the storage account, the VM attempts to resolve the account’s name to an IP address. This usually occurs through an external DNS resolver, and the traffic traverses the public internet. If the resolver has a record for the storage account, it returns the corresponding IP address. Once the address is obtained, the VM tries to connect to the storage account. The storage account then evaluates the virtual machine’s IP address against its Network ACL. If the connection is allowed, the storage account responds with the requested information. Figure 2 shows how the same connection is made when a Private Endpoint is used. Figure 2. Connection flow with the Private Link solution. Initially, the VM attempts to resolve the account’s name to an IP address. If a virtual network link exists in the virtual network (VNET) to a Private DNS zone that points to a Private Link service, Azure’s Private Link mechanism forces resolution using the Private DNS zone. This occurs when the connection is to a Private Link service of the same type (e.g., blob storage). When the DNS resolver identifies a matching A record, it provides the VM with the corresponding IP address. The VM then connects to the IP address, which belongs to the Private Endpoint. The Private Endpoint acts as a network interface for the storage account, evaluating the traffic and then forwarding it to the storage account. The storage account evaluates the request and supplies a response through the Private Link solution. The response is presented to the VM, which essentially accesses the storage account using Azure’s backbone network. Potential Private Link DNS Dangers As outlined above, interactions with a Private Link service from a virtual network configured with a Private DNS zone for that service type are forced to resolve through the Private DNS zone. Consider an environment where VM1 in VNET1 successfully accesses a storage account using its public endpoint. DNS resolution occurs through the default public DNS infrastructure, and access is permitted by the storage account’s Network ACLs. At this stage, the workload is operating normally. Later, a Private Endpoint is created for the storage account in VNET2 — either intentionally, accidentally, or by a third-party deployment. As part of this process, a Private DNS zone for blob storage (privatelink.blob.core.windows[.]net) is linked to VNET1 or shared across virtual networks. Once this DNS zone is linked, Azure’s DNS resolution logic forces all blob storage name resolution in VNET1 through the Private DNS zone. However, because no “A” record exists in the zone for the storage account within the context of VNET1, DNS resolution fails. VM1 can no longer resolve the storage account hostname and is unable to connect — even though the public endpoint remains accessible and unchanged. This configuration change effectively creates a denial-of-service condition for workloads in VNET1 that previously functioned correctly. The outage is triggered solely by a DNS resolution side effect introduced by the Private Link configuration, without any change to the target resource itself. Figure 3 demonstrates this example. Figure 3. Potential issue caused by using the Private Link solution. The figure above shows that VM1 attempts to connect to the storage account. This storage