Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

To CNAME or not to CNAME: That is the (Enumeration) Question

Article originally co-authored with Klesti Fetiu on Exaforce Substack: https://theforcemultiplier.substack.com/p/to-cname-or-not-to-cname-that-is

Introduction

Back in 2018, NetSPI researcher Karl Fosaaen published an article that shed light on something often overlooked in cloud reconnaissance: a number of Azure services expose globally unique, DNS-resolvable endpoints tied to the resources they host. By querying these, an attacker can do more than just confirm a service is running and then they can start mapping out which cloud services a target relies on and, more interestingly, identify the naming conventions the organization uses when provisioning resources. That kind of pattern recognition can be surprisingly valuable when building a broader picture of a target’s infrastructure. In total, his research identified 18 such resources, all of which are listed below.

That work served as a solid foundation, but we wanted to see how far the surface actually extended. After digging into additional services beyond Fosaaen’s original scope, we found a much wider set of queryable endpoints than was initially known.

Azure Endpoints

In his article, Karl Fosaaen lists 18 resources with globally unique endpoints that follow the format <basename>.<resource endpoint>. Some of these basenames can be configured by the resource creator during provisioning, such as storage accounts, apps, and databases, while others are configured automatically when the service is used, especially Microsoft 365-related resources such as Microsoft domains, email, and SharePoint.

| **Nr** | **Endpoint** | **Suffixes** |

| --- | --- | --- |
| 1 | azurewebsites.net | App Services |
| 2 | scm.azurewebsites.net | App Services Management |
| 3 | p.azurewebsites.net | App Services |
| 4 | cloudapp.net | App Services |
| 5 | file.core.windows.net | Storage Accounts: Files |
| 6 | blob.core.windows.net | Storage Accounts: Blobs |
| 7 | queue.core.windows.net | Storage Accounts: Queues |
| 8 | table.core.windows.net | Storage Accounts - Tables |
| 9 | redis.cache.windows.net | Databases - Redis |
| 10 | documents.azure.com | Databases - Cosmos DB |
| 11 | database.windows.net | Databases - MSSQL |
| 12 | vault.azure.net | Key Vaults |
| 13 | onmicrosoft.com | Microsoft Hosted Domain |
| 14 | mail.protection.outlook.com | Email |
| 15 | sharepoint.com | SharePoint |
| 16 | azureedge.net | CDN |
| 17 | search.windows.net | Search Appliance |
| 18 | azure-api.net | API Services |

In 2022, I found an endpoint leading to Microsoft ATP, the cloud version of Microsoft ATA, which contains an endpoint of <basename>.atp.azure.com.

Ever since then, I have been interested in exploring other resources that use globally unique endpoints. These resources span storage, CI/CD, security, AI, databases, and many services in between. Microsoft provides a partial list of endpoints used by its services.

Some of these services were introduced after the original NetSPI article was published. For example, the article examined four types of cloud storage endpoints: Blob, File, Queue, and Table storage. Since then, when a Storage Account is created, an Azure Data Lake File System endpoint (dfs.core.windows.net) is provisioned by default. We can also look at additional storage-related endpoints, such as those used for Azure Static Website Hosting (web.core.usgovcloudapi.net).

Beyond storage, Azure now includes a wide range of services with globally unique endpoints, including AI and Cognitive Services, IoT services, CI/CD platforms, database services, serverless offerings, security services, and many others. The endpoints we identified are listed and categorized in the table below.

Private Links

There are times when some services do not need to be accessible to everyone. Services such as Storage Accounts, for example, are publicly reachable by default, with access typically restricted through ACLs and other access controls. Private Endpoints can be configured on a resource to restrict access, allowing connections only from approved networks or IP addresses. Access can even be limited to a specific VNet, ensuring that only resources within the authorized network can reach the service.

Private Link endpoints are created when a Private Endpoint is configured for a resource. These endpoints use the privatelink prefix to indicate the endpoint type.

!image.png

The way this works is that when the endpoint is accessed from within the private network, DNS resolves it to a private IP address. When the same endpoint is queried from outside the network associated with the Private Endpoint, it resolves to a public IP address, where access is restricted according to the resource’s public access settings.

Like public endpoints, some Private Link endpoints return successful DNS responses when queried, which can be used to enumerate resources if the basename is known. The endpoint format is simply <basename>.privatelink.<endpoint>.

Microsoft maintains a list of Private Link endpoints that maps each service and resource type to its corresponding public endpoint. While some of these endpoints do not return valid DNS responses when queried, others do. During our research, we identified several services and resources whose Private Link endpoints resolve successfully, allowing us to enumerate them.

US Gov and China Cloud

In addition to standard Azure endpoints, there are also Government Cloud endpoints, specifically for US Gov and China Cloud environments. These environments use different service domains, most commonly usgovcloudapi.net or azure.us for US Gov Cloud (for example, blob.core.usgovcloudapi.net), and chinacloudapi.cn or azure.cn for China Cloud (for example, blob.core.chinacloudapi.cn).

There are also services whose domains do not follow these conventions, such as Azure Container Registry (azurecr.io) and Azure Kubernetes Service (azmk8s.io). In those cases, the domain suffix changes to .us for US Gov Cloud and .cn for China Cloud.

Private Link endpoints in Government Cloud environments work the same way as in Azure. They include a privatelink prefix between the basename and the resource endpoint (for example, <basename>.privatelink.blob.core.usgovcloudapi.net).

Globally Unique Endpoints That Cannot Be Enumerated

Some services use globally unique endpoint names, but their DNS behavior prevents reliable enumeration. Rather than mapping each endpoint to a distinct IP address or DNS record, all endpoint names resolve to the same service infrastructure.

As a result, DNS lookups for these endpoints will always return a valid response, regardless of whether the specific resource exists. This behavior makes DNS-based enumeration unreliable and can lead to false positives.

The hosts I managed to find are listed below.

Conclusion

In conclusion, reconnaissance in cloud environments still relies on the same core techniques: port and endpoint scanning, subdomain enumeration, and passive online research, but it introduces a unique challenge: some configurations simply can’t be changed. This means certain resources may be exposed or accessible by default, with no straightforward way to restrict them, and the engineer responsible might not even know there’s a problem.

We should always keep in mind that cloud environments are designed to make hosting and managing resources easier than traditional on-prem setups, but that convenience comes with a trade-off. The reduced maintenance overhead can quietly mask risks that go unnoticed and unaddressed for far too long.

PreviousFeeding the worm a soft cloudy bun: The second coming of Shai-HuludNextGhost in the Script: Impersonating Google App Script projects for stealthy persistence

Last updated