Notifications
Clear all
Topic starter
10/06/2026 11:52 pm
TL;DR: Scattered Lapsus$ Hunters are combining vishing with adversary-in-the-middle phishing to steal SSO credentials, MFA codes, and live sessions from hundreds of organisations across Okta, Entra, and Google, according to Push Security. The attack works because identity-first compromise bypasses endpoint and network controls and turns SSO into the blast-radius multiplier.
NHIMG editorial — based on content published by Push Security: Analyzing the latest Scattered Lapsus$ Hunters phishing campaign
By the numbers:
- 100+ companies have been targeted by the campaign so far.
- Non-email vectors now account for more than 1 in 3 phishing attacks intercepted by Push Security.
Questions worth separating out
Q: How should security teams reduce the risk of vishing-led SSO compromise?
A: Security teams should split human verification from authentication, require phishing-resistant login methods for critical SSO accounts, and train staff to treat support-driven login prompts as suspicious.
Q: Why do stolen SSO sessions create such a large blast radius?
A: A stolen SSO session inherits the user's approved access, so the attacker can reach multiple downstream applications without re-authenticating.
Q: What do organisations get wrong about passkeys and phishing resistance?
A: Teams often treat the authentication method as the whole control, but the article shows that attackers can still manipulate users into creating or validating credentials under false pretences.
Practitioner guidance
- Separate support verification from authentication Require employees to verify support calls through a second channel that is independent of the login flow, so a caller cannot guide someone into entering credentials or MFA codes on a crafted page.
- Enforce phishing-resistant authentication on SSO Prioritise passkeys or other phishing-resistant methods for the most exposed identity provider accounts, and block fallback methods that can be relayed through an adversary-in-the-middle page.
- Review post-login persistence after any suspected theft Check for attacker-added passkeys, alternative login methods, risky OAuth grants, and newly accessed apps after a stolen session, because the persistence path often appears after the initial compromise.
What's in the full analysis
Push Security's full analysis covers the operational detail this post intentionally leaves for the source:
- Examples of the live phishing panel options used to steer victims through login and post-compromise actions
- Specific SaaS activity log patterns investigators can use to spot suspicious browsing and bulk downloads
- Browser-based detection logic and behavioural checks used to block fake pages in real time
- Details on employee verification codes and how they help counter help desk scams
👉 Read Push Security's analysis of the SLH hybrid vishing and AiTM campaign →
Hybrid vishing plus AiTM phishing: are SSO controls keeping up?
Explore further
12/06/2026 6:17 am
Identity-first phishing is now a governance problem, not just a user-awareness problem. The campaign succeeds because the attacker works through the identity layer that most organisations treat as trusted by default. When a phone call can drive a user into a valid authentication flow, the control failure is structural: identity assurance is being delegated to an untrusted conversation. Practitioners should treat that as a programme-level gap, not an isolated phishing event.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- 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.
A question worth separating out:
Q: Who is accountable when stolen identity-provider access is used to reach downstream apps?
A: Accountability sits with the organisation that owns the identity lifecycle and the access graph, because the compromise flows through its SSO, its apps, and its recovery process. Security, IAM, and help desk teams all share responsibility for preventing support impersonation, revoking session access, and removing persistence methods.
👉 Read our full editorial: Hybrid vishing and AiTM phishing are reshaping SSO defense
