What is Microsoft Entra ID?

You likely know "Active Directory" from on-premise (local) Windows environments. The biggest mistake you can make is assuming Entra ID (formerly Azure AD) is just Active Directory in the cloud. It is not.

• Active Directory (On-Premise) is a directory service based on LDAP and Kerberos. It relies on servers called Domain Controllers. It is hierarchical, meaning you have Organizational Units (OUs) inside Domains, inside Trees, inside Forests. When you hack AD, you are often attacking the Kerberos protocol or trying to access the NTDS.dit database on a Domain Controller.

• Entra ID is entirely different because it is a web-based identity service designed for the internet. It uses web protocols like HTTPs and APIs (REST). There are no Domain Controllers to hack. There are no OUs or Forests.

Entra ID is completely different.

Entra ID is "flat." Think of it as a massive spreadsheet or SQL database of Users, Groups, and Applications. You cannot use tools like Mimikatz to dump hashes from Entra ID in the way you would a Domain Controller.
When you attack Entra ID, you are attacking web APIs, manipulating tokens (OAuth/OIDC), or abusing misconfigurations in applications, not exploiting the Kerberos protocol.
It is a massive, flat list of three main things:

1. Users: The actual humans (or potential attackers) logging in.

2. Groups: Collections of users for easier management.

3. Applications (Service Principals): This is crucial. In the cloud, applications are treated like users. They have their own identities and passwords (secrets).

Entra ID speaks the languages of the web: HTTP and . It uses modern authentication protocols like OAuth2 and OIDC (OpenID Connect).

Entra ID Licensing Levels (Capabilities & Constraints)

The security posture of a target tenant is dictated by their wallet. Microsoft unlocks specific features based on the license tier (Free, P1, or P2). Identifying this early helps you predict defenses.

Free Tier

• Capabilities: Core identity management, SSO, basic security defaults.

• Attacker View: These tenants lack advanced logging and automated detection. Reconnaissance here is quieter, and complex defenses like Conditional Access are often missing.

Premium P1 (The Corporate Standard)

• Key Features:
  • Conditional Access (CA): The "If/Then" engine for logins (e.g., "If User comes from unknown IP, block").
  • Dynamic Groups: Groups that automatically manage membership based on rules (e.g., user.department == "IT").

• Attacker View:
  • Constraint: You will face geographical blocking and device compliance checks.
  • Opportunity: Dynamic Groups are exploitable. If you can modify a user attribute (like changing your department to "IT"), the system automatically moves you into privileged groups.

Premium P2 (The Enterprise Fortress)

• Key Features:
  • Identity Protection: Risk-based blocking. It detects behavioral anomalies (e.g., "Impossible Travel" or anonymous IPs).
  • Privileged Identity Management (PIM): This creates "Just-in-Time" admin access. Admins do not have standing access, they must request it for a specific time window.

• Attacker View:
  • Constraint: Stolen credentials might stop working if your login behavior looks suspicious.
  • Barrier: A Global Administrator account might look "empty" initially because the PIM role is deactivated. You must find the activation workflow to elevate privileges.

The Core Function of Entra ID

The single job of Entra ID is Authentication. It answers the question: "Is this user who they say they are?"

Entra ID acts as the bouncer for the Microsoft cloud. When a user attempts to log in, Entra ID checks the username, the password, and potentially the MFA status or device health. If the user passes these checks, Entra ID issues a digital ticket called a Token.

This Token is the most valuable artifact for an attacker. It contains claims (facts) about the user, such as their name, email, and the roles they hold. Once Entra ID issues this token, its job is essentially done for that specific login event. It hands the token to the user, and the user then presents that token to other services (like Outlook or Azure) to prove their identity.
Entra ID essentially says, "I have verified this person. Here is their badge."

Managed Identity

Technically, a Managed Identity is a special type of Service Principal (an Application account) in Entra ID that is tied to an Azure Resource.

