Les comptes hybrides (synchronisés à partir d'Active Directory) qui ont des rôles privilégiés dans Entra ID présentent un risque pour la sécurité, car ils permettent aux attaquants qui compromettent AD de pivoter vers Entra ID. Dans Entra ID, les comptes privilégiés doivent être des comptes « cloud seulement ».

Si votre organisation a configuré la <a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/what-is-inter-directory-provisioning">synchronisation des annuaires</a>, par exemple avec « <a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-azure-ad-connect">Microsoft Entra Connect</a> » (anciennement « Azure AD Connect ») ou « <a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync">Microsoft Entra Cloud Sync</a> » (anciennement « Azure AD Connect Cloud Sync »), pour synchroniser (entre autres) les utilisateurs d'Active Directory sur site avec Entra ID dans le cloud, vous pourriez être tenté d'utiliser des comptes AD hybrides pour les rôles privilégiés dans Entra ID. Cependant, cela crée une opportunité de pivot pour les attaquants, qui pourraient ainsi étendre leur contrôle malveillant sur Entra ID après avoir compromis Active Directory. Ils disposent de plusieurs techniques pour usurper l'identité des utilisateurs AD et peuvent également les appliquer à Entra ID.
C'est pourquoi Microsoft met en garde contre cette pratique dans son article « <a href="https://learn.microsoft.com/en-us/entra/architecture/protect-m365-from-on-premises-attacks">Protéger Microsoft 365 des attaques locales</a> », considérant qu'« il ne devrait y avoir aucun compte sur site disposant de privilèges d'administration dans Microsoft 365 » et recommandant de s'assurer qu'« aucun compte sur site ne dispose de privilèges élevés pour Microsoft 365 ».

Modify Authentication Process: Hybrid Identity

[MITRE ATT&CK®] T1556.007 (Modify Authentication Process: Hybrid Identity)

Compte Entra privilégié synchronisé avec AD (hybride)

Protecting Microsoft 365 from on-premises attacks

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

Microsoft Entra ID permet de déléguer l'authentification à un autre fournisseur via la fédération. Toutefois, les attaquants disposant de privilèges élevés peuvent exploiter cette fonction 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/entra/identity/hybrid/connect/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).
Cependant, 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. Cette attaque permettrait 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.
Reportez-vous également à l'indicateur d'exposition connexe « Federation Signing Certificates Mismatch » (Non-concordance des certificats de signature de fédération).
Le protocole de fédération utilisé pour transmettre la preuve d'authentification du domaine fédéré malveillant au Microsoft Entra ID ciblé peut être WS-Federation ou SAML. Lors de l'utilisation de 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 présentent le faux jeton au service de fédération pour obtenir un accès non autorisé à plusieurs systèmes, plutôt que de le présenter à un service spécifique.</li>
</ul>
Les autorisations <code>microsoft.directory/domains/allProperties/allTasks</code> et <code>microsoft.directory/domains/federation/update</code> donnent aux administrateurs la possibilité de modifier les domaines fédérés. En novembre 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/entra/identity/role-based-access-control/permissions-reference#domain-name-administrator">Administrateur de nom de domaine</a> »</li>
<li>« <a href="https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#external-identity-provider-administrator">Administrateur de fournisseurs d’identité externes</a> »</li>
<li>« <a href="https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#hybrid-identity-administrator">Administrateur d'identité hybride</a> »</li>
<li>« <a href="https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#global-administrator">Administrateur général</a> »</li>
<li>« <a href="https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#partner-tier2-support">Prise en charge de niveau 2 de partenaire</a> »</li>
<li>« <a href="https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#security-administrator">Administrateur de sécurité</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

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.
Vous pouvez également utiliser les fonctions « <a href="https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-methods-activity">Activité des méthodes d'authentification</a> » et « <a href="https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-reporting">Rapports MFA</a> » dans Entra ID.
Voir aussi l'IOE connexe, « Authentification MFA manquante pour un compte privilégié », pour les comptes privilégiés.

Account Manipulation

Brute Force

Modify Authentication Process: Multi-Factor Authentication

Valid Accounts: Cloud Accounts

[MITRE ATT&CK®] T1098 (Account Manipulation)

[MITRE ATT&CK®] T1110 (Brute Force)

[MITRE ATT&CK®] T1556.006 (Modify Authentication Process: Multi-Factor Authentication)

[MITRE ATT&CK®] T1078.004 (Valid Accounts: Cloud Accounts)

Authentification MFA manquante pour un compte non privilégié

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/entra/identity-platform/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.

Détections

Indicateurs d'exposition

High

High

Critical

Medium

High