Agent Foskett Academy • Lesson 104 • Hunting Playbook Series

Hunting Playbook: OAuth Abuse in Microsoft Defender XDR.

The user changed their password.

MFA was reset. Sessions were revoked. The mailbox looked quiet.

Yet the attacker still had access.

The credentials were no longer the problem.

The user had granted consent to a malicious OAuth application, and the application still had permission to act.

Start Lesson 104 Back to Academy

Agent Foskett Academy lesson hunting OAuth abuse in Microsoft Defender XDR

Lesson overview

Learn how to hunt for OAuth abuse by investigating application consent, delegated permissions, service principals, token activity and Microsoft Entra ID evidence inside Microsoft Defender XDR.

Identify suspicious OAuth applications

Review delegated and application permissions

Correlate consent, sign-ins and mailbox access

Build a timeline of persistent access

Why OAuth abuse matters

OAuth abuse is dangerous because the attacker may no longer need the user's password. If consent remains in place, the application can continue accessing data until the permission is removed or revoked.

Credentials are only the first stepA password reset may stop interactive sign-ins, but it does not automatically remove delegated application permissions that were already granted.

Consent can become persistenceAttackers use consent phishing to convince users to approve access for applications that read mail, files, profile data or other Microsoft 365 resources.

The app may look harmlessMalicious applications often use friendly names, trusted-looking logos and vague permission wording to avoid suspicion during consent.

The OAuth abuse hunting workflow

Agent Foskett investigates OAuth abuse by moving from application discovery to permissions, user activity, token behaviour and response actions.

1. Identify the applicationFind new, unusual or rarely used applications that were granted access by a user or administrator.

2. Review the consent eventDetermine who granted consent, when it happened and whether the consent was user-level or admin-level.

3. Inspect permissionsLook for high-risk permissions such as mail read, offline access, files access, contacts or directory read permissions.

4. Correlate sign-insCheck whether the consent followed suspicious sign-ins, impossible travel, credential theft or risky authentication activity.

5. Review application usageLook for evidence that the application was used to access mailbox, file or cloud data after consent was granted.

6. Remove access and preserve evidenceRevoke consent, disable or remove the application, invalidate sessions and document the investigation timeline.

Step 1 — Review recent application consent activity

Start by looking for consent and application-related activity in Microsoft Defender XDR telemetry.

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

Step 2 — Search for suspicious application names

Consent phishing applications often use words that sound helpful, urgent or related to documents, signatures or account verification.

let TimeFrame = 30d;
let SuspiciousAppTerms = dynamic(["verify", "secure", "document", "invoice", "signature", "account", "mail", "backup"]);
CloudAppEvents
| where Timestamp > ago(TimeFrame)
| where isnotempty(Application)
| where Application has_any (SuspiciousAppTerms)
| project Timestamp,
          AccountDisplayName,
          ActionType,
          Application,
          AppId,
          IPAddress,
          UserAgent
| order by Timestamp desc

Step 3 — Pivot from the user to recent sign-ins

OAuth consent should not be reviewed in isolation. Check whether the same user had suspicious authentication activity before the application was granted access.

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

Step 4 — Summarise applications used by each account

A summary can reveal accounts that suddenly interacted with new or unusual applications.

let TimeFrame = 30d;
CloudAppEvents
| where Timestamp > ago(TimeFrame)
| where isnotempty(Application)
| summarize EventCount = count(),
            Applications = make_set(Application, 50),
            AppIds = make_set(AppId, 50),
            IPAddresses = make_set(IPAddress, 50),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
      by AccountDisplayName
| order by EventCount desc

Step 5 — Correlate consent with mailbox activity

If the application requested mail-related access, look for mailbox activity after the consent event.

let TimeFrame = 14d;
let TargetUser = "user@contoso.com";
let ConsentEvents =
    CloudAppEvents
    | where Timestamp > ago(TimeFrame)
    | where AccountDisplayName =~ TargetUser
    | where ActionType has_any ("Consent", "Grant", "Add app role assignment")
    | project ConsentTime = Timestamp,
              AccountDisplayName,
              Application,
              AppId,
              ConsentIPAddress = IPAddress;
let MailEvents =
    CloudAppEvents
    | where Timestamp > ago(TimeFrame)
    | where AccountDisplayName =~ TargetUser
    | where ActionType has_any ("MailItemsAccessed", "MailItems", "Read", "Send")
    | project MailTime = Timestamp,
              AccountDisplayName,
              ActionType,
              Application,
              IPAddress;
ConsentEvents
| join kind=leftouter MailEvents on AccountDisplayName
| where isnull(MailTime) or MailTime >= ConsentTime
| order by ConsentTime desc, MailTime desc

Step 6 — Build an OAuth abuse timeline

A timeline helps explain whether consent occurred before or after suspicious authentication, mailbox access or other post-compromise activity.

