New Federated Domain Added

Federation in Microsoft Entra ID allows your organisation to delegate authentication to an external identity provider. When a federated domain is added, users with email addresses in that domain can authenticate using tokens issued by the external provider — rather than being validated directly by Entra ID. This is a powerful and legitimate capability used for hybrid environments and SSO with external partners.

However, if an attacker has Global Admin access, adding a rogue federated domain is one of the most persistent and hard-to-detect backdoors available. Using a technique known as Golden SAML, an attacker who controls the external identity provider can forge authentication tokens for any user in the federated domain — including admin accounts — without those users needing to authenticate at all. This backdoor can survive password resets and MFA changes, because the trust relationship bypasses Entra ID's own credential validation.

If a malicious federated domain is added, an attacker who controls the associated identity provider can generate valid SAML assertions for any account in the federated domain. These assertions are trusted by Entra ID and grant full access to connected Microsoft 365 services without requiring the user's password or MFA.

This technique was used in the SolarWinds/SUNBURST attack to maintain persistent access across multiple victim organisations. Forensically, it's extremely difficult to detect because the access appears legitimate in Entra ID logs — the tokens are valid, the sign-ins succeed, and there are no failed authentication events.

The only reliable way to detect this is to catch the domain federation event itself — which is why alerting on new federated domain additions is critical.

Federated domain additions are a legitimate part of configuring hybrid identity environments and SSO integrations. Legitimate scenarios include:

• Initial setup of a federated domain as part of an ADFS, Okta, or Ping Identity SSO deployment
• Adding a new subsidiary or acquired company's domain under a federated identity model
• Adding a domain as part of a planned migration from on-premises Active Directory to Entra ID hybrid

In all cases, domain federation is a significant architectural change that should have a corresponding project ticket, change management record, or configuration review. Any addition that cannot be immediately matched to an approved change is suspicious.

• In Entra ID, go to Custom domain names and confirm which domain was federated and when
• Check the audit logs for the administrative account that made the change — is this a known admin who regularly performs identity configuration work?
• Verify with your identity/Azure team whether this change was planned and approved
• Check whether the federated domain corresponds to a real domain your organisation controls or has a legitimate relationship with — a domain you don't recognise is an immediate red flag
• Review the admin account that made the change for signs of compromise — unusual sign-in location, recent MFA changes, or session anomalies
• If the domain is unfamiliar, check who owns it using WHOIS and whether it was recently registered

1. If the federated domain cannot be matched to an approved change, remove it immediately via Entra ID > Custom domain names > select domain > Convert to managed
2. Revoke all sessions for the admin account that made the change, reset credentials, and audit all actions that account took in the preceding 24-48 hours
3. If the federation was in place for any period of time, treat all accounts in the federated domain as potentially compromised — SAML tokens may have been issued and used
4. Review Entra ID audit logs for any sign-ins using federated authentication to that domain during the period the federation was active
5. Consider engaging Microsoft incident response or a third-party forensics provider if the federation was active for an extended period, given the potential scope of token abuse
6. After removing the malicious federation, ensure all Global Admin accounts have phishing-resistant MFA (FIDO2 or certificate-based) to prevent re-compromise
7. Review all other federated domains in your tenant to confirm each has a legitimate, documented purpose

Overe Auto-Response: The New Federated Domain Added alert can be configured in Overe to trigger automatic session revocation or account block for the initiating admin when this activity is detected. Review your Auto-Response settings under Org Config > Auto-Response — given the severity of this indicator, an automated response is strongly recommended.

Microsoft: What is federation with Entra ID?

Microsoft: Managing identity in hybrid environments

Microsoft: Protecting Microsoft 365 from on-premises attacks

After investigating a new federated domain alert, review these related risk areas:

• Admins with Risky MFA Settings — the admin account used to add the domain should be reviewed for MFA strength immediately
• Break-Glass Accounts — ensure emergency access accounts are managed-domain accounts not subject to federation
• User Created and Made Admin — attackers who add federated domains often also create backdoor admin accounts
• Unprotected Admin Portals — review admin access controls to ensure future configuration changes require strong authentication
• CA MFA Bypass Paths — confirm Conditional Access policies apply to federated domain accounts appropriately