Posted on by ACouch

Beyond User Accounts: Why Penetration Testers Must Treat Azure Applications as First-Class Identities

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.