ShinyHunters’ browser-based attacks expose SaaS identity gaps

At a glance

What this is: This is a Push Security analysis of how ShinyHunters and related SLH crews are using browser-based attacks to bypass SaaS identity controls at the authorization layer.

Why it matters: It matters because IAM teams now have to govern browser-mediated sessions, OAuth trust, and credential replay as core identity risks, not edge cases.

Context

Browser-based SaaS attacks exploit the point where authentication appears to succeed but authorization is already being abused. In this campaign pattern, the browser is not just the delivery channel; it is where token capture, consent abuse, and session takeover happen fast enough to outrun human response.

For IAM and NHI programmes, the important shift is that the trust boundary has moved into browser sessions, OAuth grants, and third-party integrations. That means the security problem is no longer only password hygiene or MFA strength, but the governance of delegated access, token lifetimes, and the controls that decide what an authenticated session may do.

Key questions

Q: What breaks when identity controls stop at the endpoint and ignore the browser session?

A: Browser-native attacks can complete authentication, steal tokens, and trigger consent without host-level malware or suspicious process activity. That means the organisation may see a clean endpoint while the attacker already holds a valid session. The control failure is not endpoint weakness alone, but a missing governance boundary around where identity actions actually occur.

Q: Why do passwords, MFA, and passkeys fail to stop device code phishing?

A: They fail because the user completes a legitimate sign-in inside the identity provider, so the attacker receives a valid token rather than stealing the factor itself. The security problem is delegated token issuance to the wrong client, not weak primary authentication. Detection has to look at protocol use and downstream session activity.

Q: How should security teams govern third-party OAuth access for SaaS integrations?

A: Treat third-party OAuth grants as NHI assets with owners, scopes, and lifecycle rules. Require approval for high-risk permissions, inventory refresh-token use, and define revocation triggers for staff changes, app changes, and anomalous activity. The goal is to make delegated access visible enough to review and fast enough to remove.

Q: How should security teams reduce browser-based identity compromise across SaaS apps?

A: Security teams should treat the browser as an identity control point, not just a user interface. That means inventorying browser-accessed apps, limiting OAuth consent, restricting browser extensions, and using telemetry that can detect session theft and suspicious user actions before attackers turn access into data loss.

Technical breakdown

How AiTM phishing turns a valid login into a stolen session

Adversary-in-the-middle phishing works by proxying the victim’s authentication flow through an attacker-controlled page. The victim enters credentials and MFA input into a live phishing relay, which forwards them to the legitimate identity provider and captures the resulting session token. The attacker does not need to break authentication itself because the browser session becomes the security artifact. That is why passkeys and MFA can still be bypassed when the user is manipulated in real time. In practice, the control failure is not at credential verification but at session issuance and continuity.

Practical implication: monitor and bind sessions more tightly to browser context, device posture, and abnormal access patterns.

Why device code phishing defeats controls at the authorization layer

Device code phishing abuses the OAuth 2.0 device authorization grant, which was designed for devices that cannot comfortably complete a normal browser login. The victim is shown a code and asked to enter it on a legitimate verification page, which grants the attacker a token without the attacker ever touching the password prompt. That makes the attack structurally different from classic phishing because the login can be perfectly valid while the authorization decision is malicious. It also explains why MFA does not stop it: the dangerous act is consenting to the token grant, not authenticating a session.

Practical implication: govern device-code and consent flows as privileged authorization events, not routine sign-ins.

How OAuth supply chain abuse extends the security boundary to third parties

OAuth supply chain attacks happen when an organization authorizes a third-party SaaS integration and implicitly extends trust into the vendor’s security posture. If the integrator or connected app is compromised, the attacker can reuse legitimate OAuth tokens to reach downstream tenants and data. In this model, the attacker often enters through the supplier, not the customer, which makes blast radius depend on connection sprawl and scope granted to the app. This is why integration governance, token scope review, and connected-app inventory are identity controls, not just SaaS admin tasks.

Practical implication: inventory all connected apps and continuously review OAuth scopes, vendor ownership, and revocation paths.

Threat narrative

Attacker objective: The objective is to obtain authenticated SaaS access fast enough to steal data at scale before the organisation can detect, contain, or revoke the session.

1. Entry begins with vishing, AiTM phishing, device code abuse, or compromised third-party integrations that give the attacker a foothold in the browser or SaaS trust chain.
2. Credential or token access follows when the victim relays codes, consents to a device flow, or a compromised integrator exposes OAuth tokens and connected-app access.
3. Escalation occurs as the attacker reuses authenticated sessions or delegated tokens to move from a single account into broader SaaS and downstream data access.
4. Impact is rapid exfiltration, extortion, and in some cases downstream compromise of multiple organizations through shared SaaS integrations.

Breaches seen in the wild

