Real-time phishing bypasses SSO by exploiting human workflow

At a glance

What this is: This is an analysis of real-time phishing and voice-assisted account takeover, showing that attackers can relay a live login, satisfy MFA, and obtain a valid session without triggering traditional authentication alarms.

Why it matters: It matters because IAM teams must treat high-risk user actions, help-desk recovery, and session trust as separate control points, not assume MFA alone can prevent relay attacks across human and non-human access paths.

By the numbers:

• In March 2026, Europol coordinated a global takedown of Tycoon 2FA after the platform had sent tens of millions of phishing messages each month.
• By mid-2025, Tycoon 2FA accounted for 62% of all phishing attempts blocked by Microsoft.
• The Canadian Centre for Cyber Security analyzed over 100 AiTM phishing campaigns targeting Microsoft Entra ID accounts between 2023 and early 2025.
• $710M was lost to AiTM phishing and credential, compromise in a single wave targeting Japanese brokerages in 2025.

👉 Read Trusona's analysis of real-time phishing and SSO bypass

Context

Real-time phishing is a relay attack on the login workflow, not a password-cracking exercise. The user authenticates on a fake or proxied site, MFA is completed, and the attacker receives the resulting valid session. For identity programmes, the problem is that the session looks legitimate even when the human behind it is being manipulated in real time.

This is a direct IAM concern because the compromise happens after authentication but before trust is safely established for downstream actions. SSO and MFA are still useful controls, but they do not prove user intent, stop help-desk abuse, or prevent a relayed session from being used for token creation, device enrollment, or account recovery.

The article’s starting position is typical for enterprise environments that rely on standard MFA and session trust. That combination remains common, which is why real-time phishing continues to succeed even when organisations believe their identity stack is mature.

Key questions

Q: What breaks when MFA is present but the login can still be relayed in real time?

A: MFA stops simple credential replay, but it does not stop an attacker who can proxy the live login flow and inherit the resulting session. The broken assumption is that successful authentication proves the right person is in control. In real-time phishing, the identity provider sees a valid user, while the attacker owns the workflow that produced it.

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: How should security teams reduce help desk account takeover risk?

A: Treat account recovery as a privileged identity workflow, not a support convenience. Require step-up verification before resets, remove discretionary overrides where possible, and log every recovery action with the approving identity and evidence used. The goal is to stop attackers from using social engineering to re-establish trust through the support desk.

Q: Who is accountable when identity recovery is abused for account takeover?

A: Accountability typically spans IAM owners, help desk operations, and security governance because the failure sits in the recovery process, not only in the login method. If reset workflows are weak, the organisation owns that control gap and must govern it as part of identity assurance.

Technical breakdown

How adversary-in-the-middle phishing relays a valid login session

Adversary-in-the-middle, or AiTM, phishing inserts a proxy between the user and the legitimate service. The victim enters credentials and completes MFA on the attacker-controlled layer, while the proxy forwards each step to the real identity provider in real time. Because the authentication succeeds against the true service, the identity provider issues a valid session cookie or token. From the platform’s perspective, nothing abnormal occurred. That is why conventional signals such as failed logins, impossible travel, or repeated password attempts often never appear. The attacker is not defeating authentication; the attacker is borrowing the user’s successful authentication outcome.

Practical implication: Treat any authentication flow that can be proxied in real time as relay-exposed, and require phishing-resistant controls for high-risk access.

Why SSO and MFA can still produce attacker-owned access

Single sign-on centralises trust, but it does not validate the human’s intent at the point of login. MFA confirms a second factor was satisfied, yet a real-time proxy can present the same challenge to the victim and forward the approval instantly. The result is a legitimate session tied to the attacker’s workflow. This is why attackers often move straight to persistence actions such as enrolling a new device, issuing API tokens, changing recovery data, or setting up mail forwarding. Those steps are still ordinary platform functions, which makes them difficult to distinguish from legitimate administration unless additional policy gates exist.

Practical implication: Separate authentication from high-risk account changes and require stronger verification before any action that can extend access.

Why help-desk recovery is a critical relay target

Help desks are attractive because they can change account state in ways that authentication logs do not capture well. If an attacker can confuse or socially engineer a support agent, the session no longer matters. Password resets, MFA token transfers, and device re-enrollment convert a transient compromise into durable access. In practice, many organisations still treat these workflows as routine service operations rather than privileged identity events. That creates a gap between who is authenticated and who is authorised to reshape the account. Once the support process acts on bad context, the attacker inherits a cleaner and more persistent foothold than the original phishing session provided.

Practical implication: Classify recovery and enrollment as privileged workflows and add human verification that cannot be satisfied by a relayed session.

Threat narrative

Attacker objective: The attacker aims to obtain durable, trusted access that survives the original login session and supports follow-on account control or data theft.

1. Entry occurs when the victim is directed to a phishing site or contacted by voice and enters credentials into a live proxy controlled by the attacker.
2. Escalation occurs when the attacker relays the MFA challenge in real time and receives a valid authenticated session without triggering a login failure.
3. Impact occurs when the attacker uses the session to create persistence through device enrollment, token creation, forwarding rules, or help-desk-mediated account changes.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

