Vishing

Vishing is phishing carried out by phone call. An attacker calls, impersonates someone trusted, often internal IT or a help desk, and talks the person into handing over information or granting access. MITRE ATT&CK files it under two separate techniques, split by what the caller wants.

Every page in the captured results defines it, and most of them define it well. If you came here after a strange phone call, the answer is at the top of this page and the next section is written for you.

What none of those pages does is place it. Across a full capture of both major search engines, not one result names a technique identifier, and not one carries a number. The word gets explained and never located.

So this page does the other job: where vishing sits in the framework your organisation already uses, how often it is actually the way into a network, who the documented callers really rang, and what was genuinely done about caller ID by the people who build telephone standards.

Explain it like I'm 10

When your phone rings, it shows you a name and a number. Neither of those was checked by anyone before it reached your screen. The phone network passes along what it was told.

So someone who wants to get into a company can just ring it up and act like a person you would normally help. The trick is as old as telephones. What makes it work is that the system was never built to prove who is calling.

If a call feels wrong, the safe move never changes: end it, look up the organisation's number yourself, and dial that one. Anyone genuine will still be there.

Two technique IDs, one phone call

MITRE ATT&CK has two objects for this attack, and no page in the captured results names the second one.

The first is T1566.004, Phishing: Spearphishing Voice. Its tactic is Initial Access. Its platforms are Identity Provider, Linux, Windows and macOS. Version 1.2, created 7 September 2023, last modified 12 May 2026.

The second is T1598.004, Phishing for Information: Spearphishing Voice. Its tactic is Reconnaissance. Its platform is PRE. Version 1.0, created the same day, last modified the same day.

The split is not about the channel

Look at the table and notice what is identical. Same delivery, same social engineering, same person on the other end of the same phone call.

The framework separates them by what the caller is trying to walk away with. If the call is meant to get someone into a system, it is initial access. If the call is meant to collect something that makes a later intrusion possible, it is reconnaissance.

The platform fields say it twice. One names an Identity Provider, which is a statement about where this attack lands. The other names PRE, ATT&CK's placeholder for activity that happens before there is a system to defend at all.

There is one more thing sitting in T1598.004's description that deserves noting. It says these communications "can be manually executed by adversaries, hired call centers, or even automated via robocalls", and it is where ATT&CK files callback phishing, the variant where a message tells you to ring a number rather than the attacker ringing you.

How often vishing is the way in

Here is the figure no page in the captured results carries.

In its M-Trends 2026 report, drawing on a frontline incident response dataset, Mandiant recorded that "highly interactive voice phishing saw a significant surge to 11%, becoming the second-most commonly observed vector" among initial infection vectors in one incident response provider's investigated intrusions during the 2025 coverage year, which is a share of observed intrusion entry points rather than a prevalence rate for the attack itself.

That sentence is deliberately loaded with qualifiers, because the figure is easy to repeat wrongly. It does not say 11% of cyberattacks are vishing. It says that when this firm investigated intrusions and could determine how the attacker first got in, the phone accounted for roughly one in nine.

The comparison in the same list is what makes it land: email phishing sits at 6%. The attack the entire security industry has spent twenty years building products for is measured, in this dataset, at a little over half the rate of the one that arrives by telephone.

One incident, published by the company it happened to

In August 2022, Cisco Talos published an account of an intrusion into Cisco's own network. The attacker "conducted a series of sophisticated voice phishing attacks under the guise of various trusted organizations attempting to convince the victim to accept multi-factor authentication (MFA) push notifications", and "ultimately succeeded in achieving an MFA push acceptance, granting them access to VPN."

A phone call and a repeated prompt. That is the whole entry path in a documented case at a company that builds security products, and it is stated here plainly, without commentary.

What does not exist is a count of how many such calls are made. The volume figures in circulation are robocall totals published by companies selling call blocking, and robocalls are a far larger category that is mostly not fraud at all.

The caller is not always calling you

This is where the consumer framing gives way, and it gives way on MITRE's own evidence rather than on anyone's opinion.

ATT&CK lists procedure examples for each technique: documented cases, attributed to named actors. Read the four for T1598.004 and a pattern appears immediately.

LAPSUS$ "has called victims' help desk to convince the support personnel to reset a privileged account's credentials." Scattered Spider "has used help desk voice-based phishing and also called employees at target organizations and compelled them to navigate to fake login portals using adversary-in-the-middle toolkits".

