Escalating Privileges using a misconfigured service principal
Tags: azure, pentest, cloudsecurity
Published: 2022-04-05 16:02:01

---
title: Escalating Privileges using a misconfigured service principal
published: true
description: 
tags: Azure, PenTest, CloudSecurity
//cover_image: https://direct_url_to_image.jpg
---
* Test at your own risk

1.Open a new Powershell session(as an administrator) in your machine. Import the PowerZure module using the following commands.
```
PS C:\> cd C:\Users\$env:USERNAME\PowerZure
Import-Module .\PowerZure.ps1
```
You can see that the current user is assigned the Reader role in the subscription. You can also validate this with the Show-AzureCurrentUser function of PowerZure.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rlj46xi9aupx2k6lmtek.PNG)

2.Let's verify whether the current user is assigned as the owner of a service principal using the following command.

The Get-AzureAppOwner command is one of the function of PowerZure. It recursively looks through each registered application in Azure AD and lists the owners. The output shows that readeruser is assigned ownership of an application called customapp. Ownership allows different permissions on the app, including adding a new secret. While this is not an inherent permission for the Reader role, application ownership rights can be assigned to any account.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/iwkthv0puq16h6lgltvr.PNG)

3.Add a new secret to customapp to allow us to authenticate with the app using the following command. Remember that we are doing all this as a user that is assigned the Reader role.

Awesome! The new secret was successfully added. This means that we can authenticate as this service principal with the secret that we just set and then explore its permissions. Make a note of the displayed application ID and the tenant ID as we will need both to authenticate as the service principal.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lfsynben0hrg8o6fc1hj.PNG)

4.Switch to WSL and authenticate as the service principal using the following commands. Replace APP_ID with the application ID that you made a note of in Step 3. Replace TENANT_ID with the tenant ID that you made a note of in Step 3. Press Enter.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1cx4kruvh7x158tiufg5.PNG)
You are now logged in as the service principal. Next, we will verify the permissions that this service principal has.

5.Verify the role assignment and scope of the service principal using the following command. Replace APP_ID with the application ID that you made a note of in Step 3.
You can see that this service principal is assigned the Contributor role at the subscription scope. Awesome! We have found a route to a role assignment that gives us more permissions than that of the current user!
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/o9m1fvp24ydkf7g1y37e.PNG)
While the Reader roles (Global Reader in Azure AD and Reader in Azure RBAC) normally do not have ownership permissions on service principals, remember that member users in an Azure AD tenant have permissions to register applications and they are automatically made the owner of applications that they registered. Also, there are occasional situations where ownership rights are given to users. Since these ownership rights could pop up at any role level, we thought it would be good to address them early on.

One permission that is always available for the Reader role is the ability to connect to and pull images from Azure Container Registry(ACR). These rights don't allow readers to make changes to the images, but it does allow them to review the images.

**Reference**
https://github.com/PacktPublishing/Penetration-Testing-Azure-for-Ethical-Hackers