Microsoft OAuth Redirect Abuse: First 48 Hours of Incident Triage for Microsoft 365 and Google Workspace

Microsoft says attackers are abusing legitimate OAuth redirection behavior to move users from trusted identity flows to attacker-controlled infrastructure. In the activity Microsoft described, attackers used silent OAuth authentication flows and intentionally invalid scopes to trigger redirection without stealing tokens directly, and Microsoft also noted that related activity persists and requires ongoing monitoring.

That changes the first question defenders should ask. This is not only, “Did someone steal a password?” or even, “Was an access token issued?” It is also, “Which user clicked, which identity flow was invoked, which app or redirect URI was involved, what landed on the endpoint, and what follow-on access or persistence happened next?” For Microsoft 365 and Google Workspace teams, the first 48 hours should focus on preserving evidence, scoping impact, and containing the right things in the right order.

If you are already seeing suspicious logins, unfamiliar OAuth prompts, user complaints about fake Microsoft 365 or Google sign-in pages, or unusual downloads after a phishing click, this is the stage where an evidence-first workflow matters most. For a broader evidence-handling workflow, see our recent post, 7 Proven Digital Forensic Analysis Steps for Legal Evidence.

What Microsoft disclosed and why this attack path is different

Microsoft’s write-up is important because it frames this as abuse of standards-compliant OAuth behavior, not a classic software vulnerability and not a simple token theft scenario. Attackers can register a malicious application, point its redirect URI at attacker-controlled infrastructure, and craft OAuth URLs that look familiar enough to bypass a lot of “hover over the link” user advice. Microsoft also says this pattern was observed across Microsoft and Google OAuth providers, which is why Microsoft 365 and Google Workspace defenders should both take it seriously.

The result is a more complicated triage path. Even when the user never grants consent and the sign-in fails, the redirect can still deliver the victim to a phishing or malware destination. Microsoft documented cases where the redirect chain led to malicious landing pages, and in one malware-delivery example the follow-on activity included PowerShell execution and DLL side-loading.

That is why teams should not treat this as “only an identity issue.” It is an email, identity, endpoint, and application-governance problem at the same time. If you only review password resets and successful sign-ins, you can miss the real blast radius.

Which tenants and users should be investigated first

Start with the users most likely to turn a redirect-based phish into a business-impact event:

• users who clicked suspicious Microsoft 365, Teams, Google, password reset, document, e-signature, or meeting-themed emails
• privileged users, help desk, identity admins, finance, shared mailbox owners, and employees who can authorize or manage integrations
• users who reported odd app prompts, unfamiliar consent screens, or post-login redirects to unrelated domains
• systems where browser downloads, ZIP files, HTML files, LNK files, or unusual PowerShell activity appeared soon after a click
• tenants with unfamiliar enterprise apps, unexpected app permissions, or unusual service principal activity
• Google Workspace users tied to new OAuth grants, third-party app access, or suspicious entries in OAuth log events and API controls.

For Google Workspace, this is partly an inference from Microsoft’s observation that the technique can be used across Microsoft and Google OAuth providers, combined with Google’s own auditing and app-governance controls. In practice, that means Workspace defenders should review OAuth log events, the audit and investigation tool, the OAuth grants to new apps report, and API controls rather than assuming the problem is limited to Entra ID tenants.

First 48 hours of OAuth redirect abuse triage

Hours 0–4: preserve evidence before broad resets

The first move should be controlled preservation, not tenant-wide disruption. Microsoft documents that Entra audit and sign-in logs can be downloaded directly from the admin center, and Google Workspace gives admins access to OAuth log events and audit/investigation searches. Capture the evidence window before you revoke sessions, remove apps, or perform broad resets that make later reconstruction harder.

In this initial window, preserve:

• the original phishing email, headers, URLs, and attachments
• user-reported screenshots of the redirect flow and final landing page
• Microsoft Entra sign-in logs for affected users
• Microsoft Entra audit logs for application and consent activity
• service principal sign-in logs for suspicious apps or identities
• Google Workspace OAuth log events, admin log events, and app access records
• endpoint browser history, download history, EDR alerts, and process telemetry
• a UTC-based action log showing who collected what, when, and why.

Screenshot of the Free Website Vulnerability Scanner Dashboard

Hours 4–24: correlate email, identity, endpoint, and app-consent evidence

This is where many investigations fail. Teams look at the email in isolation, or they look only at endpoint alerts, or they review only successful sign-ins. For this attack path, correlation matters more than any single signal. Microsoft specifically recommends cross-domain hunting across email, identity, and endpoint data.

For Microsoft 365 and Entra ID, review:

• interactive and non-interactive sign-ins for affected users
• service principal sign-ins tied to suspicious apps
• audit events involving app permission grants or removals
• newly created or unusual enterprise applications
• user consent and admin consent paths for affected accounts
• risky sign-ins, unusual application usage, and changes that coincide with the phishing window.

For Google Workspace, review:

• OAuth log events to see which users used which third-party applications and when Google data access was authorized
• the OAuth grants to new apps report for recent app authorizations
• API controls and Manage App Access for unfamiliar or high-risk apps
• audit and investigation searches across related user and admin activity.

