Pretexting: How Attackers Build a Believable Story to Get What They Want

Pretexting is inventing a scenario — a role, a reason, a context — that makes a request seem legitimate. It is the foundation underneath most social engineering rather than a separate technique. A phishing email works because it comes with a pretext; remove the story and it is just a link nobody clicks.

What makes a pretext work

The lever is specificity. Anyone can claim to be from IT. Someone who names your actual ticketing system, your actual IT manager, and the actual maintenance window scheduled for this weekend is not obviously lying, and checking would feel insulting.

That detail comes from reconnaissance. Staff directories, job postings, press releases, social media, conference talks, and document metadata supply names, titles, reporting lines, vendor relationships, and technology in use. The material is public and individually harmless; assembled, it is a script.

Authority does most of the remaining work. A request that appears to come from an executive, an auditor, a regulator, or law enforcement carries built-in pressure to comply and to not ask questions. Urgency removes the time in which someone might verify — the deadline, the system going down, the executive boarding a flight. Where authority would be questioned, attackers use the opposite: a new employee who is a little lost and apologetic invites help rather than scrutiny.

Once someone has agreed to something small, consistency pressure makes the next request easier. Attackers escalate deliberately rather than asking for everything at once.

Where it shows up

The helpdesk password reset is the classic. The caller is a traveling employee locked out before a meeting, and the verification questions — employee ID, manager's name, office location — are answerable from public sources. The reset is granted because the story is plausible and the person sounds stressed.

Vendor and supplier impersonation targets finance. A supposed representative of a real supplier reports a change of banking details for the next invoice, and the invoice is real, which is the part that makes it work.

Business email compromise combines a compromised or lookalike mailbox with an executive pretext and an urgent wire transfer. IT support callbacks, physical entry as a delivery courier or contractor, and recruiter approaches that harvest details about internal systems all follow the same pattern. Over the phone the technique is vishing; in person it is impersonation and tailgating; in writing it is phishing. The pretext is the constant.

Controls that actually work

Training helps, but process is what holds under pressure, because a well-built pretext is specifically designed to defeat judgment in the moment.

Build out-of-band verification into the procedures that matter. Any change to payment details, any privileged access grant, any password reset for a sensitive account gets verified by calling back on a number from your own directory — never a number supplied in the request. Require dual authorization for financial changes above a threshold so no single person can be talked into it alone.

Give the helpdesk identity verification that does not rely on public information: a one-time code sent to a device already enrolled for the account, or callback to the number on file. Replace security questions whose answers appear on a resume.

State explicitly, in writing, that verification is expected and never penalized. Most successful pretexts exploit an employee's fear of being unhelpful to someone senior, and only leadership saying otherwise removes that fear. Reduce the raw material too by publishing less detail about staff and systems, and give people a low-friction way to report a suspicious contact so the second target gets a warning — reports that feed a SOAR workflow can trigger a broad alert within minutes.

Exam angles

Define pretexting as creating a fabricated scenario to justify a request, and recognize it as the underlying mechanism in vishing, impersonation, and business email compromise rather than a competing category. Know authority, urgency, trust, and consistency as the levers. When a scenario describes a caller who knows internal details requesting a password reset or a banking change, the expected answer is out-of-band verification through an independently obtained contact method, not additional technical controls — because no technical control fires when an authorized person is persuaded to act.