Vishing in 2026: Why Voice Phishing Is Now the Top Cloud Breach Vector

Vishing is now the second initial access vector

M-Trends 2026, built on more than 500,000 hours of incident response conducted by Mandiant during 2025, ranks the vectors unambiguously. Exploits come first for the sixth consecutive year, at 32%. Voice phishing follows at 11%. Vishing did not overtake exploits, but it overtook everything else: prior compromise, stolen credentials and email phishing.

The second number is more interesting than the first. Email phishing fell from 14% in 2024 to 6% in 2025 — not sampling noise but a consistent decline. Gateways, sandboxing and link rewriting did their job: the economics of a bulk mail campaign collapsed faster than the cost of standing up a fraudulent call centre.

In the cloud the proportions look entirely different. There, vishing accounts for 23% of compromises and is the number one vector, ahead of third-party compromise (17%), stolen credentials (16%) and email phishing (15%). Exploits drop to 6%. The explanation is simple: in SaaS there is little to exploit from the network side, but there is a help desk that can reset MFA.

The Verizon 2026 DBIR looks at the same phenomenon from another angle and lands in the same place. The human element appears in 62% of breaches, social engineering is the third most common incident pattern (16%), and pretexting — building trust through a concocted scenario, in the report's words "frequently by voice communications" — entered the rankings as its own vector at 6%. In simulations, the median success rate of mobile-centric channels, voice and SMS, is 40% higher than the same scenario sent by email.

Why the phone works where email stopped working

Email controls have nothing to carry over to the voice channel. A filter works because the message is an artefact: headers, a sender, a domain, an attachment, a link. Every one of those can be checked against reputation, a pattern and a sandbox before the user sees it. A call has none of them, and leaves behind no object that could be scanned after the fact.

Not a metaphor but a concrete list of what this channel lacks:

• No artefact to analyse — no file, no URL and no SPF, DKIM or DMARC header; nothing to send to a sandbox
• No trace to search afterwards — without a recording, the logs hold call metadata at best
• Caller ID is not authentication — CLI can be spoofed, and CERT Polska warns about it plainly: "Do not blindly trust the displayed number or the name of the caller"
• The conversation is interactive — the attacker reacts to hesitation, changes the argument, raises or eases the pressure
• Time pressure applies instantly — you can leave an email for an hour, but a phone line holds a silence someone has to fill
• Authority is asserted, not verified — "I am calling from the security team" sounds identical whether or not it is true

M-Trends says it outright: although email and voice phishing both sit under the social engineering umbrella, "the distinction between the two is crucial for defenders: interactive attacks are significantly more resilient against automated technical controls and require different detection strategies." The budget that went into the mail gateway bought no control on this channel.

Anatomy of the attack: from a message to a hijacked account

A typical campaign does not start with a call. It starts with a message engineered to provoke one, and that sequence sidesteps the controls on both channels at once. The four steps below follow the flow described in the joint FBI and CISA advisory on Scattered Spider and in Proofpoint research on TOAD.

TOAD: the email a gateway has no way to block

Telephone-Oriented Attack Delivery is the name for a message that exists purely as a pretext for a call. Proofpoint describes the mechanism without embellishment: it contains "nothing more than a phone number and some erroneous information", and the chain activates only when the victim dials. Criminal call centres guide callers into granting remote access, revealing credentials or infecting themselves with malware.

From a mail gateway's point of view this message is clean. No URL to check against reputation, no file for the sandbox, no macro to defuse. What remains is content and sender-context analysis — precisely the layer where generative language models removed the last easy signals: awkward phrasing, grammatical slips and unnatural word order.

• The financial variant — the caller talks the victim into installing legitimate remote access software, takes the desktop and operates their banking; the screen is sometimes blanked to hide the activity
• The malware variant — the victim downloads a "diagnostic tool" from a dictated address, which delivers a loader and, further down the chain, ransomware
• The corporate variant — the prize is not money in an account but a one-time code or an approved MFA prompt that opens the tenant
• The reverse variant — contact starts with the call, and the email or SMS arrives afterwards as "confirmation"

Awareness programmes badly misjudge the scale of this channel. Proofpoint reports that 23% of surveyed organisations run smishing and vishing simulations, so fewer than one in four rehearse the scenario that ranks first in the cloud. A programme that stops at clicking links drills a behaviour attackers no longer need from this set of targets.

The help desk is the target, because it holds the MFA reset

