🔍 Finding Azure Services and Vulnerabilities (Unauthenticated)

As a cloud penetration tester, your assessment may begin with zero access to the Azure tenant no credentials, no tokens, no insider knowledge. In such cases, your job is to discover, fingerprint, and exploit public facing Azure assets in scope.

From bug bounty targets to shadow IT discovery, anonymous Azure service enumeration can reveal misconfigured services, leaked data, or even paths to initial compromise.

⚠️ Microsoft’s Penetration Testing Rules of Engagement

Since June 2017, Microsoft has eliminated the need for pre approval to perform penetration tests against Azure resources you own or control. However, strict boundaries still apply.

📘 Microsoft Penetration Testing Guidance

❌ Activities That Are Prohibited

• Scanning assets that belong to other Azure customers
• Accessing any data not owned by you
• Denial of service (DoS) testing
• Phishing or social engineering attacks against Microsoft employees

🚨 Violating these rules may result in account suspension, legal action, or financial liability.

✅ Activities That Are Allowed

• Scanning your own Azure endpoints for vulnerabilities
• Performing port scans or fuzzing against your apps or APIs
• Testing public cloud services and configurations hosted in your subscription

🧾 Common Azure Pentesting Scenarios

Depending on your organization or client, Azure pentesting may include various types of testing. Defining scope and objectives in writing is critical to avoid unauthorized activity.

Typical Azure Testing Scopes:

🧠 Tip: Azure pentests are often hybrid combining multiple scopes. Always confirm in writing which methods are approved.

🕵️ Unauthenticated Enumeration

AADInternals Tool

📘 AADInternals

Install

1Install-Module AADInternals
2Import-Module AADInternals

Query all the information of an Azure tenant

1Invoke-AADIntReconAsOutsider -DomainName corp.onmicrosoft.com | Format-Table

Get Tenant ID

1Get-AADIntTenantID -Domain cybercheckpentest.onmicrosoft.com

Get All domains of the Tenant

1Get-AADIntTenantDomains -Domain cybercheckpentest.onmicrosoft.com

Get OpenID configuration

1Get-AADIntOpenIDConfiguration -Domain cybercheckpentest.onmicrosoft.com

Check if the user exists or not

1Invoke-AADIntUserEnumerationAsOutsider -UserName user@company.com

Get info about a user

1Get-AADIntLoginInformation -UserName root@corp.onmicrosoft.com

Check if users exist using a list

1Get-Content .\users.txt | Invoke-AADIntUserEnumerationAsOutsider

🌐 Azure Public IP Address Ranges

Like other public cloud providers, Microsoft Azure enables organizations to assign internet accessible IP addresses to cloud hosted services.

These public IPs are often the first line of attack surface exposed to the internet and, therefore, a prime target for reconnaissance during external pentesting.

What Resources Use Public IPs?

Azure public IPs can be attached to many infrastructure services, including:

• 🖥️ Virtual machine network interfaces
• 🌐 Internet facing load balancers
• 🔐 VPN gateways
• 🛡️ Application gateways
• 🔥 Azure Firewall instances

Depending on the resource type and configuration, the IP can be either:

🎯 Why Public IPs Matter in Pentesting

As a pentester, identifying public IPs allocated to the organization’s Azure tenant is critical to mapping the IaaS attack surface. These addresses could expose:

• Remote desktop or SSH interfaces
• Open ports on misconfigured VMs
• Unprotected application front ends
• Forgotten test environments

✅ Ethical Scanning in Engagements

When operating within a legal engagement, always request the list of public IPs from the organization. This avoids scanning unrelated Azure customers.

🔧 How to Collect IPs with Azure CLI:

1az network public-ip list --query '[].[name, ipAddress,
2publicIpAllocationMethod]' -o table

🔧 How to Collect IPs with az PowerShell module :

1Get-AzPublicIpAddress | Select
2Name,IpAddress,PublicIpAllocationMethod

⚠️ Important: Dynamic IPs can change. To avoid scanning the wrong tenant, consider targeting DNS hostnames instead, which update automatically with IP changes.

🧠 Attack Surface Enumeration with Public Data

Even without access to a tenant, adversaries can still use public data to map Azure’s global IP footprint.

📦 Microsoft Azure Public IP JSON File

Azure publishes a weekly updated JSON file listing all IPv4 and IPv6 ranges used by Azure services across regions:

📘 Download link:

Downlaod the file

1Invoke-WebRequest <json_url> -O azure_ip_range.json

Filter IP Address for a region

1$jsonData = gc .azure_ip_range.json | ConvertFrom-Json
2($jsonData | select -ExpandProperty values | where name
3-EQ AzureCloud.uksouth).properties.addressPrefixes

