This is how hackers exploit Azure App Registration

Should standard users in your tenant be allowed to complete an Azure App Registration? The answer is clearly “no” and this article clearly shows why. Otherwise, a single compromised standard account is enough for attackers to enormously increase their rights and gain access to personal emails. We first present a realistic one Attack scenario via the Azure App Registration and then explain which one simple measure you can protect yourself from it.

If you would like to first find out more about Microsoft Entra (formerly Azure AD), you can find all the basics in our basics article What is Microsoft Entra (formerly Azure) with lots of clear screenshots. You can find further articles on attacks and protection options here:

Table of Contents

What is Azure App Registration usually used for?

Microsoft Azure App Services is a versatile platform that developers can use to easily operate modern web applications. Although the name “App Services” might make you think of traditional apps, it is actually a so-called Platform as a Service (PaaS) cloud service from Microsoft, which offers a wide range of possibilities. The App Services consists of four main services:

  • Web Apps
  • API apps
  • Mobile Apps
  • Logic apps

The first three services are closely related to each other and only differ in small details. They enable developers to host and operate web applications, API services and mobile apps in the cloud. The fourth service, Logic Apps, is an innovative way to create and manage workflows without requiring extensive developer knowledge. Logic Apps allows developers to create declarative workflows that enable automated flows between different services and applications. In order for developers to use Microsoft's PaaS cloud service for their application, they must have a Azure app registration carry out. In the Default settings This is possible for every normal user of an Entra/Azure tenant. This represents an unnecessary security risk as we will show in the following section.

Attack on Entra/Azure Tenant via Azure App Registration

App registration is a way to secure access to an Azure portal. To do this we need the following requirements:

  • Azure tenant credentials as a non-privileged user
  • Azure Tenant in default configuration (unhardened)

Now we will go through the procedure as an attacker:

Step 1: Login to a compromised account

First, we log in to Entra/Azure with our compromised user.
Azure App Registration – Azure login window
Login to compromised Entra/Azure account

Step 2: Azure App Registration in the tenant of the compromised account

Next, we perform an Azure App Registration in the tenant (the name of the app appears in the phishing during the request for permissions from the victim).

Azure App Registration – App registrations menu
Azure app registration

For Azure App Registration, we select the “Accounts in any organizational directory” option.

Azure App Registration – Register Application submenu
Under “Supported account types” we select “Accounts in any organizational directory”.

Then we create a redirect URI. As an attacker, we provide an oAuth server under this URL.

Azure App Registration – Create redirect URI
We create a redirect URI to intercept credentials via an oAuth server.

Step 3: Adjust app settings

After Azure App Registration, we make the following settings to the app:
Under “Certificates & Secrets” we generate a secret client key.

Azure App Registration – Certificates & Secrets menu
In the “Certificates & Secrets” menu we generate a secret client key.

Now we have to go to “API permissions”. necessary Set permissions for “Microsoft Graph”:

  • Delegated authorization: “App” runs in the user context, no administrator consent is required.
  • Application authorization: “App” may run in the background, but without user context; administrator consent is required here.
  • We must be careful not to set too many permissions as these will be listed for our victim during the permission request.

An example configuration could look like this:

Azure App Registration - API permissions menu
In the “API permissions” menu we set some necessary permissions for Microsoft Graph.

Finally, under “Authentication” we need to set the “Allow public client flows” rule to “Yes” in order to be able to run the delegated permissions on an external oAuth server:

Azure App Registration – Authentication menu
In the “Authentication” menu we allow public client flows.

Step 4: Create and send a phishing link

After setting up the app, we create a phishing link with the following parameters:

- 'client_id=<App-ID aus “Übersicht”> &'
- 'response_type=code &'
- 'redirect_uri=<URL des oAuth-Servers> &'
- 'response_mode=query &'
- 'scope=<Notwendige App-Berechtigungen> &'
- 'stat=12345'
The result looks like this:

The reason for creating the phishing link is that the link created does not look like a “suspicious” URL. Our victim thus sees a regular and legitimate Microsoft login and can log in to Microsoft with his valid access data.

