Social Engineering Beyond Phishing: Pretexting, Impersonation & Baiting

Security Basics for Support Technicians

Chapter 3 · Social Engineering Beyond Phishing: Pretexting, Impersonation & Baiting

Chapter 2 covered phishing's three channels — but every one of them relied on a message: an email, a text, a call. This chapter covers the tactics that don't need a message at all — a fabricated backstory, a face pretending to be someone it isn't, or a lure left somewhere it's likely to be found. None of these show up in a typical "spot the phishing email" training, which is exactly why they're worth their own chapter.

Pretexting: The Fabricated Backstory

Pretexting is an invented scenario, built specifically to make a request feel routine and legitimate before the actual ask arrives. The backstory does the persuading; the request itself is often small enough to seem reasonable on its own.

Example: a caller identifies themselves as the manager of a new hire starting Monday, explains the new hire's laptop hasn't arrived yet, and asks for "just a temporary login" so the new hire can start onboarding paperwork from a personal device today. Every individual detail — a manager, a new hire, a shipping delay — is plausible in isolation. The backstory's job is to make the actual request (creating access outside the normal process) feel like a minor administrative favor rather than what it actually is.

Impersonation: Claiming to Be Someone Specific

Where pretexting invents a scenario, impersonation claims a specific identity — a named coworker, a known vendor contact, an executive, or even IT itself calling about IT's own systems. The more specific and verifiable-sounding the claimed identity, the more it discourages a target from questioning it.

  • Executive impersonation — a request that name-drops urgency and authority together ("this is [CFO name], I need this handled before my flight")
  • Vendor impersonation — someone claiming to represent a company you already do business with, asking for account details "to process a routine update"
  • IT impersonation — perhaps the most direct threat to a support technician specifically, since it targets the exact trust relationship coworkers have with the support desk itself
  • Physical impersonation (tailgating) — wearing a delivery uniform, a contractor badge, or simply carrying a box and walking confidently through a badge-locked door behind someone who holds it open

That last one is a preview of Chapter 9's own physical-security material — worth flagging here because it's a form of impersonation, not a separate category of threat.

Baiting: The Enticing Lure

Baiting offers something the target wants — curiosity, a free item, an exclusive download — with a malicious payload attached to the offer. The classic version is physical: a USB drive labeled Payroll_2026_Confidential.xlsx left in a car park, breakroom, or elevator, counting on someone's curiosity to plug it into a work machine. The digital version is the same idea online — a "free" tool, plugin, or download that quietly installs something unwanted alongside it.

A found USB drive is not a lost-and-found item
Never plug an unknown USB device into any work machine to "see who it belongs to." That instinct is precisely the mechanism the attack is built to exploit — hand it to your security or IT team unopened instead.

Quid Pro Quo: Something for Something

A close cousin of baiting, framed as an even trade rather than a free gift. An attacker calls around an organization claiming to be IT support offering a "free security upgrade," and asks whoever picks up to run a specific command or temporarily disable a specific protection in exchange. Most employees who answer won't take the offer — but the attacker only needs one who does.

Comparing the Four Tactics

TacticCore mechanismWhat makes it work
PretextingAn invented backstory precedes the actual requestThe request feels routine by the time it arrives
ImpersonationClaiming a specific, real identity or roleDiscourages the target from questioning someone they think they know
BaitingAn enticing lure carries the payloadCuriosity or self-interest overrides caution
Quid pro quoAn offer framed as a fair tradeFeels reciprocal rather than one-sided, lowering suspicion

A Request That's Left Open Again

A call comes in: "This is Facilities — we've got a delivery emergency and need the loading dock badge reader temporarily disabled for the next twenty minutes." It's a blend of pretexting (the delivery-emergency backstory) and impersonation (claiming to be Facilities). Whether it's legitimate or not can't be determined from the call alone — and that's exactly the point.

The rule this chapter is building toward
If you can't verify a claim through a channel the caller themselves doesn't control — calling Facilities back at a known internal number, rather than trusting whatever number they called from — you can't verify it at all. Chapter 4 covers exactly what that kind of independent verification looks like in practice.

Hands-On Exercises

Exercise 1

Using the new-hire example, explain what job the fabricated backstory is doing, separate from the actual request being made.

📄 View solution
Exercise 2

Explain why IT impersonation is described as "perhaps the most direct threat to a support technician specifically," using this chapter's own reasoning about trust.

📄 View solution
Exercise 3

Explain why calling a claimed caller back at a known internal number is a meaningfully different verification step than trusting the number they called from, and why this chapter says a claim can't be verified any other way.

📄 View solution

Chapter 3 Quick Reference

  • Pretexting: a fabricated backstory makes the real request feel routine
  • Impersonation: claiming a specific real identity, including physical tailgating through a badge-locked door
  • Baiting: an enticing lure (a found USB drive, a "free" download) carries the payload
  • Quid pro quo: a request framed as a fair trade, not a one-sided ask
  • None of these four rely on a suspicious link, text, or call asking for a code — phishing training alone doesn't cover them
  • A claim can only be verified through a channel the claimant doesn't control — never the contact info they themselves provided
  • Next: Chapter 4, verifying identity before acting on a request