Microsoft Entra ID can delegate authentication to another authentication provider: a feature called federation. Attackers who gained elevated privileges, can abuse this legitimate feature, by adding their malicious federated domain thus enabling persistence and privilege escalation.

A Microsoft Entra tenant can <a href="https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed">federate with an external domain</a> to establish trust with another domain for authentication and authorization. Organizations use federation to delegate authentication for Active Directory users to their on-premises Active Directory Federation Services (AD FS). (Note: the external domain is not an Active Directory "domain".)
But if malicious actors gain elevated privileges in Microsoft Entra ID, they can abuse this federation mechanism to create a backdoor by adding their own federated domain or editing an existing one to add a secondary configuration with their own settings. Such an attack would allow the following actions:
<ul>
<li>Impersonation: The malicious federated domain can generate tokens to allow an attacker to authenticate as any Microsoft Entra user without knowing or resetting their password. This includes "cloud-only" users (not hybrid) and external users. This allows attacks on Microsoft Entra ID, Microsoft 365 (O365), and other applications that rely on Microsoft Entra ID as an Identity Provider (SSO), even if you enforce MFA (see below).</li>
<li>Privilege escalation: The attacker can impersonate any user, particularly privileged Microsoft Entra users.</li>
<li>Multi-Factor Authentication bypass: With federated authentication, the trusted external domain <a href="https://learn.microsoft.com/en-us/graph/api/resources/internaldomainfederation?view=graph-rest-beta#federatedidpmfabehavior-values">takes on the role of enforcing MFA</a>. The malicious federated domain can then falsely assert that the spoofed authentication used MFA, which Microsoft Entra ID trusts and does not prompt again for MFA. This allows the attacker to impersonate all users even if there is MFA protection.</li>
<li>Persistence: Adding a malicious federated domain is a stealth technique that allows attackers who compromised the Microsoft Entra tenant and appropriated high privileges to regain access later.</li>
</ul>
This Indicator of Exposure detects federated domain backdoors that the <a href="https://aadinternals.com/">AADInternals</a> hacking toolkit creates, in particular the <code>ConvertTo-AADIntBackdoor</code> and <code>New-AADIntBackdoor</code> cmdlets, based on certain characteristics of the backdoor domain it created or converted.
The federation protocol that carries the authentication proof from the malicious federated domain to the attacked Microsoft Entra ID can either be WS-Federation or SAML. With SAML, the attack resembles a "<a href="https://www.mandiant.com/sites/default/files/2021-11/wp-m-unc2452-000343.pdf#page=9">Golden SAML</a>" attack, with these key differences:
<ul>
<li>Instead of stealing the legitimate SAML signing key of an existing federation, the attackers inject their new domain with their own key. </li>
<li>Attackers use the token for federation rather than for access to a service.</li>
</ul>
The <code>microsoft.directory/domains/federation/update</code> permission grants the ability to modify the federated domains. As of January 2023, the following built-in Microsoft Entra roles hold this permission in addition to potential custom roles:
<ul>
<li>"<a href="https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#global-administrator">Global Administrator</a>"</li>
<li>"<a href="https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#security-administrator">Security Administrator</a>"</li>
<li>"<a href="https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#hybrid-identity-administrator">Hybrid Identity Administrator</a>"</li>
<li>"<a href="https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#external-identity-provider-administrator">External Identity Provider Administrator</a>"</li>
</ul>
The APT29 threat group abused this method in the infamous December 2020 attack against SolarWinds called "Solorigate", as documented <a href="https://www.microsoft.com/en-us/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/">by Microsoft</a> and <a href="https://www.mandiant.com/sites/default/files/2021-11/wp-m-unc2452-000343.pdf#page=23">by Mandiant</a>.

Modify Trusted Domains [Mandiant]

Security vulnerability in Azure AD & Office 365 identity federation

How to create a backdoor to Azure AD - part 1: Identity federation

Deep-dive to Azure Active Directory Identity Federation

Domain Policy Modification: Domain Trust Modification

Forge Web Credentials: SAML Tokens

[MITRE ATT&CK®] T1484.002 (Domain Policy Modification: Domain Trust Modification)

[MITRE ATT&CK®] T1606.002 (Forge Web Credentials: SAML Tokens)

Known Federated Domain Backdoor

Microsoft exposes APIs in Entra ID to allow 3rd-party applications to perform actions on Microsoft services. Certain permissions can pose a serious threat to the entire Microsoft Entra tenant. Therefore, their assignment must be carefully reviewed.