A campaign tracked as Salesforce Data Exfiltration involved threat actors who "initiated voice calls with victims to socially engineer them into authorizing malicious applications or divulging sensitive credentials."

On the initial access side the pattern holds. Scattered Spider "impersonated legitimate IT personnel in phone calls to direct victims to download a remote monitoring and management (RMM) tool", and Storm-1811 "has initiated voice calls with victims posing as IT support to prompt users to download and execute scripts and other tools for initial access."

The person who answers is the control being bypassed

Count the impersonations across the five documented cases above. Two rang the help desk. Two more impersonated internal IT. Not one pretended to be a bank, a tax office or a delivery company.

That inverts the mental model the search results build. The help desk agent who takes the call is not being defrauded. They are doing their job correctly, for someone who has been described to them as a colleague in difficulty, and the outcome is a credential reset for an account they never should have touched.

Which is also why "train users to be suspicious of callers" lands differently on a help desk than on everyone else. A help desk exists to help people who cannot get into their accounts. Suspicion is not a setting it can simply turn up.

A footnote on reading primaries

The Salesforce campaign is a useful marker for how recent this is: MITRE dates its start to October 2024 and records vishing as the entry point. A small footnote on that same page, mentioned only because this article's whole method is reading primary sources instead of summaries of them: its "First Seen" field reads October 2004, twenty years before the description directly beneath it. Framework pages have typos too.

Is there anything to detect?

This is the question a practitioner actually arrives with, and the honest answer has two halves.

ATT&CK publishes a detection strategy for T1566.004, DET0245, carrying four analytics. The first asks you to "monitor call log records from corporate devices for unusual or unauthorized numbers", correlated with what happened next. The second says to "audit VoIP/SIP logs for suspicious outbound calls or call setup messages to unusual endpoints". The third covers "Facetime, iMessage, or SIP client logs".

On the reconnaissance side, DET0886 carries exactly one analytic, and it asks for call logs again, this time matched against "known malicious phone numbers", which presumes such a list exists and is current.

So three of those four, plus the only one on the reconnaissance side, ask for the telephone system's data: call detail records, VoIP or SIP logs, client call histories. The analytics name their own data sources, and whether your security team holds those sources, or could get them, is a question worth answering before treating this technique as covered. That is the uncomfortable half.

The fourth one is the useful one

The remaining analytic in DET0245 does something different. It says: "Correlate MFA push fatigue or unusual consent grant attempts with call activity where adversaries may have socially engineered the user over voice."

Notice what it is not doing. It is not looking for the call, and it does not need the phone system. It looks for what happened afterwards inside telemetry a security team already holds: an unusual pattern of authentication prompts, an application consent granted at an odd moment, a remote management tool appearing on a laptop that never had one.

That is a correlation rather than a signature, and it will never fire on the call itself. It is also the only detection in the published set that does not depend on getting the phone records, which makes it the one to build.

Did anyone ever fix caller ID?

Every page in the captured results tells you not to trust caller ID. None of them says whether anyone tried to make it trustworthy, and the answer is that they did, they wrote down what they built, and they wrote down its limit at the same time.

The starting point is RFC 7340, the IETF's Secure Telephone Identity problem statement, published in September 2014. Its own abstract explains the cause. Interworking internet telephony with the traditional phone network, it says, "has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks."

Note the date on that last clause. MFA circumvention by telephone was written into an internet standards document in 2014.

Two goals, one symptom

The same document draws a distinction none of the captured pages repeats: "number spoofing is used in two ways: impersonation and anonymization. For impersonation, the attacker pretends to be a specific individual." One symptom on your screen, two entirely different attacker goals behind it.

What the standard actually claims to do

The specification that followed, RFC 8224 of February 2018, describes its own purpose in one clause worth reading slowly. Its primary focus is "the prevention of the simple unauthorized claiming of an identity" for the purposes of robocalling, voicemail hacking, or swatting.

Unauthorized claiming of an identity means using a telephone number you have no right to use. That is what cryptographic call signing addresses, and it addresses it well.

It is not designed to establish that the human being speaking is who they say they are. A caller who legitimately obtained a number and then lies about being from your IT department has claimed no identity they were not authorised to claim. Those are two different problems, and only one of them has a standard.

