Agent Foskett Academy • Lesson 118 • Incident Response Workflow

Incident Response Workflow: OAuth Application Compromise.

The password had been changed.

MFA had been reset. Active sessions had been revoked. The user looked secure again.

But the attacker still had access.

Agent Foskett realised the compromise was no longer about the user's password. The user had granted trust to a malicious OAuth application, and that application was now doing the work for the attacker.

Start Lesson 118 Back to Academy

Agent Foskett Academy lesson investigating OAuth application compromise in Microsoft Defender XDR

Lesson overview

Learn how to investigate malicious OAuth consent, delegated permissions, token abuse and persistent Microsoft 365 access using Microsoft Defender XDR and Microsoft Entra ID telemetry.

Identify suspicious application consent

Review delegated permissions and tokens

Correlate identity and cloud activity

Remove persistent app-based access

Why OAuth application compromise matters

OAuth compromise can survive password resets because the attacker may not need the user's password anymore. The trusted application has been granted permission to access Microsoft 365 resources.

Password resets may not helpIf access is granted through OAuth consent, changing the user's password may not remove the application's permissions.

Permissions define impactThe risk depends on what the application can access: mail, files, contacts, calendars, directory data or offline access.

Persistence can be cloud-nativeThe attacker may no longer need to authenticate interactively once the malicious application has delegated access.

The OAuth application compromise workflow

Agent Foskett treats malicious OAuth consent as a cloud persistence investigation, not just an identity alert.

1. Confirm the applicationIdentify the application name, app ID, consent time, publisher, user and whether admin consent was granted.

2. Review consent activityLook for application consent, permission grants, service principal creation and changes to Enterprise Applications.

3. Inspect permissionsDetermine whether the app requested mail, files, offline_access, user profile, directory or privileged Graph permissions.

4. Review cloud activityCheck Exchange Online, SharePoint, OneDrive and Teams activity for access that continued after password resets.

5. Correlate identity evidenceReview sign-ins, risky activity, Conditional Access outcomes, token behaviour and suspicious user activity around the consent time.

6. Contain and validateRemove consent, disable the app, revoke sessions and confirm that application activity has stopped.

Step 1 — Review OAuth and application consent events

Start by looking for consent activity, OAuth-related events and new service principals.

let TimeFrame = 30d;
CloudAppEvents
| where Timestamp > ago(TimeFrame)
| where ActionType has_any ("Consent", "OAuth", "Add service principal", "Add app role assignment")
| project Timestamp,
          AccountDisplayName,
          ActionType,
          Application,
          AppId,
          ObjectName,
          IPAddress,
          RawEventData
| order by Timestamp desc

Step 2 — Build the user's cloud activity timeline

Compare application activity with the user's wider Microsoft 365 activity.

let TimeFrame = 30d;
let UserToInvestigate = "user@contoso.com";
CloudAppEvents
| where Timestamp > ago(TimeFrame)
| where AccountDisplayName =~ UserToInvestigate
| where Application has_any ("Office 365", "Microsoft 365", "Azure Active Directory")
| project Timestamp,
          AccountDisplayName,
          ActionType,
          Application,
          ObjectName,
          IPAddress,
          RawEventData
| order by Timestamp asc

Step 3 — Search for high-risk permissions

Permissions reveal impact. Mail, files, directory data and offline access increase the seriousness of the compromise.

let TimeFrame = 30d;
CloudAppEvents
| where Timestamp > ago(TimeFrame)
| where RawEventData has_any ("Mail.Read", "Mail.Send", "Files.Read", "Files.Read.All", "offline_access", "User.Read", "Directory.Read")
| project Timestamp,
          AccountDisplayName,
          ActionType,
          Application,
          AppId,
          ObjectName,
          IPAddress,
          RawEventData
| order by Timestamp desc

Step 4 — Review identity activity around consent

OAuth compromise often begins with phishing, risky sign-ins or suspicious authentication behaviour.

let TimeFrame = 14d;
let SuspectUser = "user@contoso.com";
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| where AccountUpn =~ SuspectUser
| project Timestamp,
          AccountUpn,
          ActionType,
          IPAddress,
          Location,
          DeviceName,
          FailureReason
| order by Timestamp asc

Step 5 — Scope the suspicious application

Determine whether the same application appears across multiple users or tenants.

let TimeFrame = 30d;
let SuspectApp = "Suspicious App Name";
CloudAppEvents
| where Timestamp > ago(TimeFrame)
| where Application has SuspectApp or ObjectName has SuspectApp or RawEventData has SuspectApp
| summarize EventCount = count(),
            Users = make_set(AccountDisplayName, 50),
            Actions = make_set(ActionType, 50),
            IPAddresses = make_set(IPAddress, 50),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
      by Application,
         AppId
| order by EventCount desc

Step 6 — Build the OAuth compromise timeline

Combine identity and cloud activity into one timeline to understand the full compromise sequence.