The Problem it Solves (User View):
Imagine you are a developer. You built a web app that needs to access a Database. To login to the database, your app needs a username and password (credential).

• Old Way: You write the username/password in a config file or hardcode it in the source code.

• The Risk: Developers accidentally upload these config files to GitHub, and hackers steal the credentials.

• The Managed Identity Solution: Azure creates an automatic identity for the App itself. You tell Azure, "This Web App is allowed to talk to this Database." No passwords exist. The App asks Azure for a token, Azure sees it really is the App, and hands over the token.

The Opportunity it Creates (Attacker View):
A Managed Identity is a "Token Machine."
If I compromise a Virtual Machine or Web App that has a Managed Identity, I do not need to hunt for passwords in config files. I simply ask the local internal endpoint (IMDS) for a token.
Azure creates a token for me because I am operating from within the compromised resource. I essentially become the resource. If that resource has permission to access a Key Vault or a Database, I have that permission too.

Types of Managed Identities

There are two flavors you will encounter in the lab.

1. System-Assigned

• User View: You flip a switch on a specific resource (e.g., "Enable Identity on this VM"). Azure creates a specialized account in Entra ID tied strictly to that VM. If you delete the VM, the identity dies with it.

• Attacker View: If you are root/admin on that VM, you are that identity. You cannot easily move this identity to another machine; you must operate from the compromised machine.

2. User-Assigned

• User View: You create an Identity resource first (e.g., "Backups-Identity"). Then, you assign it to five different VMs that all need to do backups. It decouples the ID from the specific machine.

• Attacker View: This is dangerous. If I compromise one of those five VMs, I can steal the token for the "Backups-Identity." Since this identity is used by four other machines, the permissions attached to it are likely broader and cleaner than a specific System-Assigned identity.

You often see Managed Identities assigned "Contributor" or "Reader" roles on Subscriptions or Resource Groups so they can do their jobs.

• Scenario: You compromise a Web App via a vulnerability (like the File Upload vulnerability in Learning Objective 10 of your lab).

• Pivot: You find the Web App has a System-Assigned Managed Identity.

• Enumeration: You query Entra ID and find out this Identity has "Contributor" rights on the Subscription.

• Kill Chain: You request a token, use it to log in as the Identity, and now you control the entire Subscription.

This bridges the gap between Infrastructure Compromise (hacking the VM) and Identity Compromise (getting Entra ID access).

What is the Azure Resource Manager (ARM)?

If Entra ID is the bouncer, Azure Resource Manager (ARM) is the building management system.

Azure allows you to rent resources like Virtual Machines, Storage Accounts, and SQL Databases. You interact with these resources through a consistent layer called the Azure Resource Manager. Whether you are clicking buttons in the Azure Portal, typing commands in PowerShell, or running az commands in the CLI, every single request goes to ARM.

ARM handles Authorization. It controls the lifecycle of resources. When you say "I want to restart this Virtual Machine," your request goes to ARM. ARM looks at the Token you received from Entra ID. It reads the token to see who you are, and then checks its own list of rules (RBAC) to see if "User X" has permission to "Restart" the specific resource "VM Y."

From an attacker's perspective, ARM is the API gateway to the infrastructure. If you can speak to ARM with a privileged token, you can manipulate the physical infrastructure of the target.

A Resource is simply a thing you rent from Microsoft. It could be:

• Compute: A Virtual Machine (Windows/Linux).

• Storage: A Storage Account (to hold files or hard drive images).

• Networking: A Virtual Network (to let VMs talk to each other).

ARM handles Authorization. When you try to restart a VM, ARM looks at the Token you got from Entra ID and checks a list to see if you are allowed to perform that action.

The Hierarchy of Control

The Core Principle: Inheritance

Imagine a physical waterfall. If you pour dye into the water at the very top, that dye eventually colors every pool, stream, and rock all the way down to the bottom. You cannot stop the dye halfway down unless you explicitly build a dam (which is possible in Azure, called a "Deny Assignment", but rare).

