Table of Contents
We tested more than 1,000 IVR systems. Nearly half leaked enough intelligence to compromise a help desk in under 20 minutes.
These figures come from GhostEye adversary simulations against more than 1,000 IVR systems and the follow-on help desk calls that used what those systems disclosed.
What We Found
Forty-nine percent of the IVRs we tested disclosed enough information to build a working help desk pretext. The leak was usually the same kind of material: valid IDs, department names, routing logic, verification prompts, and the language internal teams use for their own systems.
When we turned that recon into a help desk call, our success rate was 34 percent. One in three attempts ended in a credential reset, an MFA enrollment change, or account access. When the target enforced callback verification, that number collapsed.
If the phone system can validate people, expose org structure, and preview the help desk's questions, it belongs inside the security boundary.
What 19 Minutes Looks Like
What the IVR gives up
We call the main line. The IVR answers: press 1 for billing, 2 for technical support, 3 for HR, 4 for the company directory. We press 3. The system asks for an employee ID. We enter a random six-digit number. It responds, "That employee ID is not recognized. Please try again." We enter another number. This time the system says, "Please hold while we transfer you to HR." That is a validity oracle. In three minutes, we know how to confirm whether an employee ID is real.
We go back and press 4. The company directory accepts partial name lookups. We enter common last names. For each match, the system reads back the full name, department, and extension. Now we have real employees, real departments, and real routing language. Elapsed time: nine minutes.
Next we try billing. The prompt asks for an account number, then reads back account status and the name associated with it. The IVR just linked identities to active accounts. Then we try technical support. It asks for an employee ID followed by the pound sign before transfer. We enter one of the valid IDs from earlier. The system replies, "Thank you, [first name]. Connecting you to technical support." The IVR just confirmed the first name tied to that identifier. By minute 16, we have valid IDs, names, departments, internal terminology, and the exact verification path the help desk is likely to follow.
The help desk call
We call back and route to support. "Hi, this is [name] in [department]. I am locked out and I need an MFA reset." The agent asks for the employee ID. We have it. They ask for the department. We have it. They ask for the name on the account. The IVR already told us. Reset completed. Elapsed time: 19 minutes.
No social media stalking. No phishing email. No credential stuffing. The organization's own phone system provided the material that made the pretext work.
That is the point. Before a human ever answered, the caller already had most of what the reset depended on.
Why Nothing Caught It
Ask your SOC a simple question: can it see IVR auth failures, menu sweeps, or repeated short reconnaissance calls? Usually not.
Most call volume never reaches a human. It stays in self-service menus, transfers, and authentication prompts, which is exactly where the recon happens. The signals are there too: repeated failed inputs, rapid menu traversal, and short reconnaissance calls from rotating numbers. They just rarely land in the systems the security team already watches.
This is mostly an ownership problem. Endpoints belong to security. Email belongs to security. The phone system usually belongs to telecom or the contact center, so the attacker gets a quieter place to work.
The Defenses That Failed
Voice biometrics collapsed
The market already answered the voice-biometrics question. In 2025, Amazon stepped back from new Voice ID customers, Microsoft retired Azure AI Speaker Recognition, and Google removed public Speaker ID material. That is not a coincidence.
Voice cloning got good enough, cheap enough, and fast enough to break the old trust model. A few seconds of clean audio can now produce synthetic speech that is convincing enough for real-world abuse. The problem is not just model quality. It is that the defender expects a phone agent to make a trust decision in real time.
That matters because the IVR recon we covered in The Recon Nobody's Testing For can now be automated end to end. Phone agents are asked to move fast, trust the voice, and clear the queue. That is exactly why synthetic audio works here.
STIR/SHAKEN does not solve the problem
STIR/SHAKEN improves caller-ID assurance. It does not solve caller trust.
It raises the cost of some caller ID spoofing scenarios, but it did not stop targeted vishing. STIR/SHAKEN verifies whether the displayed number is legitimately associated with the originating call on participating IP paths. It does not verify that the person speaking is who they claim to be. It does not verify intent. It does not tell you whether the voice on the line is synthetic. An attacker who provisions a real VoIP line and routes calls through it can still present a clean-looking number.
The Insurance Problem
Many teams assume a phone-led compromise will be treated like any other cyber event. Social engineering loss often sits behind endorsements, carve-outs, or voluntary-parting language. The point is not that every carrier denies these claims. It is that phone-led loss can sit in a weaker coverage position than a more conventional breach, which turns the control gap into a finance problem fast.
What Actually Stops It
Step 1: Test what is actually exposed
Start with what the system actually exposes. Most organizations have never run an adversary simulation against the voice channel, which means they are arguing about controls before they have a map.
A vague finding like "the help desk is vulnerable to social engineering" does not change anything. A concrete finding like "the HR menu confirms valid employee IDs and the billing flow reads account names back to callers" does. The fixes are usually straightforward: normalize error messages, strip unnecessary department labels from menus, and remove verification steps the IVR already gives away. Then test again when the phone tree changes.
Step 2: Detect reconnaissance at the IVR
Do not wait for the help desk call. By then the attacker has already collected most of what they came for.
Watch for repeated failed inputs, menu sweeps, short reconnaissance calls, and clustered source numbers. Those are the phone-system version of enumeration traffic.
Synthetic-voice detection can help, but the bigger win is basic visibility. If you only see the attack when an agent answers, you are already late.
Step 3: Fix the verification model
The fix is simple: stop treating recited facts as identity. Employee ID, department, manager name, date of birth, and the last four digits of a social security number are all harvestable through OSINT and IVR enumeration.
The controls that hold up in testing move away from knowledge and toward possession, pre-registration, and out-of-band validation:
- Callback to a pre-registered number. The agent hangs up and calls back on a number that is already on file. It is simple, durable, and hard to defeat without SIM swapping.
- Push-based verification to a registered device. The caller has to approve the request from a device that is already enrolled instead of attaching a new factor during the call.
- Stronger identity proofing for high-risk actions. MFA resets, credential changes, and privileged access requests need more than an oral Q&A. The more consequential the action, the less you can rely on data the caller recites back to you.
When callback verification is in place, our success rate drops from 34 percent to near-zero. That is the difference between a control that sounds reasonable and a control that actually holds under test.
Start With The Free Leaks
This does not start as a giant platform conversation. Start with the free leaks: rate limiting, normalized error handling, input validation, and an audit for undocumented admin paths. That closes a surprising amount of exposure.
You do not need the entire voice-security market on day one. First close the free leaks. Then decide how much IVR-level analytics and fraud detection you actually need.
Closing the Gap
More than 1,000 IVR systems. Forty-nine percent leaked enough to compromise a help desk. Nineteen minutes to collect the material. A 34 percent success rate when the follow-up call is made. Near-zero when callback verification is enforced.
Web gets tested. Email gets tested. The phone system usually does not. If your IVR can confirm identities, expose org structure, and preview the help desk's verification flow, then it already belongs inside your perimeter whether the security program calls it that or not.
Part three of the "Before the Call" series. Read first: The Recon Nobody's Testing For and From Dial Tone to Domain Admin.
