Project CloTeRe - Cloud Tenant Registry

This post was originally written to support the release of a tool that was initially designed to assist in collection of federation information for EntraID/Azure tenants. However, on May 1, 2025 Microsoft announced an update to enhance the security of tenant information by limiting the exposure of domain names to unauthorized users [1]. As a result, the tool is now deprecated and the post is published to document what was once upon a time possible.

CloTeRe is a tool for collecting and aggregating information about Microsoft cloud tenants using open sources (OSINT). The ultimate goal is to generate leads for further research. Among other use cases, CloTeRe can be used to enumerate DNS and to discover sensitive information associated with tenants.

The project expands on Nestori Syynimaa’s (@DrAzureAD) work (AADInternals) by collecting this data in a database and further enriching it with information from various open (public) sources. As a result, it enables pivoting between data that would otherwise have been disparate and unconnected.

This post is divided in the following sections:

Background

The idea for this project has been lurking in author’s mind for almost two years before it was finally shaped into CloTeRe shortly after Microsoft disclosed in January 2024 the attack they suffered by the nation state threat actor they track under the moniker Midnight Blizzard. Allegedly, “[…] the threat actor used a password spray attack to compromise a legacy non-production test tenant account and gain a foothold, and then used the account’s permissions to access a very small percentage of Microsoft corporate email accounts […]”.

Following Microsoft’s announcement, the cybersecurity community began analyzing the limited information Microsft shared, to identify how and what the attackers may did in the environment. Two articles that made sense, were from SpectreOps (Microsoft Breach — What Happened? What Should Azure Admins Do?) and Wiz.io (Midnight Blizzard attack on Microsoft corporate environment: a detailed analysis, detections and recommendations). With a later update issued in March 2024, Microsoft admitted that the scope of the compromise exceeded the initial disclosure.

Although in Microsoft’s incident the compromise vector was not a tenant secret that was found in a public source code repository, the author of CloTeRe wondered if it would be possible to identify tenant secrets in public sources. The desperate hunting for secrets had only just begun. Secrets do exist but how eactly we unearth them? If we think in graphs, there appears to be a missing edge that prevents us from arriving to a node of secrets. Looking up the name of a company on a source code platform or on search engines, will either return many results or absolutely nothing. What if we had a little piece of information that could help us narrow down our searches? The ID of a Microsoft tenant might be the answer.

Analysis

The starting point is this little key concept: Every Microsoft tenant has a unique ID - the tenant ID - assigned to it. Both people and machines can lookup a certain FQDN and identify if it is linked to a Microsoft tenant. Effectively, anyone can start from a company name, translate it to a FQDN and arrive to the ID that is assigned to the tenant of that company, pressuming the company has a Microsoft tenant.

company name -(translates to)-> domain name -(translates to)-> tenant ID

A tenant may be linked to other FQDNs registered to it. This information is public and can be retrieved by querying a Microsoft API. The registered domain names may:

In summary, people can use this tool to identify:

Impact

Modern digital infrastructure is hosted on cloud. The process of deploying infrastructure can be - and most of the times is - automated by code. Enter DevOps. This code must hosted somewhere, either public or private.

So far, if we think the above in terms of graph theory, there is a node that represents a company as an entity and another that represents the deployment/DevOps code this company relies upon. What might be the missing link between these two nodes? How do you start from one and end up at the other? Perhaps by using the tenant ID - one of the key links - that helped the author discover DevOps-related projects on GitHub containing tenant secrets.

The mining of the collected data has led to the discovery of secrets linked with tenant identities that could potentialy impact the confidentiality, integrity and availability (CIA) of cloud environments. The identified secrets have been responsibly disclosed to multiple affected entities spanning various sectors. Also, multiple source code repositories were removed from GitHub, while entities confirmed the disclosure of their tenant secrets.

Overall, the collected data allows analysts to connect domains to entities, IPs, CNAMEs. This generates leads for further research, such as domain takeovers via CNAME records, subdomain enumeration, and overall attack surface discovery. Additionally, if data collection is done at scale (gathering information from thousands of tenants), frequently and over a long period of time, the accumulation of historical data can become a valuable resource and drive further research on organizations.

The research in numbers

To back this research up with numbers:

Data Sources

CloTeRe collects and aggregates information from the following sources:

Technologies

This project is built with:

Acknowledgements

I would like to thank the following individuals. This project would not have been possible without them:

References

[1] https://techcommunity.microsoft.com/blog/exchange/important-update-to-the-get-federationinformation-cmdlet-in-exchange-online/4410095


tags:#Microsoft 365 and Microsoft Entra ID