Skip to content
Start with Identity
Join free
SWI-T004 · Authentication

OTP relay via social engineering

The attacker starts a real login and calls the victim posing as support, asking them to read back the one-time code that just arrived. The code is genuine; the request is not.

WidespreadHard to detect
First observed: 2019ATT&CK T1566.004 ↗ATT&CK T1621 ↗ATT&CK T1111 ↗

How it works

OTP relay via social engineering is persuading a person to hand over a one-time passcode that the attacker caused to be sent, so the attacker can complete a real sign-in with it. No code is intercepted technically. The victim reads it out, types it into a lookalike page, or forwards it, believing they are helping stop fraud. It is the human-operated twin of an AiTM phishing proxy, and it works against every phishable MFA method that produces something a person can repeat: SMS and voice codes, TOTP authenticator codes, email codes.

The code's validity window sets the clock.

  1. Get the first factor. The attacker has the victim's password from a phishing page, an infostealer log or a breach, or, for consumer accounts, enough personal detail to start a login or recovery flow.
  2. Trigger the code. They start a genuine sign-in, password reset or payment on the real service. The service sends a real code to the victim's phone or inbox.
  3. Call or text with a pretext. By phone or by text message (smishing), posing as IT support, the bank's fraud team or the platform itself, the attacker explains the code away: "we are verifying a suspicious login," "read me the code to cancel this transfer," "IT needs it to finish your migration." This is vishing or smishing with a single goal.
  4. Relay. The victim reads the code aloud or enters it into a page the attacker watches. The attacker enters it into the real login within seconds or minutes.
  5. Persist. The first thing a careful attacker does is register their own authenticator, so they no longer need the victim. In the Retool case, one code let the attacker add their own device to the employee's Okta account.

The calling itself is now being automated. 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 counted 200 calls across nine months and 30 installations: not mass scale yet, but it removes the need for a skilled human caller who speaks the victim's language.

Why it works

An OTP proves that the holder received a message. It says nothing about which session, site or transaction it belongs to, so the person reading it cannot tell a real verification from a relay of their own login. Anything a human can read, type or repeat can be relayed by someone faster and more convincing than the defense assumes. NIST draws the line in SP 800-63B-4: authenticators that involve manual entry of an output, which includes OTP and out-of-band codes, are not phishing resistant.

The usual hardening does not help here. Number matching stops blind approval of push prompts, but over a live call the attacker simply reads the number on their screen to the victim. Rate limits do not help either, because the attacker needs only one code. And cloud-synced authenticators can turn one compromised account into every factor: Retool wrote that because Google Authenticator synced its codes to the cloud, compromising the employee's Google account exposed all of them. It is a talk-past attack: the victim satisfies authentication on the attacker's behalf.

How to detect it

  • Okta System Log. system.sms.send_factor_verify_message or system.voice.send_mfa_challenge_call followed by a successful user.authentication.auth_via_mfa from an IP, ASN or device never seen for the user, then user.mfa.factor.activate for a new factor shortly after. That last pairing, a code-based sign-in followed by a fresh enrollment, is the strongest signal. user.account.report_suspicious_activity_by_enduser catches victims who realize afterward.
  • Microsoft Entra sign-in logs. In the authenticationDetails of a sign-in, authenticationMethod values SMS, Voice or Software OATH token on a session from an unfamiliar location or device, followed in the audit log by User registered security info. authenticationStepResultDetail records cases such as "fraud code entered."
  • Repeated code sends. Several code deliveries for one account in a few minutes, which can mean an attacker retrying while keeping the victim on the line.
  • Recovery and help desk context. A call to support from the account holder just before or after a suspicious sign-in. It can be the victim reporting, or the attacker's own pretext call.

Be honest about the limits: a victim who receives a real code and later reports it looks the same in the logs as one being scammed in real time, and the relayed sign-in uses the right password and the right code. Detection leans on location and device novelty, on what happens in the first minutes after sign-in, and on user reporting. It arrives after access, so automatic session revocation on a confirmed report matters more than the alert itself.

How to stop it

Ranked by effect:

  1. Move to phishing-resistant MFA. A passkey or a hardware key such as a Yubico YubiKey has no code to read aloud, which removes the relay path. Retool's own recommendation after its breach was FIDO2 hardware keys, because no shareable code exists. Microsoft is retiring its own SMS and voice delivery in Entra ID from February 1, 2027 for most users, with a blocking passkey prompt for users left on SMS or voice only. Our MFA support matrix shows where each method stands.
  2. Protect enrollment. Require a phishing-resistant method or an identity check to register a new authenticator, so one relayed code cannot become permanent access.
  3. Turn off cloud sync for authenticator seeds where the tool allows it, or use authenticators that do not sync secrets. Retool noted administrators could not centrally disable Google Authenticator's sync.
  4. Put the context in the message. Where a code must stay, state what it authorizes ("sign-in to X from a new device in Y") and "we will never call you to ask for this code."
  5. Tell users the rule once, in every channel. IT, the bank and the platform will never ask for a code. A request for one is itself the tell.
  6. Train support teams on the inversion. The scam is a caller pretending to be them. Help desks that never ask for codes make the rule credible. See help desk social engineering for the other direction.

Seen in the wild

Sources

Last reviewed By SWI Community TeamSuggest a correctionHow we research

In the Identity Breach Database

Real incidents in our sourced breach database where this technique was used.

Browse the full database

Seeing this technique used differently, or have a detection rule that works better? Email community@startwithidentity.com. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.