Filter all the services in the region

1($jsonData | select -ExpandProperty values | where name
2-EQ AppService.UKSouth).properties.addressPrefixes

Scan with Nmap or Masscan

1nmap -Pn -p 80,443 -iL azure-ips.txt -oA azure-scan

🌐 DNS Based Enumeration of Azure Services

One of the most effective ways to anonymously discover Azure hosted services is through DNS enumeration. Many Azure services expose public endpoints that follow predictable naming conventions using Microsoft owned DNS suffixes.

This approach is particularly useful for:

• 🔍 Identifying shadow IT or misconfigured services
• 🧪 Conducting external assessments and bug bounty recon
• 🎯 Pinpointing tenant specific assets (without authentication)

🏷️ How Azure DNS Naming Works

When a customer creates a public facing Azure resource, the platform automatically assigns a subdomain under a known Microsoft-owned DNS suffix.

📘 Format:

1<resource-name>.<service-dns-suffix>

📦 Example

If a customer creates a blob storage account named azurepentesting, the resulting FQDN would be

1azurepentesting.blob.core.windows.net

🌍 Global vs Regional DNS Suffixes

Some services use region specific suffixes, while others are global.

🔎 Why This Matters for Pentesters

Understanding DNS naming patterns allows you to enumerate deployed Azure services anonymously and systematically. Once found, these endpoints can be checked for

• Open access controls (e.g., anonymous blob reads)
• Debug consoles (e.g., Kudu)
• Expired but still resolvable subdomains
• Potential for subdomain takeovers

🧰 DNS Enumeration Methodology

Here’s a typical workflow for external Azure DNS reconnaissance

🔹 1. Define Base Terms

Start with known or likely naming patterns tied to the organization.

1Examples: packt, azurepentesting, azurept, contoso

🔹 2. Generate Permutations Expand the base terms with common environment prefixes and suffixes

1Examples: packt-prod, azurept-dev, contoso-qa, azurepentesting-stage

Use automated tools or wordlists to generate hundreds of permutations quickly.

🔹 3. Resolve DNS with Azure Specific Tools

Use tools like MicroBurst, which are purpose built for Azure.

🎯 Why MicroBurst?

• Automatically knows all common Azure DNS suffixes
• Supports brute force and targeted enumeration
• Avoids manual suffix management

🔗 MicroBurst:

Download MicroBurst

1git clone https://github.com/NetSPI/MicroBurst.git

Import the MicroBurst module into your PowerShell session

1cd .MicroBurst &&
2Import-Module .\MicroBurst.psm1

Use the Invoke-EnumerateAzureSubDomains function to identify potential targets that have a base name of azurepentesting

1Invoke-EnumerateAzureSubDomains -Base azurepentesting

🧾 Custom Domains and IP Ownership in Azure

Not every Azure hosted service looks like it belongs to Azure. Many organizations use custom domains or transparent proxies that mask their cloud origin either for branding or obfuscation.

As a penetration tester, identifying the true origin of your target infrastructure is essential to

• 🎯 Define the accurate scope of your engagement
• 🔍 Uncover hidden Azure assets
• 🛡️ Avoid impacting unrelated environments

🕵️ Why This Matters

Let’s say you’re authorized to test only

• app.example.com
• IP: 20.84.204.10

On the surface, it’s unclear whether this is hosted on

• Azure?
• AWS?
• A self hosted data center?

If this resolves to a Microsoft owned IP range, it changes your targeting strategy. You may now be dealing with Azure App Services, Azure CDN, or a virtual machine behind a proxy.

💡 Knowing the underlying platform helps guide fingerprinting, exploitation, and post access techniques.

🌐 Custom Domains in Azure

Azure supports custom DNS mappings for many services, such as

These services often hide Azure DNS suffixes (e.g., azurewebsites.net) behind a vanity domain like login.mybrand.com.

🧪 Verifying Azure IP Ownership

When you're dealing with IP addresses or domains and want to confirm whether they belong to Azure, use one of the following tools.

🧰 Tool 1: Cloud IP Checker (Go)

Cloud IP Checker is a fast, Go based tool for verifying IP addresses against the official Microsoft IP ranges and Service Tags.

📦 Features:

• Compares IPs to Azure’s weekly published JSON file
• Shows matching service, region, and range
• Can be run locally or deployed as a REST API

🔗 GitHub: Cloud IP Checker

🧰 Tool 2: AzureIPCheck (Python)

AzureIPCheck is a Python alternative that supports

• Local JSON parsing of Azure IPs
• Manual or bulk IP lookup
• Easy script integration

🔗 GitHub: AzureIPCheck

🧪 Example Workflow

