Lesson 54 — The OAuth Application Was Granted Consent
The alert did not mention malware.
No suspicious executable. No PowerShell. No registry persistence.
Instead, the evidence showed something much quieter:
An OAuth application had been granted consent.
The application now had permission to interact with Microsoft 365 data on behalf of a user.
Agent Foskett looked at the grant and asked:
“What exactly did we just allow this application to do?”
Consent can create durable cloud access
Identify the application, permission scope, consenting identity and subsequent activity before deciding whether the grant is expected or dangerous.
Case briefing
Investigation objective
Determine who granted consent, what access was authorised, whether the application is expected and what cloud activity followed the grant.
Investigator's rule
An application name is not a trust decision. Investigate the application identity, permissions, publisher context, consenting account and observed behaviour.
Stage 1 — find consent-related activity
CloudAppEvents
| where Timestamp > ago(7d)
| where ActionType has_any
("Consent", "Add service principal",
"Add OAuth2PermissionGrant")
| project Timestamp, AccountId, Application,
ActionType, IPAddress, UserAgent, RawEventData
| order by Timestamp ascPreserve the raw event
Action names and details can vary by telemetry source and environment. Keep RawEventData available so the underlying application and permission information can be examined.
Anchor the timeline
The consent timestamp gives you a pivot point. Search immediately before it for authentication and user activity, then immediately after it for application access.
Stage 2 — identify what changed
Permission scope drives risk
Basic profile access creates a different exposure from permissions capable of reading mail, accessing files or interacting broadly with Microsoft 365 data.
Translate permissions into capabilities
The SOC needs to understand what the grant means operationally. Record the practical access supported by the evidence without claiming broader access than the permission relationship allows.
Stage 3 — build a permission impact map
| Permission area | Investigation question |
|---|---|
| Identity / profile | What user or directory information can the application read? |
| Can it access or manipulate mailbox data? | |
| Files | Can it reach OneDrive or SharePoint content? |
| Directory | Can it read or modify broader directory information? |
| Offline access | Can access continue without the user actively interacting with the app? |
Stage 4 — investigate the consenting identity
Consent phishing changes the attack path
A user can be persuaded to authorise an application. The resulting permission relationship may provide access to cloud data without a traditional malware payload.
A compromised session is another hypothesis
If suspicious identity activity preceded the grant, an attacker may have used existing access to establish application-based persistence. Correlate consent with the identity timeline.
Stage 5 — check application history
CloudAppEvents
| where Timestamp > ago(30d)
| where Application has "Document Helper"
| summarize Events = count(),
Accounts = dcount(AccountId),
AccountList = make_set(AccountId, 50),
FirstSeen = min(Timestamp),
LastSeen = max(Timestamp)
by ApplicationNew to the tenant is useful context
An application first observed around a suspicious consent event deserves scrutiny. Age alone does not determine trust, but history helps establish context.
Scope other users
Do not stop with the first account. Determine whether other identities have interacted with or granted access to the same application.
Stage 6 — follow what happened after consent
Capability and observed use are different
A permission tells you what may be possible. Workload evidence helps establish what appears to have actually happened. Keep those findings separate.
Search across Microsoft 365
If the granted permissions relate to Exchange, SharePoint or OneDrive, inspect relevant workload activity and correlate it chronologically.
Stage 7 — test competing hypotheses
| Hypothesis | Evidence that may support it |
|---|---|
| Approved business application | Known owner, expected permissions, established history and documented use. |
| User-installed legitimate application | User intent and a genuine business purpose align with the requested access. |
| Consent phishing | Unexpected application, suspicious lure, risky permissions and misunderstood approval. |
| Compromised-account persistence | Suspicious identity activity precedes consent and application activity follows. |
| Unknown / escalation required | Purpose, ownership or post-consent behaviour cannot be explained. |
Friendly names prove nothing
Names such as “Document Helper” or “Secure PDF Viewer” can sound trustworthy. Validate identity and behaviour rather than relying on branding.
User confirmation is context, not proof
A user may remember approving a prompt without understanding the permissions. Combine their explanation with the technical evidence.
Stage 8 — build the cloud-persistence timeline
Password remediation may not be the whole answer
If the incident involves an application permission relationship, response should also review the application, grants, affected sessions and associated cloud access according to organisational procedures.
Contain the mechanism you found
If persistence exists through OAuth consent, endpoint-only remediation does not address that cloud relationship.
Stage 9 — preserve evidence before remediation
Stage 10 — write the SOC finding
Lesson 54 key takeaways
- OAuth consent is not automatically malicious, but it can create powerful cloud access.
- Identify who granted consent and when.
- Determine the application identity and ownership context.
- Translate permissions into practical capabilities.
- Separate potential access from observed activity.
- Correlate consent with authentication and session evidence.
- Consent phishing can provide a route to cloud data without traditional malware.
- A compromised account can also be used to establish application-based persistence.
- Check whether the application is new to the tenant and whether other users are affected.
- Follow post-consent activity across relevant Microsoft 365 workloads.
- Do not trust an application because its display name sounds legitimate.
- Containment must address the application relationship as well as the identity.
Module 6 — Cloud & SaaS Incidents
Lesson 54 investigated the moment an OAuth application received consent. Lesson 55 follows the application after that point — when it accesses data without the user actively doing anything.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 6: Cloud & SaaS Incidents
Investigate OAuth application consent with Microsoft Defender XDR
Lesson 54 of the Agent Foskett SOC Analyst Academy teaches analysts how to investigate OAuth consent events by identifying the application, consenting user, permission scope, identity context and subsequent Microsoft 365 cloud activity.
Investigate OAuth consent phishing and cloud persistence
Use Microsoft security telemetry and KQL to distinguish approved applications from suspicious OAuth consent, understand permission impact, scope affected users and follow post-consent application activity.
