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

Un tenant Microsoft Entra peut être fédéré avec un domaine externe 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 :

• 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).
• É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.
• Contournement de l'authentification multifacteur : avec l'authentification fédérée, le domaine externe de confiance prend le rôle de forcer l'authentification MFA. 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.
• 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.

Cet indicateur d'exposition détecte les portes dérobées de domaine fédéré créées par le kit de piratage AADInternals, en particulier les cmdlets ConvertTo-AADIntBackdoor et New-AADIntBackdoor, 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 « Golden SAML », mais avec les principales différences suivantes :

• 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é.
• Les attaquants utilisent le jeton pour la fédération plutôt que pour accéder à un service.

L'autorisation microsoft.directory/domains/federation/update 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 :

• « Administrateur général »
• « Administrateur de sécurité »
• « Administrateur d'identité hybride »
• « Administrateur de fournisseurs d'identité externes »

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é Microsoft et Mandiant.

Ce résultat indique une porte dérobée potentielle. Lancez une procédure de réponse aux incidents avec une analyse forensique, afin de confirmer l'attaque présumée, d'identifier l'auteur et l'heure de l'attaque, ainsi que l'étendue de l'intrusion potentielle.

Microsoft considère que la fédération est une fonctionnalité légitime de Microsoft Entra ID, et cette attaque l'exploite. Microsoft insiste sur le fait qu'un attaquant doit obtenir des privilèges élevés pour créer cette porte dérobée. C'est la raison pour laquelle vous devez limiter le nombre d'administrateurs ayant la possibilité de modifier les paramètres de fédération. Pour plus d'informations, voir l'autorisation spécifique et la liste des rôles dans la description de la vulnérabilité.

Pour vérifier la liste des domaines fédérés dans le portail Azure, ouvrez le panneau « Noms de domaine personnalisés » et recherchez ceux qui sont cochés dans la colonne « Fédérés ». Le nom du domaine potentiellement malveillant est le même que celui que vous voyez dans le résultat. Mais contrairement à l'API MS Graph, le portail Azure n'affiche pas les détails techniques de la fédération.

Les cmdlets PowerShell de l'API MS Graph permettent de lister les domaines avec Get-MgDomain et leur configuration de fédération avec Get-MgDomainFederationConfiguration` :

Connect-MgGraph -Scopes "Domain.Read.All"
Get-MgDomain -All | Where-Object { $_.AuthenticationType -eq "Federated" } | ForEach-Object { $_ ; Get-MgDomainFederationConfiguration -DomainId $_.Id }

Après avoir enregistré les preuves en vue d'une éventuelle analyse forensique :

• Si le domaine n'est pas légitime, supprimez-le en utilisant Remove-MgDomain.
• Si le domaine est légitime et que la configuration de fédération est malveillante, supprimez-la en utilisant Remove-MgDomainFederationConfiguration.

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

Nom de code: KNOWN-FEDERATED-DOMAIN-BACKDOOR

Niveau de gravité: Critical