As a Normal User (IT Admin), this is a feature. It saves time. You grant access once at the top, and it flows down.

As an Attacker, this is a vulnerability. You compromise one high-level account, and you get everything below it for free.

Tenant Root Group (The Source): The absolute highest level of the Azure Resource hierarchy. It sits above all Management Groups and Subscriptions. It mirrors the scope of the Entra ID Tenant.

Management Groups: These are logical folders used to organize Subscriptions. You can nest them (folders inside folders) to match your corporate structure (e.g., "Global Corp" -> "Human Resources" -> "Payroll App").

Subscription: This is the Billing and Access Control boundary. You cannot run a Virtual Machine without a Subscription to pay for it.

Resource Group (RG): A logical container. Everything must live in a Resource Group. You cannot have a "stray" file in Azure.

Resource: The distinct object itself. A Virtual Machine is a resource. A specific Network Interface Card is a resource.

If you have "Contributor" access on the Subscription, you inherit that access on every Resource Group and every Resource beneath it. You rarely need to find permissions on specific VMs, you target the Subscription or Resource Group that holds them.

Inheritance:
This is your best friend as an attacker. If an admin gives you "Contributor" access on a Subscription, you automatically become a Contributor on every Resource Group and every Virtual Machine inside that subscription.

The Two Role Systems (RBAC)

Because Entra ID (Identity) and Azure Resources (Infrastructure) are two different systems, they use two completely different sets of permission roles. Mixing these up is the most common source of confusion.

Entra ID Roles (Identity Roles)

These roles control the directory/identity. They define what you can do to users, groups, and applications.

• Global Administrator: The highest privilege. Can manage everything in Entra ID.

• Authentication Administrator: Can reset passwords for non-admins.

• Application Administrator: Can manage application settings.

Concept: These roles essentially control the "people."

Azure RBAC Roles (Resource Roles)

These roles control the infrastructure. They define what you can do to resources like VMs, Storage Accounts, and Key Vaults.

We categorize these by Execution Power (can they touch the data?) vs. Assignment Power (can they add other users?).

Roles that Control Data (Execution Power)
These are your primary targets for data exfiltration and destruction.

• Owner: The highest privilege. Has full access to view/modify resources AND can assign roles to other users.
  • Attacker View: The "Gold" standard. You can steal data and add a "backdoor" user for persistence.

• Contributor: Has full access to view/modify resources (create VMs, delete databases), but cannot assign permissions to others.
  • Attacker View: High value for immediate damage or data theft, but fragile. If you lose access to this account, you cannot add a backup user.

• Reader: Can view resources but cannot make changes.
  • Attacker View: Useful solely for reconnaissance to map the target environment.

Roles that Control Permissions (Assignment Power)
These roles control the "Access Control (IAM)" tab. They might not be able to see the data inside a VM, but they control who can.

• User Access Administrator: Can manage user access and assign roles to other users. Has no default access to resources/data.
  • Attacker View: A "Self-Escalation" primitive. You are blind initially (cannot read storage keys), but you can use this privilege to assign yourself the Contributor role.

• Role Based Access Control Administrator: Similar to User Access Admin but with stricter controls, usually used to delegate granular access management (e.g., "Can add members, but only as Readers").

Concept: These roles essentially control the "things."

The Bridge: Global Admin Elevation

There is a mechanism to bridge the gap between the two systems.

A Global Administrator (Entra ID role) does not automatically have access to Azure Resources (Azure RBAC). However, because they own the directory, they have the right to flip a specific switch: "Access management for Azure resources." When this switch is flipped, the Global Admin assigns themselves the User Access Administrator role at the Tenant Root Management Group level. Because of the waterfall hierarchy, they can now assign themselves "Owner" rights on every single subscription in the company. This is the ultimate escalation path.

