Hybrid vishing and AiTM phishing are reshaping SSO defense

At a glance

What this is: This is analysis of a hybrid vishing and adversary-in-the-middle phishing campaign that targets SSO accounts and then uses stolen sessions to move into downstream apps.

Why it matters: It matters because identity teams need controls that can withstand social engineering, session theft, and post-login abuse across human, NHI, and delegated access paths.

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.

👉 Read Push Security's analysis of the SLH hybrid vishing and AiTM campaign

Context

Hybrid vishing plus AiTM phishing is a combined identity attack path that starts with a phone call and ends with a stolen login session. The primary weakness is not the browser or the mailbox alone, but the trust users place in support-style interactions that can steer them into a fake authentication flow. For IAM teams, the problem is that SSO becomes the control plane for both access and compromise.

The article's primary concern is SSO governance, especially around Okta, Entra, and Google accounts that unlock downstream SaaS access. Once an attacker gets into the identity provider dashboard, they can enumerate entitlements, create persistence, and pivot into the wider environment. That makes this a human identity event with direct implications for NHI and delegated access governance, because the same stolen session can expose service-linked and cloud-adjacent assets.

Key questions

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. The key is to remove any path where a caller can steer a user into entering credentials or approving MFA inside a live phishing session.

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. That makes the session a control boundary, not just a login artefact, and it means recovery must include revocation, entitlement review, and checks for attacker-added persistence.

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. Passkeys reduce replay risk, but they do not solve help desk impersonation, session hijack, or weak post-login governance by themselves.

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.

Technical breakdown

How vishing primes the authentication path

The campaign begins with a live caller impersonating IT support and using prior breach data to make the story credible. That social layer matters because the attacker is not trying to defeat cryptography first, but to control the user's next action. The call guides the victim into a crafted login flow where the attacker can observe or relay authentication in real time. This is why identity-first attacks often evade traditional endpoint and network tooling: the user is the delivery mechanism, and the browser becomes the compromise surface.

Practical implication: separate support verification from authentication workflows so a phone call cannot steer users into credential entry.

AiTM phishing and live session capture

Adversary-in-the-middle phishing sits between the user and the real identity provider, relaying credentials and MFA responses while collecting the resulting session tokens. The session, not just the password, is the prize because it can survive the initial login and enable direct access to the SSO portal. In this campaign, the operator-controlled phishing page can adapt in real time, which increases completion rates and makes static indicators much less useful. That is why phishing-resistant authentication matters, but so does session-bound detection.

Practical implication: require phishing-resistant authentication and add controls that detect session replay or token reuse.

Ghost login persistence inside SSO dashboards

Once the attacker has an active session, they can inspect the SSO dashboard, identify accessible applications, and create new persistence mechanisms such as additional passkeys or other approved login methods. That is the dangerous part of post-login compromise: the attacker no longer needs to keep phoning or phish again if the account can be silently re-anchored. In identity terms, the original theft becomes a durable access path. For responders, this changes the problem from single-account recovery to entitlement and authentication-method cleanup across the account's full access graph.

Practical implication: investigate and revoke any attacker-added authentication methods, then review all downstream app entitlements tied to the session.

Threat narrative

Attacker objective: The objective is durable SSO compromise that can be used to access downstream applications, steal data, and support extortion.

1. Entry begins with vishing, where the attacker impersonates internal IT and uses social engineering to push the victim into a fake passkey or SSO login flow.
2. Credential access happens inside an AiTM phishing page that captures credentials, MFA codes, and live session material while relaying the real authentication exchange.
3. Impact follows when the attacker uses the stolen SSO session to enumerate downstream access, create persistence, and steal data for extortion.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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

NHI Mgmt Group analysis

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.

Session theft turns SSO into a blast-radius amplifier. The compromise does not end at the login screen because the stolen session inherits the user's downstream access graph. That means SaaS, cloud consoles, and connected applications become reachable without fresh credential prompts. The practical conclusion is that SSO recovery must include entitlement review and session revocation, not only password resets.

Support impersonation exposes a named concept we should call the identity social-engineering relay. The attacker is relaying trust from the caller, to the browser, to the identity provider, and then to the session token in one continuous chain. That relay collapses the assumption that user-assisted authentication is inherently safer than machine-assisted compromise. Practitioners need to recognise that the trust boundary has shifted from the endpoint to the conversation itself.

Passkeys help only when they are paired with phishing-resistant enforcement and session controls. The article shows attackers trying to steer victims into creating a passkey the attacker can later control, which turns a protective method into persistence if governance is weak. That means identity teams should not evaluate passkeys in isolation. The control question is whether the authentication method remains bound to the legitimate user after the attacker leaves the call.

Non-human and delegated access inherit the same compromise path once an identity provider is stolen. SSO dashboards often surface access to service-linked tools, API-backed applications, and cloud services that were not the original target of the phish. That is why NHI governance cannot be separated from human identity compromise analysis. Once the identity provider falls, the downstream machine and delegated identities become part of the same incident scope.

From our research:

• 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.
• That same visibility gap is why teams should revisit 52 NHI Breaches Analysis when mapping downstream app exposure after SSO compromise.

What this signals

Identity social engineering will keep moving earlier in the attack chain. As attackers combine vishing, AiTM, and live operator control, the programme risk is no longer limited to credential theft. Teams should expect more compromises that begin before the browser ever renders a traditional phishing indicator, which means support workflows, not just mail filters, become a governance surface.

The identity social-engineering relay is a useful shorthand for the new compromise pattern. It describes how trust is relayed from caller to user to browser to SSO session and then to downstream apps. That model helps IAM, security operations, and help desk teams align on why the incident response scope must extend beyond one stolen account.

If your programme still assumes that phishing is mainly an email problem, this campaign is a warning that browser telemetry, identity verification, and post-login monitoring now belong in the same control conversation. The practical next step is to treat identity assurance as a continuous process across login, session, and delegated access.

For practitioners

• 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.
• Monitor SSO dashboards for abnormal app enumeration Look for accounts that suddenly browse many applications in a short period, since the attacker objective is to discover where the stolen identity can move next.

Key takeaways

• The breach path starts with trust manipulation, not malware, which is why support-process controls matter as much as technical phishing defences.
• The scale is already material, with 100+ companies targeted and non-email delivery making up more than 1 in 3 intercepted phishing attacks.
• Limiting damage requires revoking session artefacts, reviewing downstream app access, and removing attacker-added authentication methods after compromise.

Key terms

• Adversary-in-the-Middle Phishing: A phishing method where the attacker sits between the user and the real service, relaying authentication traffic while capturing credentials or session tokens. In identity terms, the attacker steals the authenticated session rather than only the password, which makes post-login controls and revocation critical.
• Single Sign-On Session: The authenticated browser or app session that lets a user move into multiple connected applications without logging in again. When stolen, it becomes a high-value access artefact because it inherits downstream entitlements and can outlive the original credential prompt.
• Identity Provider: The central service that authenticates a user and issues access to connected applications. If an identity provider account is compromised, the attacker can often enumerate many linked systems from one place, which turns the identity layer into a blast-radius multiplier.
• Phishing-Resistant Authentication: An authentication method designed to resist credential relay, such as a passkey bound to a legitimate device and origin. It reduces replay risk, but it still needs governance around support processes, recovery flows, and session revocation to stop social engineering-led compromise.

Deepen your knowledge

Identity-first phishing and SSO session abuse are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with delegated access, session risk, or post-login persistence, it is a practical place to build shared language.

This post draws on content published by Push Security: Analyzing the latest Scattered Lapsus$ Hunters phishing campaign. Read the original.