Callback phishing (TOAD): the email that asks you to call

Callback phishing, also called TOAD (telephone-oriented attack delivery), is a scam that starts with an email that carries no links and no attachments: only an alarming message and a phone number the victim is supposed to call. When they dial, no real support desk answers; on the line is the attacker, who walks them by voice until they install a remote access tool, hand over a password, or approve a payment.

What callback phishing (TOAD) is in one sentence

In one sentence: it is phishing that is completed by phone, not by a click. The email is only the bait that gets the person to call; the fraud happens later, on the call. The technical term, TOAD (telephone-oriented attack delivery), names exactly that two-stage design, email first and voice second, and describes a technique that is growing fast in 2026 because it sidesteps almost everything a company has in place to stop classic phishing. It is also known as callback phishing, and its hook is not a disguised link but an emotion: a charge you do not recognize, an expensive subscription about to renew, an account supposedly compromised.

Why the email has no link and no attachment (and how it evades the filter)

The callback phishing email carries no link and no attachment for a very specific reason: that is what makes it nearly invisible to filters. Most email defenses inspect URLs and files looking for something malicious, and a plain-text message with a logo and a phone number has nothing to flag. There is no suspicious domain to block and no attachment to detonate in a sandbox. That is why many of these emails land straight in the inbox, looking like an invoice or a renewal notice.

And they still come in through the same door as almost everything else. According to CISA, more than 90 percent of successful cyberattacks begin with a phishing email, and callback phishing is no exception: it changes the bait, not the door. The attacker gives up the link, which is what filters know how to catch, in exchange for something no email gateway can intercept, which is a phone conversation.

What the call script looks like: from the victim who dials to the fraud

What makes callback phishing dangerous is that the victim calls of their own accord, convinced they are solving a problem. That detail changes the whole dynamic: it is no longer a stranger reaching out, it is the victim who is looking for help, and they arrive at the call ready to cooperate. The attacker knows this and builds a script that plays on that willingness.

The call tends to follow a pattern. First, whoever answers introduces themselves as billing, technical support, or the fraud team of a well-known brand, and confirms the detail the email already planted: yes, there is a charge, yes, the account is at risk. Then they create urgency: to cancel the charge or protect the account, you have to act now.

And finally they ask for the step that completes the fraud, which is almost always one of three: install a remote access tool to help fix it, read out a code or a password, or move money to a safe account. In some cases those credentials end up feeding a business email compromise (BEC), when the attacker uses the victim's real inbox to deceive others.

How it differs from vishing against the help desk

Here it helps to separate two things that get confused. Vishing is voice fraud, and its best-known form is the opposite of this one: the attacker calls, often posing as an employee, to trick the help desk into resetting an access (we cover it in detail in vishing: the phone fraud that targets your help desk). Callback phishing flips the direction: the attacker does not call, the victim calls, and does so because an email pushed them to.

That reversal matters for two reasons. The first is detection: an email with no link slips past filters, so the first line of technical defense sees nothing. The second is psychological: whoever dials the number believes they took the initiative, lowers their guard, and enters the call ready to follow instructions. Traditional vishing has to overcome the distrust of an unsolicited call; callback phishing skips that work, because the email already disarmed the distrust.

What your team can do when the email asks you to call

The most useful practical rule is easy to state and hard to hold under pressure: an email that creates urgency and asks you to call a number to resolve something about money or access deserves distrust, not a call. The number in the email is never the channel to use. If there really is a charge or an alert, you verify it through the company's official channel (the app, the site you already know, the phone number printed on your card), never through the one that arrived in the message.

For the security team, there are three concrete fronts. One, name the pattern, because people resist better what they can recognize, and "an email that only gives you a number to call" is easy to remember. Two, provide a frictionless way to report, so an employee in doubt forwards the email instead of calling. And three, understand that this is one more vector within a surface that has widened: social engineering no longer arrives only by link, but by phone, by SMS, and by QR code, a map we lay out in types of social engineering by attack channel. Recognizing the whole family helps you avoid defending only against yesterday's attack.

How to validate that behavior changed, not just that people saw the notice

Here is the underlying problem, and it is not unique to callback phishing. Warning people that a threat exists is not the same as getting them to behave differently when they face it. Cisco's 90-5-5 framework estimates that close to 90 percent of breaches involve a human factor, so preparing people is where the real leverage sits; but preparing them is not enough if no one checks that the preparation worked.

The peer-reviewed evidence is clear on this. Studies from the IEEE Symposium on Security and Privacy (Ho et al., 2025; Lain et al., 2022) show that completing training does not, on its own, predict that real failures will drop. Put another way: someone having seen the notice, or even passed a course, does not prove they will hang up on the next suspicious call.

The only thing that proves it is testing them again. That is what the retest is for: weeks after the first test, an equivalent simulation is sent, of the same type but with a different context, to see whether the person learned the lesson or only remembered one specific email. Validating behavior, and not attendance, is what separates a human risk management (HRM) program that truly reduces risk from one that only produces reassuring reports.

At Fensivo we work on exactly that layer: how people behave under real pressure, not their grade on a course. Because callback phishing enters through email, our personalized phishing simulations prepare each employee at the point where the attack begins, and whoever falls receives, within minutes, brief training specific to the trick. What closes the loop is the retest, which tests behavior again weeks later to confirm the change holds. If you want to see how this applies to concrete situations, you can review our use cases.

The uncomfortable question is this: if tomorrow one of your employees receives an email that carries only a number and an alarm, do you know whether they would make the call, and do you have a way to check before a real attacker does it for you?

Sources and references

CISA, "4 Things You Can Do To Keep Yourself Cyber Safe". https://www.cisa.gov/news-events/news/4-things-you-can-do-keep-yourself-cyber-safe

Cisco, "The 90-5-5 Concept: Your Key to Solving Human Risk in Cybersecurity", May 27, 2025. https://blogs.cisco.com/security/the-90-5-5-concept-your-key-to-solving-human-risk-in-cybersecurity

Ho, G. et al., "Understanding the Efficacy of Phishing Training in Practice", 2025 IEEE Symposium on Security and Privacy. https://ieeexplore.ieee.org/document/11023357

Lain, D., Kostiainen, K. and Čapkun, S., "Phishing in Organizations: Findings from a Large-Scale and Long-Term Study", 2022 IEEE Symposium on Security and Privacy. https://ieeexplore.ieee.org/document/9833766