Azure Recon to Foothold and Profit

What this lab covers

You perform reconnaissance against an Azure environment from outside, moving from unauthenticated discovery through credential validation to an authenticated foothold, then enumerate the directory from within.

The lab covers the progression rather than a single technique, which is useful because the unauthenticated stage is invisible to the target and shapes everything an attacker does next. By the time anything appears in the tenant's logs, the attacker already knows the organization's domains, its tenant identifier and a list of valid usernames.

It assumes no prior Azure experience and works well before the more specific Entra ID labs, since almost all of them begin from a position this lab explains how to reach.

How unauthenticated Azure reconnaissance works

Microsoft exposes endpoints that answer questions about tenants without authentication, because federated sign-in requires clients to discover where to authenticate before they have any credentials. Whether a domain corresponds to a tenant, the tenant identifier and the authentication type in use are all discoverable as a consequence of that design.

The authentication type is more useful than it first appears. It reveals whether a domain is managed directly by Entra ID or federated to another identity provider, which tells an attacker where the actual authentication happens and therefore which techniques are worth attempting. A federated domain points at an on-premises system that may be reachable separately.

User validation is the more sensitive disclosure. Depending on tenant configuration, responses can differ for existing and non-existing usernames, which lets an attacker confirm valid accounts without attempting a password and therefore without generating failed sign-in events. Combined with email address formats inferred from public sources, a validated user list can be assembled entirely offline.

Once a valid credential is obtained, the authenticated position is very productive. Default directory permissions in Entra ID allow ordinary users to read a great deal about the organization, including users, groups, roles, administrative units and registered applications, which is why a single low-privilege credential is worth so much more in a cloud directory than a single workstation account traditionally was.

How to detect this in your own environment

The unauthenticated stage is genuinely not visible to you, and it is worth saying so rather than implying otherwise. It happens against Microsoft endpoints rather than against your tenant, so it produces nothing in your logs and no control of yours is involved.

The first observable event is authentication. Sign-in logs, including failures, are where a validated user list turns into activity you can see, so failed sign-in patterns spread thinly across many accounts deserve attention, since that shape indicates spraying against a list rather than one user mistyping a password.

After a foothold, watch for broad directory enumeration by an ordinary user. Most people never read the directory at scale, so an account suddenly listing users, groups and applications is a strong and low-noise signal that something has changed about who is using it.

How to prevent it

Restrict default user permissions so ordinary accounts cannot enumerate the directory freely. This is a tenant setting many organizations have never changed since the tenant was created, and it substantially reduces what a single compromised credential yields.

Reduce what is discoverable externally where configuration allows, and accept that tenant existence and identifier will remain discoverable. No control in your environment should depend on either being secret, because neither is.

Focus effort on making credentials hard to use rather than hard to guess. Phishing-resistant authentication, conditional access conditions on device and location, and blocking legacy authentication all mean a validated username list is much less valuable than the effort required to build it.

Real-world context

Unauthenticated tenant enumeration is a standard first step in Azure assessments and is implemented in widely used offensive tooling. It is documented platform behavior rather than a flaw, which is why the defensive answer is limiting the value of the information rather than trying to prevent its disclosure.

The default directory read permissions are the more consequential issue in practice. Many organizations discover during an incident that a single compromised standard account provided a complete picture of the organization's structure, privileged roles and application estate, which is precisely the map needed to plan the next stage.

The pattern maps to MITRE ATT&CK T1590 Gather Victim Network Information, T1087 Account Discovery and T1078.004 Cloud Accounts.

Applying this at work

• Check your tenant's default user permissions and restrict directory read access for ordinary users.
• Review which of your domains are associated with the tenant and whether that matches expectations.
• Alert on broad directory enumeration by non-administrative accounts.
• Move privileged users to phishing-resistant authentication so validated usernames are less useful.
• Confirm no control in your environment depends on your tenant identifier being private.

Frequently asked questions

What can someone learn about my Azure tenant without credentials?

Whether a domain corresponds to a tenant, the tenant identifier, and the authentication type in use, which reveals whether the domain is managed by Entra ID or federated elsewhere. Depending on configuration, they may also confirm whether specific usernames exist.

Is unauthenticated enumeration visible in my logs?

No. It happens against Microsoft endpoints rather than your tenant, so it produces no events for you. The first thing you can observe is an authentication attempt against an account.

What is the single most useful hardening step here?

Restricting default user permissions so ordinary accounts cannot enumerate the directory. It is a tenant setting many organizations have never changed, and it sharply reduces what one compromised credential provides.

Do I need my own Azure account to practice this?

No. The lab runs in a live environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own tenant.

Which certification covers this in depth?

The Microsoft Cloud Red Team Professional (MCRTP) covers Entra ID, Azure and Microsoft 365 attack paths in full, including token abuse, phishing tradecraft and privilege escalation, and is assessed hands-on in a live tenant.