The scenario
A receptionist at a Rotterdam law firm gets an email from the managing partner: 'Hi — quick favour, I'm in client meetings all morning. Can you grab me five €50 Bol.com vouchers and send the codes? It's for a team birthday surprise, please don't tell anyone. I'll reimburse you this afternoon.' The signature line matches the partner's normal sign-off. The email address looks right at a glance. The pretext is plausible — vouchers are a normal team-gift category. But four red flags are present: the request asks for an unusual action (vouchers, not normal work), there is urgency ('this morning'), there is a channel mismatch (partner usually walks over for personal favours, doesn't email finance), and the secrecy ask ('don't tell anyone') is the credibility prop that doesn't hold up — real surprise-gifts use the office assistant, not the front-desk receptionist. The receptionist walks across the office to the partner's desk. The partner has no idea what she is talking about. The lure is forwarded to IT — who report 14 other firms in the same building received variants the same morning.
How the attack works
Almost every phishing variant — email, SMS, voice, QR, chat, deepfake video — shares the same four-element structure. **Red flag 1: a request for action.** The lure asks you to DO something — click, pay, transfer, sign in, read aloud, install. Pure information emails ('your invoice is ready, log in via the app') are usually safer than action-demanding emails. **Red flag 2: urgency or pressure.** Time pressure ('before close of business', 'expires in 24 hours'), authority pressure ('your manager wants this'), or consequence pressure ('your account will be closed') is engineered to short-circuit thinking. **Red flag 3: a channel mismatch.** The request arrives via a channel the legitimate sender doesn't normally use, or asks you to switch to a new channel ('don't reply to email, just call this new number'). Real organisations stay in their normal channels. **Red flag 4: a credibility prop that doesn't quite hold up.** A look-alike sender domain, slightly wrong tone of voice, a missing or odd signature, weird grammar, or pretextual details that contradict each other ('grab the vouchers, don't tell anyone'). The phisher has to put SOMETHING credible in front of you — but they can rarely make the entire context perfect. The combination of one or two red flags should already raise suspicion; three or four is the lure itself. The other modules in this Foundations track and the full Phishing track go deeper on each variant; this lesson is the universal pattern.
What to watch for
- Requests for action — clicks, payments, transfers, sign-ins, OTPs, software installs, document approvals
- Urgency framing — deadlines, audit pressure, authority pressure, fear of consequence
- Channel mismatch — sender using a different channel than they normally would, or pushing you to switch channels
- Credibility props that don't quite hold up — domain mismatch, tone mismatch, missing details, contradictory context
- ANY communication asking you to bypass your normal workflow ('skip the approval', 'don't loop in finance', 'I'll explain later')
What to do
- Use the four-red-flags test on any suspicious messageIf two or more are present, treat as phishing until verified. Three or more = the lure itself.
- Verify out-of-band — on a channel the sender already uses with youWalk over, call them on a number you have in your records, or DM them on a platform you know they use. Never call a number from the suspicious message.
- Report — use your mail client's 'Report Phishing' button or forward to security with full headersReporting is free, fast, and identifies attacks targeting your colleagues simultaneously.
- Never act on urgency before verifying — the urgency is the trapReal urgent requests survive a 2-minute verification call. Phishing ones don't.
Defenses to deploy
Technical controls
- DMARC enforcement on your domain (stops easy spoofing)
- Phishing-resistant MFA (FIDO2/passkeys) — defeats credential-stealing phishing kits even if a click happens
- Email gateway with link rewriting + attachment detonation
Policy controls
- Written 'IT will never ask you to read aloud OTPs or click MFA-reset links from email or SMS' rule, reinforced quarterly
- Two-person rule on payment-instruction changes
- Reporting button on every mail client, no-blame culture
Training cadence
Pair this with monthly simulated phishing. Measure reporting rate first, click rate second.
Quick check
Five questions. Answers and rationale appear after submission.
- Q1.
Which of these is NOT one of the four universal phishing red flags?
- Q2.
Two of the four red flags appear in a message. What is your correct response?
- Q3.
A coworker DMs you a link in Slack asking you to 'log in to the new IT portal'. The DM was unsolicited and the link domain is unfamiliar. Most likely:
- Q4.
Which type of verification is genuinely safe?
- Q5.
Is urgency by itself enough to flag a message as phishing?
Sources & further reading
- NCSC-NL — Phishing herkennen[primary]
- ENISA — Phishing threat landscape[primary]
- MITRE ATT&CK — T1566 Phishing[primary]
- Krebs on Security — Phishing case studies[secondary]