Pretexting is a social engineering technique where an attacker invents a believable scenario, the pretext, to justify asking for information, access or money. While phishing often relies on a malicious link, pretexting relies on a story: the "CEO" who needs a payment approved before a deadline, the "supplier" with new bank details, the "IT technician" who needs a verification code.
Key facts:
- Pretexting is the engine of business email compromise: the fraudulent instruction only works because the invented context makes it plausible.
- Pretexts increasingly arrive without any malicious link or attachment, which is why they pass filters that only scan for known-bad content.
- Generative AI has removed the effort barrier: researched, fluent, individually tailored pretexts can now be produced automatically.
Anatomy of a pretext
Effective pretexts combine four elements: a character (an authority the target expects to obey or help, like an executive, vendor or IT staff), plausible context (real project names, org charts and vendor relationships, harvested from LinkedIn, websites and breached data), urgency or confidentiality ("the acquisition is not public yet, keep this between us"), and a reasonable ask that grows once trust is established. The first message often asks for nothing at all ("Are you at your desk?"), which is exactly why it evades content filters.
Common pretexting scenarios in email
Modern variants extend the story across channels: an email followed by an SMS, or a deepfake voice call "from the CFO" that confirms the fraudulent email. The pretext is the constant; the channel varies.
Why pretexting beats traditional filters
Legacy email security looks for malicious payloads: bad links, infected attachments, known spam patterns. A well-built pretext contains none of that. It is a clean, well-written message from a plausible-looking sender, sometimes from a genuinely compromised vendor mailbox where every technical signal is legitimate. Detection therefore has to evaluate behavior and intent: Is this sender's address subtly different (see spoofing)? Does this request deviate from how this relationship normally communicates? Is a payment instruction appearing in a thread where none ever appeared before?
How to defend
Verification procedures beat vigilance: any request involving money, credentials or sensitive data gets confirmed through a second, known channel, no matter how legitimate it looks. Limit what attackers can research by tightening what employee and vendor details are public. Train teams on the psychology (authority, urgency, confidentiality) rather than on spotting bad grammar, which AI-written pretexts no longer have. And deploy email security that models relationships and intent rather than payloads. Targeted variants like spear phishing and broader social engineering techniques all rely on the same pretext mechanics.
How Sentaro detects pretexting
Sentaro's Behavioral and Message Defense vectors learn how each organization actually communicates: who requests payments, in which threads, with what language and cadence. A pretext succeeds by imitating authority, but it cannot imitate history. When an instruction deviates from the learned relationship, a lookalike domain appears, or an intent shift occurs mid-thread, Sentaro flags or blocks it, link or no link.