Caller-Led Vishing Kits Are Defeating Okta MFA in Real Time

The phone rings on a Tuesday afternoon and the caller ID says it is your own help desk. The voice is calm, knows your name, knows you use Okta, and says there is a sign-in problem on your account that needs a quick re-verification. They send you to a page that looks exactly like your company portal. You type your username and password. A push lands on your phone with a two-digit number, and the caller reads you the same two digits and asks you to approve. You do. Thirty seconds later the attacker is inside your single sign-on, and your second factor never once misfired.

That is the mechanic behind the wave of caller-led phishing kits that Okta Threat Intelligence dissected on June 26, 2026. These are not the static credential-harvesting pages we have all learned to spot. They are real-time relays, operated by a human on the phone, built to keep pace with whatever multi-factor prompt your identity provider throws up. Okta's own summary is blunt: the synchronization between caller and victim lets the operator "defeat any form of MFA that is not phishing-resistant."

Who this actually affects

Here is the relevance verdict, because it is the whole point of covering this. If your workforce signs in with SMS codes, authenticator app one-time passcodes, or push notifications - including push with number matching - you are exposed to this technique today, on Okta, Microsoft Entra, and Google Workspace alike. If you have already moved every account, privileged ones first, onto FIDO2 security keys, passkeys, or Okta FastPass, and you enforce that with policy so a phishable factor cannot be used as a fallback, this specific kit cannot relay your login. You can stop reading and instead go verify that the enforcement is real and has no exceptions. Almost nobody is in that second group yet, which is exactly why the kits work.

The business stakes are not abstract. The actors running these campaigns are the same crews monetizing SSO access at scale. ShinyHunters claimed the recent run of voice-phishing intrusions, and CyberScoop reported that an earlier ShinyHunters campaign against connected SaaS reached more than 700 Salesforce customer environments, with Sophos tracking a cluster of roughly 150 lookalike domains spun up to support the operation. One harvested SSO login is rarely the end of the story - it is the front door to every app behind the identity provider.

What the caller-led kits actually do

Strip away the branding and the flow is a tight loop between three things: a human caller, a victim, and a live proxy sitting in the middle of a genuine login. Okta's analysis traces the sequence:

• Reconnaissance. The operator learns employee names and the real internal IT support number, then spoofs that number so the call looks legitimate on the handset.
• Pretext and redirect. Under an IT-support story, the victim is steered to a custom phishing page that mirrors the real identity-provider sign-in flow. Okta found dedicated panels for impersonating Google, Microsoft, and Okta logins.
• Capture and forward. Whatever the victim types - username, password, the one-time code - is "automatically forwarded to the threat actor's Telegram channel" in real time.
• Relay. The operator immediately replays those credentials against the real login, watches which MFA challenge the provider issues, and updates the phishing page on the fly so what the victim sees matches what the operator needs them to do.
• Service model. These kits are sold as a service, so the barrier to running one is low and the target list - identity providers and cryptocurrency platforms - keeps widening.

The reason this beats a one-time passcode is timing. A TOTP code is valid for roughly 30 seconds, which is plenty of time for a human on the phone to read it back and an operator to paste it into the live session. The kit closes the gap between "user enters the code" and "attacker uses the code" to a few seconds of conversation.

Sort your MFA into two piles

The decision in front of every team right now is which factors survive a real-time relay and which do not. It maps cleanly onto two piles.

Phishable - an operator can replay it

• SMS and voice one-time codes. Read aloud over the phone, intercepted in transit, the weakest of the set.
• Authenticator app TOTP codes. A six-digit code the user can be talked into reading back is a code the operator can paste into the real login inside its validity window.
• Standard push approval. The user taps "approve" on a prompt the operator triggered by submitting the stolen password.
• Push with number matching. This is the one teams assume is safe, and it is the one this technique targets directly. Okta states plainly that "push with number matching/challenge is not phishing-resistant by definition, as a social engineer interacting on the phone with a targeted user can simply request a user to choose or enter a specific number." The caller reads the number; the user approves; the relay completes.

Phishing-resistant - the relay breaks

• FIDO2 security keys. The authenticator cryptographically binds the assertion to the real origin. A login presented at a phishing domain does not match, so the key refuses to sign.
• Passkeys. The same WebAuthn origin binding, delivered through platform authenticators on phones and laptops, with nothing for a caller to read aloud.
• Okta FastPass. Device-bound, origin-aware, and resistant to the same adversary-in-the-middle relay. Okta's recommendation is to deploy "Okta FastPass, passkeys or both for the sake of redundancy."