1. Get your list of target IPs/domains.
2. Resolve domains to IPs using tools like dig, nslookup, or massdns.
3. Run IPs through Cloud IP Checker or AzureIPCheck.
4. Identify which targets are on Azure infrastructure.
5. Adjust enumeration and exploitation techniques accordingly.

🧠 Pentest Insight

• Custom domain? Check underlying A records and CNAME chains.
• IP not owned by target? You may be out of scope or dealing with shared cloud infra.
• Azure-verified? Now you can map likely service type and pivot accordingly (e.g., blob storage, App Service, VM).

⚠️ Always confirm scope boundaries with stakeholders when you discover unexpected cloud infrastructure behind custom domains.

🔐 Identifying Vulnerabilities in Public Facing Azure Services

Once you’ve mapped out your anonymous Azure attack surface and validated scope with the asset owner, you’re ready to start probing for vulnerabilities.

In Azure environments, public facing weaknesses generally fall into three primary categories

1. ⚙️ Misconfigurations
2. 🧰 Missing patches
3. 🧑‍💻 Vulnerable application code

⚠️ Configuration Related Vulnerabilities

These issues are often caused by human error and poor defaults. Misconfigured Azure services can expose

• Sensitive files and logs
• Internal applications or VMs
• Access control flaws

🖥️ IaaS (Infrastructure as a Service) Misconfigurations

Azure IaaS includes services like

• Virtual Machines (VMs)
• Virtual Machine Scale Sets
• Windows Virtual Desktop (WVD)

These services often expose management interfaces such as RDP (3389) or SSH (22) via public IP addresses.

🔎 What to Look For

• Weak or default credentials on public facing ports
• Forgotten dev/test environments left online
• Exposed applications on HTTP/HTTPS (e.g., admin panels, old versions)

🧪 Enumeration Workflow

1. Obtain the organization’s IP list (via Azure CLI or PowerShell).
2. Use Nmap, Masscan, or RustScan to fingerprint hosts and open ports.
3. Attempt authentication brute force or credential stuffing (if in scope).

⚠️ Always verify IP ownership and get written authorization before scanning!

🧱 PaaS (Platform as a Service) Misconfigurations

PaaS services like Azure Blob Storage, Web Apps, or Key Vaults are often internet accessible by design. Misconfigurations here can lead to anonymous access or data exposure.

💾 Azure Storage Accounts: Blob Service Vulnerabilities

🔐 Note: Only Blob storage supports full anonymous access. Others require authentication.

📂 Blob Storage Structure

• Storage Account: Top-level namespace (e.g., azurepentesting)
• Container: Like a folder (e.g., public, files, uploads)
• Object: The actual file (e.g., README.txt, report123.pdf)

🌐 Public Access Permission Levels

📜 Listing Container Contents (Unauthenticated)

If the container has Container level access, you can list all blobs using

1https://azurepentesting.blob.core.windows.net/public/?restype=container&comp=list

This will return an XML response with blob names and timestamps.

🧰 Container Guessing

If you don’t know the container name

• Use wordlists and tools like Gobuster or MicroBurst to guess container names
• Check access permissions by appending ?restype=container&comp=list
• Look for containers with open listings

1gobuster dir -u https://azurepentesting.blob.core.windows.net/ -w containers.txt -q -e -k

🕵️ IDOR in Blob URLs

Some applications store user files using predictable filenames (e.g., invoice-001.pdf, invoice-002.pdf).

This can be exploited using

• Sequential brute force
• Guessing based on naming patterns

📘 Learn more

Use MicroBurst

use the Invoke-EnumerateAzureBlobs script to access data in a misconfigured Azure Blob storage service.

1Invoke-EnumerateAzureBlobs -Base azurepentesting

download the contents of the objects

1Invoke-WebRequest -Uri "https://azurepentesting.blob.core.windows.net/private/credentials.txt" -OutFile "credentials.txt"

Use a custom list

1Invoke-EnumerateAzureBlobs -Base azurepentesting -Folders .customcontainername.txt

🧭 Summary

Identifying and exploiting misconfigurations in Azure services is often low effort, high impact, especially when public access is misapplied

🔑 Finding Azure Credentials

While misconfigured services are an effective way to gain access to Azure environments, the most common real world method is far simpler: using valid credentials.

In penetration tests, red team engagements, and even real-world breaches, attackers routinely gain access to Azure tenants by:

• Guessing weak passwords
• Reusing leaked credentials from past breaches
• Exploiting poor identity hygiene

🧩 Step 1: Guessing Azure AD Credentials

Despite modern security features, weak and default passwords are still widespread in the enterprise.

📘 Common Issues:

• Poor password policies
• Reused passwords across systems
• Users who choose seasonal or easily guessable phrases (e.g., Winter2024!, Company@123)

