Agent Foskett Academy • KQL Academy • Module 13 • Lesson 154 • Cloud & SaaS Investigation

Lesson 154 — The OAuth Application Was Granted Consent

Module 13 has already uncovered unusual data volume, geographically inconsistent SharePoint access and a high-speed download burst. Then the identity timeline reveals another event: an OAuth application was granted consent.

Consent can be completely legitimate. It can also give an application delegated access to organisational data without requiring the user to interact with every resource directly. In this lesson we use KQL to identify the consent event, inspect the application and permissions, correlate it with surrounding sign-ins and determine whether the grant may represent cloud persistence.

OAuth consent is not suspicious because an application exists. The investigation begins with who granted it, what permissions were approved, when it happened and what the application did next.

Begin the Investigation Back to KQL Academy

Agent Foskett KQL Academy OAuth consent investigation

Your case file

At 2:34 PM, an Entra audit event records application consent associated with alex.wilson@contoso.com during the same suspicious cloud activity window.

✓ Find the consent event

✓ Identify the application

✓ Inspect permission evidence

✓ Correlate surrounding sign-ins

Case briefing

CASE FILE User: alex.wilson@contoso.com 14:00–14:11 High-velocity file downloads ↓ 14:21 Geographically unusual session context ↓ 14:34 OAUTH APPLICATION CONSENT EVENT ↓ Application permissions require review ↓ THE QUESTION Was this an approved application, or did the suspicious session establish persistent access to cloud data?

Investigation objective

Use Microsoft Entra AuditLogs and SigninLogs to identify application-consent activity, preserve the initiating identity and target resources, inspect available permission evidence and correlate the grant with the surrounding authentication timeline.

Investigator's rule

Consent is an authorisation event, not proof of abuse. The permissions, application provenance, initiating identity, tenant policy and subsequent application activity determine the security significance.

Stage 1 — find the consent event

Start with Entra audit telemetry and the target user. Search consent- and permission-related operations while retaining the raw target resources and additional details for later inspection.

123456789101112131415

let TargetUser = "alex.wilson@contoso.com";
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has_any ("Consent", "permission")
| extend InitiatingUPN = tostring(InitiatedBy.user.userPrincipalName)
| where InitiatingUPN =~ TargetUser
| project TimeGenerated,
          OperationName,
          Result,
          InitiatingUPN,
          InitiatedBy,
          TargetResources,
          AdditionalDetails,
          CorrelationId
| order by TimeGenerated asc

Preserve the raw evidence

TargetResources, AdditionalDetails and InitiatedBy are dynamic structures. Keep them available during the first pass so useful application or permission details are not discarded too early.

Operation names can vary

Audit wording can differ by consent workflow and tenant activity. Inspect the actual OperationName values in your environment rather than assuming one exact string will capture every grant.

Stage 2 — identify the application and target resource

Expand TargetResources so the application or service-principal details associated with the event become easier to inspect.

12345678910111213141516171819

let TargetUser = "alex.wilson@contoso.com";
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has_any ("Consent", "permission")
| extend InitiatingUPN = tostring(InitiatedBy.user.userPrincipalName)
| where InitiatingUPN =~ TargetUser
| mv-expand TargetResources
| extend TargetDisplayName = tostring(TargetResources.displayName),
         TargetType = tostring(TargetResources.type),
         ModifiedProperties = TargetResources.modifiedProperties
| project TimeGenerated,
          OperationName,
          Result,
          InitiatingUPN,
          TargetDisplayName,
          TargetType,
          ModifiedProperties,
          CorrelationId
| order by TimeGenerated asc

Application name is not reputation

A convincing display name does not establish that an application is trustworthy. Validate application identifiers, publisher information and organisational approval through the appropriate Entra records and governance process.

Keep the CorrelationId

CorrelationId can help connect related audit activity generated by the same workflow. It is a useful pivot when several Entra events occur around the grant.

Stage 3 — inspect permission evidence

Expand modified properties and look for consent-, scope- or permission-related values. The exact structure varies, so treat this as an investigative extraction rather than a universal parser.

