Phishing-Relay Attack

How a phishing-relay attack works

A phishing-relay attack intercepts an authentication exchange and forwards it in real time so the attacker can reuse the resulting proof or session. The core weakness is not just credential theft, but the ability to capture trust as it is being established.

This matters because the attacker may never need to see the underlying password or code in a reusable form. If the victim completes the flow, the relay can preserve enough of the authenticated transaction to impersonate the user or continue the session.

Why phishing-relay attacks defeat simple “multi-factor” thinking

These attacks exploit the difference between having a second factor and resisting relay. A one-time code, approval prompt, or other proof can still be relayed if the authentication design does not bind the proof to the right origin, device, or transaction context.

That is why phishing-relay attacks are often discussed alongside phishing-resistant authentication methods. The question is not whether a second step exists, but whether the proof can be forwarded and accepted elsewhere without breaking the trust model. Guidance on NIST SP 800-63 Digital Identity Guidelines is useful here because it distinguishes phishing-resistant authenticators from weaker second factors.

Common relay paths and where they succeed

Relay attacks usually succeed when the attacker can sit between the victim and the target service, then reproduce the same messages quickly enough that the service accepts them as authentic. That can happen against web login flows, OAuth consent flows, device-code style sign-ins, and session handoff processes.

Infrastructure and credential handling choices can make the problem worse. If a captured session token can be reused immediately, or if authentication material is not tightly scoped to a specific device or transaction, a relay can turn a single victim interaction into durable access. In cloud and SaaS environments, this can expose broader account and API access than the original login path suggests, which is why practical incident examples such as CoPhish OAuth phishing via Copilot Studio are so instructive.

Security implications for session, token, and identity trust

The real danger is that a successful relay can convert a momentary authentication event into an authenticated session that looks legitimate to the service. Once that happens, downstream authorization often works normally, which means the attacker inherits whatever access the victim already had.

Relay-based abuse is especially damaging when sessions are long-lived, when access is broad, or when a compromised login can reach sensitive business functions without additional step-up checks. Broader breach analysis such as The State of NHI & AI Agent Breach Report 2026 shows how stolen tokens and session material often become the real prize after initial compromise.

Risk and Threat Considerations

Phishing-relay attacks are dangerous because they bypass the assumption that a verified login event proves the user was present at the target service. If the attacker can forward the exchange fast enough, the victim may unknowingly complete a valid authentication that the attacker can immediately reuse.

Failure mechanism: The attack succeeds when authentication proof is not bound tightly enough to the original origin, device, or transaction, allowing the relay to preserve trust across an attacker-controlled middle step.

Impact: The attacker can obtain a usable session or token, impersonate the victim, and expand from initial access into mailbox, SaaS, cloud, or administrative compromise.

Practitioner Guidance

What to watch for: Treat any control that can be forwarded in real time as relay-prone unless it is explicitly phishing-resistant. Prompt-based approvals, one-time codes, and generic second-factor flows can still be abused if they do not cryptographically tie the proof to the legitimate service and session.

Governance implication: Prioritise authentication methods and policy decisions that reduce relayability, then align step-up access, session lifetimes, and reauthentication requirements to the sensitivity of the action being performed. The practical test is not whether MFA exists, but whether the authentication design actually prevents an attacker from turning the victim’s login into their own session.

Related resources from NHI Mgmt Group

• How can organisations use one confirmed phishing attack to improve broader detection?
• Who is accountable when a help-desk style phishing attack reaches SaaS data?
• Why do phishing and credential reuse remain such damaging attack paths?
• Who is accountable when a phishing attack drains a treasury through a signer?