Authentication without consent is the core failure exposed by real-time phishing. MFA can confirm that a user satisfied a challenge, but it cannot confirm that the resulting session is being used by the person who intended it. That gap is why AiTM attacks succeed even when identity systems behave exactly as designed. Practitioners should stop treating successful login as proof of safe access.

Help-desk recovery has become a privileged identity control, not a support convenience. The article shows how attackers convert confusion into durable access by pushing support teams to reset credentials, transfer MFA state, or re-enrol devices. That means recovery workflows now sit inside the identity attack surface. Organisations that still classify these steps as routine support are underestimating their blast radius.

Session trust is too coarse for modern phishing-resistant governance. Once a session is valid, downstream systems often trust it uniformly, regardless of how the session was obtained. That assumption made sense when credential theft was delayed and detectable. It fails when the attacker can inherit the login live and act before conventional monitoring reacts. Security teams should re-evaluate where session legitimacy ends and action-level trust begins.

Phishing-resistant verification is becoming a control for intent, not just authentication. The article makes clear that the decisive difference is architectural, not educational. A control that binds authentication to a specific device or out-of-band confirmation changes the attack economics because the relay cannot complete the trust step. That is why identity programmes need to think in terms of challenge provenance, not only factor count.

Runtime identity governance must extend to the post-authentication window. Real-time phishing proves that the most dangerous actions happen after the login succeeds. Device enrollment, token issuance, and recovery changes determine whether the attacker keeps access after the original session ends. Identity governance programmes that stop at initial authentication are leaving the persistence layer ungoverned.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• From our research: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• That persistence gap makes 52 NHI Breaches Analysis the natural next read for understanding how compromised identities turn into durable access paths.

What this signals

Authentication proof is no longer enough for governance decisions. Security teams should expect more attacks that preserve the appearance of a normal login while changing only the human side of the interaction. With 91.6% of secrets still valid five days after notification in our research, the remediation problem is often slower than the attacker’s ability to persist, which is why post-authentication controls now matter as much as MFA.

Real-time phishing turns identity workflows into the actual attack surface. Organisations need to map where a session can trigger device enrollment, token creation, or support-led recovery because those paths are the ones attackers monetize. The right programme response is to limit what a newly authenticated session can do until device, intent, and context are independently confirmed.

The next governance step is to align session trust with action trust by using phishing-resistant verification for high-risk operations and by tightening the lifecycle of recovery paths. If a login can be relayed, the downstream controls must assume the attacker will try to make the session last longer than the login itself.

For practitioners

• Move high-risk actions out of standard login trust Require separate verification for password resets, MFA enrollment, device registration, token creation, and recovery-data changes. These actions should not inherit the same assurance level as a routine SSO session.
• Adopt phishing-resistant authentication for exposed populations Prioritise passkeys or FIDO2-style controls for administrators, finance users, and help-desk personnel who can approve privileged changes. The goal is to make relay attacks fail before the session is issued.
• Treat support workflows as privileged identity events Build step-up checks for help-desk actions that alter account state, and verify the requester through a channel that cannot be satisfied by a voice call or proxied session.
• Review persistence paths created after authentication Audit where sessions can create long-lived access through API tokens, mail rules, trusted devices, and recovery settings, then require explicit approval for those changes.
• Map relay exposure to control gaps in downstream apps Identify applications that trust SSO sessions without rechecking device context or step-up signals, then limit what those sessions can do until trust is revalidated.

Key takeaways

• Real-time phishing succeeds because it relays a legitimate login, which makes standard MFA and SSO logs look normal even when an attacker owns the session.
• The evidence shows this is a scaled and persistent problem, not a niche tactic, with millions of phishing messages, broad enterprise reach, and large financial losses.
• Identity teams should shift control points to high-risk actions, help-desk recovery, and phishing-resistant verification that cannot be proxied in real time.

Key terms

• Adversary-in-the-middle phishing: A phishing method that places an attacker between the user and the real identity provider so the attacker can intercept or relay the authenticated session. It often preserves the user experience, which is why it can evade awareness and some detection paths while still producing usable session tokens.
• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Runtime Trust: Runtime trust is the idea that access should remain valid only while current context justifies it. Instead of trusting a setup decision indefinitely, teams continuously re-evaluate whether a workload or agent still deserves privilege. This approach is especially important for AI agents that can change behaviour mid-task.
• Help-desk account recovery: Support-driven processes that reset credentials, re-enrol authenticators, or restore access for a user. These workflows are identity-sensitive because they can convert social engineering into durable account control if they rely on weak verification.

What's in the full article

Trusona's full analysis covers the operational detail this post intentionally leaves for the source:

• A step-by-step breakdown of how Tycoon 2FA-style relay infrastructure proxies the login flow.
• Source references and campaign context for the Europol takedown, Microsoft reporting, and the Canadian Centre for Cyber Security findings.
• More detail on the help-desk impersonation patterns used by Scattered Spider and similar groups.
• The article's own defensive framing for phishing-resistant verification and post-authentication controls.

👉 Trusona's full post covers the attack chain, help-desk abuse, and control points that stop relay-based account takeover.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 lifecycle control in your organisation, it is worth exploring.