Vishing and AiTM phishing are driving SSO account takeover

At a glance

What this is: This is a threat analysis of vishing combined with AiTM phishing, showing how attackers use social engineering to hijack SSO accounts through password resets, MFA approvals, and malicious pages.

Why it matters: It matters because identity teams need controls that address both the human trust step and the browser session step, especially where SSO, session tokens, and unmanaged access paths are in play.

By the numbers:

• 2026, ce code phishing attacks have skyrocketed in 2026, enabling attackers to steal access tokens while bypassing standard access controls.
• The 2026 installment of the Verizon Data Breach Investigations Report helps explain how breaches happen across identity-led attack paths.

👉 Read Push Security's analysis of vishing and AiTM phishing account takeover

Context

Vishing is voice phishing, where attackers use phone calls to impersonate IT support, help desks, or internal staff and persuade targets to reset credentials, approve MFA prompts, or visit attacker-controlled pages. In identity security terms, the problem is not only deception. It is the way a successful social engineering step becomes an authentication event that can be chained into browser-based account takeover.

For IAM, the issue sits across human identity, session management, and non-human access paths that depend on SSO trust. Once the attacker gets a user to approve a prompt or hand over a reset path, the browser session becomes the control surface, which means conventional perimeter controls and static authentication checks often arrive too late.

Push Security argues that these campaigns are no longer isolated nuisance calls. They are repeatable identity attacks that depend on weak verification at the help desk, over-trusted browser sessions, and insufficient telemetry on unmanaged identity use.

Key questions

Q: How should security teams reduce vishing-driven account takeover risk?

A: Start by treating voice verification as an access control, not a support courtesy. Use callback procedures, stronger identity proofing for resets, phishing-resistant MFA where possible, and logging for every recovery event. The goal is to make a successful phone call insufficient to complete the identity handoff.

Q: Why do AiTM phishing attacks remain effective against SSO environments?

A: Because they target the authenticated session, not only the password. Even strong credentials can be relayed in real time, and the resulting session tokens may let attackers access downstream apps until the session expires or is revoked. That is why session telemetry matters as much as login telemetry.

Q: What do security teams get wrong about help desk social engineering?

A: Many teams treat the help desk as a service function rather than a security boundary. That mistake lets attackers convert routine recovery actions into account takeover paths through credential resets, MFA changes, or bypassed checks. Help desk workflows need the same verification discipline as privileged access processes, especially when outsourced support is involved.

Q: Who is accountable when a social engineering call leads to SSO compromise?

A: Accountability is shared across identity operations, help desk governance, and security architecture. Teams that own resets, MFA recovery, browser telemetry, and identity monitoring all influence the outcome. Framework-wise, this sits under identity governance, access control, and incident response rather than only user training.

Technical breakdown

How vishing becomes an identity attack chain

Vishing works because the attacker does not need to break authentication directly if they can convince the target to do it for them. The call establishes urgency and authority, often by impersonating support personnel or a manager, then steers the victim into a password reset, MFA approval, or session handoff. That makes the human the initial access path, while the identity system simply records a seemingly valid action. In environments with SSO, one successful social engineering step can cascade into broad application access.

Practical implication: treat help desk workflows and reset approvals as security controls, not administrative convenience.

Why AiTM phishing amplifies SSO compromise

Adversary-in-the-middle phishing sits between the user and the real login flow, relaying credentials and session artifacts in real time. That allows attackers to capture access tokens, session cookies, or MFA completions without necessarily needing the password again. In SSO environments, those tokens can be more valuable than the password itself because they inherit authenticated state and can outlive the interaction that created them. The result is a session hijack problem, not just a credential theft problem.

Practical implication: focus detection on session issuance, token reuse, and suspicious browser authentication patterns.

Why browser telemetry changes detection

Browser-based attacks often evade traditional network and endpoint controls because the malicious action happens inside a legitimate browser session. Browser telemetry can expose page context, unusual redirects, suspicious session elevation, and interactions with unmanaged SaaS or AI tools. That matters for identity security because the browser is increasingly where authentication, authorisation, and data access converge. Without browser-level visibility, teams often learn about compromise only after the attacker has already moved from login to abuse.

Practical implication: use browser telemetry to detect abnormal identity behaviour before downstream application access is abused.

Threat narrative

Attacker objective: The attacker aims to obtain authenticated browser-session access that can be reused for account takeover and follow-on SaaS abuse.

1. Entry begins with a phone-based vishing call that impersonates trusted support and convinces the target to disclose credentials or approve a login action.
2. Credential access follows when the victim enters credentials into an attacker-controlled page or completes an AiTM relay that captures session material.
3. Impact occurs when the attacker reuses the session to access SSO-backed applications and operate as the legitimate user across connected services.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

