« Entra ID Custom Domain Added or Verified Entra ID Elevated Access to User Access Administrator »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

Entra ID Domain Federation Configuration Change

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Entra ID Domain Federation Configuration Change

edit

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.

Rule type: query

Rule indices:

  • filebeat-*
  • logs-azure.auditlogs-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • 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
  • Tactic: Privilege Escalation
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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.

Setup

edit

Microsoft Entra ID Audit Logs

This 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.

Rule query

edit
event.dataset: azure.auditlogs
    and azure.auditlogs.properties.category: DirectoryManagement
    and event.action: ("Set domain authentication" or "Set federation settings on domain")
    and event.outcome: success

Framework: MITRE ATT&CKTM

« Entra ID Custom Domain Added or Verified Entra ID Elevated Access to User Access Administrator »