DFIR Tools · Research · Blog

OAuth abuse is one of those areas where the activity can look very clean on the surface. There may be no malware. There may be no suspicious executable. There may not even be a traditional “bad login” in the way many people expect.

That is what makes it dangerous.

OAuth itself is not malicious. It is a legitimate authorization framework used across modern cloud platforms to allow applications to access resources without constantly asking users to re-enter credentials. The problem is that attackers can abuse that same legitimate framework to gain access, maintain access, and interact with cloud data through approved-looking application activity.

From an investigative standpoint, OAuth abuse is not just an authentication issue. It is an identity, application, permission, and activity correlation problem.

What OAuth Abuse Looks Like in Practice

In a common OAuth abuse scenario, the attacker does not need to install malware on the victim system. Instead, the attacker gets the user to authorize an application.

That may happen through a phishing email, a fake document sharing link, a spoofed productivity application, or a login flow that looks close enough to normal that the user does not realize what they approved.

The user may believe they are signing into Microsoft 365, Adobe, DocuSign, Dropbox, or some other legitimate service. In reality, they are being asked to grant permissions to an application controlled by the attacker.

Depending on the permissions requested and granted, that application may be able to read mail, access files, maintain offline access, enumerate profile information, or interact with cloud resources through API calls.

Once consent is granted, the attacker may not need the user’s password again in the same way they would during a traditional credential compromise. The attacker can potentially use tokens and granted permissions to continue accessing data through the authorized application.

That is the part that gets missed.

The compromise may not be a continuing series of obvious interactive logins. It may transition into application-driven or token-driven activity that blends into normal cloud behavior.

The Basic Attack Flow

The specific details will vary, but the general pattern often looks something like this:

• The attacker registers or controls an OAuth application.
• The attacker sends the victim a link that initiates an authorization or consent flow.
• The victim authenticates through a legitimate identity provider page.
• The victim grants requested permissions to the application.
• The attacker receives authorization to access resources through the granted permissions.
• The attacker uses tokens or application permissions to access mail, files, profile data, or other cloud resources.
• The activity may continue until the consent grant, service principal, token/session, or application access is revoked.

This is why password resets alone may not be enough in every OAuth abuse scenario. If the investigation identifies suspicious application consent, the response has to address the application, the consent grant, the service principal, active sessions, and any downstream activity performed through that access.

Why OAuth Abuse Can Be Hard to Detect

OAuth abuse is difficult because it often uses legitimate infrastructure and legitimate authentication flows.

To the user, the screen may look normal. To the cloud provider, the flow may look like a user authenticated and approved an application. To a basic log review, the activity may look like a successful sign-in followed by application activity.

That is not enough context.

Investigators have to ask different questions:

• Was this application expected in the tenant?
• Who consented to the application?
• When was consent granted?
• What permissions were requested?
• Were the permissions excessive for the stated purpose of the app?
• Was the application publisher verified?
• Did access continue after the initial user interaction?
• Did the activity involve mailbox access, file access, or Graph API activity?
• Were there related sign-ins from suspicious infrastructure?

OAuth abuse is rarely solved by looking at one event. It is reconstructed by correlating authentication, application, consent, and activity data across time.

Log Sources That Matter

The exact log availability depends on licensing, retention, configuration, and what data was collected before the investigation began. But in Microsoft 365 and Entra ID environments, the following sources are typically important.

Microsoft Entra Interactive Sign-In Logs

Interactive sign-in logs help show direct user authentication activity. These logs are useful for identifying the user’s authentication path around the time consent was granted or suspicious application access began.

Investigators should review:

• User principal name
• Application displayed in the sign-in event
• Resource accessed
• Source IP address
• Location details
• Device details
• Client application
• User agent
• Authentication requirement
• MFA details and Conditional Access results
• Result codes and failure reasons
• Correlation IDs, request IDs, and token identifiers where available

These logs may help answer whether the user completed an interactive authentication session from an unusual location, unfamiliar network, new device, or unexpected client.

Microsoft Entra Non-Interactive Sign-In Logs

Non-interactive sign-in logs are important because OAuth abuse may continue through background authentication activity, token refreshes, or application-driven access.

A victim may only have one or two obvious interactive events, while the more important activity appears later as non-interactive access.

Investigators should review:

• Repeated non-interactive activity involving the suspicious application
• Refresh token behavior
• Access from unfamiliar IP addresses or ASNs
• Activity occurring after password resets or user remediation
• Client applications and resources accessed
• Unexpected service principal or application activity

