Anonymous service identification in Azure

Previous Section

Azure public IP address ranges

• Microsoft Azure, like other public cloud providers, enables the assignment of internet-accessible IP addresses to Azure resources
• Public IP addresses can be allocated to various Azure resources, including virtual machine network interfaces, internet-facing load balancers, VPN gateways, application gateways, and Azure firewall instances
• Public IP addresses can be categorized as either static or dynamic
• Dynamic public IP addresses have the potential to change during the lifespan of the Azure resource to which they are assigned
• Static public IP addresses, on the other hand, remain constant throughout the lifespan of the Azure resource
• The allocation of public IP addresses provides organizations with the means to establish internet connectivity and enable external access to their Azure resources

• As an Azure penetration tester, your objective is to discover resources within an organization’s Azure Infrastructure-as-a-Service (IaaS) environment and assess their attack surface area
• Scanning the allocated public IP addresses of the Azure environment from the internet is a common method to identify these resources
• For an authorized engagement, the organization should provide you with a list of the current allocated public IP addresses in their Azure subscriptions to ensure you only target their resources and avoid impacting other Azure customers
• To obtain the list of allocated public IP addresses using Azure CLI.

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

• To obtain the list of allocated public IP addresses using Az PowerShell module

Get-AzPublicIpAddress | Select Name,IpAddress,PublicIpAllocationMethod

• It is important to note that dynamically allocated public IP addresses can change over time, so they may no longer be assigned to the organization you are testing. In such cases, targeting DNS host names is recommended, as they will automatically update with the new IP addresses.
• Performing public IP scans immediately after gathering the IP addresses is advised to ensure the accuracy of the results.
• External adversaries often discover Azure targets by leveraging publicly available information. The Microsoft Azure network team publishes a JSON file containing public IP address ranges for all Azure regions and public services. This file is updated weekly with new ranges. Adversaries may obtain and parse this list using tools like JQ, and then perform scans using tools like Nmap to identify the attack surface area.
• In the upcoming exercises, we will simulate the process of anonymously discovering Azure targets using publicly available information, allowing you to learn and understand the techniques involved.

Microsoft strongly discourages scanning public IP ranges that are not allocated to your Azure subscription, or that you do not have the authorization of the owner to scan. The next exercise is for educational purposes only. Do not scan the addresses without the written legal permission of the assigned owner!

Parsing Azure public IP addresses using PowerShell

• Within your pentest VM, open a web browser and browse to https://www.microsoft.com/en-us/download/details.aspx?id=56519 (you can also use this shortened URL: http://bit.ly/azureipranges).
• Click on the Download button to obtain the current list of Azure public IP address ranges. This will download a JSON file that contains a list of the public IP address ranges by region and by service.
• In the window that is displayed, right-click on click here to download manually, and then click on Copy link address to obtain the URL to the JSON file.
• In the PowerShell console of your pentest VM, download the JSON file using the following commands. Replace <json_url> with the URL that you obtained.

cd C:\Users\$env:USERNAME\ Invoke-WebRequest -O azure_ip_range.json

• For example, we will use PowerShell to filter the public IP address ranges for all the services in the Azure UK South region. This will return a list of IP ranges that an attacker could scan to determine the open ports and the listening services on those ports.

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

• Next, try filtering the public IP address ranges used by a specific service (Azure App Service instances) in the UK South region. An attacker could obtain these IP ranges and scan them for web application vulnerabilities, as Azure App Service resources are typically used to host web applications and APIs.

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

• An attacker could obtain the IP ranges and scan them for open ports and listening services to understand the attack surface area. Using the examples in Steps 5 and 6, try out other queries to identify the public IP ranges for other Azure services and regions.

To “just make things work,” some Azure administrators/engineers may open up wide ranges of IPs that have been assigned to different Azure regions to allow virtual machines to communicate. This may also allow you to reach those same systems from a VM in the right region. If you have authenticated access to the Azure environment, keep an eye out for Azure IP ranges in the network security group rules that you may be able to take advantage of.

Azure platform DNS suffixes