The same document adds a second limit that matters operationally. It "does not propose any authorization policy" for what should happen based on a valid signature, an invalid one, or a missing one. The signature is evidence. What anyone does with it is somebody else's decision.

The designers said so first

The clearest statement of the limit is in the 2014 problem statement, several years before the standard shipped:

"Secure origin identification should prevent impersonation and, to a lesser extent, anonymization. However, if numbers are easy and cheap to obtain, and if the organizations assigning identifiers cannot or will not establish the true corporate or individual identity of the entity requesting such identifiers, robocallers will still be able to switch between many different identities."

That is not a criticism of the work. It is the people doing the work stating the boundary of what it can achieve, in the document that defined the problem.

So the standard advice is correct, and the reason is architectural rather than a matter of anyone failing. Caller ID authentication authenticates a number. Your question is about a person.

Where the number came from

The reconnaissance tactic on T1598.004 is not decorative. Somebody assembled a list before anybody dialled it, and the Canadian Centre for Cyber Security publishes the four ways that happens.

• Dumpster diving "involves retrieving discarded documents or lists of phone numbers".
• War dialling "uses automated systems to call a range of phone numbers within a specific area code".
• Internet searches "gather information from publicly available online sources, such as social media".
• Data breaches "expose phone numbers, contact lists and personal or organizational information".

Its guidance was revised on 21 July 2026, one month before this article, which makes it the freshest source in the entire result set, and it sits seventh on one engine and nowhere on the other.

The same page contains the whole of what this article will say about synthetic voice: "Threat actors use artificial intelligence (AI) technology and short audio samples to create a simulation of a person's voice." That is a government's plain statement of a capability. It is not a reason to describe how it is done.

The only control anyone publishes

For both techniques, ATT&CK lists exactly one mitigation. Not one that is best, one in total: M1017 User Training, described as training users "to identify and report social engineering techniques and spearphishing attempts, while also being suspicious of and verifying the identify of callers." The typo in that last phrase is MITRE's, quoted as printed.

The Canadian guidance adds the organisational half: "Train staff and set clear phone-based verification processes. Educate employees on vishing tactics and how to respond."

Put those together and the picture is uncomfortable but consistent. For a vector one IR provider measured as its second-most-commonly observed way in, the published control surface is procedural. That is not the framework being lazy. It is the framework being accurate about where the decision actually gets made, which is in a conversation, by a person, under time pressure.

Which turns the reader's next step into a question with a definite answer:

• Does the help desk have a written procedure for verifying a caller who asks for a credential or MFA reset?
• Does it specify what counts as verification, rather than leaving it to judgement?
• Does it survive a caller who sounds senior, sounds rushed, and says the usual channel is broken?
• Is anyone allowed to say no, and does the procedure say so out loud?

Those four questions cost nothing to ask and are the whole of what this evidence supports.

What this page cannot tell you

No count of vishing calls was located for this article. The available volume figures measure robocalls, a much larger category, and are published by firms selling blocking services.

No independent measurement of whether caller ID authentication reduced this attack was located. The specifications describe what the mechanism authenticates, which is a different thing from an effect. This article makes no claim in either direction.

There is no origin story here, because no coinage date could be sourced. The encyclopedia entry that ranks first for this term has a Terminology section that contains none either. Rather than attribute a date to a vendor blog, this page carries no coinage beat at all.

The 11% is one provider's caseload, from investigated intrusions where the entry point could be determined.

And the US regulator's own pages returned HTTP 403 to automated retrieval, the fourth such page in this cluster. The caller ID section above is therefore built directly on the IETF documents rather than on a regulator's summary of them, which is the stronger source in any case, and the pages that could not be read are not linked.

The short version

Vishing is phishing over a phone call, and the framework has two objects for it: T1566.004 when the caller wants access, T1598.004 when the caller wants information. Same call, different goal.

One incident response provider measured it at 11% of the initial infection vectors it observed in 2025, second-most-commonly observed among them and ahead of email phishing at 6%. And in the documented cases, the caller frequently rings the help desk rather than the victim and impersonates internal IT rather than a bank.

Caller ID authentication is real, it works, and it authenticates a number rather than a person. The people who designed it published that limit in 2014.

The one thing worth doing after reading this: find out what your help desk's phone verification procedure says, and whether it survives someone who sounds senior and in a hurry. If the answer is that there is no written procedure, that is the finding, and it is a cheaper problem to fix than most.