let TimeFrame = 14d;
let TargetUser = "user@contoso.com";
let IdentityEvents =
    IdentityLogonEvents
    | where Timestamp > ago(TimeFrame)
    | where AccountUpn =~ TargetUser
    | project Timestamp,
              EventType = "IdentitySignIn",
              Account = AccountUpn,
              Detail = strcat(ActionType, " from ", tostring(IPAddress), " ", tostring(Location));
let AppEvents =
    CloudAppEvents
    | where Timestamp > ago(TimeFrame)
    | where AccountDisplayName =~ TargetUser
    | project Timestamp,
              EventType = "CloudAppActivity",
              Account = AccountDisplayName,
              Detail = strcat(ActionType, " | App: ", tostring(Application), " | IP: ", tostring(IPAddress));
union IdentityEvents, AppEvents
| order by Timestamp asc

Common false positives

Legitimate business applicationsTools such as Adobe, DocuSign, Salesforce, Zoom and ticketing platforms may request delegated permissions for valid business workflows.

Microsoft first-party appsNot every application consent event is suspicious. Microsoft apps and approved enterprise applications may appear frequently in normal environments.

Admin-approved integrationsSome integrations are deployed by IT with admin consent. Confirm whether the application is known and approved before treating it as malicious.

User productivity toolsUsers often approve calendar, email or file access for productivity tools. The risk depends on the permissions, publisher, behaviour and timing.

Security toolsMonitoring and backup tools may legitimately request broad read permissions. Validate ownership and expected behaviour.

Old consent, new activityAn application granted months ago may become suspicious only when it starts being used from unusual locations or by unexpected users.

Real-world investigation

The password was changedThe helpdesk reset the user password and revoked sessions after a suspected credential theft incident.

Access continuedMailbox activity continued even though the user was no longer signing in from the suspicious IP address.

The application was still trustedThe attacker had convinced the user to grant consent to a malicious application before the password reset occurred.

The permissions matteredThe application had delegated access that allowed it to read mailbox content without requiring the attacker to know the new password.

The timeline explained itConsent occurred shortly after a suspicious sign-in and before the mailbox access pattern changed.

The response removed persistenceThe team revoked consent, removed the application, invalidated sessions and reviewed other users for similar consent activity.

Investigation checklist

Was a new application granted consent?Identify when the application was added and whether the user or an administrator approved it.

What permissions were requested?Review whether the application requested mail, files, directory, offline access or other high-impact permissions.

Who granted the permission?Determine whether consent came from the affected user, an administrator or another account.

Was consent close to suspicious sign-ins?Correlate the consent event with impossible travel, credential theft, risky sign-ins or MFA anomalies.

Has the application been used?Look for application activity after consent, especially mailbox, file or directory access.

Has access been revoked?Remove the app, revoke consent, invalidate sessions and check whether similar permissions exist for other users.

Related Agent Foskett Academy lessons

Lesson 101 — Hunting Playbook: Impossible TravelInvestigate suspicious location changes and impossible travel sign-in behaviour.

Lesson 102 — Hunting Playbook: Credential TheftBuild a credential theft timeline using identity and Microsoft Defender XDR telemetry.

Lesson 103 — Hunting Playbook: Malicious Inbox RulesInvestigate mailbox persistence and suspicious forwarding rules after compromise.

Investigating CloudAppEventsUse CloudAppEvents to investigate application and cloud activity inside Defender XDR.

Investigating IdentityLogonEventsReview identity sign-ins, user activity, IP addresses and authentication patterns.

Building Reusable Hunting QueriesUse reusable query patterns to investigate OAuth abuse consistently.

Coming next

Lesson 105 — Hunting Playbook: PowerShell AbuseNext, Agent Foskett investigates suspicious PowerShell usage, encoded commands, parent-child process relationships and endpoint execution behaviour in Microsoft Defender XDR.

Why this mattersOAuth abuse shows why incident response must remove persistence, not just reset passwords.

Final thought

A compromised password can be changed. A malicious consent grant must be found and removed.

Agent Foskett mindsetWhen access continues after the password is reset, stop looking only at sign-ins and start looking at what has been trusted.

Hunting Playbook SeriesLesson 104 continues the practical investigation series by showing how attackers maintain access through application permissions.

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

Hunting OAuth Abuse in Microsoft Defender XDR

Agent Foskett Academy Lesson 104 teaches defenders how to investigate OAuth abuse, malicious application consent, delegated permissions and persistent access in Microsoft Defender XDR and Microsoft Entra ID.

Microsoft Entra ID OAuth abuse investigation playbook

This hunting playbook explains how to review consent events, suspicious applications, permissions, token activity and cloud application telemetry during Microsoft 365 compromise investigations.

Learn to hunt malicious OAuth applications with KQL

Defenders can use KQL, CloudAppEvents, IdentityLogonEvents and Microsoft Defender XDR telemetry to detect malicious OAuth apps and remove attacker persistence.