Microsoft exposes APIs through applications in Entra ID to allow 3rd-party applications to perform actions on Microsoft Entra ID itself, Microsoft 365 (O365), Azure cloud, etc. "API permissions" protect the access to these APIs which only the service principals that need them can have. The permissions approval is called an "application role assignment" or a "consent grant".
Certain permissions on some Microsoft APIs (see below) can pose a serious threat to the entire Microsoft Entra tenant, because a service principal with these permissions becomes very powerful while being more discreet than a user with a powerful administrator role such as Global Administrator. Abusing this can allow an attacker to bypass the Multi-Factor Authentication (MFA) and resist user password resets.
When legitimate, the permissions increase the attack surface for the tenant. When they are not legitimate, it can be an malicious attempt to escalate privileges or persistence method. 
There are two types of API permissions in Microsoft Entra ID as described in the Microsoft documentation <a href="https://learn.microsoft.com/en-us/azure/active-directory/develop/permissions-consent-overview">Introduction to permissions and consent</a>:
<ul>
<li>Application permissions: The consent comes from administrators and the permissions apply tenant-wide.</li>
<li>Delegated permissions: The consent comes from users or administrators on behalf of the entire organization. Note that these permissions limit the application's ability to perform actions based on the signed-in user's privilege (i.e. the intersection of the permission and the user's privilege level). Therefore, the dangerousness of these delegated permissions depends on the actual permissions of the user of the application, as described in <a href="https://learn.microsoft.com/en-us/security/zero-trust/develop/developer-strategy-delegated-permission">Developing delegated permissions strategy</a>. Example: If a normal user delegated the "Group.ReadWrite.All" permission, it actually allows the application to modify only the groups that the user can edit and not all groups.</li>
</ul>
This Indicator of Exposure examines both types of permissions. It only reports on service principals because API permissions can only apply to service principals and not users.
This Indicator of Exposure is also focused on permissions that allow access to the <a href="https://learn.microsoft.com/en-us/graph/overview">Microsoft Graph API</a> and the legacy <a href="https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview">Azure AD Graph API</a>. In particular, the following dangerous permissions can pose a security risk:
<ul>
<li><code>RoleManagement.ReadWrite.Directory</code>: Allows attackers to elevate themselves to the Global Administrator role.</li>
<li><code>AppRoleAssignment.ReadWrite.All</code>: Allows attackers to grant themselves the <code>RoleManagement.ReadWrite.Directory</code> permission (see above).</li>
</ul>
Legitimate applications with these dangerous permissions ask for permissions that may be too broad. This can also signal a phishing attack called an "illicit consent grant", where an attacker succeeds in obtaining the consent of an administrator.

Phishing

Steal Application Access Token

Use Alternate Authentication Material: Application Access Token

[MITRE ATT&CK®] T1566 (Phishing)

[MITRE ATT&CK®] T1528 (Steal Application Access Token)

[MITRE ATT&CK®] T1550.001 (Use Alternate Authentication Material: Application Access Token)

Dangerous API Permissions Affecting the Tenant

First-Party Service Principals have powerful permissions while being overlooked because they are hidden, owned by Microsoft and numerous. Attackers add credentials to them to stealthily benefit from their privileges for privilege escalation and persistence.

First-Party Service Principals (Enterprise Applications) come from applications (Application Registrations) belonging to Microsoft. Most of them have sensitive permissions in Microsoft Entra ID that you often overlook during security reviews. This allows attackers to add credentials to them to stealthily benefit from their privileges.
This technique offers persistence capabilities as well as privilege escalation, because principals with the Application Administrator role can add credentials to applications including those that have higher privileges.
First-party service principals should not have any credentials, except in rare cases (see Recommendations).
The APT29 threat group abused this method in the infamous December 2020 attack against SolarWinds called "Solorigate", as documented <a href="https://www.microsoft.com/en-us/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/">by Microsoft</a> and <a href="https://www.mandiant.com/sites/default/files/2021-11/wp-m-unc2452-000343.pdf#page=29">by Mandiant</a>.

Azure AD privilege escalation - Taking over default application permissions as Application Admin

Account Manipulation: Additional Cloud Credentials

[MITRE ATT&CK®] T1098.001 (Account Manipulation: Additional Cloud Credentials)

First-Party Service Principal With Credentials

MFA provides strong protection for accounts against weak or breached passwords. Security best practices and standards recommend that you enable MFA, even for non-privileged accounts. Accounts without an MFA method registered cannot benefit from it.

Multi-Factor Authentication (MFA), or previously Two-Factor Authentication (2FA), provides strong protection for accounts against weak or breached passwords. Security best practices and standards recommend that you enable MFA, even for non-privileged accounts.
When an attacker obtains a user password by any method, MFA blocks authentication by requesting an additional factor such as a time-expiring code from a mobile application, a physical token, a biometric feature, etc.
This Indicator of Exposure alerts you when an account does not have a registered MFA method or if you enforce MFA without registering a method, which can allow attackers with a password to register their own MFA methods and create a security risk. However, this Indicator of Exposure cannot report on whether or not Microsoft Entra ID enforces MFA as Conditional Access Policies may require MFA depending on dynamic criteria.
See also the related IOE, "Missing MFA for Privileged Account", for privileged accounts.

Name	Description	Severity
Known Federated Domain Backdoor	Microsoft Entra ID can delegate authentication to another authentication provider: a feature called federation. Attackers who gained elevated privileges, can abuse this legitimate feature, by adding their malicious federated domain thus enabling persistence and privilege escalation.	Critical
Dangerous API Permissions Affecting the Tenant	Microsoft exposes APIs in Entra ID to allow 3rd-party applications to perform actions on Microsoft services. Certain permissions can pose a serious threat to the entire Microsoft Entra tenant. Therefore, their assignment must be carefully reviewed.	High
First-Party Service Principal With Credentials	First-Party Service Principals have powerful permissions while being overlooked because they are hidden, owned by Microsoft and numerous. Attackers add credentials to them to stealthily benefit from their privileges for privilege escalation and persistence.	High
Missing MFA for Non-Privileged Account	MFA provides strong protection for accounts against weak or breached passwords. Security best practices and standards recommend that you enable MFA, even for non-privileged accounts. Accounts without an MFA method registered cannot benefit from it.	Medium

Detections

Analytics

Indicators of Exposure

Critical

High

High

Medium