This matches the federal baseline. CISA's Implementing Phishing-Resistant MFA fact sheet names FIDO/WebAuthn as the widely available phishing-resistant standard and treats number matching as an interim mitigation for MFA fatigue, not as a defense against an adversary in the middle. The kits Okta found are precisely the threat that interim mitigation was never built to stop.

Hunt for the relay in your logs

You will not see "phishing kit" in your logs. You will see a successful, fully MFA-satisfied login that arrives from infrastructure your user has never touched - frequently a hosting provider or anonymizing service the operator uses to run the proxy. Okta's guidance is to "know where your legitimate requests come from, and allowlist those networks," and to deny known anonymizing services outright. Start by finding the sessions that came through one.

On Okta, pull session starts that the platform already flagged as coming through a proxy or anonymizer, which is where relayed logins surface:

# Okta System Log: session starts that came through a proxy/anonymizer in the
# last 24h - the infrastructure caller-led relay kits hide behind.
OKTA="yourorg.okta.com"
SINCE=$(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ)

curl -s -H "Authorization: SSWS ${OKTA_API_TOKEN}" \
  "https://${OKTA}/api/v1/logs?since=${SINCE}&filter=eventType+eq+%22user.session.start%22" \
| jq -r '.[]
    | select(.securityContext.isProxy == true)
    | [.published, .actor.alternateId, .client.ipAddress,
       .securityContext.asOrg, .outcome.result] | @tsv'

The same campaign hits Microsoft tenants, so run the matching hunt in Entra. This surfaces successful, MFA-satisfied sign-ins that Entra ID Protection flagged for an anonymized IP - the relay's fingerprint:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0                       // successful sign-in
| where AuthenticationRequirement == "multiFactorAuthentication"
| where RiskEventTypes_V2 has_any ("anonymizedIPAddress", "unfamiliarFeatures")
| project TimeGenerated, UserPrincipalName, IPAddress, AutonomousSystemNumber,
          AppDisplayName, RiskLevelDuringSignIn, ConditionalAccessStatus
| order by TimeGenerated desc

A hit on either query is not proof of compromise, but it is a thread worth pulling: confirm the device, the location, and whether the user took a help-desk call around that timestamp. If they did, treat the account as compromised and revoke its sessions before you do anything else.

The migration that actually closes this

Detection buys you time; it does not remove the exposure. The fix is to retire the phishable factors, and you do not have to boil the ocean to get most of the protection. Sequence it by blast radius:

1. Privileged accounts first. Okta and Entra admins, anyone with access to the SSO configuration itself, and your financial and engineering power users move to FIDO2 keys or passkeys this quarter. These are the accounts the kits are hunting.
2. Enforce, do not offer. A phishing-resistant factor a user can skip in favor of a push is not a control. Set an authentication policy that requires FastPass, a passkey, or a security key for the application groups that matter, with no OTP or push fallback.
3. Cut the anonymizer paths. Build network zones that deny known anonymizing and hosting-provider ranges for interactive sign-in, and allowlist the networks your legitimate users actually come from. This is straight out of Okta's advisory and it raises the cost of the relay considerably.
4. Brief the help desk and the humans. The kit depends on a user approving a prompt during a phone call. A standing rule - we will never call and ask you to approve a sign-in or read back a code - removes the social pressure the whole technique runs on.

For a 50-person company without an identity team, none of this requires an enterprise budget. Passkeys are free and built into the phones and laptops your staff already carry. Hardware security keys run roughly 25 to 50 dollars each, and you only need them for the handful of privileged accounts. The phishing-resistant policy controls ship inside the Okta and Entra licenses you are already paying for. The hard part is the decision: commit to the cutover and then enforce it without leaving a phishable fallback open.

Cut your privileged logins over to phishing-resistant factors

The next move is concrete and it is this week's work, not next quarter's project: pull a list of every account that can still authenticate with SMS, TOTP, or push, sort it by privilege, and start the migration to FastPass or passkeys from the top of that list. Run the two log queries above first so you know whether anyone has already been relayed. The teams that get hit hardest by this campaign are the ones still treating number-matching push as the finish line for MFA. It was a good interim step. It is no longer the destination.