1234567891011121314151617181920

let TargetUser = "alex.wilson@contoso.com";
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has_any ("Consent", "permission")
| extend InitiatingUPN = tostring(InitiatedBy.user.userPrincipalName)
| where InitiatingUPN =~ TargetUser
| mv-expand TargetResources
| mv-expand ModifiedProperty = TargetResources.modifiedProperties
| extend PropertyName = tostring(ModifiedProperty.displayName),
         OldValue = tostring(ModifiedProperty.oldValue),
         NewValue = tostring(ModifiedProperty.newValue),
         Application = tostring(TargetResources.displayName)
| where PropertyName has_any ("Consent", "Scope", "Permission")
   or NewValue has "Scope"
| project TimeGenerated,
          Application,
          PropertyName,
          OldValue,
          NewValue,
          CorrelationId

Permissions change the risk

A narrow low-impact permission and a broad data-access scope do not create the same exposure. Record the permissions actually granted before assessing the application's potential reach.

Delegated versus application access

Consent models differ. Determine whether the access operates on behalf of a signed-in user or whether the application can act independently. That distinction materially changes persistence and impact analysis.

Stage 4 — correlate the consent with surrounding sign-ins

Return to the identity timeline. Examine authentication within thirty minutes of the consent event and preserve source, location, application, device and policy context.

1234567891011121314151617

let TargetUser = "alex.wilson@contoso.com";
let ConsentTime = datetime(2026-08-18 14:34:00);
SigninLogs
| where TimeGenerated between (ConsentTime - 30m .. ConsentTime + 30m)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          Location,
          AppDisplayName,
          ClientAppUsed,
          DeviceDetail,
          AuthenticationRequirement,
          ConditionalAccessStatus,
          ResultType,
          CorrelationId
| order by TimeGenerated asc

Who controlled the session?

If the consent follows an already suspicious authentication, the event becomes more significant. The key question is whether the legitimate user or an unauthorised actor controlled the session when consent was granted.

MFA does not answer everything

An authentication requirement being satisfied does not prove later actions were authorised by the legitimate user. Session theft and consent phishing investigations require the wider timeline.

Stage 5 — build the consent investigation timeline

Bring Entra audit events and sign-ins into one chronological view. This shows whether application consent sits inside the same suspicious cloud sequence discovered in Lessons 151–153.

12345678910111213141516171819202122232425262728

let TargetUser = "alex.wilson@contoso.com";
let StartTime = datetime(2026-08-18 14:00:00);
let EndTime = datetime(2026-08-18 15:00:00);
union
(
    AuditLogs
    | where TimeGenerated between (StartTime .. EndTime)
    | extend InitiatingUPN = tostring(InitiatedBy.user.userPrincipalName)
    | where InitiatingUPN =~ TargetUser
    | project TimeGenerated,
              EvidenceType="Entra audit",
              Activity=OperationName,
              Detail=strcat("Result=", Result),
              CorrelationId
),
(
    SigninLogs
    | where TimeGenerated between (StartTime .. EndTime)
    | where UserPrincipalName =~ TargetUser
    | project TimeGenerated,
              EvidenceType="Sign-in",
              Activity=AppDisplayName,
              Detail=strcat(IPAddress, " | ",
                            tostring(Location),
                            " | CA=", tostring(ConditionalAccessStatus)),
              CorrelationId
)
| order by TimeGenerated asc

What happened after consent?

The grant itself is only half the investigation. The next step is to determine whether the application subsequently accessed resources, acquired tokens or performed activity without direct user interaction.

Do not remove first and investigate later

Containment may be urgent, but preserve the application identifiers, permissions, audit records and relevant timeline evidence required by your incident-response process before remediation destroys useful context.

Agent Foskett's OAuth consent timeline

14:00–14:11 High-velocity cloud downloads ↓ 14:21 Unusual identity/session context ↓ 14:34 OAuth consent recorded ↓ INITIATING IDENTITY alex.wilson@contoso.com ↓ APPLICATION target resource identified ↓ PERMISSIONS scope evidence reviewed ↓ SIGN-IN CONTEXT IP + location + device + policy correlated ↓ NEXT QUESTION Did the application use the granted access? ↓ ASSESSMENT Consent may represent cloud persistence — subsequent application activity must be proved

