OIDC Discovery URL Changed in Entra ID

calendar Aug 5, 2025 · Domain: Cloud Domain: Identity Data Source: Azure Data Source: Microsoft Entra ID Data Source: Microsoft Entra ID Audit Logs Use Case: Identity and Access Audit Tactic: Persistence Resources: Investigation Guide  ·
Share on: linkedin copy

Detects a change to the OpenID Connect (OIDC) discovery URL in the Entra ID Authentication Methods Policy. This behavior may indicate an attempt to federate Entra ID with an attacker-controlled identity provider, enabling bypass of multi-factor authentication (MFA) and unauthorized access through bring-your-own IdP (BYOIDP) methods.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/07/14"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2025/07/31"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects a change to the OpenID Connect (OIDC) discovery URL in the Entra ID Authentication Methods Policy. This behavior
 11may indicate an attempt to federate Entra ID with an attacker-controlled identity provider, enabling bypass of
 12multi-factor authentication (MFA) and unauthorized access through bring-your-own IdP (BYOIDP) methods.
 13"""
 14from = "now-9m"
 15language = "esql"
 16license = "Elastic License v2"
 17name = "OIDC Discovery URL Changed in Entra ID"
 18note = """## Triage and analysis
 19
 20### Investigating OIDC Discovery URL Changed in Entra ID
 21
 22This rule detects when the OIDC `discoveryUrl` is changed within the Entra ID Authentication Methods policy. Adversaries may leverage this to federate Entra ID with a rogue Identity Provider (IdP) under their control, allowing them to authenticate users with attacker-owned credentials and bypass MFA. This misconfiguration allows an attacker to impersonate valid users by issuing tokens via a third-party OIDC IdP while still passing validation in Entra ID. This technique has been publicly demonstrated and has critical implications for trust in federated identity.
 23
 24### Possible investigation steps
 25- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who made the change and from where.
 26- Examine the `old_oidc_discovery` and `new_oidc_discovery` to confirm if the new `discoveryUrl` points to an unexpected or untrusted IdP.
 27- Check that the discovery URLs have `.well-known/openid-configuration` endpoints, which are standard for OIDC providers.
 28- Use `azure.auditlogs.properties.correlation_id` to pivot to related changes and activity from the same session.
 29- Review any subsequent sign-in activity that may have originated from the new IdP.
 30- Pivot to additional logs associated with the user or application that made the change to identify any further suspicious activity.
 31
 32### False positive analysis
 33- Entra ID administrators may intentionally reconfigure OIDC trust relationships to support new business requirements.
 34- Validate any changes with the identity or security operations team before taking action.
 35
 36### Response and remediation
 37- If the change is unauthorized, immediately revert the discovery URL to the trusted IdP via the Entra ID portal.
 38- Revoke tokens or sessions issued after the configuration change.
 39- Investigate how the unauthorized change occurred (e.g., compromised account or over-privileged app).
 40- Apply conditional access policies and change control procedures to protect IdP configuration changes.
 41"""
 42references = ["https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/"]
 43risk_score = 73
 44rule_id = "498e4094-60e7-11f0-8847-f661ea17fbcd"
 45severity = "high"
 46tags = [
 47    "Domain: Cloud",
 48    "Domain: Identity",
 49    "Data Source: Azure",
 50    "Data Source: Microsoft Entra ID",
 51    "Data Source: Microsoft Entra ID Audit Logs",
 52    "Use Case: Identity and Access Audit",
 53    "Tactic: Persistence",
 54    "Resources: Investigation Guide",
 55]
 56timestamp_override = "event.ingested"
 57type = "esql"
 58
 59query = '''
 60from logs-azure.auditlogs-* metadata _id, _version, _index
 61| where event.action == "Authentication Methods Policy Update"
 62| eval Esql.azure_auditlogs_properties_target_resources_modified_properties_new_value_replace = replace(`azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`, "\\\\", "")
 63| eval Esql.azure_auditlogs_properties_target_resources_modified_properties_old_value_replace = replace(`azure.auditlogs.properties.target_resources.0.modified_properties.0.old_value`, "\\\\", "")
 64| dissect Esql.azure_auditlogs_properties_target_resources_modified_properties_new_value_replace "%{}discoveryUrl\":\"%{Esql.azure_auditlogs_properties_auth_oidc_discovery_url_new}\"}%{}"
 65| dissect Esql.azure_auditlogs_properties_target_resources_modified_properties_old_value_replace "%{}discoveryUrl\":\"%{Esql.azure_auditlogs_properties_auth_oidc_discovery_url_old}\"}%{}"
 66| where Esql.azure_auditlogs_properties_auth_oidc_discovery_url_new is not null and Esql.azure_auditlogs_properties_auth_oidc_discovery_url_old is not null
 67| where Esql.azure_auditlogs_properties_auth_oidc_discovery_url_new != Esql.azure_auditlogs_properties_auth_oidc_discovery_url_old
 68| keep
 69    @timestamp,
 70    event.action,
 71    event.outcome,
 72    azure.tenant_id,
 73    azure.correlation_id,
 74    azure.auditlogs.properties.activity_datetime,
 75    azure.auditlogs.properties.operation_type,
 76    azure.auditlogs.properties.initiated_by.user.userPrincipalName,
 77    azure.auditlogs.properties.initiated_by.user.displayName,
 78    azure.auditlogs.properties.initiated_by.user.ipAddress,
 79    source.geo.city_name,
 80    source.geo.region_name,
 81    source.geo.country_name,
 82    Esql.azure_auditlogs_properties_auth_oidc_discovery_url_new,
 83    Esql.azure_auditlogs_properties_auth_oidc_discovery_url_old
 84'''
 85
 86
 87[[rule.threat]]
 88framework = "MITRE ATT&CK"
 89[[rule.threat.technique]]
 90id = "T1556"
 91name = "Modify Authentication Process"
 92reference = "https://attack.mitre.org/techniques/T1556/"
 93[[rule.threat.technique.subtechnique]]
 94id = "T1556.009"
 95name = "Conditional Access Policies"
 96reference = "https://attack.mitre.org/techniques/T1556/009/"
 97
 98
 99
100[rule.threat.tactic]
101id = "TA0003"
102name = "Persistence"
103reference = "https://attack.mitre.org/tactics/TA0003/"

Triage and analysis

Investigating OIDC Discovery URL Changed in Entra ID

This rule detects when the OIDC discoveryUrl is changed within the Entra ID Authentication Methods policy. Adversaries may leverage this to federate Entra ID with a rogue Identity Provider (IdP) under their control, allowing them to authenticate users with attacker-owned credentials and bypass MFA. This misconfiguration allows an attacker to impersonate valid users by issuing tokens via a third-party OIDC IdP while still passing validation in Entra ID. This technique has been publicly demonstrated and has critical implications for trust in federated identity.

Possible investigation steps

  • Review azure.auditlogs.properties.initiated_by.user.userPrincipalName and ipAddress to identify who made the change and from where.
  • Examine the old_oidc_discovery and new_oidc_discovery to confirm if the new discoveryUrl points to an unexpected or untrusted IdP.
  • Check that the discovery URLs have .well-known/openid-configuration endpoints, which are standard for OIDC providers.
  • Use azure.auditlogs.properties.correlation_id to pivot to related changes and activity from the same session.
  • Review any subsequent sign-in activity that may have originated from the new IdP.
  • Pivot to additional logs associated with the user or application that made the change to identify any further suspicious activity.

False positive analysis

  • Entra ID administrators may intentionally reconfigure OIDC trust relationships to support new business requirements.
  • Validate any changes with the identity or security operations team before taking action.

Response and remediation

  • If the change is unauthorized, immediately revert the discovery URL to the trusted IdP via the Entra ID portal.
  • Revoke tokens or sessions issued after the configuration change.
  • Investigate how the unauthorized change occurred (e.g., compromised account or over-privileged app).
  • Apply conditional access policies and change control procedures to protect IdP configuration changes.

References

  • Persisting on Entra ID applications and User Managed Identities with Federated Credentials

    Using applications and service principals for persistence and privilege escalation is a well-known topic in Entra ID (Azure AD). I’ve written about these kind of attacks many years ago, and talked about how we can use certificates and application passwords to authenticate as applications and abuse the permissions they have. In this blog, we cover a third way of authenticating as an application: using federated credentials. Federated credentials have been around for a few years, but haven’t been covered much yet from the offensive side. For Entra ID applications, there is no large difference between configuring federated credentials or regular client secrets/certificates. The more interesting part on this topic is that we can also configure federated credentials on User Managed Identities in Azure. This is unusual, because normally Managed Identities have their authentication controlled by Microsoft, and their authentication is tied to a certain resource such as a Virtual Machine. With federated credentials, we can bypass that limitation, given that we have sufficient privileges, and authenticate as this managed identity without requiring access to another resource in Azure. With this blog I’m also introducing a new utility to the ROADtools family: roadoidc, which can set up a minimal Identity Provider (IdP), allowing us to authenticate using federated credentials as apps and user managed identities with roadtx.


    Read More

Related rules

to-top