Every practitioner has a threat they lose sleep over. It usually is not the one with the highest CVSS score. For us it is a phone call that lasts ninety seconds, comes from a number that looks internal, and asks a user to do something entirely reasonable.

Spear vishing, targeted voice phishing aimed at a named individual, is not new. What changed is the economics. Cloning a voice used to require a cooperative sample, a specialist, and time. Now a few seconds of public audio produces a usable clone, and a conversational voice agent can hold the call live, handle interruptions, respond to pushback, and stay in character for as long as the target stays on the line. The pretext that used to cost an adversary a day of preparation now costs minutes, which means it is no longer reserved for the highest-value targets. It scales.

And the pretext that scales best is IT support.

We are not writing this from threat reporting. We build and run this exact sequence against enterprise organizations as a paid engagement, and it is the one that most reliably ends in a room going quiet. Mature security programs. High training completion rates. Well-run help desks staffed by people who are good at their jobs. The call still works, and what it hands us in a controlled simulation is the same thing it would hand an adversary who was not obligated to give it back.

That is the part worth sitting with. The consequences are not theoretical and they are not proportional to how sophisticated the organization is. They are proportional to whether a single procedure existed at the moment the phone rang.

Why IT Support Is the Pretext That Works

Most social engineering has to manufacture a reason to ask for something. A vendor payment change needs a plausible invoice. An executive request needs urgency and a reason the executive cannot be reached. The help desk pretext needs none of that, because the ask is the job.

When someone from IT calls and says they need you to authenticate, approve a prompt, or join a quick remote session, nothing about that request is anomalous. It is the expected behavior of that role. Your users have been conditioned by years of legitimate support interactions to comply with exactly this sequence.

There is a second inversion that makes it worse. In most social engineering, the target believes they are giving something away, so some part of their judgment engages. In a support pretext, the target believes they are receiving help. Suspicion never activates because from the user's side of the call, they are not the one being asked for a favor. They are the one being done one.

The same pretext runs in reverse, and this is the direction that has produced the most damaging intrusions in recent years. Instead of impersonating IT to an employee, the caller impersonates an employee to IT. A stressed help desk analyst, working a queue, gets a call from someone who knows their own manager's name, their office location, their device model, and the ticket they supposedly opened last week. They ask for a password reset or an MFA re-enrollment. Every piece of verifying knowledge the analyst asks for is knowledge the caller researched in advance.

How the Call Actually Runs

Below is the sequence as we observe and reproduce it. Nothing here requires exotic capability. It requires patience and a phone.

Why Detection Training Fails Against This

The instinct is to train people to spot the fake. It is the wrong control, and it fails in three specific ways.

It degrades over time by design. Every artifact you teach people to listen for, the flat prosody, the odd pause, the breath that is not there, is a defect in the current generation of synthesis. Those defects are being engineered out. A control whose effectiveness declines as the adversary improves is not a control, it is a countdown.

It puts the decision in the worst possible place. You are asking a person, under time pressure, on a call they did not initiate, to make a forensic media authenticity judgment they are untrained and unequipped to make. Even trained analysts get this wrong with tooling. Expecting it of a payroll clerk between meetings is not a security posture.

It produces false confidence. A user who has completed detection training and believes they can tell is more dangerous than one who knows they cannot. Certainty is what the pretext needs.

The Controls That Actually Hold

Everything below shares one property: it works whether or not the person on the phone sounds real.

• Out-of-band callback, always. The user ends the call and dials a number they look up themselves from the internal directory. Not a number provided during the call, not a number in the caller ID, not a callback link in a text.
• A standing negative rule. IT will never ask for a password, never ask you to read back an MFA code, and never ask you to approve a prompt you did not personally initiate. A rule with no exceptions is a rule a user can apply under pressure. A rule with exceptions is a rule an adversary can talk their way into.
• Ticket-first for privileged actions. No password reset, MFA re-enrollment, or remote session without a pre-existing ticket the user can independently see in the portal. This removes the analyst's judgment from the critical path.
• Help desk identity proofing that is not researchable. Manager name, office location, device model, and start date are all public or inferable. Proofing should use something the caller cannot look up, such as a callback to the number of record or verification through the manager on a separate channel.
• Reporting that costs less than compliance. If reporting a suspicious call takes six minutes and a form, and complying takes ninety seconds, you have already chosen the outcome. One button, one number, no judgment call required about whether it was "worth" reporting.
• Step-up controls on the actions themselves. Number matching, device-bound credentials, and additional verification on help desk-initiated resets shrink what a successful call can convert into.

None of these ask a user to be a detector. They ask a user to follow a procedure, which is a thing organizations already know how to build and measure.

Measure the Right Thing

Click rate is meaningless on a phone call, and its equivalents are not much better. If your vishing program reports "how many people answered," you have measured availability, not risk. These are the questions worth answering after a simulation.

The last two matter most. A user who felt something was wrong and hung up without reporting it is not a success. It is an adversary who gets to call the next person on the list with no one watching. And an internal trend line tells you whether you improved against yourself, which is a low bar when you do not know where you started relative to peers.

We wrote up a full IT support impersonation sequence, including how the pretext is built and where it breaks, in our remote support simulation breakdown.

What We Would Do First

If you have one week and no budget, do these three things in this order.

Publish the negative rule and say it in plain language everywhere your users look. IT will never ask for your password or your MFA code, and will never ask you to approve a prompt you did not start. Put it in the email signature block of every help desk analyst.

Audit your help desk reset procedure against a researched caller. Sit with an analyst, take the script they follow for a password reset, and ask of every verification question: could someone find this on LinkedIn, in a data broker record, or in a public filing? Whatever survives that test is your actual control. It is usually shorter than the script.

Then run the call. Not a survey, not a training module, an actual simulated sequence against a real population, measured on the action rate and the verification rate. You cannot fix what you have not measured, and the gap between what people say they would do and what they do on a live call is the entire problem.

Frequently Asked Questions