This is one of the areas where investigators can miss the attack if they only review interactive sign-ins.

Microsoft Entra Audit Logs

Audit logs are critical for understanding changes made to users, applications, service principals, permissions, and consent grants.

Investigators should look for events involving:

• Consent granted to application
• Application registration activity
• Service principal creation
• Permission grant changes
• Admin consent activity
• Changes to application credentials or secrets
• Changes to users, groups, roles, or delegated access

These records help establish what changed in the tenant and when those changes occurred.

Microsoft 365 Unified Audit Log

The Unified Audit Log can help determine what the attacker did after access was granted.

Relevant activity may include:

• Mailbox access
• Mail item reads or searches
• Inbox rule creation
• File access in OneDrive or SharePoint
• Sharing activity
• Administrative operations
• Application or Graph API-driven activity where logged

This is where the investigation starts moving from “how did access occur?” to “what did the attacker do with that access?”

Endpoint and Browser Artifacts

Endpoint evidence may still matter, even when the primary compromise is cloud based.

Browser history, cached pages, downloaded files, phishing emails, local token artifacts, suspicious extensions, and process execution history may help explain how the user reached the consent page or whether token theft occurred through another mechanism.

The absence of malware does not mean the absence of compromise.

Indicators and Patterns to Look For

OAuth abuse usually becomes clearer when the investigator focuses on patterns instead of single log entries.

Useful indicators include:

• New or unfamiliar OAuth applications granted access by a user
• Applications with vague or misleading names
• Unverified publishers or suspicious publisher information
• Delegated permissions inconsistent with the application’s stated purpose
• Requests for broad permissions such as mail, files, directory, or offline access
• Consent activity shortly after phishing email delivery
• Interactive sign-ins from new countries, ASNs, VPNs, proxies, or hosting providers
• Non-interactive activity continuing after the initial authentication event
• Mailbox or file access without a normal user activity pattern
• Graph API activity associated with an unfamiliar application
• Service principal or app registration activity that does not align with normal business operations

None of these automatically prove malicious activity by themselves. They are investigative leads. The value comes from correlating them into a timeline that explains what happened.

Practical Investigation Approach

A practical OAuth abuse investigation should usually start with scope and timeline.

First, identify the user, application, and relevant time window. Then determine whether there was a suspicious consent event, unusual authentication activity, or unexpected application access.

From there, build the timeline:

• When did the user receive or interact with the suspected phishing lure?
• When did interactive authentication occur?
• When was consent granted?
• What permissions were granted?
• What IPs, ASNs, devices, and user agents were involved?
• Did non-interactive activity follow?
• What mailbox, file, or cloud activity occurred afterward?
• Was access still active after password reset or other remediation?

The goal is not simply to find a bad app. The goal is to reconstruct the access path, identify what data may have been exposed, determine persistence mechanisms, and document the activity in a way that can be explained clearly.

Why Correlation Matters

OAuth abuse sits at the intersection of identity, application permissions, tokens, and user activity.

That means no single log source is usually enough.

Interactive sign-ins may show the user authentication. Non-interactive sign-ins may show continued token activity. Entra ID audit logs may show application registrations, consent grants, or permission changes. Unified Audit Log records may show what the application or user accessed. Endpoint evidence may show the phishing path or token theft mechanism.

Each source provides part of the story.

The investigation becomes defensible when those pieces are placed into a coherent timeline.

Final Thought

OAuth abuse represents a shift in how modern cloud intrusions occur.

Attackers do not always need malware when they can abuse legitimate authorization workflows, trusted identity providers, and approved-looking application access.

For investigators, this means OAuth activity cannot be treated as background noise. Application consent, token behavior, sign-in telemetry, audit events, and cloud activity all need to be reviewed together.

The question is not just whether a user logged in.

The better question is what access was granted, what used that access, and what happened afterward.

OAuth abuse is not “just an app issue.” It is an identity-forensics issue, and it requires timeline reconstruction across authentication, authorization, and cloud activity.

References and Further Reading

• Microsoft: App consent grant investigation
• Microsoft: Detect and remediate illicit consent grants in Microsoft 365
• Microsoft: Protect against consent phishing
• Microsoft: Sign-in logs in Microsoft Entra ID
• Microsoft: Audit logs in Microsoft Entra ID