The biggest problem is not that an employee reads out a code. It is that the help desk resets MFA at the request of someone whose identity nobody verified. The joint advisory from the FBI, CISA, RCMP, ACSC, AFP, CCCS and NCSC-UK on Scattered Spider, in its 29 July 2025 update, describes this as a core technique of the group: the actors pose as employees to convince help desk staff to reset the password and transfer the MFA token to a device they control.

Microsoft tracks the same group as Octo Tempest and adds the detail that decides whether the call succeeds: the attackers research the organisation beforehand, mimic the idiolect of a specific person and hold enough personal information to pass standard knowledge questions. They have also been seen impersonating new hires, where "I do not have access yet" raises no suspicion.

The operational cost column matters here as much as resistance. A procedure that adds ten minutes to every ticket becomes something to work around within a week of rollout, especially on a ticket from a board member. The sensible compromise is tiering: routine requests after one verification, password resets and MFA re-enrolment after two independent ones, and privileged accounts only through a path where the help desk cannot act alone.

// 1. Authentication methods changed by somebody other than the account owner.
//    This is the signature of a reset talked out of the help desk: actor != target.
AuditLogs
| where TimeGenerated > ago(30d)
| where LoggedByService == "Authentication Methods"
| where OperationName has_any ("registered security info", "updated security info",
                               "deleted security info")
| extend Actor  = tostring(InitiatedBy.user.userPrincipalName)
| extend Target = tostring(TargetResources[0].userPrincipalName)
| where isnotempty(Actor) and isnotempty(Target) and Actor != Target
| project TimeGenerated, Actor, Target, OperationName, Result, CorrelationId
| order by TimeGenerated desc

// 2. An admin-driven password reset followed within the hour by a successful
//    sign-in from a country the user has not signed in from before. That gap is
//    the tail end of a hijack that started as a phone call.
let resets = AuditLogs
    | where TimeGenerated > ago(30d)
    | where OperationName has "Reset user password" and Result == "success"
    | project ResetTime = TimeGenerated,
              Target = tostring(TargetResources[0].userPrincipalName),
              Admin  = tostring(InitiatedBy.user.userPrincipalName);
let baseline = SigninLogs
    | where TimeGenerated between (ago(90d) .. ago(30d)) and ResultType == 0
    | summarize KnownCountries = make_set(tostring(LocationDetails.countryOrRegion))
        by UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(30d) and ResultType == 0
| extend Country = tostring(LocationDetails.countryOrRegion)
| join kind=inner resets on $left.UserPrincipalName == $right.Target
| where TimeGenerated between (ResetTime .. ResetTime + 1h)
| join kind=leftouter baseline on UserPrincipalName
| where isnull(KnownCountries) or Country !in (KnownCountries)
| project TimeGenerated, UserPrincipalName, Country, IPAddress, ResetTime, Admin

// 3. A help desk operator whose reset volume spikes well above their own norm.
//    Not an incident by itself, but it is the cheapest metric that catches a
//    campaign aimed at one support seat rather than at one user.
AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName has_any ("Reset user password", "registered security info")
| extend Admin = tostring(InitiatedBy.user.userPrincipalName)
| where isnotempty(Admin)
| summarize Daily = count() by Admin, Day = bin(TimeGenerated, 1d)
| summarize AvgDaily = avg(Daily), PeakDaily = max(Daily), ActiveDays = count() by Admin
| where PeakDaily > 3 * AvgDaily and ActiveDays > 5
| order by PeakDaily desc

These queries will not detect the conversation. They detect its consequences. That is the only place vishing produces telemetry: an authentication method changed by someone other than the account owner, a password reset immediately followed by a sign-in from an unfamiliar country, and a help desk operator suddenly handling a multiple of their usual reset volume. If nobody reads those signals daily, that is the scope covered by SOC-as-a-Service.

Voice cloning: what is proven and what is a demonstration

It is worth separating research from marketing here. "From One Stolen Utterance", presented at the IEEE Symposium on Security and Privacy in 2025, tested five voice cloning techniques against eight voice authentication systems and thirty human listeners, using voice data from more than 7,000 speakers. The conclusion: modern cloning deceives both verification systems and people, and detection does not keep pace with new generators.

The review prepared for the European Parliament adds the market context. 53% of people share recordings of their own voice online, 70% of adults are unsure they could tell a clone from the original, and one in four has encountered a voice-cloning scam. On top of that, 49% of companies in the surveyed countries have faced fraud involving audio or video deepfakes.