For endpoint evidence, do not stop at “user clicked.” Microsoft documented campaigns that progressed from redirect abuse to payload delivery. That means your review should include downloaded files, browser-launched child processes, PowerShell, signed-binary abuse, DLL side-loading, and outbound connections that started immediately after the redirect flow.

A useful first hunting query for Defender customers is to search for invalid-scope patterns associated with OAuth redirect abuse:

UrlClickEvents
| where ActionType == "ClickAllowed" or IsClickedThrough == true
| where Url has "scope=invalid" or UrlChain has "scope=invalid"
| project Timestamp, AccountUpn, Url, UrlChain, NetworkMessageId
| order by Timestamp desc

This is adapted from Microsoft’s own hunting guidance for the campaign family it described.

If you need to export Entra sign-in evidence quickly, Microsoft documents the Get-EntraAuditSignInLog cmdlet and the required scopes and roles:

Connect-Entra -Scopes 'AuditLog.Read.All','Directory.Read.All'
Get-EntraAuditSignInLog -All

Microsoft also notes that Reports Reader is the least-privileged role required to access activity logs in the admin center.

Hours 24–48: scope impact and decide whether you have phishing only, app abuse, or endpoint compromise

By this stage, you should be able to answer five questions clearly:

1. Which users interacted with the lure?
2. Which redirect URI, app, or provider flow was involved?
3. Did any user grant or modify access to an app?
4. Did any endpoint execute or download suspicious content after the redirect?
5. Did any mailbox, Drive, SharePoint, Graph, or other data-access activity follow?

Be especially careful with Microsoft’s note that the Azure portal method for app consent review is limited for older admin consent history; the Microsoft incident-response playbook recommends PowerShell-based investigation for broader visibility. If your incident window extends beyond what the portal shows, do not assume the absence of visible grants means the absence of abuse.

Containment steps before resets or tenant-wide disruption

Containment should be precise. Broad resets done too early can destroy investigative context and still fail to remove the real foothold.

A more defensible order is:

• export and secure logs first
• isolate affected endpoints if malware execution is suspected
• disable or restrict suspicious apps and review their permissions
• remove or restrict malicious or unnecessary Google Workspace app access through API controls
• revoke sessions and rotate credentials for confirmed affected users after evidence capture
• review mailbox rules, forwarding, delegated access, and high-risk data access
• document every action in the case record.

For Microsoft tenants, app permission activity logs and enterprise app permission views help confirm what was granted and by whom. For Google Workspace, API controls and OAuth reporting help you determine whether access should be blocked, limited, or escalated for deeper review.

Sample report from the tool to check Website Vulnerability

When to escalate to remediation, DFIR, or pentest validation

Escalate to full remediation or DFIR when any of the following are true:

• a user reached an attacker-controlled landing page and there is evidence of download or execution
• an unfamiliar OAuth app, consent grant, or enterprise application is present
• an administrator, finance user, or integration owner is affected
• you cannot confidently explain the sign-in, consent, and endpoint timeline
• the incident touches regulated data, contractual reporting duties, or customer-facing services
• you need defensible evidence preservation and a formal investigation record.

That is where DFIR and Digital Forensics, Remediation Services, and Risk Assessment Services fit naturally. Pentest Testing Corp’s live service pages position DFIR around confirming compromise, preserving evidence, and guiding containment, while remediation and risk assessment services focus on closing gaps and building an audit-ready path forward.

After containment, API Penetration Testing is also a strong follow-on step. OAuth abuse rarely stays isolated to one screen; it often intersects with API permissions, delegated access, integrations, and business workflows. If you want proof that your fixes work across tokens, scopes, callbacks, webhooks, and authorization boundaries, validate them with a targeted post-incident assessment.

Hardening the tenant after triage

Once the immediate fire is under control, hardening should focus on governance and visibility, not just password resets.

Priority improvements include:

• tightening user consent and admin consent processes
• routinely reviewing consented or accessed applications
• using Conditional Access and stronger risk-based authentication controls
• extending log retention and exporting identity logs to SIEM or Log Analytics
• creating detections for invalid-scope redirect patterns and suspicious app grants
• strengthening endpoint controls against HTML-smuggling, shortcut abuse, and suspicious scripting
• validating OAuth, API, webhook, and integration flows through targeted security testing.

If you want a practical companion read for the hardening phase, pair this with 7 Powerful Risk-Based Authentication Hardening Moves and 7 Proven Digital Forensic Analysis Steps for Legal Evidence. One helps reduce future identity abuse; the other helps preserve the evidence you will need if something still gets through.

Final takeaway

OAuth redirect abuse matters because it exploits trust in legitimate identity flows. That means the first 48 hours should not revolve around a single console or a single control. They should revolve around evidence preservation, cross-domain correlation, precise containment, and fast validation of what actually happened. Microsoft has already said this activity is operational and ongoing, not theoretical.

If your team needs help with Microsoft 365 or Google Workspace incident triage, evidence preservation, remediation support, or post-incident validation, review our Digital Forensic Analysis Services, or contact us to book a rapid scoping discussion.