The consent event told us access was granted. It did not tell us whether that access was ever used.

Your evidence board

Evidence	What it supports	Weight
Consent event associated with the target user	Establishes that an authorisation workflow occurred.	Strong fact
Previously unknown or unapproved application	Raises concern about application provenance.	Strong when governance data confirms it
Broad data-access permissions	Increases potential impact if the application is abused.	Strong impact evidence
Consent immediately follows suspicious sign-in activity	Connects the grant temporally to the compromise hypothesis.	Strong context
Successful MFA or Conditional Access	Shows authentication or policy requirements were satisfied.	Does not prove authorised consent
Consent event alone	Does not prove malicious application use or persistence.	Insufficient alone

Write the finding like an investigator

Example: Microsoft Entra audit telemetry recorded an OAuth application-consent event associated with alex.wilson@contoso.com during the same investigation window as unusual Microsoft 365 download and authentication activity. The event was reviewed to identify the initiating identity, target application, available modified properties and permission-related evidence. Surrounding Entra sign-ins were correlated by time and reviewed for IP, location, client, device, authentication and Conditional Access context. The timing of the grant within an already suspicious cloud sequence supports further investigation for possible application-based persistence. The consent event alone does not establish malicious application use. Subsequent token and resource-access activity should be examined before concluding that the granted permissions were exercised.

Lesson 154 key takeaways

Use Entra AuditLogs to investigate application-consent activity.
Preserve InitiatedBy, TargetResources, modified properties and CorrelationId.
Audit operation names and dynamic structures can vary, so validate your tenant schema.
An application's display name does not establish its legitimacy.
Permission scope determines potential exposure.
Distinguish delegated access from application access when assessing persistence.
Correlate consent with the surrounding sign-in timeline.
MFA or Conditional Access success does not automatically prove authorised consent.
Consent establishes permission; subsequent activity establishes whether it was used.
Preserve evidence before remediation where incident-response requirements allow.

Module 13 — from consent to application activity

Lesson 154 identifies the application grant and places it inside the suspicious cloud timeline. The next investigation asks the question that matters most after consent: did the application begin accessing organisational data without the user?

Next: Lesson 155 — The Application Accessed Data Without the User.

Continue your KQL investigation training

Module 13 follows users, sessions, applications and data through Microsoft 365 and cloud services.

KQL Academy Lesson 153 — Hundreds of Files Were Downloaded in Eleven Minutes Microsoft Entra Security Academy Agent Foskett Academy

Related Agent Foskett Investigations

Continue investigating suspicious cloud identity and application activity using evidence-led KQL hunting.

OAuth Consent Grant Investigation KQL Threat Hunting Microsoft Defender KQL Threat Hunting Guide Browse Agent Foskett Investigations

🔎 KQL Academy — Module 13: Advanced Cloud & SaaS Investigation

Following users, sessions, applications and data through Microsoft 365 and cloud services.

⬅ Previous lesson

Lesson 153 — Hundreds of Files Were Downloaded in Eleven MinutesMeasure high-velocity Microsoft 365 data collection and investigate the mechanism behind the burst.

✅ Current lesson

Lesson 154 — The OAuth Application Was Granted ConsentInvestigate application consent, permissions and surrounding identity activity to assess possible cloud persistence.

Next lesson

Lesson 155 — The Application Accessed Data Without the UserFollow application activity after consent and determine whether granted access was exercised independently of interactive user activity.

Investigate OAuth consent with KQL

Lesson 154 of the Agent Foskett KQL Academy uses Microsoft Sentinel, Microsoft Entra AuditLogs and SigninLogs to investigate OAuth application consent and possible cloud persistence.

Investigate suspicious application permissions in Microsoft Entra ID

Learn how to identify the initiating user and application, inspect permission evidence, correlate consent with surrounding authentication activity and distinguish a permission grant from confirmed application abuse.