Skip to main content

Conditional Access Bypass

ATT&CK: T1556 — Modify Authentication Process, T1078 — Valid Accounts

Conditional Access (CA) policies are Entra ID's primary enforcement mechanism. Bypassing them allows attackers to authenticate without MFA, from non-compliant devices, or from any location — even when policies appear to require otherwise.

How Conditional Access Works (and Where It Fails)​

CA policies consist of:

  • Conditions: Who (users/groups), What (apps), Where (IP/location), Which device (compliance), What risk (sign-in/user risk)
  • Grant controls: Require MFA, require compliant device, require hybrid join, etc.
  • Session controls: Limit token lifetime, require app protection policy, etc.

Bypass is possible when:

  1. A condition is not covered (gap in the policy)
  2. A protocol is excluded (legacy auth)
  3. A trusted IP/location is too broad
  4. Device compliance can be spoofed
  5. The policy has misconfigured exclusions

Bypass Technique 1: Legacy Authentication Protocols​

The most common and highest-impact bypass. Legacy protocols (SMTP, IMAP, POP3, Exchange ActiveSync, Basic Auth) do not support modern authentication flows and cannot be challenged by MFA.

If BasicAuthProtocols (SMTP,IMAP,POP3,EAS,AutoDiscover) are not blocked:
  → Attacker uses stolen credentials to authenticate via SMTP/IMAP
  → MFA is never triggered
  → CA policies don't apply (legacy auth endpoints bypass CA evaluation)

Testing for Legacy Auth​

# Test IMAP basic auth
curl -v --url "imaps://outlook.office365.com:993" \
  --user "user@domain.com:password" \
  --request "CAPABILITY"

# Test SMTP basic auth  
swaks --to test@domain.com --from attacker@attacker.com \
  --server smtp.office365.com --port 587 \
  --auth LOGIN --auth-user "user@domain.com" --auth-password "password"

# Spray via IMAP
python3 ruler.py spray --hostname autodiscover.domain.com --users users.txt --passwords passwords.txt

Fix​

Block legacy authentication with a CA policy:

  • Condition: Client apps = Exchange ActiveSync clients + Other clients
  • Grant: Block access

Detection​

// Entra - detect legacy auth sign-ins
SigninLogs
| where ClientAppUsed in ("Exchange ActiveSync", "IMAP4", "MAPI Over HTTP", "SMTP", "POP3", "Other clients")
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, ClientAppUsed, IPAddress

Bypass Technique 2: CA Policy Gap — Excluded Users/Groups​

A common misconfiguration: break-glass accounts or service accounts are excluded from MFA policies.

Policy: "Require MFA for all users"
Exclusions: "Break-glass accounts" group, "SVC_automation" group

If attacker compromises any excluded account:
→ MFA is never required
→ CA policy satisfied by exclusion

Common Exclusion Targets​

  • Break-glass/emergency access accounts (often have permanent Global Admin)
  • Legacy service accounts added to exclusions to avoid breaking automation
  • External/guest accounts excluded from device compliance requirements
// Find which accounts are excluded from which CA policies
// (via Entra ID Audit Logs or Graph API)
// The Graph API endpoint:
// GET /identity/conditionalAccess/policies
// Look for excludeGroups, excludeUsers, excludeRoles in each policy

Bypass Technique 3: Trusted Named Location Abuse​

If a VPN IP range, office CIDR, or partner network is listed as a trusted location:

Policy: "Require MFA from untrusted locations"
Trusted location: "Corporate VPN: 203.0.113.0/24"

If attacker can route through that IP range:
→ Sign-in comes from "trusted location"
→ MFA not required

Attackers who have compromised on-prem infrastructure (which routes through corporate IPs) can use this to avoid MFA challenges.

Bypass Technique 4: Device Compliance Spoofing​

Policies requiring "Compliant device" check device compliance status in Intune. Bypass methods:

  1. Entra Hybrid Join without Intune compliance — A device that is hybrid-joined but not Intune-enrolled may satisfy Hybrid Azure AD joined condition without being managed
  2. Device registration from attacker machine — If Users may register devices is not restricted, attacker registers a VM as a device
  3. Compliance policy gaps — If Intune compliance policies have weak baselines (e.g., password required = yes, nothing else)
# Register a new device in Entra ID (if not restricted)
dsregcmd /status  # Check current device state
# Joining from a non-managed VM to satisfy hybrid join requirement

Bypass Technique 5: Token / Session Replay​

Steal an already-authenticated session token (post-MFA) and replay it. This is AiTM phishing scope — CA is satisfied at the point of authentication; the stolen cookie bypasses subsequent CA evaluation.

See AiTM Phishing.

Bypass Technique 6: CAP Misconfiguration — Wrong App Target​

Policy: "Require MFA for Microsoft 365"
Condition: App = "Office 365 Exchange Online"

But if the policy doesn't cover:
- "All apps" or
- Doesn't explicitly include Graph API / SharePoint / Teams

→ Attacker calls Graph API directly with credentials
→ No MFA required for that endpoint

Always set CA policies to target All Apps with specific exclusions, not a list of included apps.

Bypass Technique 7: Authentication Context Not Implemented​

Authentication Context (Auth Context) allows requiring step-up auth for sensitive operations. If not implemented for privileged operations (e.g., accessing PIM, admin portals), users with expired MFA claims can still access sensitive resources.

Comprehensive CA Assessment​

# ROADtools - dump all CA policies and analyze coverage
python3 roadtx.py gettokens -u user@domain.com -p password
python3 roadtx.py cawhat --token-file tokens.json

# MFASweep - test what's protected by MFA
Import-Module .\MFASweep.ps1
Invoke-MFASweep -Username user@domain.com -Password P@ssword

Detection​

// Legacy auth bypasses
SigninLogs
| where ClientAppUsed !in ("Browser", "Mobile Apps and Desktop clients")
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, ClientAppUsed

// Successful auth that explicitly skipped CA due to exclusion
SigninLogs
| where ConditionalAccessStatus == "notApplied"
| where UserPrincipalName in (sensitive_account_list)
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress

// Sign-in from trusted location with unusual behavior post-auth
SigninLogs
| where NetworkLocationDetails has "trustedNamedLocation"
| where ResultType == 0
| join kind=inner (
    AuditLogs | where TimeGenerated > ago(1h) | where OperationName has_any ("Reset password", "Delete user", "Add member")
) on $left.UserPrincipalName == $right.InitiatedBy.user.userPrincipalName

Mitigation Checklist​

CheckAction
Block legacy authCA policy: Other clients + EAS → Block
Review all exclusionsAudit break-glass and service account exclusions quarterly
Require compliant device for sensitive appsCA policy: Require Intune compliant + enforce compliance
Set named locations conservativelyReview trusted IP ranges; remove stale ranges
Use "All apps" as targetAvoid gaps from app-specific targeting
Enable Continuous Access EvaluationRevokes sessions mid-session on risk signals
TopicLink
AiTM Phishingaitm-phishing
MFA Technologiesmfa-technologies
Entra ID Conditional Accessconditional-access
Entra ID Identity Protectionidentity-protection