Microsoft Entra ID peut déléguer l'authentification à un autre fournisseur d'authentification : cette fonctionnalité s'appelle la fédération. Les attaquants qui obtiennent des privilèges élevés peuvent exploiter cette fonction légitime en ajoutant leur propre domaine fédéré malveillant, ce qui permet la persistance et l'élévation des privilèges.

Un tenant Microsoft Entra peut <a href="https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed">être fédéré avec un domaine externe</a> pour établir une relation d'approbation avec un autre domaine à des fins d'authentification et d'autorisation. Les organisations utilisent la fédération pour déléguer l'authentification des utilisateurs Active Directory à leur Active Directory Federation Services (AD FS) sur site. (Remarque : le domaine externe n'est pas un « domaine » Active Directory).
Mais si des acteurs malveillants obtiennent des privilèges élevés dans Microsoft Entra ID, ils peuvent exploiter ce mécanisme de fédération pour créer une porte dérobée en ajoutant leur propre domaine fédéré ou en modifiant un domaine existant pour ajouter une configuration secondaire avec leurs propres paramètres. Une attaque de ce type permet d'exécuter les actions suivantes :
<ul>
<li>Usurpation d'identité : le domaine fédéré malveillant peut générer des jetons permettant à un attaquant de s'authentifier en tant que n'importe quel utilisateur Microsoft Entra sans connaître ni réinitialiser son mot de passe. Cela comprend les utilisateurs « cloud seulement » (non hybrides) et les utilisateurs externes. Des attaques peuvent alors viser Microsoft Entra ID, Microsoft 365 (O365) et d'autres applications qui utilisent Microsoft Entra ID comme fournisseur d'identité (SSO), même si vous forcez l'authentification MFA (voir ci-dessous).</li>
<li>Élévation de privilèges : l'attaquant peut usurper l'identité de n'importe quel utilisateur, notamment ceux qui ont des privilèges Microsoft Entra ID.</li>
<li>Contournement de l'authentification multifacteur : avec l'authentification fédérée, le domaine externe de confiance <a href="https://learn.microsoft.com/en-us/graph/api/resources/internaldomainfederation?view=graph-rest-beta#federatedidpmfabehavior-values">prend le rôle de forcer l'authentification MFA</a>. Le domaine fédéré malveillant peut alors affirmer faussement que l'authentification usurpée a utilisé l'authentification MFA ; Microsoft Entra ID va alors lui faire confiance et ne demandera plus de nouvelle authentification MFA. Ainsi, l'attaquant peut usurper l'identité de tous les utilisateurs, même s'il existe une protection MFA.</li>
<li>Persistance : l'ajout d'un domaine fédéré malveillant est une technique furtive qui permet aux attaquants qui ont compromis le tenant Microsoft Entra ID et ont acquis des privilèges élevés d'y accéder facilement à nouveau par la suite.</li>
</ul>
Cet indicateur d'exposition détecte les portes dérobées de domaine fédéré créées par le kit de piratage <a href="https://aadinternals.com/">AADInternals</a>, en particulier les cmdlets <code>ConvertTo-AADIntBackdoor</code> et <code>New-AADIntBackdoor,</code> en fonction de certaines caractéristiques du domaine de porte dérobée créé ou converti.
Le protocole de fédération qui transmet la preuve d'authentification du domaine fédéré malveillant au Microsoft Entra ID attaqué peut être WS-Federation ou SAML. Avec SAML, l'attaque ressemble à une attaque « <a href="https://www.mandiant.com/sites/default/files/2021-11/wp-m-unc2452-000343.pdf#page=9">Golden SAML</a> », mais avec les principales différences suivantes :
<ul>
<li>Au lieu de voler la clé de signature SAML légitime d'une fédération existante, les attaquants injectent leur nouveau domaine avec leur propre clé. </li>
<li>Les attaquants utilisent le jeton pour la fédération plutôt que pour accéder à un service.</li>
</ul>
L'autorisation <code>microsoft.directory/domains/federation/update</code> donne la possibilité de modifier les domaines fédérés. En janvier 2023, les rôles Microsoft Entra intégrés suivants disposent de cette autorisation, en plus d'éventuels rôles personnalisés :
<ul>
<li>« <a href="https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#global-administrator">Administrateur général</a> »</li>
<li>« <a href="https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#security-administrator">Administrateur de sécurité</a> »</li>
<li>« <a href="https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#hybrid-identity-administrator">Administrateur d'identité hybride</a> »</li>
<li>« <a href="https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#external-identity-provider-administrator">Administrateur de fournisseurs d'identité externes</a> »</li>
</ul>
Le groupe d'attaquants APT29 a exploité cette méthode lors de la fameuse attaque « Solorigate » de décembre 2020 contre SolarWinds, comme l'ont documenté <a href="https://www.microsoft.com/en-us/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/">Microsoft</a> et <a href="https://www.mandiant.com/sites/default/files/2021-11/wp-m-unc2452-000343.pdf#page=23">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)