We can then send the phishing link by email.

Once a victim falls into the trap, they will see this message asking them to accept the permissions:

Azure App Registration – Phishing link view
Our phishing victims will be prompted to accept permissions.

Step 5: Intercept access token

When a victim accepts the permissions and logs in, a redirect follows to the oAuth server we provide. This is where the access token is intercepted.

Azure App Registration – Intercept access token via oAuth server
A phishing victim's access token is intercepted via the oAuth server.

Step 5: Use the intercepted access token

Finally, we can use the intercepted access token to authenticate ourselves in our victim's user context with the app's delegated permissions.

Possible permissions for a realistic attack scenario would be:

  1. Mail.Read: This makes it possible to read the victim's emails.
  2. Mail.Send: This allows the attacker to send an email on behalf of the victim. It is even possible to prevent emails from being stored in “Sent Items”!
  3. User.ReadBasic.All: Allows the attacker to enumerate all users of the tenant.
Azure App Registration – Attack scenario with Mail.Read
With the Mail.Read permission we can read the victim's emails.
Azure App Registration – Access scenario with User.ReadBasic.All
With the Mail.Send permission we can send emails on behalf of the victim - even without them appearing in the “Sent” folder.
Azure App Registration – Mail.Send attack scenario
With the User.ReadBasic.All permission we can enumerate all users of the tenant.

In summary, through the attack scenario presented here, we used the previously compromised account of a normal tenant user to obtain numerous additional permissions and information. For this we used Azure App Registration, which is freely available to all users in the standard settings.

In the following section we will show you how you can prevent such an attack in 3 simple steps.

Are you unsure whether your Active Directory is securely configured?
We'll find out for you so you can close vulnerabilities efficiently!
For the penetration test

How to protect yourself from an attack via Azure App Registration

It is advisable to allow only one administrator to register self-developed applications. This ensures that these applications undergo a formal security review and approval process before being granted access to Azure Active Directory data.

In certain cases, it may make sense to grant permissions to specific users, such as developers or other users with high requirements, to avoid long wait times for an administrative user. It is important to review policies and determine specific needs to ensure appropriate access control.

Therefore, we recommend prohibiting regular users from registering apps. This can be set in the Azure portal in the following 3 steps:

  1. Select Azure Active Directory
  2. Go to “User Settings” in the “Users” section
  3. Set the “Users can register applications” slider to “No”.
Azure App Registration – secure setting for regular users
Configure user settings securely: Normal users should not be allowed to register applications.

Conclusion: Reserve Azure App Registration for the administrator

In our realistic attack scenario we have shown why Azure App Registration should be reserved for the administrator of a tenant. Otherwise, attackers can enormously increase their rights via a single compromised account in just a few steps.

Attackers achieve this by using the compromised account Register app with specific settings, a Phishing link create and send it to potential further victims. If users agree to the set permissions via this link and enter their access data, the attackers will catch them oAuth server away. This allows them, for example, to send emails on behalf of the victims or enumerate all other users of the tenant.

To prevent such an attack, all it takes is a few clicks in the Microsoft Entra Admin Center: Simply set the default to not allow users to register their own applications. Exceptions can be useful for developers, for example.

Want to learn more about penetration testing techniques?
Find out about our certificate courses with our own hacking lab!
Ethical Hacker Courses
Follow for more!
Newsletter Form

Become a Cyber ​​Security Insider

Get early access and exclusive content!

By signing up, you agree to receive occasional marketing emails from us.
Please accept the cookies at the bottom of this page to be able to submit the form!

Table of Contents

Do you have any questions or additions? bring it on!
Write a comment and we will reply as soon as possible!

Your email address will not be published. Required fields are marked with *.

NewsLetter Form Pop Up New

Become a Cyber ​​Security Insider

Subscribe to our knowledge base and get:

Early access to new blog posts
Exclusive content
Regular updates on industry trends and best practices

By signing up, you agree to receive occasional marketing emails from us.
Please accept the cookies at the bottom of this page to be able to submit the form!