Why do attackers use WhatsApp or other chat redirects to bypass multi-factor authentication on social accounts?

How chat redirects work as an MFA bypass

Attackers use WhatsApp or similar chat channels because they shift the conversation into a space that feels informal, immediate, and trusted. That matters most when the victim is already expecting help, a reset, or a verification check. The redirect is not about breaking the MFA technology itself, it is about moving the user out of the normal sign-in context where the one-time code would otherwise be treated as sensitive.

In practice, the attacker creates a believable support-style exchange, then narrows the victim’s attention to a single action: share the code, approve the prompt, or confirm a recovery detail. Once that happens, the attacker can complete the login or binding step inside the legitimate service flow. Stronger sign-in methods, such as phishing-resistant MFA and passkeys, reduce this exposure because there is no reusable code for the victim to hand over and relay in the first place. See MFA Guide and NIST SP 800-63 Digital Identity Guidelines for the control side of that shift.

For social accounts, the attacker often does not need the password if they can capture the live verification step. That is why chat redirects are effective against accounts protected by SMS OTP, authenticator-app codes, or help-desk style recovery paths. The attack succeeds by exploiting user trust and timing, not by defeating cryptography. The account owner sees a conversation that looks like support or a routine check, while the attacker is really harvesting the final factor needed to complete sign-in.

Why this social engineering pattern works so well

Chat redirects are effective because they replace a binary login screen with a guided conversation. A login screen tends to raise suspicion: it asks for a password, shows the domain, and often warns about invalid code entry. A chat thread lowers that guard. It feels continuous, responsive, and human, which makes the request for a code or confirmation seem like a normal service interaction rather than a takeover attempt.

The tactic also exploits urgency and confusion. Victims are more likely to comply when the attacker claims the account is at risk, a post has been flagged, or verification is needed to restore access. That pressure can make people overlook the basic rule that an MFA code should never be shared with another person or typed into an unsolicited chat. The same logic underlies many real-world credential and token theft cases, including Twilio 0ktapus breach 2022 and Uber Breach, where the attacker’s advantage came from social pressure and trust abuse rather than technical exploitation.

For defenders, the key point is that MFA only helps if the second factor stays bound to the real authentication event. When the user is tricked into reading the code aloud, entering it in a chat, or approving a prompt they did not initiate, the control is being used against itself. That is why phishing-resistant methods matter, and why recovery, reset, and support flows need to be treated as part of the authentication surface, not just the password screen.

What to harden on social platforms and recovery paths

On social accounts, the most important hardening step is to reduce code sharing opportunities and remove easy recovery abuse. That means preferring passkeys or phishing-resistant MFA, limiting SMS where possible, and tightening account recovery so a chat-based impersonator cannot pivot from “verification” to reset. It also means reviewing how email, phone, and device recovery channels are chained together, because one weak path can defeat a stronger login method.

Attackers often look for the easiest indirect route, not the strongest direct one. If a platform allows code reuse, weak recovery, or support-based exceptions, the attacker can simply steer the victim there. Current guidance suggests treating “verify this code for me” requests as a high-confidence fraud signal. The practical control is not just technical, it is behavioral: users must know that legitimate support never needs their one-time code, and organizations should assume any chat thread claiming urgency is part of the attack surface.

A useful reference point is the broader identity lifecycle. A well-run account should have a clear enrollment path, a narrow recovery path, and a fast revocation path when compromise is suspected. Where those boundaries are loose, chat redirects become much more effective because the attacker can keep the victim engaged long enough to complete the takeover. For operational guidance on reducing that exposure, see Workforce Identity Security Guide and Passwordless and Passkeys Guide.

Risk and Threat Considerations

Chat redirect attacks are dangerous because they bypass the strongest part of MFA: the assumption that only the real user can see and approve the challenge. Once the victim is social-engineered into handing over a code or approving a prompt, the attacker can take over the account, alter recovery settings, and lock the owner out before the compromise is obvious.

Failure mechanism: The attacker moves the victim into an off-channel conversation, builds trust, and extracts the one-time code or approval that was meant to stay inside the authentication flow. That turns the user into the final delivery mechanism for the second factor.

Impact: The attacker can authenticate as the victim, steal messages, impersonate the account owner, reset linked credentials, and use the account for further fraud, spam, or phishing against contacts.

Practitioner Guidance

What to prioritise: Treat any MFA method that can be relayed by a human in chat, SMS, or voice as exposure, not assurance. Where possible, move the highest-value accounts to phishing-resistant sign-in and make recovery controls stricter than everyday login controls.

What to verify: Confirm that your recovery process cannot be completed with only a conversational request and a one-time code. If a support path, help desk, or phone-based exception can reset access faster than you can detect compromise, it needs redesign.

Common mistake: Teams often train users to watch for fake login pages but leave chat-based impersonation and recovery abuse undercontrolled. That creates a gap between “MFA enabled” and “MFA actually resistant to social engineering.”

Practitioner takeaway: The real control objective is not to add another code, it is to make sure no attacker can persuade the user to become the bypass path.

Related resources from NHI Mgmt Group

• How should security teams use fingerprint verification in multi-factor authentication without creating weak fallback paths?
• How should security teams use one-time passwords as part of multi-factor authentication without creating avoidable friction?
• What do security teams get wrong about two factor authentication for social media accounts?
• How should security teams implement multi-factor authentication for workloads and service accounts?