Recognizing Phishing: Email, SMS & Voice
Security Basics for Support Technicians
Chapter 2 · Recognizing Phishing: Email, SMS & Voice
Phishing is the most common way an attacker reaches a support technician directly, and it now comes through three genuinely different channels — email, text message, and phone calls — each with its own specific tells. This chapter builds the concrete pattern-recognition Chapter 1's tip-box promised: manufactured urgency is the constant across all three, but the surface details differ enough that each channel deserves its own look.
Email Phishing
The classic channel, and still the most common. The red flags rarely show up one at a time — a genuine phishing email usually stacks several at once:
- Sender domain mismatch — a display name that looks legitimate ("IT Support Desk") hiding a domain that isn't
- Urgency and consequence — "within 24 hours," "your account will be suspended," "immediate action required"
- A generic greeting — "Dear User" instead of an actual name, since bulk phishing rarely has one
- A link whose visible text doesn't match its real destination — the single most reliable technical tell, and the easiest to check
The display text of that link reads exactly like the real password-reset page — that's deliberate. The actual destination, visible by hovering over the link (or reading its raw HTML source, as above) rather than clicking it, is a completely different domain. This gap between what a link says and where it actually goes is worth checking on every single link in a message that asks you to log in or reset anything.
SMS Phishing ("Smishing")
The same manipulation, compressed into a text message. Smishing relies on the format itself working in the attacker's favor — a text message has no visible "From" domain to inspect, sender IDs are trivially spoofed, and shortened links (bit.ly/..., t.co/...) hide their real destination by design, not just by accident.
- "Your package couldn't be delivered — confirm your address: [link]"
- "Unusual sign-in detected. Verify your identity now or your account will be locked: [link]"
- A sender ID that looks like a short internal extension or an official-looking company name, spoofable with no special tools
Voice Phishing ("Vishing")
The channel most likely to reach a support technician directly, and the hardest to fake-detect on instinct alone, because caller ID can be spoofed just as easily as an email's display name. A vishing call typically impersonates IT, a vendor, or an executive, and leans even harder on urgency than email or SMS, since a live conversation gives the caller room to keep pushing past hesitation in real time.
The specific attack worth knowing by name is the one-time-code relay: the caller triggers a genuine password reset or MFA challenge on the real account first, then calls claiming to be verifying your identity, and asks you to "read back the code we just sent you to confirm it's really you."
Red Flags That Appear Across All Three Channels
| Signal | Why it works on the attacker's side |
|---|---|
| Manufactured urgency | Pressures you to act before you'd normally stop to verify |
| A request for credentials or a one-time code | No legitimate process ever needs these read back or forwarded |
| Branding that's almost, but not quite, right | Close enough to pass a glance, wrong enough to be checkable if you look |
| Pressure to skip your normal verification step | Directly targets the one safeguard that would otherwise catch the attempt |
That last row connects directly back to Chapter 1's own framing: the request that asks you to skip verification "just this once, because it's urgent" isn't an edge case this course has to imagine — it's the single most common shape a real attack actually takes.
Hands-On Exercises
Using the email example in this chapter, explain specifically why the link's visible text being different from its actual destination is described as "the single most reliable technical tell."
📄 View solutionExplain why the one-time-code relay attack tricks the victim into believing they're confirming their own identity, when they're actually doing the opposite.
📄 View solutionExplain why a shortened link in an unsolicited text message is treated as unverifiable by default, rather than just "worth a second look" the way a full URL in an email is.
📄 View solutionChapter 2 Quick Reference
- Email: check sender domain (not just display name) and the real destination of every link, not its visible text
- SMS: spoofable sender IDs, shortened links hide their destination by design — treat as unverifiable by default
- Voice: caller ID is spoofable; never read back a one-time code to anyone who calls asking for it — that code proves access, it doesn't prove identity
- Shared thread across all three: manufactured urgency, requests for credentials/codes, near-right branding, pressure to skip normal verification
- Report suspicious messages through your organization's own channel rather than only deleting them
- Next: Chapter 3, social engineering tactics that don't rely on a suspicious link or call at all