Securing Service Principals

How Entra ID App Registrations / Enterprise Applications are comonly misconfigured and can be used by attackers to elevate privileges, access sensitive information and move laterally across Azure tenancies.

Entra ID Service Principals are akin to on-prem service accounts and are used by applications to authenticate to Azure and access Entra ID roles, MS Graph permissions and Azure RBAC roles. This allows applications, automated tools and other Azure services to access resources without having to use a set of user credentials.

Service Principals can be granted permission to do pretty much anything in Azure, Entra ID and Microsoft 365, including accessing mailboxes, configuring user accounts. Accessing encryption keys and pulling data from storage accounts for example.

When an application is registered in the “App Registrations” blade in the Azure portal it will automatically create an application object which will be listed in the “App Registration” blade, and a service principal object, which be listed under the “Enterprise Apps” blade. The application is the master blueprint for the application and the service principal is an instantiation of that application within the tenant, you can have service principals in multiple tenants that point back a single app registration.

The Application Object or App Registration defines the permissions required by the application, who has ownership over the application, along with any credentials (secrets and certificates) used by application to authenticate to respective tenancies. The service principal, which is an instantiation of the application, is where any required API permissions are actually granted and can be given roles in Entra ID as well as Azure RBAC.

A much more detailed description of service principals along with their configuration and usage can be found here - https://identity-man.eu/2021/03/19/service-principals-all-you-need-to-know/

Application Administrators

Application Administrator and Cloud Application Administrator are Entra ID roles that enable users to configure service principals:

  • Cloud Application Administrator - Can create and manage all aspects of app registrations and enterprise apps except App Proxy.
  • Application Administrator - Can create and manage all aspects of app registrations and enterprise apps.

From a security perspective, Application Administrators (as well as Global Administrators) can configure existing app registrations, including assigning ownership and registering new credentials. Therefore, any privileges afforded to service principals can also be leveraged by Entra ID users with an application administrator role. If any of these privileges are greater than what the user currently has, this presents a privilege escalation path. Additionally, this also presents a potential path for an attacker to access sensitive resources with the wider Azure and M365 environment. if an attacker is able to compromise a user account with an Application Administrator role and add credentials to an application with the “‘Mail.Read’” API permission for example, they could then read peoples emails and exfiltrate data from M365 mailboxes.

Shadow Administrators

Entra ID Roles

Something that crops up on cloud configuration reviews alarmingly often is the granting of Service Principals privileged Entra ID roles (Global Administrator, Privileged Authentication Administrator and Privileged Role Administrator), coupled with users, which hold none of these privileged roles, being granted an application administrator role. This means, these users are “Shadow Admins” as they can simply add a credential to a privileged application and gain effective global administrator privileges within the tenancy.

App roles / API permissions

Similarly, application administrators can often end up in a shadow admin position through the over application of sensitive MS Graph App roles / API permissions.

If a service principal has either of the following MS Graph app roles then it is effectively a Global Administrator as it can simply promote itself to the role.

  • RoleManagement.ReadWrite.Directory
  • AppRoleAssignment.ReadWrite.All

Additionally, although not considered Shadow Admin, the following API permissions are marked as sensitive by Microsoft and should be handled carefully plus monitored closely:

  • Mail.* (including Mail.Send*, but not Mail.ReadBasic*)
  • Contacts. *
  • MailboxSettings.*
  • People.*
  • Files.*
  • Notes.*
  • Directory.AccessAsUser.All
  • User_Impersonation

Delegated and AppOnly versions of the following permissions:

  • Application.ReadWrite.All
  • Directory.ReadWrite.All
  • Domain.ReadWrite.All*
  • EduRoster.ReadWrite.All*
  • Group.ReadWrite.All
  • Member.Read.Hidden*
  • RoleManagement.ReadWrite.Directory
  • User.ReadWrite.All*
  • User.ManageCreds.All

Although less important, all other AppOnly permissions that allow write access

Foreign / External Service Principals

As mentioned previously, service principals can be configured across multiple tenancies for a single application. In this scenario, the app registration is potentially controlled by the foreign tenant, meaning an attacker within the external tenant can add credentials to the registration and leverage them to gain privileged access to your tenancy and or resources. This risk was highlighted in the January 25, 2024, disclosure by Microsoft, where Russia’s SVR exploited such a trust relationship to breach Microsoft’s own corporate Entra ID environment.

What To Do

For existing workloads, a security audit / cloud configuration review can identity service principals that are considered overly privileged and users that are considered to be shadow admins. This helps you fully understand the risk and to devise potential remediation and mitigation plans.

Also, when registering a new application in your tenancy, follow the standard security advice of granting least privilege by granting only the minimum set of permissions required for the application to function. Start with no or minimal permissions and grant additional permissions as necessary. Doing so is more secure than starting with permissions that are too lenient and then trying to tighten them later.

Monitor the creation of new application credentials, as well as ownership changes as this is often a sign of malicious activity. Also keep an eye on sign-in logs for suspicious activity related to service principals.

Regularly review all foreign applications with privileged roles and remove as necessary, application developers may specify certain privileged roles and API permissions in order to use the application, but this is often not the case and when pushed the application will function perfectly fine with a smaller for fine grain set of permissions. Finally, secure your supply chain and perform third party assurance to ensure suppliers are themselves following good security practices and are honouring contractual obligations.

Links