TL;DR: ShinyHunters and related SLH crews have driven a sustained wave of browser-based SaaS compromise through vishing, AiTM phishing, device code abuse, and OAuth supply-chain attacks, with some campaigns reaching complete exfiltration in under an hour according to Push Security. Existing identity controls are being bypassed at the authorization layer, where session capture, token theft, and third-party trust assumptions outpace review and response.
Editorial analysis by NHI Mgmt Group, based on content published by Push Security: “The three attack techniques behind ShinyHunters' 2026 campaigns”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Browser-based SaaS compromise now bypasses many login-centric assumptions by abusing sessions, consent grants, and third-party trust.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A few things that frame the scale:
- 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%.
A question worth separating out:
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.
👉 Read our full editorial: ShinyHunters’ browser-based attacks expose SaaS identity gaps
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.
A few things that frame the scale:
- 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%.
A question worth separating out:
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.
👉 Read our full editorial: ShinyHunters’ browser-based attacks expose SaaS identity gaps
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.
A question worth separating out:
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.
👉 Read our full editorial: ShinyHunters’ browser-based attacks expose SaaS identity gaps