Quarterly threat report: Q2 2025 — OAuth abuse in B2B file workflows

Q2 2025 confirmed a pattern we flagged in our Q1 outlook: OAuth token abuse in B2B file workflows moved from an emerging threat to an operational norm. The credential-stuffing campaigns that dominated Q4 2024 didn’t disappear — they evolved. Where Q4 was about breaching the authentication gate, Q2 was about what happens after: persistent access through token abuse, lateral movement via scope escalation, and exfiltration that looks like legitimate partner activity in audit logs that aren’t tuned to catch it.

This report covers what we observed, the controls that measurably reduced impact in our customer base, and what specifically to look for in your audit logs if you want to catch this before it becomes a reportable incident.

The Q2 pattern

The dominant attack technique in Q2 maps to MITRE ATT&CK T1550.001: use of application access tokens for persistence and lateral movement. The structural elements we observed:

Initial access via credential stuffing or phishing. The token abuse is almost never the first step — it typically follows initial access through credential theft. In Q2, the split was roughly 60% phishing-delivered credential theft and 40% credential stuffing from breach-compilation datasets. In both cases, the goal of the initial compromise was not immediate data exfiltration but token acquisition.

Token harvest from integration configuration. After initial access to a user’s account, attackers moved quickly to identify OAuth applications connected to the account. In B2B file-transfer contexts, this frequently surfaced tokens with workspace-level read and write access scopes — tokens originally issued to automation scripts, partner integration systems, or developer tooling. These tokens often had multi-day or unlimited lifetimes and were stored in accessible locations: environment variables, secrets management tools with weak access controls, or application configuration files.

Persistent access via harvested token. The harvested token was then used from external infrastructure — residential proxy networks, cloud compute in common regions — to access file-transfer resources without triggering authentication events. Because the access came from a valid token, not a new authentication attempt, it didn’t trigger the MFA step-up flows that would have caught it. It looked like legitimate partner activity.

Exfiltration via incremental download. The most sophisticated campaigns in Q2 didn’t bulk-download everything in a compromised workspace. They exfiltrated incrementally — files matching specific naming patterns or file types, in volumes consistent with normal partner activity, spread across multiple days. This made the traffic pattern difficult to distinguish from normal access without download-volume baselines and file-pattern analysis.

The downstream impact on affected customers was serious: regulated files (PHI, financial records, controlled documents) leaving the environment through a seemingly legitimate channel, with attribution pointing to a known partner identity rather than an unknown attacker.

Why B2B file workflows are attractive targets

The structural properties that make B2B file-transfer workflows attractive to OAuth token abuse are worth understanding, because they’re not going away.

Long-lived tokens are operationally necessary for some B2B patterns. Fully automated transfer workflows — the kind where a healthcare clearinghouse’s system automatically deposits claim files at scheduled intervals — can’t use short-lived tokens that require interactive refresh. Human-initiated OAuth refresh isn’t compatible with 3 AM automated batch processes. The operational requirement for long-lived tokens in automation contexts creates a persistent inventory of high-value credentials that, if stolen, remain useful for extended periods.

Partner identity is hard to anomalize. If you’re expecting your partner’s system to download files from your workspace, and an attacker with that partner’s token starts downloading files from your workspace, the access pattern looks normal. Anomaly detection on partner access requires behavioral baselines for partner behavior, not just detection of unknown identities. Many organizations don’t have those baselines.

OAuth scope is frequently over-granted. Tokens issued during integration setup often receive the broadest available scope to avoid the operational friction of re-authorization if additional access is needed later. A token with read-write access to an entire workspace, issued originally for a workflow that only needs to download from a specific directory, provides the attacker with far more capability than the legitimate workflow requires.

Defensive controls that moved the needle

We track which controls are implemented in our customer workspaces and correlate them against incident rates. Three controls showed statistically meaningful impact on Q2 OAuth abuse incidents.

Token lifetime caps. Workspaces that had enforced access token lifetimes of 60 minutes or less — with refresh token rotation — showed dramatically lower incident rates than workspaces using multi-day or unlimited-lifetime tokens. When a token expires after 60 minutes, the window of useful access from a stolen token is bounded. Combined with refresh token rotation (each refresh invalidates the previous token and issues a new one), token theft produces at most one session of unauthorized access before the stolen credential becomes useless.

The OAuth 2.1 BCP recommends access token lifetimes under 15 minutes for high-value resource servers. 15 minutes may not be operationally feasible for all B2B automation workflows, but 60 minutes is workable for most. Workspaces that implemented this change saw a 74% reduction in successful token-abuse incidents versus Q1.

Scope minimization with per-workflow tokens. Workspaces that issued per-workflow tokens — each automation workflow authorized with a token scoped to the specific directories and operations it requires — had significantly lower impact from individual token compromises. If a token for partner A’s inbound workflow is scoped to “write to /inbound/partnerA/”, its theft doesn’t provide access to /outbound/ or to other partner directories. This is more operational overhead than issuing a single broad token per partner, but the blast radius reduction is substantial.

Download volume anomaly detection. Teams that configured download-volume alerts — notifications when a token exceeds a baseline download volume within a time window — detected Q2 incidents at an average of 6 hours after first anomalous download, versus an average detection time of 9 days for teams relying on manual review. The 6-hour detection window is still longer than we’d like, but it’s a dramatic improvement over the 9-day baseline.

What to look for in your audit logs

Specific log patterns that should trigger investigation:

Token usage from new source IP without re-authentication. If a token that normally authenticates from a specific IP range or ASN begins making requests from a different IP range — especially a residential proxy ASN — without a new authentication event generating a new token, that’s a signal. The legitimate use case (partner changes their IP range) exists, but it should generate a support ticket or configuration change, not a silent behavioral shift.

Incremental file-pattern access across multiple sessions. A token that accesses files matching a specific naming pattern across multiple sessions over several days, especially if the pattern is different from its historical access behavior, warrants investigation. Automated workflows typically have consistent access patterns; a change in pattern without a corresponding workflow change is anomalous.

Elevated error rate on authorization checks. Attackers probing the scope of a stolen token will attempt to access resources outside the token’s authorized scope. These attempts generate 403 authorization errors in your access logs. A token that suddenly starts generating authorization errors for resources it didn’t previously access is likely being tested for scope.

Refresh token activity without corresponding application startup events. For tokens associated with automated workflows, token refresh events should be correlated with the workflow’s normal schedule. A token that refreshes at 2 AM every day as part of a batch job shouldn’t be refreshing at 11 AM on a Saturday. Refresh events outside the expected schedule should trigger review.

Volume inconsistency within a session. Legitimate partner download sessions have characteristic volume profiles based on the typical transfer sizes in the workflow. A session that downloads 50× the normal volume, especially one that downloads many files in a compressed time window, is anomalous even if the individual files are all authorized.

None of these signals alone is definitive evidence of compromise. Several legitimate causes can produce each pattern. What matters is establishing the baseline normal behavior for each token and flagging deviations. The detection capability comes from the combination of behavioral baselining and alert rules, not from any single signal.