Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Azure Applications are configured with the permissions they will be able to use when a user consents the application (like enumerating the directory, access files, or perform other actions). Note, that the application will be having on behalf of the user, so even if the app could be asking for administration permissions, if the user consenting it doesn't have that permission, the app won't be able to perform administrative actions.
By default any user can give consent to apps, although this can be configured so users can only consent to apps from verified publishers for selected permissions or to even remove the permission for users to consent to applications.
If users cannot consent, admins like GA, Application Administrator or Cloud Application Administrator can consent the applications that users will be able to use.
Moreover, if users can consent only to apps using low risk permissions, these permissions are by default openid, profile, email, User.Read and offline_access, although it's possible to add more to this list.
nd if they can consent to all apps, they can consent to all apps.
Unauthenticated: From an external account create an application with the low risk permissions User.Read and User.ReadBasic.All for example, phish a user, and you will be able to access directory information.
This requires the phished user to be able to accept OAuth apps from external tenant
If the phised user is an some admin that can consent any app with any permissions, the application could also request privileged permissions
Authenticated: Having compromised a principal with enough privileges, create an application inside the account and phish some privileged user which can accept privileged OAuth permissions.
In this case you can already access the info of the directory, so the permission User.ReadBasic.All isn't no longer interesting.
You are probable interested in permissions that require and admin to grant them, because raw user cannot give OAuth apps any permission, thats why you need to phish only those users (more on which roles/permissions grant this privilege later)
Note that you need to execute this command from a user inside the tenant, you cannot find this configuration of a tenant from an external one. The following cli can help you understand the users permissions:
Users can consent to all apps: If inside permissionGrantPoliciesAssigned you can find: ManagePermissionGrantsForSelf.microsoft-user-default-legacy then users can to accept every application.
Users can consent to apps from verified publishers or your organization, but only for permissions you select: If inside permissionGrantPoliciesAssigned you can find: ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team then users can to accept every application.
Disable user consent: If inside permissionGrantPoliciesAssigned you can only find: ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat and ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team then users cannot consent any.
It's possible to find the meaning of each of the commented policies in:
Check users that are considered application admins (can accept new applications):
The attack involves several steps targeting a generic company. Here's how it might unfold:
Domain Registration and Application Hosting: The attacker registers a domain resembling a trustworthy site, for example, "safedomainlogin.com". Under this domain, a subdomain is created (e.g., "companyname.safedomainlogin.com") to host an application designed to capture authorization codes and request access tokens.
Application Registration in Azure AD: The attacker then registers a Multi-Tenant Application in their Azure AD Tenant, naming it after the target company to appear legitimate. They configure the application's Redirect URL to point to the subdomain hosting the malicious application.
Setting Up Permissions: The attacker sets up the application with various API permissions (e.g., Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). These permissions, once granted by the user, allow the attacker to extract sensitive information on behalf of the user.
Distributing Malicious Links: The attacker crafts a link containing the client id of the malicious application and shares it with targeted users, tricking them into granting consent.
Register a new application. It can be only for the current directory if you are using an user from the attacked directory or for any directory if this is an external attack (like in the following image).
Also set the redirect URI to the expected URL where you want to receive the code to the get tokens (http://localhost:8000/callback by default).
Then create an application secret:
Select API permissions (e.g. Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read)
Execute the web page (azure_oauth_phishing_example) that asks for the permissions:
Send the URL to the victim
In this case http://localhost:8000
Victims needs to accept the prompt:
Use the access token to access the requested permissions:
365-Stealer: Check https://www.alteredsecurity.com/post/introduction-to-365-stealer to learn how to configure it.
Depending on the requested permissions you might be able to access different data of the tenant (list users, groups... or even modify settings) and information of the user (files, notes, emails...). Then, you can use this permissions to perform those actions.
Check the Applications and Service Principal sections of the page:
Az - EntraID PrivescLearn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