• Many Azure platform services utilize public DNS suffixes owned and managed by Microsoft.
• When an Azure customer creates a resource instance, it is assigned a subdomain of the associated DNS suffix in the format of <resource instance name>.<service dns suffix name>.
• For example, the public DNS suffix for Azure Blob storage service is blob.core.windows.net. If a storage account named azurepentesting is created, the fully qualified domain name (FQDN) of that instance will be azurepentesting.blob.core.windows.net.
• It is important to note that some DNS suffixes are regional, while others are global.
• Regional DNS suffixes follow the format <dns label>.<region>.cloudapp.azure.com.
• For example, if a public IP resource is created with an associated DNS label in the Azure UK South region, the FQDN of that resource will be <dns label>.uksouth.cloudapp.azure.com.
• Understanding the FQDN structure helps in identifying and accessing Azure resources.

Commonly found DNS domains and their associated services:

To anonymously enumerate platform services in Azure:

1. Determine base-word search terms to work with. This will usually be linked with the name of the Azure customer that you are engaged with or known terms that are associated with the organization; for example, packt, azurepentesting, azurept, and so on.
2. Create permutations on the base words to identify potential subdomain names; for example, packt-prod, packt-dev, azurepentesting-stage, azurept-qa, and so on.
3. Enumerate subdomains that match these permutations using a tool such as MicroBurst, Gobuster, or DNSscan.

Using MicroBurst to enumerate PaaS services

• Start a Powershell with admin privileges.
• Download MicroBurst:

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

• Import the MicroBurst module into your PowerShell session with the following commands:

cd .\MicroBurst\

Import-Module .\MicroBurst.psm1

• The MicroBurst toolkit will import different PowerShell functions depending on which PowerShell modules you have installed on your system.
• Use the Invoke-EnumerateAzureSubDomains function to identify potential targets that have a base name of azurepentesting.

Invoke-EnumerateAzureSubDomains -Base azurepentesting

Custom domains and IP ownership

• Azure services provide the option for customers to use custom domains.
• Some hosts may have redirects or transparent proxies configured to conceal the fact that the services are hosted in Azure.
• During penetration testing, it is crucial to accurately determine the location of your targets, as it can significantly impact the scope of your assessment.
• For example, your authorized external penetration test scope may include specific IP addresses and hostnames within a given environment. If these targets are hosted in Azure, it will affect the approach you take when attacking those particular resources.
• Understanding the hosting environment, including any custom domains or obfuscation techniques, is essential for effective targeting and testing.

Cloud IP Checker

• Cloud IP Checker is a tool written in Go that allows you to check IP addresses against the published Azure IP ranges and service tags.
• When an IP address matches a published range, the tool provides information about the corresponding Azure service and its region.
• The tool can be used as a published API or self-hosted to suit your needs.
• Another tool that offers similar functionality is AzureIPCheck, developed by Leron Gray. It is a Python-based tool and can be found on GitHub at https://github.com/daddycocoaman/azureipcheck.
• Both tools provide valuable capabilities for verifying IP addresses against Azure’s published ranges and can assist in identifying Azure services associated with specific IPs.

Invoke-WebRequest https://cloudipchecker.azurewebsites.net/api/servicetags/manual?ip= -UseBasicParsing | Select-Object -ExpandProperty Content

Subdomain takeovers

• Subdomain takeovers are an important consideration when discussing Azure platform DNS enumeration.
• In some cases, when applications hosted in Azure are reconfigured or content sources are changed, the initial Azure endpoints and associated DNS records may not be properly cleaned up.
• This can result in requests going out to non-existent Azure subdomains.
• Attackers can potentially exploit this situation by recreating the affected resource in Azure and claiming the subdomain.
• By delivering content through the affected website, attackers can achieve various malicious outcomes such as site defacement, stored cross-site scripting (XSS), or redirects to malicious content.
• Subdomain takeovers are commonly observed in bug bounties and can have significant impacts on the security of public-facing systems.
• Azure Blob, CDN, Traffic Manager, and App Services are some of the frequently vulnerable services when it comes to subdomain takeovers, although other services with a public DNS suffix can also be affected.
• Understanding subdomain takeovers is crucial for identifying vulnerabilities in custom domain setups within Azure and assessing their potential risks.

Next Section