Even organizations that enforce complexity and expiration rules can still fall victim to predictable password patterns.

👥 Step 2: Building a Username List

To guess credentials, you’ll first need valid usernames often in email address format:

1<firstname>.<lastname>@company.com  
2<firstinitial><lastname>@company.com  
3<first>.<last_initial>@domain.com

🛠️ How to Gather Usernames

• 🔎 Public company websites and support pages
• 🔗 LinkedIn profiles (name and title matching)
• 💻 GitHub commits and open source repositories
• 📂 Past data breaches (e.g., via HaveIBeenPwned, DeHashed)

Use known formats and user naming conventions to generate a list of likely usernames.

🔐 Step 3: Building a Password List

Use targeted or generic password lists, keeping policy requirements in mind (length, complexity, rotation)

🎯 Common Lists:

• 📘 PwnedPasswordsTop100k
• 🔒 RockYou.tx
• 🧠 Custom seasonal/company themed patterns (e.g., Contoso2024!, Fall2023@)

🎯 Choosing a Password Guessing Strategy

Different strategies work better in different contexts. You should always tailor your approach to avoid account lockouts and maintain stealth.

💥 Brute Force Attack

Target one or a few usernames, cycling through many passwords.

• 🛑 Risk of account lockout
• 💡 Limit guesses (e.g., 3 attempts) to avoid triggering Azure AD lockout policies

🚿 Password Spray Attack

Try one password across many usernames, slowly and stealthily

• 🧠 Effective against large orgs with poor password hygiene
• 🚫 Often blocked after multiple bad attempts from the same IP

💡 Tip: Distribute attempts across IP addresses to bypass smart lockout protections.

🧰 Introducing: MSOLSpray

MSOLSpray is a PowerShell based password spraying tool built specifically for Microsoft Online services (Azure AD, Office 365).

✅ Features

• Validates credentials
• Detects:
  • ❌ Invalid accounts
  • 🔒 Locked/disabled accounts
  • 🔑 Password expiration
  • 🛡️ MFA status

🔗 MSOLSpray

Download MSOLSpray

1git clone https://github.com/dafthack/MSOLSpray.git

Import the MSOLSpray module into your PowerShell session

1cd .MSOLSpray && 
2Import-Module .\MSOLSpray.ps1

Run MSOLSpray against the user accounts

1Invoke-MSOLSpray -UserList .\userlist.txt -Password Password123

⚠️ Ethical Guidance for Credential Attacks

Credential attacks can easily violate your scope or policies if done incorrectly

Always:

• Get written authorization
• Confirm lockout thresholds and policies
• Coordinate with the Azure security or IAM team
• Limit guesses and delay between attempts
• Never guess credentials for Microsoft employee domains

📘 Microsoft’s own protections like Smart Lockout, Identity Protection, and Defender for Identity will trigger alerts and lockouts if abuse is detected.

🛡️ Conditional Access Policies and MFA Bypasses

Modern Azure AD environments often rely on Conditional Access (CA) policies to control access to Microsoft cloud services. These policies act as identity firewalls, blocking access unless certain conditions such as location, device type, or MFA are met.

However, even strong identity controls can be circumvented, especially when legacy protocols or misconfigured exceptions are present.

🧠 What Is Conditional Access?

Conditional Access policies allow admins to enforce identity driven controls based on:

• User risk level
• Device platform (e.g., Android, iOS)
• Location or IP address
• App type or protocol
• Sign in behavior

⚠️ Bypassing Conditional Access in the Wild

Despite their strength, Conditional Access policies are not bulletproof. Pentesters have repeatedly observed

• Misconfigured CA exclusions
• Legacy authentication protocols bypassing MFA
• Mobile device exceptions exploited using spoofed user agents
• Admins disabling CA or MFA during help desk troubleshooting

These gaps offer attackers a foothold into the Azure AD tenant, even with MFA in place.

🧰 Tool: MFASweep

🔗 MFASweep is a PowerShell based tool designed to identify which Microsoft services are not enforcing MFA or Conditional Access for a set of user credentials.

✅ What MFASweep Tests

Download MFASweep

1git clone https://github.com/dafthack/MFASweep.git

Import the MFASweep

1cd  MFASweep && 
2Import-Module .\MFASweep.ps1

Run MFASweep against any compromised user accounts

1Invoke-MFASweep -Username johnra@azurepentesting.com -Password Password123

🧭 Summary

Even in modern Azure tenants with Conditional Access and MFA:

• 🧱 Misconfigured exceptions and outdated protocols remain exploitable
• 🎯 MFASweep is a valuable tool for identifying these weak spots
• 🛡️ Always test responsibly, with written approval and clear scope boundaries