Porte dérobée de domaine fédéré connue

Microsoft expose des API dans Entra ID pour permettre à des applications tierces d'effectuer des actions sur les services Microsoft. Certaines autorisations peuvent constituer une grave menace pour l'ensemble du tenant Microsoft Entra. Vous devez donc vérifier leur attribution attentivement.

Microsoft expose des API par l'intermédiaire d'applications dans Entra ID pour permettre à des applications tierces d'effectuer des actions au sein de Microsoft Entra ID, de Microsoft 365 (O365), du cloud Azure, etc. Des « autorisations d'API » protègent l'accès à ces API, et seuls les principaux de service qui en ont besoin peuvent les obtenir. L'approbation des autorisations s'appelle « attribution de rôle d'application » ou « octroi d'autorisation ».
Certaines autorisations sur certaines API Microsoft (voir ci-dessous) peuvent représenter une grave menace pour l'ensemble du tenant Microsoft Entra ID, car un principal de service qui dispose de ces autorisations devient très puissant, tout en étant plus discret qu'un utilisateur disposant d'un rôle d'administrateur puissant tel que l'Administrateur général. En exploitant ces autorisations, un attaquant peut contourner l'authentification multifacteur (MFA) et résister aux réinitialisations de mot de passe des utilisateurs.
Lorsqu'elles sont légitimes, les autorisations augmentent la surface d'attaque pour le tenant. Lorsqu'elles ne le sont pas, il peut s'agir d'une tentative malveillante d'élévation de privilèges ou d'une méthode de persistance. 
Il existe deux types d'autorisations d'API dans Microsoft Entra ID, comme décrit dans la documentation Microsoft <a href="https://learn.microsoft.com/en-us/azure/active-directory/develop/permissions-consent-overview">Présentation des autorisations et du consentement</a> :
<ul>
<li>Autorisations d’application : le consentement est donné par les administrateurs et les autorisations s'appliquent à l'ensemble du tenant (locataire).</li>
<li>Autorisations déléguées : le consentement est donné par les utilisateurs ou les administrateurs au nom de l'ensemble de l'organisation. Notez que ces autorisations limitent la possibilité pour une application d'effectuer des actions, sur la base des privilèges de l'utilisateur connecté (autrement dit, ses possibilités se limitent à l'intersection de l'autorisation et du niveau de privilège de l'utilisateur). Par conséquent, la dangerosité de ces autorisations déléguées dépend des autorisations réelles de l'utilisateur de l'application, comme décrit dans la section <a href="https://learn.microsoft.com/en-us/security/zero-trust/develop/developer-strategy-delegated-permission">Développement d'une stratégie de délégation des autorisations</a>. Exemple : si un utilisateur standard délègue l'autorisation « Group.ReadWrite.All », l'application peut modifier uniquement les groupes que l'utilisateur peut modifier et non pas tous les groupes.</li>
</ul>
Cet indicateur d'exposition examine les deux types d'autorisations. Il ne porte que sur les principaux de service, car les autorisations d'API ne peuvent s'appliquer qu'aux principaux de service, et non pas aux utilisateurs.
Cet indicateur d'exposition porte également sur les autorisations qui permettent d'accéder à l'<a href="https://learn.microsoft.com/en-us/graph/overview">API Microsoft Graph</a> et à l'<a href="https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview">API Azure AD Graph</a> obsolète. En particulier, les autorisations dangereuses suivantes peuvent présenter un risque de sécurité : 
<ul>
<li><code>RoleManagement.ReadWrite.Directory</code> : permet aux attaquants d'acquérir le rôle d'Administrateur général.</li>
<li><code>AppRoleAssignment.ReadWrite.All</code>: : permet aux attaquants de s'accorder l'autorisation <code>RoleManagement.ReadWrite.Directory</code> (voir ci-dessus).</li>
</ul>
Les applications légitimes disposant de ces autorisations dangereuses demandent des autorisations qui peuvent être trop larges. Ce peut également être le signe d'une attaque par hameçonnage appelée « octroi d'autorisation illicite », au cours de laquelle un attaquant réussit à obtenir le consentement d'un administrateur.

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)

Autorisations d'API dangereuses affectant le tenant