let TimeFrame = 30d;
let SuspectUser = "user@contoso.com";
let IdentityActivity =
    IdentityLogonEvents
    | where Timestamp > ago(TimeFrame)
    | where AccountUpn =~ SuspectUser
    | project Timestamp,
              Source = "IdentityLogonEvents",
              Account = AccountUpn,
              Activity = ActionType,
              Detail = strcat(IPAddress, " ", Location);
let CloudActivity =
    CloudAppEvents
    | where Timestamp > ago(TimeFrame)
    | where AccountDisplayName =~ SuspectUser
    | project Timestamp,
              Source = "CloudAppEvents",
              Account = AccountDisplayName,
              Activity = ActionType,
              Detail = strcat(Application, " ", ObjectName);
union IdentityActivity, CloudActivity
| order by Timestamp asc

Common OAuth compromise clues

OAuth abuse is often subtle. The strongest cases are built by combining consent, permissions, identity and cloud activity.

Unexpected app nameApplications with vague names, fake branding or names mimicking Microsoft services deserve careful review.

High-risk permissionsPermissions such as Mail.Read, Mail.Send, Files.Read.All, offline_access or directory access can create serious exposure.

Activity after remediationCloud activity after password resets and session revocation may indicate app-based persistence.

New consent near phishingOAuth consent shortly after a phishing email or risky sign-in can link the application to the compromise.

Multiple affected usersThe same suspicious application appearing across several accounts may indicate a wider consent phishing campaign.

Publisher uncertaintyUnverified publishers, strange redirect URIs or unfamiliar app IDs should be investigated before trust is assumed.

False positives to consider

Not every OAuth application is malicious. Always validate business context before disabling production applications.

Legitimate SaaS toolsDocuSign, Adobe, Salesforce, Zoom, backup platforms and other business tools may request broad permissions.

Admin-approved integrationsSome applications are approved centrally and may look unusual if the analyst is not aware of the business process.

Migration toolingMailbox migration, archive and backup tools can generate large volumes of legitimate cloud activity.

Developer testingInternal development and automation apps may create service principals, consent events and unusual access patterns.

Security platformsCASB, SIEM, monitoring and response tools may legitimately access many Microsoft 365 resources.

User productivity appsCalendar, scheduling and email add-ins may request access that looks suspicious without business context.

Investigation checklist

Use this checklist before closing an OAuth application compromise investigation.

Who granted consent?Identify whether consent was user-based, admin-approved or created through another privileged workflow.

What permissions were requested?Review delegated and application permissions to understand what the app could access.

Was offline access granted?offline_access can allow continued access even after the original interactive session ends.

What data was accessed?Review mail, files, SharePoint, OneDrive and Teams activity to determine exposure.

Is the application still active?Disable or remove the Enterprise Application and associated service principal when malicious.

Has access stopped?Validate that tokens are revoked, sessions are closed and cloud activity has ceased.

Related Agent Foskett Academy lessons

These lessons help support OAuth application compromise investigations.

Hunting Playbook: OAuth AbuseUnderstand how attackers abuse OAuth consent as a persistence technique.

Business Email Compromise WorkflowInvestigate mailbox compromise, fraud attempts and post-compromise behaviour.

Data Exfiltration WorkflowDetermine whether files, mail or sensitive data were accessed or transferred.

Investigating CloudAppEventsUse cloud activity telemetry to review Microsoft 365 and application actions.

Investigating IdentityLogonEventsReview identity sign-in telemetry and authentication activity.

Building Reusable Hunting QueriesBuild repeatable investigation logic for OAuth, identity and cloud workflows.

Coming next

The Incident Response Workflow series continues with cloud identity attack investigations.

Lesson 119 — Incident Response Workflow: Cloud Identity AttackNext, Agent Foskett investigates cloud identity attacks involving Microsoft Entra ID, risky sign-ins, Conditional Access, privilege escalation and attacker activity across Microsoft 365.

Why this mattersOAuth application compromise shows how attackers can maintain access through application trust. Cloud identity attack investigations broaden that view across users, roles, sessions, policies and identity controls.

Final thought

Sometimes the attacker is not using the password anymore. They are using the trust that was granted to an application.

Agent Foskett mindsetDo not stop at password resets. Check consent, permissions, service principals, tokens and cloud activity before declaring the account clean.

Incident Response Workflow SeriesLesson 118 connects identity compromise, cloud activity and application consent into a repeatable OAuth incident response workflow.

Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD

Incident Response Workflow OAuth Application Compromise in Microsoft Defender XDR

Agent Foskett Academy Lesson 118 teaches defenders how to investigate OAuth application compromise using Microsoft Defender XDR, Microsoft Entra ID, CloudAppEvents, identity telemetry, delegated permissions and KQL hunting workflows.

Learn OAuth application compromise investigation with KQL and Microsoft Defender XDR

OAuth compromise investigations help Microsoft security analysts identify malicious application consent, delegated permissions, token abuse, cloud access and persistent attacker activity across Microsoft 365 services.

Microsoft Entra ID OAuth consent investigation tutorial

This lesson explains how to investigate suspicious OAuth consent, malicious Enterprise Applications, service principals, delegated Graph permissions, offline access and cloud persistence using Microsoft security telemetry.