Lesson 28 — The OAuth Application Had More Access Than Expected
The user remembered approving an application.
What they did not remember was giving it access to mail, files and profile data.
The application itself did not immediately look malicious, and there was no dramatic failed sign-in to investigate.
But its permissions were broader than the business purpose appeared to require.
Agent Foskett had a different identity question now:
what exactly had been granted, who granted it, and what could the application do?
The application had a bigger key than expected
The analyst must establish who consented, which permissions were granted, whether the access matches the application's purpose and what activity followed.
Case briefing
Investigation objective
Determine whether the OAuth application and its granted permissions are legitimate, whether consent was informed and expected, and whether the application used its access suspiciously.
Investigator's rule
Consent does not automatically make access safe. A user can legitimately approve an application that requests excessive or malicious permissions.
Stage 1 — understand what you are investigating
| Entity | Why it matters |
|---|---|
| User | Who granted or was affected by the access? |
| Application | What software requested access? |
| Service principal | What application identity exists in the tenant? |
| Permission / scope | What data or operations can the application access? |
| Consent event | When and how was access granted? |
| Post-consent activity | What did the application or affected identity do afterwards? |
Application names are weak evidence
A reassuring name or logo does not prove an OAuth application is trustworthy. Investigate identifiers, publisher information, permissions and tenant activity.
Business purpose defines expected access
A document-conversion tool requesting basic file access may make sense. The same tool requesting broad mail access should immediately raise another question: why?
Stage 2 — find consent and application changes with KQL
Use Microsoft Entra audit telemetry to locate consent, service-principal and application-management activity around the incident window.
AuditLogs
| where TimeGenerated > ago(7d)
| where Category in ("ApplicationManagement", "Policy")
or OperationName has_any ("consent", "service principal", "application")
| project TimeGenerated,
OperationName,
Result,
InitiatedBy,
TargetResources,
AdditionalDetails,
CorrelationId
| order by TimeGenerated desc
Capture the initiator
Identify the user or administrator associated with the consent event. Then determine whether that identity's surrounding sign-in activity was normal.
Capture the target application
Record the application and service-principal identifiers. Names can change or be imitated; stable identifiers are better pivots for investigation.
Stage 3 — read the permission story
Delegated permissions
Delegated access is exercised in the context of a signed-in user. The effective access depends on both the permission granted to the application and what the user can access.
Application permissions
Application permissions can allow an application to operate without a signed-in user. Broad application-level access therefore deserves especially careful review.
Stage 4 — correlate the consenting user's sign-ins
Was the consent event performed during a normal session, or did it occur after suspicious authentication?
let TargetUser = "s.bennett@contoso.com";
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
IPAddress,
Location,
AppDisplayName,
ClientAppUsed,
ResultType,
ConditionalAccessStatus,
AuthenticationRequirement,
DeviceDetail
| order by TimeGenerated asc
Consent after suspicious authentication matters
If an unusual sign-in is immediately followed by an OAuth grant, the consent may be persistence rather than an isolated user mistake.
Consent during a normal session still needs review
Consent phishing can persuade a legitimate user to authorise malicious access themselves. A normal sign-in does not clear the application.
Stage 5 — test the application against the evidence
| Evidence | Lower concern | Higher concern |
|---|---|---|
| Publisher | Expected and verified publisher | Unknown, misleading or unexpected publisher |
| Permissions | Minimum required for stated purpose | Broad mail, files, directory or offline access without clear need |
| User intent | User knowingly installed approved business app | User followed unexpected link or did not understand the grant |
| Timing | Matches planned business activity | Immediately follows suspicious sign-in or phishing activity |
| Post-consent behaviour | Expected application use | Unexpected access, enumeration or data activity |
Offline access can extend the story
Permissions that allow continued access can make OAuth abuse valuable to an attacker because access may persist beyond the original interactive session.
Privilege changes the impact
If a highly privileged user or administrator granted consent, determine whether the application received tenant-wide or otherwise elevated access.
Stage 6 — containment is more than changing the password
Password remediation may leave OAuth access behind
If the attacker has established application-based access, changing the user's password alone may not remove the malicious grant. Investigate and revoke the access path itself.
Scope beyond one user
Search for the same application or service principal across the tenant. Other users may have granted identical permissions without generating an alert.
Stage 7 — make the SOC decision
Write the investigation finding
Lesson 28 key takeaways
- OAuth consent is an access decision and should be investigated like any other identity control change.
- Do not judge an application by its display name alone.
- Record stable application and service-principal identifiers.
- Compare granted permissions with the application's genuine business purpose.
- Understand the difference between delegated and application permissions.
- Correlate consent events with the consenting user's authentication activity.
- A normal sign-in does not rule out consent phishing.
- Broad or persistent access deserves higher scrutiny.
- Password changes alone may not remove malicious OAuth access.
- Scope the same application across other users and the wider tenant.
Module 3 — Identity Incidents
Lesson 28 moves the investigation from user authentication into application identity and consent. Next, Agent Foskett investigates a service principal that suddenly began behaving like an administrator.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 3: Identity Incidents
How to investigate suspicious OAuth consent in Microsoft Entra
Lesson 28 of the Agent Foskett SOC Analyst Academy teaches analysts how to investigate OAuth application consent, review unexpected permissions, identify the consenting user and determine whether application access is legitimate or malicious.
KQL investigation of Microsoft Entra OAuth and application activity
Learn how to use AuditLogs and SigninLogs with KQL to correlate application-management events, consent activity and user authentication while investigating suspicious OAuth permissions and service principals.
