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.userPrincipalNameandipAddressto identify who made the change and from where. - For
"Set domain authentication"events, checkazure.auditlogs.properties.target_resources.0.display_nameto identify which domain was federated. - Use
azure.correlation_idto 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.originalfield 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
- Entra ID Federated Identity Credential Issuer Modified
- Entra ID Unusual Cloud Device Registration
- Entra ID Elevated Access to User Access Administrator
- Entra ID Global Administrator Role Assigned
- Entra ID MFA Disabled for User