• ShinyHunters Salesforce data theft campaign 2025: Vishing calls got staff to approve malicious Salesforce connected apps that bulk-exported CRM data from Qantas, Allianz Life, Google and dozens more.
• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser-layer identity abuse is now a core SaaS governance problem, not a phishing variant. The common thread across AiTM, device code abuse, and OAuth supply-chain compromise is that the browser has become the control plane for identity abuse. That means the most important decision is no longer whether a login succeeded, but whether the resulting session, token, or consent grant should have been allowed to exist at all. Practitioners should treat browser-mediated authorization as a governed identity surface.

Authorization-layer controls have become more important than login-layer controls for this threat class. These campaigns routinely bypass password strength, MFA, and even passkey narratives by attacking the session or grant after authentication. That changes the identity security model for SaaS-first organisations: the binding risk is no longer just who authenticated, but what that session was allowed to do once established. Teams need to re-evaluate whether their current controls can inspect, constrain, and revoke delegated access in near real time.

Ephemeral trust assumptions are being monetised faster than human review cycles can operate. ShinyHunters’ operating model shows that a validated session or token can be acquired, exploited, and converted into exfiltration in the same short window. The implication is not simply that credentials are valuable, but that review-based governance assumes a slower lifecycle than modern browser attacks actually follow. Security teams should treat rapid token abuse as a structural mismatch between control timing and attacker timing.

Shadow integration risk is now an identity risk, not a vendor-management afterthought. Every third-party OAuth grant extends the organisation’s trust perimeter, and that perimeter can be weaponised when suppliers, apps, or their build chains are compromised. This makes connected-app governance a first-class identity control area alongside access review and secrets management. Practitioners should assume that a forgotten integration can become a breach path even when internal authentication remains intact.

Identity blast radius is the right concept for browser-based SaaS compromise. The same playbook can start with a phish, a stolen token, or a third-party compromise and still end in multi-system data theft. That is why response planning must focus on how far an authenticated identity can reach once the browser session is live, not just on the method used to get in. Teams should measure and reduce the blast radius of every delegated SaaS trust relationship.

What this signals

Identity governance now has to follow the browser. Traditional IAM programmes often stop at authentication events, but these attacks show that the meaningful security decision happens after sign-in, when a session, consent, or integration grant is created. Teams should align browser telemetry with access governance so that delegated access can be inspected and revoked in time.

Shadow integrations create hidden privilege paths. A forgotten SaaS connection can expand organisational trust into a third party that may not be under the same security controls or lifecycle discipline. That makes connected-app inventory, ownership, and offboarding a practical governance priority, not an administrative cleanup task.

Session lifetime is becoming the operational boundary for SaaS risk. When attackers can turn a valid browser session into exfiltration quickly, the programme question shifts from who authenticated to how much damage that access can do before it expires or is revoked. That pushes identity teams toward shorter-lived grants, stronger step-up decisions, and faster token invalidation.

For practitioners

• Audit browser-mediated authorization paths Map where your users grant access through device code flows, OAuth consent prompts, and third-party SaaS integrations, then identify which of those paths can create high-impact delegated access without additional review.
• Tighten connected-app governance Inventory every connected app, service integration, and vendor token relationship, then define explicit owner, scope, and revocation requirements for each grant.
• Constrain session abuse windows Shorten token lifetime where feasible, require reauthentication for sensitive SaaS actions, and tie session risk decisions to device and browser context rather than login success alone.
• Detect high-risk consent and relay patterns Alert on unusual consent grants, device-code enrolment, impossible travel after token issuance, and browser sessions that show rapid privilege expansion.
• Prepare for rapid containment Pre-stage revocation playbooks for OAuth grants, refresh tokens, and browser sessions so responders can cut off access before data exfiltration completes.

Key takeaways

• Browser-based SaaS compromise now bypasses many login-centric assumptions by abusing sessions, consent grants, and third-party trust.
• The article describes sustained campaigns that have reached exfiltration in under an hour, which is too fast for slow human triage to contain.
• Teams that want to reduce impact need to govern browser-mediated authorization, connected-app scope, and rapid token revocation together.

Key terms

• AiTM Phishing: Adversary-in-the-middle phishing inserts attacker infrastructure between the victim and the real login service. The attacker relays the login in real time, captures the issued token, and bypasses MFA by stealing the authenticated session rather than guessing the password.
• Device code phishing: An identity attack that abuses the device authorization flow by tricking a user into entering a code on a legitimate login page while the attacker completes the flow elsewhere. It is effective because it relies on a real authentication protocol and can bypass password theft and familiar MFA prompts.
• OAuth consent governance: OAuth consent governance is the discipline of approving, limiting, and revoking delegated application access created through OAuth authorisation. It matters because the user’s click can create machine-mediated access that outlives the original session and becomes part of the enterprise identity attack surface.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.