ShinyHunters’ browser-based attacks expose SaaS identity gaps

At a glance

What this is: This is a Push Security analysis of how ShinyHunters and SLH are using browser-based identity attacks to compromise SaaS environments at scale.

Why it matters: It matters because the attack paths cut across human IAM, NHI trust, and third-party OAuth governance, which means identity teams have to treat browser-layer authorization as a control plane, not a convenience layer.

By the numbers:

• ShinyHunters alone claimed over 1.5 billion stolen Salesforce records from a single campaign targeting more than 1,000 organizations.
• Unit 42 documented Cordial Spider and Snarky Spider moving from initial compromise to complete data exfiltration in under an hour.
• Push now tracks 12+ distinct device code phishing kits in the wild and has measured a 37.5x increase in device code phishing activity since the start of 2026.

👉 Read Push Security’s analysis of ShinyHunters’ browser-based attack chains

Context

Browser-based identity compromise is now a primary path into SaaS, and the security failure starts before exfiltration. In this threat pattern, the attacker does not need to break the cloud platform directly; they exploit human authentication, device authorization, or third-party OAuth trust to obtain valid access.

For IAM and NHI programmes, the key problem is that existing controls often assume the login event is the control point. ShinyHunters and related SLH activity shows the real control point is the authorisation decision, the session token, and the downstream trust boundary created when integrations are granted access.

That makes this topic relevant across human identity, NHI governance, and lifecycle control. A stolen browser session, a compromised OAuth grant, or a replayed credential all produce the same governance failure: an identity artefact is accepted as proof of legitimacy long after the trust decision that created it has gone stale.

Key questions

Q: How should security teams stop browser-based SaaS identity attacks?

A: Security teams should treat the browser as part of the identity control plane. That means monitoring session creation, OAuth consent, and device-code flows, then blocking risky grants before tokens are issued or reused. Browser-layer visibility is essential because these attacks often bypass email security and succeed after the login screen has already been satisfied.

Q: Why do OAuth-connected third-party apps create identity risk?

A: OAuth-connected apps extend trust beyond the organisation’s own perimeter into a vendor’s security posture. If the integrator is compromised, attackers can inherit downstream access through valid tokens without attacking the customer directly. The risk grows when grants are broad, refresh-capable, or left in place without ownership review.

Q: How do you know if device-code phishing controls are working?

A: They are working when suspicious code-entry events are blocked or stepped up, and when the organisation can see which apps requested the flow, which scopes were asked for, and whether the grant was approved under policy. If device-code activity is invisible to the identity team, the control is not working.

Q: Who is accountable when a compromised integration exposes downstream SaaS data?

A: Accountability sits with both the business owner that approved the integration and the identity or security team that allowed the grant to remain in place without lifecycle review. Third-party OAuth access should be governed like standing access, because once it is granted it can persist until someone explicitly revokes it.

Technical breakdown

AiTM phishing and browser session capture

Adversary-in-the-middle phishing proxies the victim’s login in real time, relays the username, password, and MFA challenge to the genuine identity provider, and steals the resulting session token after authentication succeeds. The attacker does not need to defeat MFA cryptographically because they are harvesting the authenticated browser session itself. In practice, this turns the browser into the compromise surface and leaves the IdP believing the login was legitimate. When voice phishing is used to steer the victim into the page, traditional email controls miss the interaction entirely.

Practical implication: monitor and block suspicious browser-mediated authentication flows, not just email phishing.

Device code phishing and OAuth authorisation abuse

Device code phishing abuses OAuth 2.0 device authorization by tricking the user into entering an attacker-provided code on a legitimate verification page. The victim is often already signed in, so no password or MFA prompt is bypassed. Instead, the attacker receives an access token after the user approves the flow, which makes the attack structurally different from login theft. The core weakness is that the organisation treats the authorisation flow as low-risk, even though it can mint broad API access and refresh tokens for downstream systems.

Practical implication: govern device-code and consent flows as privileged access events.

OAuth supply chain compromise through third-party integrators

OAuth-connected third-party apps extend an organisation’s security boundary into the vendor’s own posture. If an integrator is compromised, stolen tokens can provide durable downstream access without touching the victim’s perimeter directly. That makes the trust relationship itself the attack surface. In these cases, the weakness is not only token theft but also the absence of tight scope control, grant visibility, and lifecycle review for external SaaS connections.

Practical implication: inventory third-party OAuth grants and treat them as externally governed access paths.

Threat narrative

Attacker objective: The objective is durable SaaS access that can be monetised through data theft, extortion, and repeated compromise of connected systems.

1. Entry begins with vishing, AiTM phishing, device code abuse, or a compromised third-party integrator that creates a legitimate-looking access path into the browser-based identity flow.
2. Credential access occurs when the attacker captures a session token, OAuth token, or refresh token, or reuses infostealer-harvested credentials already circulating in criminal markets.
3. Escalation follows as the attacker uses the granted session or token to pivot into SaaS data stores, connected applications, cloud consoles, and downstream integrations.
4. Impact is achieved through bulk data exfiltration, extortion, and repeated re-entry into the same environment if the original trust relationship remains active.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser-layer identity is now part of identity governance, not just endpoint security. The attacks in this campaign family succeed because the browser is where authentication, consent, and session reuse all converge. That makes the browser the practical control plane for SaaS identity abuse, especially where the attack never touches a traditional perimeter. Practitioners should treat browser-mediated identity events as governable access decisions, not background user activity.

