Entra ID Conditional Access MFA Bypass with Unusual User, Client and Source ASN

Identifies the first observed instance of a Microsoft first-party public client application acquiring a Microsoft Graph token using single-factor (password-only) authentication while an MFA Conditional Access grant control went unenforced, for a given user, application, and source autonomous system (ASN). This pattern is associated with the Conditional Access "resource exclusion" bypass: when a tenant's "all resources" Conditional Access policy contains at least one application exclusion, Entra ID issues tokens for low-privilege baseline scopes (User.Read, openid, profile, email) to any resource, including Microsoft Graph, without enforcing the policy's grant controls (such as MFA). An adversary holding only a stolen password can therefore obtain a Graph token through a trusted first-party public client (for example, Microsoft Bing Search) and enumerate directory objects, even though the tenant requires MFA. Critically, the overall conditional_access_status is never "failure" for this technique (the sign-in is not blocked); it is reported as "success" or "notApplied" depending on what other policies exist in the tenant, so detections that key on Conditional Access failures will not observe it. The reliable fingerprint is in the per-policy results: a policy whose enforced grant control is MFA reports a result of "notApplied" for this sign-in, meaning the MFA requirement was silently not enforced while the single-factor, password-only sign-in still succeeded.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/06/22"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2026/06/22"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies the first observed instance of a Microsoft first-party public client application acquiring a Microsoft Graph
 11token using single-factor (password-only) authentication while an MFA Conditional Access grant control went unenforced,
 12for a given user, application, and source autonomous system (ASN). This pattern is associated with the Conditional
 13Access "resource exclusion" bypass: when a tenant's "all resources" Conditional Access policy contains at least one
 14application exclusion, Entra ID issues tokens for low-privilege baseline scopes (User.Read, openid, profile, email) to
 15any resource, including Microsoft Graph, without enforcing the policy's grant controls (such as MFA). An adversary
 16holding only a stolen password can therefore obtain a Graph token through a trusted first-party public client (for
 17example, Microsoft Bing Search) and enumerate directory objects, even though the tenant requires MFA. Critically, the
 18overall conditional_access_status is never "failure" for this technique (the sign-in is not blocked); it is reported as
 19"success" or "notApplied" depending on what other policies exist in the tenant, so detections that key on Conditional
 20Access failures will not observe it. The reliable fingerprint is in the per-policy results: a policy whose enforced
 21grant control is MFA reports a result of "notApplied" for this sign-in, meaning the MFA requirement was silently not
 22enforced while the single-factor, password-only sign-in still succeeded.
 23"""
 24from = "now-9m"
 25index = ["filebeat-*", "logs-azure.signinlogs-*"]
 26language = "kuery"
 27license = "Elastic License v2"
 28name = "Entra ID Conditional Access MFA Bypass with Unusual User, Client and Source ASN"
 29note = """## Triage and analysis
 30
 31### Investigating Entra ID Conditional Access MFA Bypass with Unusual User, Client and Source ASN
 32
 33This rule fires the first time a user signs in to Microsoft Graph through a Microsoft first-party app using single-factor, password-only authentication, keyed on the user, app, and source ASN within the history window. First-party apps are matched by their owner tenant (`app_owner_tenant_id` `f8cdef31-a31e-4b4a-93e4-5f571e91255a`) instead of a fixed client ID list, so switching to a different first-party client does not get around the detection. The password-only form of this bypass depends on first-party apps: they are pre-consented in every tenant and cannot be blocked, so a stolen password is enough to use one. A third-party or confidential client would mean the attacker already controls an app in the tenant, which is a different scenario.
 34
 35The behavior comes from the Conditional Access resource-exclusion bypass. If an "all resources" CA policy excludes even one application, Entra ID issues tokens for baseline scopes (User.Read, openid, profile, email) to Microsoft Graph without applying the policy's grant controls, so MFA is skipped. Default directory permissions then let that `User.Read` token read groups, service principals, directory roles, and devices.
 36
 37Do not read too much into the top-level `azure.signinlogs.properties.conditional_access_status` here. It shows `success` or `notApplied` (never `failure`, since the sign-in is not blocked), and which one you see depends on the other policies in the tenant. The useful evidence is in `azure.signinlogs.properties.applied_conditional_access_policies`: an MFA grant control (`enforced_grant_controls` of `Mfa`) that came back `notApplied` on a sign-in that was still single-factor and password-based. That is what the query keys on.
 38
 39### Possible investigation steps
 40
 41- Review `azure.signinlogs.properties.user_principal_name` to identify the user and whether they hold privileged roles or are otherwise a high-value target.
 42- Confirm the client via `azure.signinlogs.properties.app_display_name` and `azure.signinlogs.properties.app_id`. End-user authentication of clients such as Microsoft Bing Search to Microsoft Graph is uncommon and warrants scrutiny; everyday clients (Microsoft Teams, OneDrive, Outlook Mobile) are far more likely to be benign.
 43- Examine `source.ip`, `source.as.number`, `source.as.organization.name`, and `source.geo.*` for hosting-provider or geographic anomalies inconsistent with the user's normal sign-in locations.
 44- Inspect `azure.signinlogs.properties.applied_conditional_access_policies` for the sign-in. A policy with `enforced_grant_controls` of `Mfa` and a `result` of `notApplied`, on a `singleFactorAuthentication` / `Password` sign-in, means the MFA grant control was present but not enforced. Note the aggregate `conditional_access_status` may read `success` or `notApplied` and is not by itself indicative.
 45- Review whether the tenant has an "all resources" Conditional Access policy with one or more application exclusions, which is the configuration that enables this bypass.
 46- Pivot to `logs-azure.graphactivitylogs-*` for the same `user_principal_object_id` and `app_id` to identify directory enumeration (requests to `/groups`, `/servicePrincipals`, `/directoryRoles`, `/devices`, `/users`) shortly after the sign-in.
 47- Correlate using `azure.signinlogs.properties.session_id` to reconstruct the full token-acquisition sequence, including any non-interactive token redemption.
 48
 49### False positive analysis
 50
 51- Everyday first-party public clients (Microsoft Teams, OneDrive, Outlook Mobile, Microsoft 365 Copilot, Microsoft To-Do, Edge, Windows Search) legitimately acquire Microsoft Graph tokens with single-factor authentication, particularly when MFA was already satisfied earlier in the session or no MFA policy applies to that application. Expect benign first-time `(user, app, ASN)` combinations, especially during onboarding or first use of a tool.
 52- Users signing in from a new network (travel, VPN, new ISP) will present a new ASN and may trigger the New Terms condition once.
 53- In tenants with broad MFA Conditional Access policies, those policies can legitimately report `notApplied` for single-factor sign-ins that are genuinely out of policy scope (for example, sign-ins from a trusted named location or an app excluded from the policy). The `applied_conditional_access_policies` condition therefore sharpens, but does not perfectly isolate, the bypass; corroborate with the application identity and source.
 54- The rule scopes to all Microsoft first-party applications via `app_owner_tenant_id` rather than a fixed client ID list, so it covers every first-party public client but is correspondingly broad. New Terms on `(user, app_id, ASN)` limits this to first-occurrence events; consider allowlisting expected `(user, app)` pairs, or specific high-volume everyday first-party apps, to further reduce volume.
 55- Tune by excluding known developer or automation identities that routinely use these clients against Microsoft Graph.
 56
 57### Response and remediation
 58
 59- Contact the user to confirm whether they initiated the sign-in and used the detected application.
 60- If unauthorized, revoke the user's refresh tokens and require password reset and MFA re-registration.
 61- Review `logs-azure.graphactivitylogs-*` for directory enumeration or data access performed with the issued token.
 62- Remediate the enabling configuration: review "all resources" Conditional Access policies for application exclusions, and enable strict baseline-scope enforcement so baseline scopes do not bypass grant controls.
 63- Block the source IP or ASN if confirmed malicious.
 64"""
 65references = [
 66    "https://dirkjanm.io/bypassing-conditional-access-with-resource-exclusion/",
 67    "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema",
 68]
 69risk_score = 47
 70rule_id = "921544bd-e2aa-44a6-9fb9-98629c342adf"
 71severity = "medium"
 72tags = [
 73    "Domain: Cloud",
 74    "Domain: Identity",
 75    "Data Source: Azure",
 76    "Data Source: Microsoft Entra ID",
 77    "Data Source: Microsoft Entra ID Sign-in Logs",
 78    "Use Case: Identity and Access Audit",
 79    "Use Case: Threat Detection",
 80    "Tactic: Initial Access",
 81    "Tactic: Defense Evasion",
 82    "Resources: Investigation Guide",
 83]
 84timestamp_override = "event.ingested"
 85type = "new_terms"
 86
 87query = '''
 88data_stream.dataset: "azure.signinlogs" and
 89event.outcome: "success" and
 90azure.signinlogs.properties.user_type: "Member" and
 91azure.signinlogs.properties.authentication_requirement: "singleFactorAuthentication" and
 92azure.signinlogs.properties.conditional_access_status: ("success" or "notApplied") and
 93azure.signinlogs.properties.authentication_details.authentication_method: "Password" and
 94azure.signinlogs.properties.applied_conditional_access_policies.enforced_grant_controls: "Mfa" and
 95azure.signinlogs.properties.applied_conditional_access_policies.result: "notApplied" and
 96(
 97    azure.signinlogs.properties.resource_id: "00000003-0000-0000-c000-000000000000" or
 98    azure.signinlogs.properties.resource_display_name: "Microsoft Graph"
 99) and
100azure.signinlogs.properties.app_owner_tenant_id: "f8cdef31-a31e-4b4a-93e4-5f571e91255a" and
101azure.signinlogs.properties.user_principal_name: * and
102azure.signinlogs.properties.app_id: * and
103source.as.number: *
104'''
105
106
107[[rule.threat]]
108framework = "MITRE ATT&CK"
109[[rule.threat.technique]]
110id = "T1556"
111name = "Modify Authentication Process"
112reference = "https://attack.mitre.org/techniques/T1556/"
113[[rule.threat.technique.subtechnique]]
114id = "T1556.009"
115name = "Conditional Access Policies"
116reference = "https://attack.mitre.org/techniques/T1556/009/"
117
118
119
120[rule.threat.tactic]
121id = "TA0005"
122name = "Defense Evasion"
123reference = "https://attack.mitre.org/tactics/TA0005/"
124[[rule.threat]]
125framework = "MITRE ATT&CK"
126[[rule.threat.technique]]
127id = "T1078"
128name = "Valid Accounts"
129reference = "https://attack.mitre.org/techniques/T1078/"
130[[rule.threat.technique.subtechnique]]
131id = "T1078.004"
132name = "Cloud Accounts"
133reference = "https://attack.mitre.org/techniques/T1078/004/"
134
135
136
137[rule.threat.tactic]
138id = "TA0001"
139name = "Initial Access"
140reference = "https://attack.mitre.org/tactics/TA0001/"
141
142[rule.investigation_fields]
143field_names = [
144    "@timestamp",
145    "azure.signinlogs.properties.user_principal_name",
146    "azure.signinlogs.properties.app_id",
147    "azure.signinlogs.properties.app_display_name",
148    "azure.signinlogs.properties.resource_id",
149    "azure.signinlogs.properties.resource_display_name",
150    "azure.signinlogs.properties.authentication_requirement",
151    "azure.signinlogs.properties.conditional_access_status",
152    "azure.signinlogs.properties.applied_conditional_access_policies.display_name",
153    "azure.signinlogs.properties.applied_conditional_access_policies.enforced_grant_controls",
154    "azure.signinlogs.properties.applied_conditional_access_policies.result",
155    "azure.signinlogs.properties.is_interactive",
156    "azure.signinlogs.properties.session_id",
157    "source.ip",
158    "source.as.number",
159    "source.as.organization.name",
160    "source.geo.country_name",
161    "user_agent.original",
162]
163
164[rule.new_terms]
165field = "new_terms_fields"
166value = [
167    "azure.signinlogs.properties.user_principal_name",
168    "azure.signinlogs.properties.app_id",
169    "source.as.number",
170]
171[[rule.new_terms.history_window_start]]
172field = "history_window_start"
173value = "now-7d"

Triage and analysis

Investigating Entra ID Conditional Access MFA Bypass with Unusual User, Client and Source ASN

This rule fires the first time a user signs in to Microsoft Graph through a Microsoft first-party app using single-factor, password-only authentication, keyed on the user, app, and source ASN within the history window. First-party apps are matched by their owner tenant (app_owner_tenant_id f8cdef31-a31e-4b4a-93e4-5f571e91255a) instead of a fixed client ID list, so switching to a different first-party client does not get around the detection. The password-only form of this bypass depends on first-party apps: they are pre-consented in every tenant and cannot be blocked, so a stolen password is enough to use one. A third-party or confidential client would mean the attacker already controls an app in the tenant, which is a different scenario.

The behavior comes from the Conditional Access resource-exclusion bypass. If an "all resources" CA policy excludes even one application, Entra ID issues tokens for baseline scopes (User.Read, openid, profile, email) to Microsoft Graph without applying the policy's grant controls, so MFA is skipped. Default directory permissions then let that User.Read token read groups, service principals, directory roles, and devices.

Do not read too much into the top-level azure.signinlogs.properties.conditional_access_status here. It shows success or notApplied (never failure, since the sign-in is not blocked), and which one you see depends on the other policies in the tenant. The useful evidence is in azure.signinlogs.properties.applied_conditional_access_policies: an MFA grant control (enforced_grant_controls of Mfa) that came back notApplied on a sign-in that was still single-factor and password-based. That is what the query keys on.

Possible investigation steps

  • Review azure.signinlogs.properties.user_principal_name to identify the user and whether they hold privileged roles or are otherwise a high-value target.
  • Confirm the client via azure.signinlogs.properties.app_display_name and azure.signinlogs.properties.app_id. End-user authentication of clients such as Microsoft Bing Search to Microsoft Graph is uncommon and warrants scrutiny; everyday clients (Microsoft Teams, OneDrive, Outlook Mobile) are far more likely to be benign.
  • Examine source.ip, source.as.number, source.as.organization.name, and source.geo.* for hosting-provider or geographic anomalies inconsistent with the user's normal sign-in locations.
  • Inspect azure.signinlogs.properties.applied_conditional_access_policies for the sign-in. A policy with enforced_grant_controls of Mfa and a result of notApplied, on a singleFactorAuthentication / Password sign-in, means the MFA grant control was present but not enforced. Note the aggregate conditional_access_status may read success or notApplied and is not by itself indicative.
  • Review whether the tenant has an "all resources" Conditional Access policy with one or more application exclusions, which is the configuration that enables this bypass.
  • Pivot to logs-azure.graphactivitylogs-* for the same user_principal_object_id and app_id to identify directory enumeration (requests to /groups, /servicePrincipals, /directoryRoles, /devices, /users) shortly after the sign-in.
  • Correlate using azure.signinlogs.properties.session_id to reconstruct the full token-acquisition sequence, including any non-interactive token redemption.

False positive analysis

  • Everyday first-party public clients (Microsoft Teams, OneDrive, Outlook Mobile, Microsoft 365 Copilot, Microsoft To-Do, Edge, Windows Search) legitimately acquire Microsoft Graph tokens with single-factor authentication, particularly when MFA was already satisfied earlier in the session or no MFA policy applies to that application. Expect benign first-time (user, app, ASN) combinations, especially during onboarding or first use of a tool.
  • Users signing in from a new network (travel, VPN, new ISP) will present a new ASN and may trigger the New Terms condition once.
  • In tenants with broad MFA Conditional Access policies, those policies can legitimately report notApplied for single-factor sign-ins that are genuinely out of policy scope (for example, sign-ins from a trusted named location or an app excluded from the policy). The applied_conditional_access_policies condition therefore sharpens, but does not perfectly isolate, the bypass; corroborate with the application identity and source.
  • The rule scopes to all Microsoft first-party applications via app_owner_tenant_id rather than a fixed client ID list, so it covers every first-party public client but is correspondingly broad. New Terms on (user, app_id, ASN) limits this to first-occurrence events; consider allowlisting expected (user, app) pairs, or specific high-volume everyday first-party apps, to further reduce volume.
  • Tune by excluding known developer or automation identities that routinely use these clients against Microsoft Graph.

Response and remediation

  • Contact the user to confirm whether they initiated the sign-in and used the detected application.
  • If unauthorized, revoke the user's refresh tokens and require password reset and MFA re-registration.
  • Review logs-azure.graphactivitylogs-* for directory enumeration or data access performed with the issued token.
  • Remediate the enabling configuration: review "all resources" Conditional Access policies for application exclusions, and enable strict baseline-scope enforcement so baseline scopes do not bypass grant controls.
  • Block the source IP or ASN if confirmed malicious.

References

Related rules

to-top