OAuth Triage: Scope and Blast Radius of a Malicious App

The same permission, two incidents

Two consent grants land on your desk in the same hour, both flagged by the same rule. Both show the scope Mail.Read. The first turns out to be one mailbox: a single user authorized an app to read their own mail, and the exposure stops there. The second is every mailbox in the organization: a tenant-wide grant that lets an application read the CEO's mail, the legal team's mail, the entire company's mail. You size the first as a contained incident and the second as the breach that defines the company's year. The scope string on both was identical.

If you size those two the same way, you have either over-escalated a one-user problem into a company-wide panic or, far worse, under-escalated a company-wide breach into a one-user ticket. The field that separates them is not in the scope name at all. This sub is about the factor that turns a scope into an actual data-reach number, and why reading it correctly is the difference between an incident you describe in one sentence and one that triggers organization-wide breach notification.

This is the next move after reading the consent grant. Decomposing a consent told you what the application is and what it asked for; sizing the blast radius tells you how much of the organization is on the line if that grant is malicious. Blast radius is the full set of data a compromised application can reach with the permissions it holds, and it is determined by two things working together: the scopes that were granted, and the permission type those scopes belong to. You already know how to read the scopes (the Resource.Action.Audience pattern). What this sub adds is the second factor, the one analysts consistently misread: the distinction between delegated and application permissions.

Delegated vs application permissions

OAuth has two fundamentally different permission models, and the same scope name behaves completely differently depending on which one a consent uses. This is the single most important concept in sizing an application's blast radius.

A delegated permission lets the application act on behalf of the user who signed in. The app's access is the intersection of what the app was granted and what the user can do. A delegated Mail.Read lets the application read the mail of the user who consented, and only that user. If a standard employee consents, the app reaches that employee's mailbox. The user is always present in the access equation: the app borrows the user's permissions and can never exceed them.

An application permission lets the application act as itself, with no user involved. The app authenticates with its own credential and accesses data directly through the API, bounded only by the permission it was granted. An application Mail.Read (which in practice appears as Mail.Read granted as an application permission, often with admin consent) lets the application read every mailbox in the tenant, because there is no user to bound it. The app is not borrowing anyone's access; it has its own, and its own is tenant-wide.

A note on the suffix, because it can look like it contradicts what you learned about reading scopes. The .All suffix marks the tenant-wide variant within the delegated catalog, but the application-permission catalog is a separate list, and many application permissions are tenant-wide without carrying an .All suffix at all. That is exactly why the permission type is the rule and the suffix is only a hint. You cannot size breadth from the scope string alone; you read whether the permission was granted as delegated or as application, and that field is what tells you whether "every mailbox" is in play.

The trap is that the scope name alone does not always tell you which model you are looking at. You have to read the permission type from the consent record or the application's granted permissions, not infer it from the scope string. Some scopes exist only as application permissions, some only as delegated, and some as both with the same name. The audit record distinguishes them, and reading that distinction is the difference between a correct and an incorrect blast-radius estimate.

The escalation that hides in plain sight

The most dangerous pattern in OAuth attacks is the application permission granted via admin consent. A delegated permission needs a user, and a user can only consent to access their own data. An application permission with admin consent has no such limit. When an attacker compromises an account with administrative rights (or escalates to one), the prize is not the admin's mailbox. The prize is the ability to grant an application a tenant-wide application permission, which converts a single compromised admin into standing access to every user's data.