Where does the line between demonstration and real use fall? Confirmed cases centre on financial fraud and impersonation of public figures. The FBI IC3 described a campaign in which actors sent text messages and "AI-generated voice messages" impersonating senior US officials. Europol reported an operation in which more than 7,500 calls were intercepted, preventing losses above 10 million euro in over 80% of cases.

What the data does not support is that a cloned voice is now the default component of corporate vishing. In the published accounts of Scattered Spider and Octo Tempest, the edge comes from reconnaissance and mimicking how someone speaks, not from speech synthesis. The conclusion is identical either way: since the voice has stopped being proof of identity, no procedure can treat it as authentication.

A real call from IT or your bank versus an attack

The differences are not in how the voice sounds but in what the caller asks for and how they react to being interrupted. The comparison below draws on guidance from CERT Polska and the FBI IC3 and on the joint Scattered Spider advisory.

The first 60 minutes after someone was talked into it

The report usually sounds like this: "I think I just read someone the code from my text messages." From that moment the order of operations is what matters, because a stolen session and a re-enrolled MFA method both survive a password reset. The flow below assumes one identity provider and the usual cast: user, help desk, security team.

1. Minutes 0–5User and help desk
   Report the call, do not try to fix it yourself

   The employee reports the call even if unsure whether they disclosed anything. The help desk does not investigate; it takes the report and escalates. Note the number that called, the time and what was requested — those three facts are enough to start searching the logs.

2. Minutes 5–15Security team
   Revoke sessions and tokens, not just the password

   Force a password reset, then revoke every active session and refresh token for that identity. A password reset on its own leaves the attacker in place for as long as the refresh token lives. If continuous access evaluation is in use, confirm the revocation actually propagated to the applications.

3. Minutes 15–30Security team
   Check MFA methods and registered devices

   List the authentication methods and devices registered against the account over the past 30 days. Anything added during the call window, or just after it, has to go. This is the step most often skipped, and it decides whether the attacker returns despite the changed password.

4. Minutes 30–45Security team
   Establish the blast radius: mailbox, rules, files, permissions

   Check mailbox rules and forwarding created after the call, file access logs, permission changes and new OAuth application consents. If the account held directory roles, extend the review to operations performed with those roles. Preserve the findings before you start cleaning up.

5. Minutes 45–60Security, HR and communications
   Warn the rest of the organisation and decide on notifications

   The same campaign almost never calls once. Send out a warning with specifics — which pretext was used and what was requested — and check whether others received similar calls. In parallel assess the notification obligations: a personal data breach to the supervisory authority within 72 hours, a significant incident under your sector rules. Do not punish the person who reported it.

If within that hour it turns out the attacker managed to register their own MFA method or perform operations with administrative privileges, this stops being a help desk ticket. That is the point to invoke incident response and to treat identity, not the workstation, as the primary scope of the investigation.

Controls that genuinely reduce the risk

Vishing is a problem of process and permissions, not of tooling. The most effective controls are organisational and require no new product — they require a decision about who is allowed to do what, and on whose request. The list below runs from the cheapest to the most demanding to roll out.

The cost spreads across lines that no single licence replaces. The first is help desk time: extra verification lengthens each ticket, so it is costed against monthly ticket volume rather than as abstract procedural overhead. The second is hardware for phishing-resistant authentication: the number of keys, the issuing path and the procedure for a lost one. The third is integration: alerts from the identity directory have to land where somebody reads them.

The fourth line is the one most often forgotten: upkeep. Challenge phrases need rotating, the supplier register needs an owner, and simulation scenarios wear out after a few repetitions. Better to anchor this in a cycle, for instance through vCISO, than treat it as a one-off project. Resistance to a specific pretext is measured through social engineering simulations that include the voice channel; vishing also features in our guide to the types of phishing, alongside spear phishing and whaling.

Frequently asked questions about vishing

Conclusion

The shift from email to the phone is not a surprise but a consequence of email controls starting to work. Attackers moved to the channel with no gateway, no headers and nothing to scan. The defence has to move with them: into a caller verification procedure, into limiting what the help desk can do on a telephone request, and into rehearsing the scenario that now ranks first in the cloud. No technical control will answer that phone for you.

A phone call cannot be patched and cannot be scanned. The only control that scales past a single person on this channel is a procedure that states plainly what the help desk will not do over the phone — and a board that has confirmed hanging up will never be the wrong call.