Notifications
Clear all
Topic starter
09/06/2026 11:56 pm
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.
NHIMG editorial — based on content published by Push Security: ShinyHunters' 2025 hacking spree has continued at pace in 2026
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Control browser-mediated authentication paths Block or step up suspicious browser sessions that show AiTM patterns, unusual device-code enrolment, or anomalous login chaining.
- 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.
- Limit consent scope at the point of authorisation Restrict what an app can request, not just what a user can log into.
What's in the full article
Push Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Per-vector breakdowns of AiTM, device-code, and OAuth supply-chain tradecraft in real campaigns.
- Named victim lists and campaign timelines that show how each technique spread across sectors.
- Browser-layer detection approaches and control examples that support implementation work.
- Specific examples of how compromised credentials and token theft move from access to exfiltration.
👉 Read Push Security’s analysis of ShinyHunters’ browser-based attack chains →
ShinyHunters browser attacks: what IAM teams are missing?
Explore further
10/06/2026 2:29 am
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