This is why the consent type and the permission type compound. A user-consented delegated permission is bounded twice (one user, that user's access). An admin-consented application permission is bounded by nothing except the scope. The first is a contained incident; the second is the kind of breach that defines a company's year. When you triage a consent, reading whether it is an application permission with admin consent is the highest-priority field, because it is the one that can turn a routine alert into a tenant-wide exposure.

A practical note on how attackers reach the bottom-right cell. They rarely start with admin rights. The common path is: compromise a standard user through consent phishing or token theft, use that foothold to escalate (a directory-role assignment, a privileged-role-eligible account, a misconfigured group), and once they hold admin, grant an application a tenant-wide application permission. The application permission is the objective, not the admin account itself. The admin compromise is the means; the standing tenant-wide data access is the end. This is why an admin-consent event for an application permission, appearing shortly after any privilege-escalation signal, is one of the highest-severity correlations in identity-and-application triage.

Mapping scopes to data reach

Once you know the permission type, you can map the granted scopes to the actual data the application can reach. The mapping is the blast-radius estimate, and it is what you hand to the incident lead and the data-protection function to drive notification decisions.

The estimate has two dimensions. The first is breadth: how many principals' data is reachable (one user for delegated, the whole tenant for application permissions). The second is depth: what categories of data the scopes unlock (mail, files, calendar, contacts, directory, Teams messages). A delegated Mail.Read plus Files.Read reaches one user's mail and files. An application Mail.Read.All plus Files.Read.All reaches every user's mail and files. The breadth comes from the permission type; the depth comes from the set of scopes.

Depth deserves its own scrutiny because attackers frequently request a bundle of scopes that, read individually, each look modest, but read together describe a complete data-theft toolkit. A grant of Mail.Read, Contacts.Read, and Files.Read on a single user is not three small exposures; it is one complete exposure of that person's communications, network, and documents. When you list the depth, list the union and read it as a whole. The attacker chose that combination for a reason, and the reason is usually that the combination reaches everything they want from the target. A useful discipline is to translate each scope into the plain-language question it answers for the attacker: Mail.Read answers "what is this person discussing," Contacts.Read answers "who do they know," Files.Read answers "what are they working on." Stated that way, the depth of even a single-user grant becomes obvious to the incident lead who has to decide on notification.

Seeing it in the evidence

A generic worked example. Two applications have been flagged in a tenant, and you need to size each one's blast radius before deciding which to contain first. Both show a Mail.Read scope in their granted permissions. The naive reading treats them as equivalent. The permission type tells the real story.

# Application (app-role) permissions on the service principal: tenant-wide reach
Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $spId |
  Select-Object PrincipalDisplayName, ResourceDisplayName, AppRoleId
# Delegated (OAuth2) permissions: bounded to consenting users
Get-MgServicePrincipalOauth2PermissionGrant -ServicePrincipalId $spId |
  Select-Object ConsentType, PrincipalId, Scope

# Application permissions (app-role assignments) for the service principal
az ad sp show --id "$SP_ID" --query "appRoles" -o table
# Delegated permission grants
az rest --method get \
  --url "https://graph.microsoft.com/v1.0/servicePrincipals/$SP_ID/oauth2PermissionGrants"

AuditLogs
| where OperationName has_any ("Add app role assignment", "Add delegated permission grant")
| extend App = tostring(TargetResources[0].displayName)
| project TimeGenerated, OperationName, App, InitiatedBy
| sort by TimeGenerated desc

The output resolves the two applications cleanly. Application A's access came back as a delegated grant with a single principal and "Principal" consent type, which means one user consented for their own mailbox: a one-mailbox blast radius, a contained incident. Application B's access came back as an app-role assignment, which is an application permission operating tenant-wide: every mailbox in reach, an organization-scale exposure. The scope string Mail.Read was identical in both. The query that separated them was the one that read the permission type, and it changed the severity of Application B by the entire size of the organization.

This is the blast-radius estimate in practice. You do not size an incident from the scope name. You size it from the permission type (which sets breadth) and the full scope set (which sets depth), and you let that estimate drive the containment order and the notification scope.

Your turn

You find an application with three granted permissions: User.Read (delegated, one user), Mail.ReadWrite (delegated, one user), and Files.Read.All (application permission, admin-consented). The application name suggests a document-collaboration tool. How do you size the blast radius, and what is the most exposed data?

Where this leads: you can separate delegated from application permissions and produce a defensible blast-radius estimate. Next, TR3.6 moves from what the application could reach to what it actually did, tracing the application's real data-access activity to confirm the exposure and distinguish a dormant grant from active data harvesting.