How Azure Decides Access (The Logic Flow)

When you attempt an action in Azure (like restarting a server), the system doesn't just check your title. It runs a specific logic flow to determine "Yes" or "No." Understanding this logic prevents confusion when attacks fail despite high privileges.

Access is Additive (The Keychain Rule)

Azure permissions are cumulative. You never lose access by gaining a more restrictive role; you only gain more keys.

• Scenario: Your user account is assigned the Reader role directly. Your user is also a member of the "IT Admins" group, which has the Contributor role.

• Result: You are a Contributor. Azure adds all your permissions together.

• Attacker View: Do not stop enumerating after finding a direct user assignment. You must enumerate every Group the user belongs to. A low-level user might be hiding high-level power inside a group membership.

Explicit Deny Beats Everything

This is the only thing that stops the "Waterfall" of inheritance. If a "Deny Assignment" exists on a resource, it overrides any "Owner" or "Contributor" permission you have inherited.

• User View: Used for regulatory compliance. Example: "Deny creation of public IPs" to prevent anyone from accidentally exposing servers.

• Attacker View: This acts as a "trap." If you have Administrator-level access but get a "403 Forbidden" error on a specific resource, do not panic. Check if a Blueprints Deny Assignment is active on that resource blocking your action.

The Anatomy of a Role (Role Definitions)

Titles like "Contributor" or "Reader" are just human-friendly labels. Under the hood, a Role is a file containing three key lists:

1. Actions: The specific operations allowed (e.g., Microsoft.Compute/virtualMachines/start/action).

2. NotActions: Operations explicitly excluded from the allowed list.

3. AssignableScopes: Where this role can be used.

• Attacker View (Custom Roles): You will encounter roles with names like "L1 Support" or "Custom-Auditor." Do not guess their power by the name. You must inspect the Role Definition . A sloppy administrator might have used a wildcard () in the Actions list of a "Support" role, inadvertently giving you full control over a resource type.

Azure Attribute-Based Access Control (ABAC)

