Vishing is phishing that arrives as a phone call instead of an email. The word is a contraction of voice phishing, and if you have not run into the term before you are not alone, because most security awareness training still frames phishing as something that shows up in an inbox.
Okta has been publishing warnings about a vishing campaign that has been running since around April. The pattern is worth understanding precisely, because the details are what make it a configuration problem rather than only an access problem.
Someone calls an employee claiming to be corporate IT. They walk that employee through what looks like a routine passkey enrollment. The page is a phishing kit that mimics the real enrollment flow closely enough to survive a distracted Tuesday afternoon. While the employee is following along, the attacker registers their own passkey against that account. The employee finishes the call believing they enrolled a new authenticator, which in a sense they did, just not for themselves.
Threat intelligence has tracked this against automotive, aviation, construction, food and beverage, healthcare, and technology organizations, mostly for data extortion. It follows an earlier wave in which attackers combined vishing calls with branded credential harvesting pages to collect SSO credentials and MFA codes in real time.
Okta publishing this is the right call, and their security research team publishes the campaign analysis openly is worth reading. I want to talk about the part that comes afterward, because almost none of the coverage does.
Why phishing-resistant MFA does not save you here
This is the detail I would want a board to understand.
Passkeys and hardware-backed MFA are designed to defeat credential theft. An attacker cannot replay a passkey the way they can replay a stolen password or a one-time code, because the private key never leaves the device and the challenge is bound to the origin.
This attack does not steal a credential. It gets the victim to enroll a new one that the attacker controls.
The result is an attacker holding a legitimate, correctly registered authenticator on a real account. Every login after that is genuine. There is no replayed token, no impossible travel, no anomaly for a detection rule to catch, because from the identity provider's point of view nothing improper happened. An authorized user enrolled a factor, which is a thing authorized users do.
That is why the campaign keeps working in orgs that did the hard work of rolling out phishing-resistant MFA. It attacks the enrollment ceremony rather than the authentication.
This is not hypothetical
The playbook has a track record, and it is worth being specific about it rather than gesturing at risk.
In September 2023, the group commonly tracked as Scattered Spider used help desk social engineering against MGM Resorts and Caesars Entertainment. The initial access was a phone call. Operators pulled employee details from LinkedIn, called the service desk impersonating those employees, and talked agents into resetting MFA and passwords. CISA later published an advisory on the group's tradecraft. Reporting put MGM's cost at roughly 100 million dollars, and Caesars paid a ransom reported at 15 million.
Also in 2023, Okta disclosed a breach of its support case management system in which every support customer was ultimately affected, with downstream impact at 1Password, BeyondTrust and Cloudflare. Different entry point, same lesson about identity sitting upstream of everything else.
More recently, security researchers have documented how modern phishing kits have made vishing far more scalable, which is roughly the point at which a technique stops being a targeted operation and starts being a volume business.
Prevention advice is not recovery advice
Nearly everything written about this campaign so far tells you how to stop it. Train the helpdesk. Verify callers out of band. Watch for enrollment events from unusual locations. Tighten who can enroll a new factor and from where. That advice is correct and you should follow it.
But every organization I have talked to that has been through an identity incident describes the same second phase, and nobody writes about it. The attacker is out. Sessions are cleared, credentials rotated, the rogue authenticator removed. Then somebody senior asks a question that sounds simple and turns out not to be:
What did they change while they were in there?
An account takeover is rarely the objective. It is the entry. What an attacker does with fifteen minutes of authenticated admin access is quiet and specific. They add themselves to a group that happens to carry an application assignment. They grant a role. They loosen an authentication policy so the next login is easier. They add a network zone, or widen an existing one. They register a trusted origin. They create an API token. None of it looks like an attack in the moment, and all of it survives the password reset.
The evidence problem
The instinct is to go to the system log, and you should. But a system log answers a different question than the one being asked. It tells you events happened. It does not tell you the shape of your configuration before and after, and it will not hand you a clean list of every difference.
If your org has a few thousand users, a few hundred groups, and a policy set that has accumulated exceptions over four years, reconstructing prior state from an event stream is slow work under exactly the conditions where you have no time. Most teams end up doing it from screenshots, tribal memory, and whoever happened to be in the admin console last week.
That is the gap. Not detection, not eviction, but the ability to put your configuration side by side with a known good version of itself and see the delta.
What is actually snapshottable, and what is not
I want to be precise here, because this space is full of vendors who round up.
Per-user enrolled factors, meaning the specific passkey an attacker registered against one employee, live in Okta's own admin surfaces and system log. That is where you go to find and remove them, and Okta's tooling is the right tool for that job.
What sits outside that, and what nobody keeps a known good copy of, is the org configuration around it. Butterfly snapshots the pieces an attacker with admin access actually touches: authentication policies and their rules, group definitions and group rules, application assignments, org level authenticator configuration, network zones, device assurance policies, trusted origins, and behaviors. When something changes between two snapshots, you get a diff, and you can preview a restore before anything is written back.
So the answer to "what did they change" stops being an archaeology project and becomes a comparison.
A reasonable thing to do this week
You do not need us for most of this. If you take one thing from the campaign, make it these four:
Verify out of band before any enrollment assistance, and make that a rule the helpdesk is allowed to enforce against an impatient executive.
Alert on authenticator enrollment from a new device or an unusual location, and route it somewhere a human reads.
Write down, now, while nothing is on fire, how you would answer the question of what changed in your identity configuration between last Tuesday and today. If the honest answer involves screenshots, that is worth knowing before you need it.
Take a configuration snapshot on a schedule and keep it somewhere your identity provider is not.
The last one is the one people skip, and it is the one that turns a bad week into a bad afternoon.
If you want to see the diff and preview restore workflow against real configuration, the interactive demo runs without a signup.