Les principaux de service propriétaires (ou internes) disposent de puissantes autorisations, mais ils sont négligés parce qu'ils sont cachés, nombreux et détenus par Microsoft. Les attaquants y ajoutent des identifiants pour exploiter discrètement leurs autorisations à des fins d'élévation de privilèges et de persistance.

Les principaux de service propriétaires/internes (applications d'entreprise) proviennent d'applications (inscription d'applications) qui appartiennent à Microsoft. La plupart d'entre eux disposent d'autorisations sensibles dans Microsoft Entra ID que vous négligez généralement lors des vérifications de sécurité. Des attaquants peuvent donc y ajouter des identifiants pour exploiter discrètement leurs privilèges.
Cette technique donne accès à des capacités de persistance et d'élévation des privilèges, car les principaux ayant le rôle d'Administrateur d'application peuvent ajouter des identifiants aux applications, y compris à celles qui ont des privilèges plus élevés.
Les principaux de service propriétaires (internes) ne doivent pas disposer d'identifiants, sauf dans de rares cas (voir les recommandations).
Le groupe de menace APT29 a exploité cette méthode lors de la fameuse attaque « Solorigate » de décembre 2020 contre SolarWinds, comme l'ont documenté <a href="https://www.microsoft.com/en-us/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/">Microsoft</a> et <a href="https://www.mandiant.com/sites/default/files/2021-11/wp-m-unc2452-000343.pdf#page=29">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)

Principal de service propriétaire (ou interne) avec identifiants

L'authentification MFA, ou multifacteur, protège efficacement les comptes contre les mots de passe faibles ou compromis. Les bonnes pratiques et les normes de sécurité recommandent d'activer l'authentification MFA, même pour les comptes non privilégiés. Les comptes pour lesquels aucune méthode MFA n'a été enregistrée ne peuvent pas en bénéficier.

L'authentification multifacteur (MFA), ou auparavant, authentification à deux facteurs (2FA), protège efficacement les comptes contre les mots de passe faibles ou compromis. Les bonnes pratiques et les normes de sécurité recommandent d'activer l'authentification MFA, même pour les comptes non privilégiés.
Lorsqu'un attaquant obtient le mot de passe d'un utilisateur par une méthode quelconque, l'authentification MFA bloque l'authentification en demandant un facteur supplémentaire tel qu'un code valide temporairement provenant d'une application mobile, un jeton physique, une caractéristique biométrique, etc.
Cet indicateur d'exposition signale les comptes qui ne disposent pas de méthode MFA enregistrée et vous informe si vous forcez l'authentification MFA sans avoir enregistré de méthode. En effet, ce cas de figure peut permettre à des attaquants disposant d'un mot de passe d'enregistrer leurs propres méthodes MFA et de créer un risque de sécurité. Cependant, cet indicateur d'exposition n'indique pas si Microsoft Entra ID force ou non l'authentification MFA, car les stratégies d'accès conditionnel peuvent exiger l’authentification MFA en fonction de critères dynamiques.
Voir aussi l'IOE connexe, « Authentification MFA manquante pour un compte privilégié », pour les comptes privilégiés.

Nom	Description	Niveau de gravité
Porte dérobée de domaine fédéré connue	Microsoft Entra ID peut déléguer l'authentification à un autre fournisseur d'authentification : cette fonctionnalité s'appelle la fédération. Les attaquants qui obtiennent des privilèges élevés peuvent exploiter cette fonction légitime en ajoutant leur propre domaine fédéré malveillant, ce qui permet la persistance et l'élévation des privilèges.	Critical
Autorisations d'API dangereuses affectant le tenant	Microsoft expose des API dans Entra ID pour permettre à des applications tierces d'effectuer des actions sur les services Microsoft. Certaines autorisations peuvent constituer une grave menace pour l'ensemble du tenant Microsoft Entra. Vous devez donc vérifier leur attribution attentivement.	High
Principal de service propriétaire (ou interne) avec identifiants	Les principaux de service propriétaires (ou internes) disposent de puissantes autorisations, mais ils sont négligés parce qu'ils sont cachés, nombreux et détenus par Microsoft. Les attaquants y ajoutent des identifiants pour exploiter discrètement leurs autorisations à des fins d'élévation de privilèges et de persistance.	High
Authentification MFA manquante pour un compte non privilégié	L'authentification MFA, ou multifacteur, protège efficacement les comptes contre les mots de passe faibles ou compromis. Les bonnes pratiques et les normes de sécurité recommandent d'activer l'authentification MFA, même pour les comptes non privilégiés. Les comptes pour lesquels aucune méthode MFA n'a été enregistrée ne peuvent pas en bénéficier.	Medium

Détections

Indicateurs d'exposition

Critical

High

High

Medium