Consent trust debt is the named concept this campaign makes unavoidable. Every third-party OAuth grant increases the amount of trust the organisation has already prepaid without continuous revalidation. When a vendor, integrator, or app is later compromised, the organisation still carries the old trust decision forward as if it were current. The implication is that governance cannot rely on initial approval alone, because the attack surface grows with every dormant or under-reviewed grant.

Session theft exposes a collapse in the assumption that successful login equals controlled access. That assumption was designed for a world where authentication and authorisation were closer together. It fails when an attacker can relay MFA in real time, steal the resulting token, and operate entirely inside a valid session. The implication is that identity programmes must separate proof of login from proof of continuing legitimacy.

Device code phishing shows that MFA coverage is not the same as authorisation safety. The user can still satisfy MFA while unknowingly granting a token with broad downstream reach. That means the control gap sits at the consent and scope layer, not the password or passkey layer. Practitioners should re-evaluate where their policy engines actually intervene in the OAuth lifecycle.

Browser-driven SaaS compromise is compressing detection windows below human triage capacity. When compromise to exfiltration can happen in under an hour, review-based security models arrive too late by design. That does not mean review is useless, but it does mean the response model has to move upstream into live control of grant, session, and token issuance. Teams should assume the attacker is already inside the workflow by the time a ticket is opened.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, ahead of inadequate monitoring and logging at 37%.
• For the broader breach context, 52 NHI breaches Report shows how recurring credential and trust failures become repeatable attack patterns.

What this signals

Consent trust debt: security teams should expect third-party OAuth grants to accumulate as a hidden liability unless they are reviewed like standing access. The practical shift is toward continuous grant governance, where new scopes, dormant owners, and stale integrations are monitored alongside traditional identity events.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the control gap is already structural rather than exceptional. That visibility deficit is exactly why browser-layer identity telemetry and app-grant inventories belong in the same operating model.

Teams that still separate endpoint, IAM, and SaaS governance will keep missing the handoff point where browser activity becomes durable access. The forward move is to align browser signals, consent policy, and token lifecycle controls so the identity team sees the full attack path.

For practitioners

• Control browser-mediated authentication paths Block or step up suspicious browser sessions that show AiTM patterns, unusual device-code enrolment, or anomalous login chaining. Feed browser telemetry into identity response so session risk is visible before tokens are reused across SaaS applications.
• Review third-party OAuth grants as standing access Inventory all connected SaaS apps, identify refresh-token capable grants, and require re-approval for any integration with broad scopes or inactive ownership. Remove dormant connections and tie approvals to an explicit business owner.
• Limit consent scope at the point of authorisation Restrict what an app can request, not just what a user can log into. Apply policy to OAuth consent screens, device-code flows, and connected-app requests so broad API access cannot be approved by default.
• Correlate session tokens with downstream data movement Treat a valid session as an early warning signal, then correlate it with unusual export activity, new SaaS connections, and token reuse across tenants. This helps identify when an attacker turns initial access into exfiltration.

Key takeaways

• ShinyHunters’ campaigns show that the browser, not the password field alone, is now a primary identity attack surface for SaaS compromise.
• The scale is material, with campaigns exceeding 1.5 billion claimed Salesforce records and exfiltration sometimes completed in under an hour.
• Practitioners need to govern session tokens, OAuth consent, and third-party grants as active access, because that is where these attacks actually succeed.

Key terms

• AiTM Phishing: Adversary-in-the-middle phishing proxies a real login session between the user and the identity provider so the attacker can steal the resulting authenticated session. It is effective because the user still completes the expected login path, while the attacker captures the token or session cookie that proves access.
• Device Code Phishing: Device code phishing abuses the OAuth device authorisation flow by persuading a user to enter an attacker-provided code on a legitimate verification page. The attack targets authorisation, not password entry, so it can grant broad token-based access even when strong MFA is in place.
• OAuth Consent Grant: An OAuth consent grant is the approval that allows an application to access user or tenant resources through scoped permissions. In practice, it becomes a standing trust decision, and if it is broad, refresh-capable, or poorly reviewed, it can outlive the security conditions under which it was approved.
• Session Token: A session token is the artefact that proves an authenticated browser session is still valid. For identity governance, it matters because a stolen token can let an attacker operate as an already-approved user without repeating the login ceremony that originally created the trust decision.

Deepen your knowledge

Browser-based SaaS identity attacks and OAuth governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to bring browser-layer access under identity control, it is worth exploring.

This post draws on content published by Push Security: ShinyHunters' 2025 hacking spree has continued at pace in 2026. Read the original.