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

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

Commencez par évaluer la légitimité des identifiants observés. Vous pouvez considérer que ces identifiants sont légitimes s'ils sont associés à l'un des principaux de service suivants : Exchange Online / Skype for Business / AAD Password Protection Proxy.

Dans les autres cas où vous soupçonnez que les identifiants ne sont pas légitimes :

• Procédez à une analyse forensique, car il peut s'agir d'une attaque. L'objectif est de confirmer l'attaque présumée, d'identifier l'auteur et le moment de l'attaque, et de déterminer l'étendue de l'intrusion potentielle.
• Consultez les journaux d'audit pour déterminer quand ils ont été ajoutés et s'ils sont ou ont été utilisés.
• Vérifiez également les identifiants qui ont expiré, car un attaquant peut les avoir utilisés dans le passé, même s'ils ne sont plus utilisables.

Vous ne pouvez pas établir la liste des identifiants des principaux de services en utilisant le portail Azure, contrairement aux identifiants liés aux applications. Utilisez la cmdlet Get-MgServicePrincipal de Microsoft Graph PowerShell pour lister les identifiants des principaux de services :

• Pour les identifiants de clé : Get-MgServicePrincipal -ServicePrincipalId <objectid> -Property keyCredentials | select -ExpandProperty keyCredentials
• Pour les identifiants de mot de passe : Get-MgServicePrincipal -ServicePrincipalId <objectid> -Property passwordCredentials | select -ExpandProperty passwordCredentials

Pour supprimer ces identifiants, utilisez :

• Pour les identifiants de clé : la méthode standard consiste à utiliser Remove-MgServicePrincipalKey, mais il faut disposer d'une « preuve de possession » qui nécessite d'avoir accès à la clé privée, ce qui ne sera pas toujours possible. Dans ce cas, vous pouvez contourner ce problème en obtenant au préalable le tableau des identifiants de clé avec $keycredentials = (Get-MgServicePrincipal -ServicePrincipalId <objectid>).KeyCredentials, puis en supprimant le ou les éléments indésirables de $keycredentials et enfin, en appliquant ce nouveau tableau avec Update-MgServicePrincipal -ServicePrincipalId <objectid> -KeyCredentials $keycredentials. Pour tout effacer, il suffit d'utiliser : Update-MgServicePrincipal -ServicePrincipalId <objectid> -KeyCredentials @().
• Pour les identifiants de mot de passe : Remove-MgServicePrincipalPassword (qui ne pose pas le même problème)

Vous pouvez également utiliser le module désormais obsolète AzureAD PowerShell Module:

• Pour les identifiants de clé : Get-AzureADServicePrincipalKeyCredential et Remove-AzureADServicePrincipalKeyCredential
• Pour les identifiants de mot de passe : Get-AzureADServicePrincipalPasswordCredential et Remove-AzureADServicePrincipalPasswordCredential

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

Nom de code: FIRST-PARTY-SERVICE-PRINCIPAL-WITH-CREDENTIALS

Niveau de gravité: High