First-Party Service Principal With Credentials

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 by Microsoft and by Mandiant.

Disabled service principals are ignored by default (parameter can be changed) because they cannot be immediately used by attackers.

Begin by evaluating the legitimacy of the observed credentials. You may consider these credentials to be legitimate if they associate with one of the following service principals: Exchange Online / Skype for Business / AAD Password Protection Proxy.

In other cases where you suspect that the credentials are not legitimate:

• Perform a forensic investigation because it can signal an attack. The goal is to confirm the alleged attack, identify who did it and when, and what is the extent of the potential intrusion.
• Review the audit logs to identify when they were added and whether they are or have been used.
• Check expired credentials too, because a threat actor could have used them in the past even though they are no longer usable.

You cannot list service principal credentials using the Azure portal, unlike credentials attached to applications. Use the Get-MgServicePrincipal cmdlet of Microsoft Graph PowerShell to list service principal credentials:

• For key credentials: Get-MgServicePrincipal -ServicePrincipalId <objectid> -Property keyCredentials | select -ExpandProperty keyCredentials
• For password credentials: Get-MgServicePrincipal -ServicePrincipalId <objectid> -Property passwordCredentials | select -ExpandProperty passwordCredentials

To delete these credentials, use:

• For key credentials: the normal method is to use Remove-MgServicePrincipalKey, however it requires a "proof of possession" for which you need to have access to the private key which will not always be possible. In that case, you can circumvent this by first obtaining the key credentials array with $keycredentials = (Get-MgServicePrincipal -ServicePrincipalId <objectid>).KeyCredentials, then removing the undesired one(s) from $keycredentials, and finally by applying this new array with Update-MgServicePrincipal -ServicePrincipalId <objectid> -KeyCredentials $keycredentials. To clear all you can use simply: Update-MgServicePrincipal -ServicePrincipalId <objectid> -KeyCredentials @().
• For password credentials: Remove-MgServicePrincipalPassword (which does not have the same issue)

Or alternatively using the now deprecated AzureAD PowerShell Module:

• For key credentials: Get-AzureADServicePrincipalKeyCredential and Remove-AzureADServicePrincipalKeyCredential
• For password credentials: Get-AzureADServicePrincipalPasswordCredential and Remove-AzureADServicePrincipalPasswordCredential

Name: First-Party Service Principal With Credentials

Codename: FIRST-PARTY-SERVICE-PRINCIPAL-WITH-CREDENTIALS

Severity: High