OTP relay via social engineering

How it works

The attacker has a stolen password or enough personal detail to start a login, and a one-time passcode (OTP) is sent to the victim by SMS, email, or an authenticator prompt. Instead of trying to intercept that code technically, the attacker calls, texts, or has an automated voice agent call the victim, posing as support staff from the bank, the employer's help desk, or the platform itself. The pretext explains the code away: "we're verifying a login attempt," "read us the code to cancel a fraudulent transaction," or a matching script for whatever channel sent it. The victim, believing they are helping stop fraud, reads the code aloud or types it into a page the attacker controls. The attacker enters it into the real login within the code's short validity window and is authenticated.

Recent kits have automated the calling itself. SOCRadar documented AnonyMousKIT, a phishing-as-a-service platform that rents commercial voice AI to run a persona in three languages, calling victims and asking for a passcode and a live two-factor code, at a cost of about ten cents per call. SOCRadar's own count, 200 calls across nine months and 30 installations, is not yet mass-scale by volume, but it establishes that a single operator can now run a multilingual, round-the-clock voice-phishing operation without hiring or training a human caller, which is the constraint that previously capped how far this technique could scale.

Why it works

An OTP proves the holder received a message, not that they understood what they were authorizing. The code carries no information about the transaction or session it belongs to, so a victim reading it aloud cannot tell a legitimate verification request from a real-time relay of their own login. This is a social-engineering failure layered on top of a factor that was already easy to forward: anything a human can read, type, or repeat can be relayed by an attacker who is faster and more convincing than the defense assumes. Automation removes the last practical limit, the need for a skilled human operator who speaks the victim's language, and turns the attack into commodity infrastructure priced per call.

How to detect it

• A successful authentication using an OTP that was generated moments earlier and used from a device or location the account has never shown before.
• Help desk or account-recovery logs showing a call or contact from the account holder immediately before or after a suspicious sign-in, which can indicate either a legitimate report or an attacker's own pretext call.
• Repeated OTP generation requests for the same account in a short span, suggesting the attacker retried after a failed relay.

Be honest about the limits: a victim who receives a real OTP and later contacts support about it looks identical in the logs to a victim actively being scammed in real time. Detection here leans heavily on user reporting and fraud-pattern context, not on a clean technical signature.

How to stop it

• Move to phishing-resistant MFA: a hardware key or passkey has no code for a victim to read aloud, which removes the relay path entirely.
• Never ask users to read a code to anyone, and say so explicitly in every communication channel, so a request to do so is itself the tell.
• Bind OTP delivery to transaction details where possible, so the message states what is being authorized rather than a bare number.
• Train help desks and consumer-facing support on the specific inversion: the scam is a caller pretending to be them, not a caller pretending to be the customer.
• Rate-limit and monitor OTP generation per account to slow an attacker's ability to retry after a failed or delayed relay attempt.

Seen in the wild

• A phishing kit rents an AI voice agent to call theft victims and ask for their 2FA code

Sources

• MITRE ATT&CK T1566.004: Phishing: Spearphishing Voice
• MITRE ATT&CK T1621: Multi-Factor Authentication Request Generation
• NIST SP 800-63B: Digital Identity Guidelines, Authentication and Lifecycle Management