Entra ID Domain Federation Configuration Change

Detects when domain federation settings are configured or modified in an Entra ID tenant via the Microsoft Graph API. Adversaries with Global Administrator or Domain Administrator privileges may add a custom domain, verify ownership, and configure it to federate authentication with an attacker-controlled identity provider. Once federated, the adversary can forge SAML or WS-Federation tokens to authenticate as any user under that domain, bypassing MFA and conditional access policies. This technique, commonly known as Golden SAML, was used by UNC2452 (APT29) during the SolarWinds campaign for persistent, stealthy access to victim tenants.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/03/03"
  3integration = ["azure"]
  4maturity = "development"
  5updated_date = "2026/03/03"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects when domain federation settings are configured or modified in an Entra ID tenant via the Microsoft Graph API.
 11Adversaries with Global Administrator or Domain Administrator privileges may add a custom domain, verify ownership, and
 12configure it to federate authentication with an attacker-controlled identity provider. Once federated, the adversary can
 13forge SAML or WS-Federation tokens to authenticate as any user under that domain, bypassing MFA and conditional access
 14policies. This technique, commonly known as Golden SAML, was used by UNC2452 (APT29) during the SolarWinds campaign for
 15persistent, stealthy access to victim tenants.
 16"""
 17from = "now-9m"
 18index = ["filebeat-*", "logs-azure.auditlogs-*"]
 19language = "kuery"
 20license = "Elastic License v2"
 21name = "Entra ID Domain Federation Configuration Change"
 22note = """## Triage and analysis
 23
 24### Investigating Entra ID Domain Federation Configuration Change
 25
 26This rule detects when domain federation settings are added or modified in an Entra ID tenant. Domain federation allows organizations to delegate authentication for a UPN domain suffix to an external Identity Provider (IdP). While this is a legitimate feature for organizations using external IdPs like Okta or ADFS, adversaries can abuse it to establish persistent access by federating a domain to an attacker-controlled IdP.
 27
 28This is the highest blast radius federation abuse technique, unlike app-level federated identity credentials (which affect a single service principal), domain federation affects all users whose UPN matches the federated domain.
 29
 30Both events share the same `correlation_id` but neither includes the federation configuration details (issuer URI, signing certificate) in the event properties.
 31
 32### Possible investigation steps
 33
 34- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who made the change and from where.
 35- For `"Set domain authentication"` events, check `azure.auditlogs.properties.target_resources.0.display_name` to identify which domain was federated.
 36- Use `azure.correlation_id` to correlate the companion `"Set federation settings on domain"` event and establish the full context.
 37- Query the Graph API to retrieve the actual federation configuration details, since they are not logged in the audit event: `Get-MgDomainFederationConfiguration -DomainId "<domain>"`.
 38- Review the configured issuer URI and signing certificate to determine if the external IdP is legitimate or attacker-controlled.
 39- Check for precursor events with the same actor: `"Add unverified domain"` and `"Verify domain"` events targeting the same domain would indicate the full attack chain.
 40- Review Azure sign-in logs for any authentication activity from users under the newly federated domain.
 41- Investigate whether the domain was recently added to the tenant or was a pre-existing domain whose authentication type was changed.
 42- Review the `user_agent.original` field for the actor to determine if the change was made via the Azure Portal, Microsoft Graph API, or PowerShell, which may provide additional context on whether this was a manual or scripted action.
 43
 44### False positive analysis
 45
 46- Legitimate domain federation changes by IT administrators during initial tenant setup or IdP migrations (e.g., migrating from ADFS to Okta).
 47- Organizational restructuring such as mergers or acquisitions where new domains are federated.
 48- Scheduled maintenance or updates to federation certificates or IdP endpoints.
 49- Validate with the Global Administrator or identity team before dismissing.
 50
 51### Response and remediation
 52
 53- If the federation change is unauthorized, immediately remove the federation configuration: `Remove-MgDomainFederationConfiguration -DomainId "<domain>" -InternalDomainFederationId "<id>"`.
 54- Revert the domain authentication type to managed if it should not be federated.
 55- Revoke all active sessions and tokens for users under the affected domain.
 56- Audit recent sign-in activity for users under the federated domain to identify unauthorized access.
 57- Investigate how the adversary obtained Global Administrator privileges to perform this action.
 58- Review and restrict who has Domain Administrator or Global Administrator roles using PIM (Privileged Identity Management).
 59- Implement alerts on domain management operations and restrict domain federation changes via conditional access policies.
 60"""
 61references = [
 62    "https://cloud.google.com/blog/topics/threat-intelligence/unc2452-merged-into-apt29",
 63    "https://learn.microsoft.com/en-us/graph/api/domain-post-federationconfiguration",
 64    "https://medium.com/tenable-techblog/roles-allowing-to-abuse-entra-id-federation-for-persistence-and-privilege-escalation-df9ca6e58360",
 65    "https://securitylabs.datadoghq.com/articles/i-spy-escalating-to-entra-id-global-admin/",
 66    "https://techcommunity.microsoft.com/blog/microsoft-entra-blog/understanding-and-mitigating-golden-saml-attacks/4418864",
 67]
 68risk_score = 73
 69rule_id = "1cfb39e1-4b6c-4dc7-85fe-733e4a1a33ca"
 70setup = """### Microsoft Entra ID Audit Logs
 71This rule requires the Azure integration with Microsoft Entra ID Audit Logs data stream ingesting in your Elastic Stack deployment. For more information, refer to the [Microsoft Entra ID Audit Logs integration documentation](https://www.elastic.co/docs/reference/integrations/azure/adlogs).
 72"""
 73severity = "high"
 74tags = [
 75    "Domain: Cloud",
 76    "Domain: Identity",
 77    "Data Source: Azure",
 78    "Data Source: Microsoft Entra ID",
 79    "Data Source: Microsoft Entra ID Audit Logs",
 80    "Use Case: Identity and Access Audit",
 81    "Tactic: Persistence",
 82    "Tactic: Privilege Escalation",
 83    "Resources: Investigation Guide",
 84]
 85timestamp_override = "event.ingested"
 86type = "query"
 87
 88query = '''
 89event.dataset: azure.auditlogs
 90    and azure.auditlogs.properties.category: DirectoryManagement
 91    and event.action: ("Set domain authentication" or "Set federation settings on domain")
 92    and event.outcome: success
 93'''
 94
 95
 96[[rule.threat]]
 97framework = "MITRE ATT&CK"
 98[[rule.threat.technique]]
 99id = "T1484"
100name = "Domain or Tenant Policy Modification"
101reference = "https://attack.mitre.org/techniques/T1484/"
102[[rule.threat.technique.subtechnique]]
103id = "T1484.002"
104name = "Trust Modification"
105reference = "https://attack.mitre.org/techniques/T1484/002/"
106
107
108
109[rule.threat.tactic]
110id = "TA0004"
111name = "Privilege Escalation"
112reference = "https://attack.mitre.org/tactics/TA0004/"
113[[rule.threat]]
114framework = "MITRE ATT&CK"
115[[rule.threat.technique]]
116id = "T1098"
117name = "Account Manipulation"
118reference = "https://attack.mitre.org/techniques/T1098/"
119[[rule.threat.technique.subtechnique]]
120id = "T1098.001"
121name = "Additional Cloud Credentials"
122reference = "https://attack.mitre.org/techniques/T1098/001/"
123
124
125
126[rule.threat.tactic]
127id = "TA0003"
128name = "Persistence"
129reference = "https://attack.mitre.org/tactics/TA0003/"

Triage and analysis

Investigating Entra ID Domain Federation Configuration Change

This rule detects when domain federation settings are added or modified in an Entra ID tenant. Domain federation allows organizations to delegate authentication for a UPN domain suffix to an external Identity Provider (IdP). While this is a legitimate feature for organizations using external IdPs like Okta or ADFS, adversaries can abuse it to establish persistent access by federating a domain to an attacker-controlled IdP.

This is the highest blast radius federation abuse technique, unlike app-level federated identity credentials (which affect a single service principal), domain federation affects all users whose UPN matches the federated domain.

Both events share the same correlation_id but neither includes the federation configuration details (issuer URI, signing certificate) in the event properties.

Possible investigation steps

  • Review azure.auditlogs.properties.initiated_by.user.userPrincipalName and ipAddress to identify who made the change and from where.
  • For "Set domain authentication" events, check azure.auditlogs.properties.target_resources.0.display_name to identify which domain was federated.
  • Use azure.correlation_id to correlate the companion "Set federation settings on domain" event and establish the full context.
  • Query the Graph API to retrieve the actual federation configuration details, since they are not logged in the audit event: Get-MgDomainFederationConfiguration -DomainId "<domain>".
  • Review the configured issuer URI and signing certificate to determine if the external IdP is legitimate or attacker-controlled.
  • Check for precursor events with the same actor: "Add unverified domain" and "Verify domain" events targeting the same domain would indicate the full attack chain.
  • Review Azure sign-in logs for any authentication activity from users under the newly federated domain.
  • Investigate whether the domain was recently added to the tenant or was a pre-existing domain whose authentication type was changed.
  • Review the user_agent.original field for the actor to determine if the change was made via the Azure Portal, Microsoft Graph API, or PowerShell, which may provide additional context on whether this was a manual or scripted action.

False positive analysis

  • Legitimate domain federation changes by IT administrators during initial tenant setup or IdP migrations (e.g., migrating from ADFS to Okta).
  • Organizational restructuring such as mergers or acquisitions where new domains are federated.
  • Scheduled maintenance or updates to federation certificates or IdP endpoints.
  • Validate with the Global Administrator or identity team before dismissing.

Response and remediation

  • If the federation change is unauthorized, immediately remove the federation configuration: Remove-MgDomainFederationConfiguration -DomainId "<domain>" -InternalDomainFederationId "<id>".
  • Revert the domain authentication type to managed if it should not be federated.
  • Revoke all active sessions and tokens for users under the affected domain.
  • Audit recent sign-in activity for users under the federated domain to identify unauthorized access.
  • Investigate how the adversary obtained Global Administrator privileges to perform this action.
  • Review and restrict who has Domain Administrator or Global Administrator roles using PIM (Privileged Identity Management).
  • Implement alerts on domain management operations and restrict domain federation changes via conditional access policies.

References

Related rules

to-top