Category: Azure

As penetration testers, red teamers and cyber security professionals, we’re accustomed to thinking about identity in Azure as synonymous with user accounts. But in the modern cloud, identity extends far beyond users — and nowhere is this more apparent than with Azure applications and service principals.

Applications in Azure AD are not just passive objects — they can be assigned roles, own secrets or certificates, and can have the ability to authenticate directly to the Microsoft Graph API. In other words, they are valid identities capable of holding privileges and accessing resources just like human users. This shift means we must broaden our threat models accordingly.

Applications as Logins

Every Azure AD application, once provisioned, comes with a service principal — an identity used to access resources. With the right permissions, these principals can:

• Read or write to Microsoft Graph (e.g., list users, modify group memberships)
• Query directory objects such as roles, users, groups, and devices
• Reset user passwords if the app is assigned PrivilegedAuthenticationAdministrator or HelpdeskAdministrator
• Access mailbox data via Mail.Read or send emails via Mail.Send
• Control Entra ID Conditional Access policies or even register/deregister MFA settings if granted high-privilege Graph scopes

These permissions can be assigned either via delegated access (on behalf of a user) or application-level access (with no user context at all). The latter is especially dangerous, as it allows silent, background API access with no interactive login required.

Real-World Exploitation: Certificate-Based Logins

If an attacker compromises a certificate or client secret assigned to a privileged application, they can authenticate as the app via OAuth 2.0 client credential flow and obtain an access token for Graph:

POST /{tenant}/oauth2/v2.0/token
grant_type=client_credentials
client_id=APP_ID
client_secret=APP_SECRET
scope=https://graph.microsoft.com/.default

This token can then be used to enumerate users, groups, access email, or even perform password resets depending on the app’s assigned roles.

Example Scenarios

• Helpdesk Password Resets: An app with HelpdeskAdministrator can reset passwords for non-admin users. Imagine the implications of silently resetting and impersonating a targeted user.
• Email Exfiltration: An app granted Mail.Read could silently monitor executive inboxes or extract sensitive emails over time.
• Persistent Access: Compromising an app with a 2-year certificate enables long-term, hard-to-detect API access without MFA or sign-in logs typical for users.

Mitigations and Takeaways

Security teams must:

• Audit app and service principal permissions regularly.
• Revoke unused credentials and reduce excessive Graph scopes.
• Use certificate expirations and rotation policies.
• Log app-based Graph accesses in Microsoft Entra logs if required.

Takeaway: Azure applications are not passive configurations — they are active identities, we must think of them differently, almost like a way to login. For attackers, they represent low-noise, high-impact avenues for persistence and privilege escalation. For defenders, this is a call to treat them with the same scrutiny as human users.

For further reading on app permissions in Microsoft Entra ID, see Microsoft’s permission and consent documentation.

Just when we thought we had got our heads around Role Based Access Control (RBAC) along comes Attribute-Based Access Control (ABAC). Great. ABAC is a flexible and granular access control model that evaluates attributes—characteristics associated with users, resources, and the environment—when determining whether access should be granted. Unlike Role-Based Access Control (RBAC), which relies on predefined roles with fixed permissions, ABAC allows organisations to define access policies based on dynamic combinations of attributes.

In the Azure world, ABAC is supported through the use of custom Azure roles combined with resource and request context attributes. For example, you could define a custom role that allows access to storage blobs only when the user’s department attribute matches the resource’s “department” tag. A real-world policy might say: “Grant read access to blobs if user.department equals resource.department.” This allows a single role definition to be reused across departments without hardcoding resource-level access rules.

This model is particularly useful for large-scale environments where traditional RBAC roles become unmanageable due to the explosion of permutations. ABAC helps reduce role sprawl while still enforcing strict, attribute-driven access boundaries.

Don’t let me butcher it anymore however, there is a great article on introducing ABAC via Microsoft here:
Introducing Attribute Based Access Control (ABAC) in Azure.