While RBAC is binary (you have the role or you don't), ABAC allows permissions based on specific conditions. It refines the "Contributor" or "Reader" roles.

• The Mechanism: Administrators attach a Condition to a Role Assignment.

• User View: "User Bob is a Blob Data Reader, BUT only if the Blob has the index tag Project = 'Blue'." This reduces the need to create hundreds of custom roles for specific datasets.

• Attacker View: This acts as a Hidden Filter. You may compromise an account that lists Microsoft.Storage/blob/read in its permissions, yet still get Access Denied on sensitive files because the resource tags do not match the ABAC condition. Do not rely solely on Role names; check for conditions attached to the assignment.

The Operator's Toolkit

Because Azure architecture is split into two pillars (Identity and Resources), the tools provided by Microsoft are also split.
A common frustration for beginners is running a command to find a User (Identity) inside a tool designed for VMs (Resources) and getting an error.

Infrastructure Tools (For the "Offices")

These tools interact with the Azure Resource Manager (ARM). You use them to list Storage Accounts, restart VMs, or read Key Vaults.

• Az CLI (az): This is the preferred tool for offensive operations. It is cross-platform (Python-based) and outputs data in format. This is critical because attackers need to parse large amounts of data programmatically. The CLI allows filtering data on the fly using JMESPath queries (like grep for ), making it faster than PowerShell for rapid enumeration.
  • Command Example: az vm list (List all VMs).

• Az PowerShell: This is the standard administrative framework. It is powerful but verbose. It outputs .NET objects, which are great for automation scripts but harder to "grep" quickly during a live attack compared to the CLI. It has replaced the legacy "AzureRM" module.
  • Command Example: Get-AzVM.

Identity Tools (For the "Phonebook")

These tools interact with Entra ID and the Microsoft Graph API. You use them to list users, check group memberships, or reset passwords.

• Microsoft Graph PowerShell (Mg module): This is the modern standard. It directly wraps the Microsoft Graph API. The commands often start with Get-Mg... (e.g., Get-MgUser). It effectively replaces the older modules.

• AzureAD PowerShell: This is the legacy module. It is being deprecated but you will still see it in older playbooks and documentation.

The Authentication Caveat:
Just because you log in with Connect-AzAccount (Infrastructure) does not mean you are logged into Connect-MgGraph (Identity). They often require separate authentication flows and tokens, even though you are the same user.

Community Tools

Microsoft's tools are designed for Administration (building things). They have guardrails. As attackers, we use community tools designed for Enumeration (finding things).

• AADInternals: A PowerShell framework that bypasses standard APIs to hit internal Microsoft endpoints. We use this for Reconnaissance because it reveals details Microsoft's official tools hide (like exact federation configurations).

• MicroBurst: A set of PowerShell scripts designed to bruteforce and map the attack surface of an Azure tenant from the outside.

Phase 1: Discovery and Reconnaissance (Unauthenticated)

In an assumed breach scenario, we typically start with a set of credentials. It is instinctual to log in immediately. Doing so without prior reconnaissance is a strategic error.

The Strategic Value of Unauthenticated Reconnaissance

Bypassing RBAC via Public DNS
The primary reason we perform unauthenticated reconnaissance is to outmaneuver the Azure Role-Based Access Control system. The credentials we possess usually belong to a low-privilege user.
If we log in and attempt to list sensitive resources, such as asking Azure to list all Storage Accounts, the Resource Manager will deny the request because our user lacks specific permissions on those objects.

However, Azure resources must have public DNS records to function on the internet. A Storage Account named secretproject for example creates a publicly resolvable DNS entry like secretproject.blob.core.windows.net. Public DNS servers do not enforce Azure permissions. By identifying these public hostnames from the outside, we effectively locate targets that our compromised user is technically forbidden from listing inside the directory. This creates a map of the infrastructure that is independent of our internal privileges.

Mapping the Identity Engine
Before logging in, we must understand the authentication flow. Knowing if a target is Managed or Federated tells us if we should focus on cloud vulnerabilities or on-premise Active Directory trusts. Detecting configurations like Seamless SSO informs us of high-value lateral movement targets before we even compromise a single machine.

Target Identification and Authentication Analysis

Our first objective is to confirm the organization uses the Microsoft Cloud and audit their authentication capabilities. We utilize both active and passive techniques to map the tenant.

Active Identification (User Realm Analysis)

We determine the unique Tenant ID and the authentication protocol by analyzing the User Realm. When a user enters their email address into a Microsoft login page, the browser sends a request to the backend API getuserrealm.srf. This API responds with instructions on how to handle that specific user.

However, every Azure tenant must have a default <tenant>.onmicrosoft.com domain. If we query nonexistent@defcorphq.onmicrosoft.com and receive a valid response containing NameSpaceType: Managed (or Federated) and a FederationBrandName, we have positively confirmed the tenant exists. This works even if the specific user "nonexistent" is invalid.
The API validates the Realm presence before checking the User identity. This allows us to brute-force Tenant Names effectively without fearing account lockouts.

When identifying a target, we must test against the immutable default domain ending in .onmicrosoft.com rather than just the company's vanity domain.

https://login.microsoftonline.com/getuserrealm.srf?login=nonexistent@defcorphq.onmicrosoft.com&xml=1

This screenshot captures a successful execution of the Target Identification technique using the "User Realm" API (getuserrealm.srf).
By forcing the output to XML (using &xml=1), you can clearly see the raw data Microsoft returns about the target domain.

1. Proof of Existence (<FederationBrandName>)

• Value: Defense Corporation

• Insight: This is the "smoking gun." Even though we requested a non-existent user (nonexistent@...), the API validated that the Domain belongs to a tenant named "Defense Corporation." If the tenant did not exist, this field would be missing or generic, and the NameSpaceType would be "Unknown." This confirms Target Identification is complete.

2. Attack Surface (<NameSpaceType>)

• Value: Managed

• Insight: This tells us the target is NOT Federated. Authentication happens directly in the cloud (Azure AD), not via an on-premise ADFS server.

• Attack Implication: We cannot use "Golden SAML" attacks here (which require Federation), but we can attempt Password Spraying because Microsoft handles the auth directly.

3. Anti-Evasion Logic (<IsFederatedNS>)

• Value: false

• Insight: This reinforces the "Managed" status. It explicitly confirms the namespace (NS) does not redirect to a third-party identity provider.

4. The Target (<DomainName>)

• Value: defcorphq.onmicrosoft.com

• Insight: This confirms you hit the immutable, default tenant address. As discussed before, attacking this address (rather than a vanity domain like .com) ensures we are querying the core Azure directory without DNS filtering or external routing confusion.

The screenshot validates the "Domain Strategy". we queried a valid domain with an invalid user, yet the API still surrendered the Organization Name ("Defense Corporation") and Security Posture ("Managed"). This is the essence of unauthenticated tenant reconnaissance.

If we query a custom domain like defcorphq.com and receive a NameSpaceType: Unknown response, it does not prove the target is offline. It simply means that specific domain is not registered or correctly federated in Azure.

https://login.microsoftonline.com/getuserrealm.srf?login=nonexistent@defcorphq.com&xml=1

This next step transitions us from manual browser checks to automated tooling using AADInternals. We are performing the exact same User Realm analysis as before but using PowerShell to parse the output cleanly for us.

We are querying the public API to build a profile of the defcorphq.onmicrosoft.com tenant. By using a randomly generated user (nonexistent@...), we ensure we are testing the Tenant's configuration, not a specific user's settings. Let’s start by importing ADDInternals module into powershell then we can make the query.

Import-Module .\AADInternals.psd1

Get-AADIntLoginInformation -UserName 'nonexistent@defcorphq.onmicrosoft.com'

Positive Tenant Identification
The Federation Brand Name returned Defense Corporation. This is the most important field during initial discovery. It proves that defcorphq.onmicrosoft.com is a valid, active tenant. If the tenant did not exist, the script would have returned an error or blank fields. We have successfully mapped the infrastructure name to a corporate identity.

Attack Surface Definition
The Account Type is Managed. This tells us that Microsoft Entra ID is handling the authentication directly. It is not passing credentials to an on-premise Active Directory Federation Services (ADFS) server. From a Red Team perspective, this closes the door on Golden SAML attacks (which require federation) but opens the door to Password Spraying and Brute Force, as there is no on-premise firewall to block our cloud login attempts.

Lateral Movement Intelligence
The Desktop Sso Enabled field is blank (False). This indicates that Seamless Single Sign-On is not enabled for this specific domain. This allows us to deprioritize searching for the AZUREADSSOACC computer account if we later breach the on-premise network, as that specific attack vector (Silver Ticket) requires Desktop SSO to be active.

User State Confirmation
The User State is 1. In the context of this API, a state of 1 often indicates "Unknown" or "Non-existent". The fact that we retrieved full tenant details (Brand Name, Domain Type) despite the user state being "Unknown" validates our strategy: We do not need valid credentials to map the high-level architecture of the target.

Enumerating SubDomains (NetSPI by MicroBurst - Permutation Scanning)

We utilize a brute-force approach called permutation scanning. We take the base name of the target and combine it with common IT nomenclature like "backup" or "dev" to generate thousands of potential FQDNs. We check these against public DNS resolvers to see if they resolve to an Azure IP address.

Storage Accounts (blob.core.windows.net)
This is the highest value target during recon. Developers often set container permissions to Public Read or Blob for convenience. Finding a valid storage account endpoint allows us to scan for publicly readable containers later in the attack chain. These often leak configuration files, backups, or hard drive images.

App Services (azurewebsites.net)
This domain hosts web applications and APIs. Discovering these allows us to map the external attack surface of the company. These apps are entry points for traditional web vulnerabilities like SQL Injection or Insecure File Uploads, which serve as our initial foothold into the network.

Cloud Services (cloudapp.net)
This is the legacy domain used for older Virtual Machines and Load Balancers. Identifying these often points to older infrastructure that may be unpatched or forgotten by the IT team.

Databases (database.windows.net)
This domain identifies public SQL endpoints. While these are usually protected by a firewall that only allows Azure IPs, finding them maps the backend of the applications we discovered earlier and gives us specific targets for future exploitation.

We use the MicroBurst PowerShell module. Specifically, the function Invoke-EnumerateAzureSubDomains. This tool takes the base name we found earlier (defcorphq) and iterates through a list of common Azure suffixes to check for valid DNS records.

Import-Module .\MicroBurst.psm1

Invoke-EnumerateAzureSubDomains -Base 'defcorphq' -Verbose

The screenshot reveals three critical components of the defcorphq infrastructure.

1. Identity and Tenant Root
The result defcorphq.onmicrosoft.com validates our findings from Phase 1. This confirms the core tenant name is locked. This domain is the root of trust for all their cloud identities.

2. Email Infrastructure (Exchange Online)
The result defcorphq.mail.protection.outlook.com is highly significant. This DNS record exists solely for routing incoming email. Its presence confirms that defcorphq uses Exchange Online (Office 365) for their email handling.
From a Red Team perspective, this validates that Phishing is a viable entry vector. We know their email is hosted by Microsoft, not an on-premise Exchange server or Google Workspace.

3. Collaboration Infrastructure (SharePoint)
The results defcorphq.sharepoint.com and defcorphq-my.sharepoint.com confirm the organization uses SharePoint Online.
The -my.sharepoint.com domain is particularly interesting. This is the root domain for OneDrive for Business. Every user's personal file storage lives as a subdomain under this URL. Confirming this exists validates the OneDrive Personal Site Analysis technique we discussed in the "Validating User Targets" section. We now know that if we valid users, we can find their personal file silos.

What We Are Still Hunting For
While the screenshot confirms the SaaS (Software as a Service) elements like Email and SharePoint, an attacker is often looking for PaaS (Platform as a Service) resources.
We should continue to look for:

• defcorphq.blob.core.windows.net (Azure Storage Accounts)

• defcorphq.azurewebsites.net (Azure App Services)

• defcorphq.database.windows.net (Azure SQL Databases)

Finding these specific PaaS domains is critical because they often suffer from misconfigurations like anonymous public read access, which allows us to steal data without any credentials at all.

Since we should not rely on one single tools, we also have AADInternals.psd1 by Nestori Syynimaa, which basically contains lots of well-Known APIs that belong to microsoft, and sometimes we may end up finding few more domains that belong to our target as well.

Import-Module .\AADInternals.psd1

Invoke-AADIntReconAsOutsider -DomainName 'defcorphq.onmicrosoft.com' | Format-Table

Enumerating the Tenant ID

While finding the domain name (defcorphq.onmicrosoft.com) is useful, the Tenant ID is the most critical technical artifact you need for attacks involving APIs.

The Tenant ID is a Globally Unique Identifier (GUID). It serves as the primary key for the target's environment within the massive Azure ecosystem. Almost every tool you use later including Evilginx, ROADTools, and raw Azure CLI commands will eventually require you to specify --tenant <GUID> to ensure your packets reach the correct victim. It functions exactly like an IP address, but for the identity layer.

Method A: The Specialized Cmdlet (AADInternals)
We used AADInternals earlier to get the realm status. It also has a specific function dedicated to resolving a domain name into a Tenant ID.

Get-AADIntTenantID -Domain defcorphq.onmicrosoft.com

This command performs a quick lookup against the public identity APIs and returns the raw GUID. This is often faster and cleaner than parsing a large JSON blob manually.

Method B: OpenID Configuration Extraction
By browsing to the standardized URL https://login.microsoftonline.com/<TARGET_DOMAIN>/.well-known/openid-configuration, we can retrieve a object containing the authorization endpoints.

https://login.microsoftonline.com/defcorphq.onmicrosoft.com/.well-known/openid-configuration

A successful HTTP 200 response here confirms the tenant is active and its Tenant ID. When you visit this URL, look for the endpoint named token_endpoint. The structure of this URL is standardized:
https://login.microsoftonline.com/<TENANT-ID-GUID>/oauth2/token

The long hexadecimal string sitting between microsoftonline.com/ and /oauth2 is the Tenant ID. This value allows you to interact directly with the tenant's authentication gateway, even if you are pretending to be an external application requesting a token.

Enumerating Users Unauthenticated

Attacking invalid email addresses creates failed login logs that alert the Blue Team without generating any value. We must refine our raw list of employees gathered from OSINT into a verified list of valid targets using methods that rely on server response discrepancies.

Method A: Using AADInternals

We can keep our workflow entirely within PowerShell by using the Invoke-AADIntUserEnumerationAsOutsider cmdlet from the AADInternals suite. This function performs the exact same checks against the GetCredentialType API as python scripts like o365creeper, but allows us to pipe data directly from file lists.

The -Method 'Normal' switch tells the tool to simulate the standard login flow. It sends the User Principal Name (email) to Microsoft and interprets the If Exists Result in the JSON response.

Analysis of Results

The output gives us a binary True or False status for every email in our list.

• True confirms the API accepted the username and is waiting for a password or federation redirect. These are valid accounts inside the directory and
  are now primary targets for Phase 2.

• False confirms the user is not found in the directory. We immediately discard these to avoid generating noise or failed login events for accounts
  that do not exist.

So, Assuming that by doing an OSINT we were able to find a list of some valid users like the ones below, we will be able to check if those are valid users inside Entra ID or not.

admin@defcorphq.onmicrosoft.com
root@defcorphq.onmicrosoft.com
test@defcorphq.onmicrosoft.com
contact@defcorphq.onmicrosoft.com

Get-Content .\emails.txt | Invoke-AADIntUserEnumerationAsOutsider -Method 'Normal'

It is possible to find out that we do have 2 valid users inside this Entra ID, which are Admin and test.

Method B: Login Portal Discrepancies

This technique leverages the GetCredentialType API endpoint used during the login process. When we send a POST request containing a username to this API, the server responds differently depending on the validity of the user.

• Valid User: The server responds with a state of 0 asking for the password or redirection.

• Invalid User: The server returns an error state indicating the user was not found in the directory.

We use the tool o365creeper-ng to automate this check against our user list.

Method C: OneDrive Personal Site Analysis

This is a high-fidelity stealth technique derived from the behavior of SharePoint. When an enterprise user is provisioned, Microsoft creates a specific personal OneDrive URL for them based on their Principal Name. The structure follows the pattern https://<tenant>-my.sharepoint.com/personal/<user_email_structure>.

We send HTTP HEAD requests to these predicted URLs. The server HTTP response code reveals the existence of the user.

• 404 Not Found indicates the user likely does not exist or has not been licensed for storage.

• 403 Forbidden / 401 Unauthorized is the positive result we want. This error confirms the resource exists and belongs to a valid user, but we simply lack permission to access it. This validates the identity without touching the primary login portal.

Method D: Teams Availability Search

We can validate users via Microsoft Teams if we control a valid personal Microsoft account. By initiating a search or chat attempt within the Teams interface for a target email address, the API attempts to resolve that user against the global directory. If the target organization permits external collaboration, which is a default setting, Teams will resolve the email address to a Full Name and potentially a profile picture.