Vishing is no longer a social engineering side channel, it is an identity entry point. The attack works because help desks and users are still trusted to authenticate identity decisions through conversation. Once that trust is exploited, the attacker does not need to bypass IAM directly, only to redirect an existing workflow into a fraudulent reset or approval. Identity teams should treat voice-based deception as part of the access control surface, not as a separate awareness problem.

AiTM phishing turns authentication into session theft, which changes the unit of defence. In SSO environments, the valuable asset is often the authenticated session, not the password. That means the governance question shifts from who knows the secret to who can capture, replay, or persist the token. Practitioners should read this through OWASP NHI and Zero Trust assumptions: authentication success no longer proves safe intent or safe context.

Identity verification at the help desk is a control plane, not a support script. The article shows how attacker success depends on weak verification before reset or MFA approval paths are executed. That failure spans human IAM and downstream browser sessions, which is why governance around call-back procedures, step-up verification, and escalation authority now belongs in identity architecture reviews. Teams that leave this outside the programme create a predictable bypass route.

Browser visibility is becoming mandatory for identity-led threat detection. Traditional logs can show that a login happened, but not whether the browser session was manipulated through a malicious redirect, suspicious page content, or unmanaged access path. That leaves a blind spot between successful authentication and malicious use. The practical conclusion is that identity controls must extend into the browser layer when attackers can weaponise the user interface itself.

Named concept: identity handoff abuse. This pattern describes attacks that exploit trusted transitions such as resets, approvals, and session transfers rather than exploiting a credential store directly. It is especially dangerous because the handoff appears legitimate to both the user and the control owner. For practitioners, the governance lesson is that every identity handoff needs its own verification boundary and audit trail.

From our research:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• Our research also found that 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, which is a governance signal rather than an edge case.
• That same research is a useful next step for teams evaluating how identity sprawl and compromise rates should change their browser and session controls.

What this signals

Vishing and AiTM phishing show that identity programmes can fail at the handoff between human trust and browser session control. As attackers move further upstream into support workflows, organisations need stronger verification boundaries, better session telemetry, and a clearer separation between recovery and approval authority.

Identity handoff abuse: this is the failure mode to watch when a legitimate reset or approval path becomes the attacker’s entry point. The more SSO and SaaS access is centralised, the more damage a single manipulated handoff can create across the programme.

For teams that already track browser-based attacks, the next maturity step is to connect help desk events, MFA events, and token use into one investigation path. That is where modern identity detection becomes operational rather than merely descriptive.

For practitioners

• Harden help desk identity verification Require out-of-band callback checks, step-up questions that are not publicly discoverable, and supervisor approval for high-risk resets or MFA recovery. Keep a record of every identity handoff and review exceptions weekly.
• Instrument browser-session detection Monitor for suspicious redirects, unusual login page provenance, token replay indicators, and browser sessions that suddenly expand scope across SaaS applications. Feed those signals into incident triage alongside standard IdP logs.
• Reduce MFA approval abuse Replace simple prompt approval where possible with phishing-resistant methods and enforce context-aware checks for high-risk resets, new devices, and impossible travel conditions.
• Separate reset authority from access approval Do not let the same workflow owner approve both identity recovery and privileged application access. Split responsibilities so a single compromised conversation cannot complete the whole attack chain.

Key takeaways

• Vishing and AiTM phishing now form a repeatable account-takeover chain that turns help desk trust into a security weakness.
• The real risk is not only credential theft but session hijack, where authenticated browser access can be reused across SSO-connected applications.
• Teams that separate reset authority, strengthen verification, and monitor browser sessions will reduce the attacker’s ability to turn a phone call into enterprise access.

Key terms

• Vishing: Voice phishing is a social engineering technique that uses phone calls or voice channels to persuade a target to reveal information or approve access. It succeeds by exploiting trust, urgency, and procedural shortcuts, often bypassing technical controls that would have stopped a direct login attack.
• 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.
• Identity Handoff: The controlled transfer of access from one user to the next on a shared device or application session. In manufacturing, the handoff must close the prior session, preserve auditability, and prevent residual access from carrying into the next operator’s activity.
• Session Hijacking: Session hijacking is the takeover of an authenticated session after the original login has completed. The attacker does not need to know the password if they can use the active session token, which is why session monitoring and revocation are essential controls in SaaS identity governance.

What's in the full article

Push Security's full article covers the operational detail this post intentionally leaves for the source:

• Specific examples of how voice phishing is paired with browser-based phishing to complete account takeover.
• The attack flow from support impersonation to password reset, MFA approval, and session hijack.
• Push's own browser-security telemetry examples for spotting suspicious identity activity earlier in the chain.
• The article's campaign-level context on how these techniques are being used across identity-led attacks.

👉 Push Security's full post covers the attack chain, browser telemetry, and identity abuse details.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.