Two-factor authentication code hijacking is the interception or theft of a one-time verification code during a phishing attack. It weakens the second factor by letting an attacker complete sign-in in real time, often turning stolen credentials into full account access.
How Two-Factor Code Hijacking Works
Two-factor authentication code hijacking usually begins with a convincing phishing page or social-engineering flow that captures the first factor, then persuades or proxies the victim into revealing the one-time code. In real time, the attacker uses that code before it expires, turning a supposedly stronger sign-in into a live account takeover.
The key detail is timing. Unlike password theft alone, code hijacking exploits the short validation window of the second factor, so the attacker does not need to store the code for later use. That makes the attack especially effective against SMS codes, app-generated OTPs, and other code-based flows that can be relayed or intercepted during the session.
This is why phishing-resistant methods matter more than code strength alone. A code can still be numerically strong and briefly valid, yet remain vulnerable if the attacker can trick the user into reading it aloud, entering it into a fake site, or approving a prompt in the wrong context.
Common Hijacking Paths and Why They Succeed
Code hijacking can happen through adversary-in-the-middle phishing, OTP relay kits, vishing, help-desk social engineering, or session theft after the code is entered. MFA Guide is a useful reference for the main bypass patterns, from MFA fatigue to relay attacks and phishing-resistant rollout.
Some attacks never need the code itself to be stored. For example, a proxy site can forward the login sequence to the legitimate service in real time, capture the OTP, and complete authentication before the victim notices. In other cases, attackers use a stolen password plus social engineering to extract the code from the user and finish the sign-in themselves.
The attack succeeds because many second factors prove possession, not context. If the user can be manipulated into providing the code to the attacker’s live session, the code still validates, even though the attacker never controls the victim’s device or inbox in a durable way.
Security Implications for Accounts and Sessions
Code hijacking matters because it collapses the barrier between stolen credentials and active access. Once the attacker completes sign-in, they may reset recovery options, enroll a new factor, access email or SSO-linked applications, and pivot into downstream systems that trust the compromised session.
That is why breaches often move quickly from initial phishing to broader compromise when MFA is code-based. Twilio 0ktapus breach 2022 shows how SMS phishing and one-time codes can be abused at scale, while CitrixBleed exploitation 2023 shows the related downstream problem of session-token theft, where an attacker can bypass authentication entirely after the session is established.
Because the second factor is often only one step in a broader identity chain, compromise can extend beyond the original account. Email, admin consoles, customer portals, and federation links can all become reachable if the hijacked sign-in is accepted as trustworthy by adjacent systems.
What Stronger Defenses Change
Stronger defenses change the attack by removing the value of a relayable code. Passwordless and Passkeys Guide explains why phishing-resistant credentials such as passkeys and FIDO2 security keys are harder to hijack than codes, because they bind authentication to the origin and the device rather than to a transferable OTP.
That shift is also reflected in the formal identity guidance for phishing-resistant authentication. NIST SP 800-63 Digital Identity Guidelines is the clearest external reference for authenticator assurance, phishing resistance, and the difference between simple code-based factors and stronger authenticators.
For organizations, the practical lesson is that code-based MFA still improves security, but it should not be treated as the end state for high-value accounts. Workforce Identity Security Guide and IAM and Identity Provider Buyer’s Guide both help frame MFA, recovery, and sign-in design as part of a broader identity architecture rather than a single control.
Risk and Threat Considerations
Code hijacking is dangerous because the attacker is not merely guessing a secret, but stealing a live trust signal during authentication. The result can be rapid account takeover, session abuse, and expansion into email, SaaS, admin tooling, or recovery paths before the victim or defender can intervene.
Failure mechanism: The attacker captures or relays the code in the same authentication window that the legitimate user is expected to complete, so the code validates for the attacker’s session instead of the victim’s.
Impact: The second factor no longer prevents takeover, and the compromised sign-in can be used to reset credentials, enroll new factors, and move laterally into connected services.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines phishing-resistant authentication and authenticator assurance for code-based sign-in. |
| Recommendation — Prefer phishing-resistant authenticators for high-value accounts and recovery flows. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Covers authenticating workforce users whose MFA can be hijacked or relayed. |
| IA-5 — Authenticator Management | Addresses lifecycle and protection of OTPs, tokens, and other authenticators. | |
| Recommendation — Require stronger user authentication for accounts exposed to phishing and relay attacks. Manage authenticators so one-time codes and secrets are not easily intercepted or reused. | ||
| OWASP ASVS | V6 — Authentication | Specifies authentication requirements that address code capture and MFA bypass risk. |
| V10 — OAuth and OIDC | Relevant where federation flows and token exchanges are abused after code-based sign-in. | |
| Recommendation — Verify authentication flows resist phishing, relay, and account takeover. Harden federated sign-in and token handling against interception and replay. | ||
Practitioner Guidance
Why practitioners should care: The most important decision is whether a code-based factor is acceptable for the account class being protected. High-value users, administrators, support desks, and recovery flows deserve phishing-resistant authentication rather than reliance on reusable or relayable codes.
What to watch for: Repeated OTP prompts, unusual geolocation or device changes during sign-in, sudden factor enrollment, and help-desk recovery requests are all signs that code hijacking or a related relay attack may be in play. Treat these as identity events, not just login noise.
Practitioner takeaway: If an attacker can read, relay, or coerce the code in real time, the second factor is only as strong as the user interaction around it.
