Language:
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.
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:
You cannot list service principal credentials using the Azure portal, unlike credentials attached to applications. Use the following cmdlets from the AzureAD PowerShell Module to list service principal credentials:
Get-AzureADServicePrincipalKeyCredential
Get-AzureADServicePrincipalPasswordCredential
To delete these credentials, use:
Remove-AzureADServicePrincipalKeyCredential
Remove-AzureADServicePrincipalPasswordCredential
Name: First-Party Service Principal With Credentials
Codename: FIRST-PARTY-SERVICE-PRINCIPAL-WITH-CREDENTIALS
Severity: High
Techniques: T1098.001
More: Azure AD privilege escalation - Taking over default application permissions as Application Admin