[DEEP RESEARCH] The account stealing your data may not be human

A SaaS breach may begin with a person, but the account that moves the data can be an OAuth app, refresh token, integration user, service principal, API key, or vendor connector. That is the core judgment: delegated authority is becoming the operational center of SaaS data theft, while many investigations still center the human login.

The defender tension is practical. Resetting a password and MFA can close the visible door while leaving a reusable contractor badge active. The payoff for analysts is a better incident model: trace who granted authority, which non-human principal inherited it, what data it touched, where it operated from, and whether revocation was actually proved.

TL;DR

• Recent Salesforce-centered campaigns show two recurring paths: users induced to authorize malicious connected apps, and trusted third-party integrations whose OAuth tokens are compromised.
• The human interaction is often the ignition. The app, token, or integration identity becomes the engine for scripted API access and bulk collection.
• Login-only detections miss the important layer. Defenders need app identity, scope, source-network, API-volume, object-access, and export telemetry.
• Public reporting does not support a reliable prevalence percentage. The evidence does support treating delegated authority as a leading hypothesis in SaaS exfiltration cases.
• Containment is not complete until grants, tokens, keys, sessions, connectors, and downstream exposure are mapped and revocation is proved.

The thesis

The weak read is: “the user was phished.”

The stronger read is: “the attacker obtained reusable delegated authority, then used sanctioned SaaS APIs to query and export data with less behavioral noise.”

That distinction changes the investigation. A user timeline asks which person authenticated and whether the sign-in looked suspicious. An authority map asks which app, token, service principal, or connector could read the data; which scopes it held; which objects it accessed; which infrastructure used it; and what survived the first containment action.

Public evidence is incomplete, so this is not a claim that non-human identities drive most SaaS breaches. Many disclosures never name the identity primitive involved. The defensible judgment is narrower: across multiple technically detailed 2025–2026 SaaS data-theft campaigns, delegated non-human authority was not background configuration. It was the mechanism that made collection durable and scalable.

What changed

Three campaign patterns sharpen the lesson.

Google reported that UNC6040 operators used voice phishing to manipulate users into authorizing malicious Salesforce connected apps, including apps presented as Data Loader-like tooling. The user action mattered, but the connected app became the data-access principal.

Google and Unit 42 reported that compromised OAuth credentials associated with the Salesloft Drift integration were used to access Salesforce customer environments, query CRM objects, and export data. This path did not require compromising every downstream user. Trust already granted to the integration carried the access.

Microsoft’s July 2026 reporting on ShinyHunters-associated SaaS abuse described both vishing-driven OAuth consent and compromise through trusted SaaS relationships. The durable pattern is not one actor label or one CRM vendor. It is the conversion of legitimate delegated authority into attacker-operated automation.

The malware is missing because the platform already provides the collection machinery.

Why attackers prefer delegated authority

SaaS APIs are designed to move data efficiently. CRM, support, collaboration, marketing, and data platforms need exports, synchronization, enrichment, reporting, and automation. An attacker with the right authority can use the same paths.

Delegated access offers four advantages:

1. Durability. Refresh tokens, app grants, service credentials, and integration sessions may outlive the initial user event.
2. Scale. APIs, report exports, pagination, list views, and bulk jobs support scripted collection.
3. Legitimacy. Activity can appear under an approved client ID, connected app, integration user, or vendor workflow.
4. Inherited reach. One connector may bridge CRM records, support cases, documents, collaboration tools, identity systems, and data warehouses.

This is the kind of problem that punishes tired teams. Password reset, MFA reset, and endpoint triage are familiar moves. Mapping app grants, scopes, vendor tokens, and downstream connectors is slower, often split across owners, and easy to postpone.

Attackers benefit from that ownership gap.

The paywall tear line

The public lesson is simple: do not stop at the phished user.

Below the line, we map the full authority chain, show the telemetry that exposes app-driven collection, and give teams a revocation-proof workflow that can prevent a reassuring but false containment call. We also attach the technical deep dive.

The authority chain

A useful SaaS incident model has seven steps: