12 β Social Engineering and Phishing
Level: Beginner Β· Time: ~20 min Β· Prerequisites: Lesson 11 β Malware and Ransomware
Why this matters
Ask any incident responder what the most common first step of a breach is and the answer is the same: a person was persuaded to do something. Not a firewall bypassed, not a zero-day β a message that arrived at a moment when clicking made sense. This is why social engineering deserves its own lesson: no configuration change fixes it, because the "vulnerability" is a colleague's judgement under time pressure, and the "exploit" is a well-written email that looks exactly like the work they do all day. The defence is partly technical β email authentication genuinely helps β but mostly it is process and culture, and both are cheaper than a breach.
[!IMPORTANT] This lesson describes social engineering so you can recognise it in your own inbox and train others to do the same. Do not run simulated phishing campaigns against anyone without written authorisation from the organisation concerned.
The mental model: you are attacking judgement, not software
Every social engineering attack is a three-part story: a pretext (a plausible reason for the contact), a lever (an emotion or habit that makes acting feel urgent and normal), and an ask (a click, a password, a payment, a moment of door-holding). Remove any one of the three and the attack fails.
| Component | What the attacker needs | What breaks it |
|---|---|---|
| Pretext | a reason that fits your business β an invoice, a delivery, a policy update, an IT ticket | verification: does this request make sense from this sender, at this time, by this route? |
| Lever | urgency, authority, fear, helpfulness, or routine | a rule that says "verify before acting", regardless of how the request feels |
| Ask | one small action, usually one click or one reply | phishing-resistant MFA, payment procedures, device controls |
The important insight: the lever is chosen to fit your culture. An organisation that prides itself on fast customer service will receive an urgent customer problem. An organisation with a culture of never questioning the boss will receive a message from the boss. That is not a coincidence; it is reconnaissance.
[!TIP] The strongest single sentence for a staff briefing: the attacker does not need you to be foolish, only to be in a hurry. Most people who fall for phishing describe being busy, not being credulous.
The psychology, with one concrete example each
| Principle | How it is used | What it looks like in an email |
|---|---|---|
| Authority | compliance with a senior person's request feels obligatory | "Please handle this personally and do not discuss it with the team." |
| Urgency | time pressure suppresses verification | "Payment must clear before 16:00 today or the contract lapses." |
| Fear | a threat triggers action before thought | "Your mailbox is over quota and will be closed within two hours." |
| Curiosity | an unexplained artefact begs to be opened | "Salary review spreadsheet attached β check your row." |
| Reciprocity | an offered favour creates obligation | "I have sorted the refund for you; just confirm your card details." |
| Social proof | everyone else has already acted | "All staff have completed this β you and two others remain." |
| Helpfulness | people want to be useful, especially to customers | "I cannot access the portal from here, could you send me the statement?" |
| Routine | ordinary business traffic passes without scrutiny | an invoice that matches a real supplier's format, from a similar address |
Routine deserves extra weight. A generic phishing email is easy to spot; the attacks that work are the ones that look like the 200 legitimate emails the recipient processes every day. This is also why the control is procedural rather than perceptual: you cannot teach people to feel suspicious of their own normal work, but you can require a callback before changing bank details.
The family of social attacks
| Attack | What it looks like in practice | One red flag |
|---|---|---|
| Bulk phishing | the same message to thousands of addresses, usually a generic lure and a link | the greeting is generic and the link does not match the sender's domain |
| Spear-phishing | a message written for one person, referencing their role, colleagues or a live project | it is unusually well-informed about your work for someone you do not know |
| Whaling | spear-phishing aimed at executives, often as a legal or regulatory notice | a legal threat sent to an executive's address with an unexpected attachment |
| Clone phishing | a copy of a real email with its link or attachment swapped for a hostile version | a resend of something you already received, with a changed link |
| Thread hijacking | a reply inside a genuine email conversation, sent from a compromised mailbox | the tone or request changes mid-thread; the reply-to address is different |
| Vishing (voice) | a phone call from "IT support" or "the bank" walking someone through steps | the caller cannot be called back on a number you already hold |
| Smishing (SMS) | a text about a delivery fee, a bank alert or an MFA message | a link in a text message that asks for any account detail |
| Quishing (QR codes) | a QR code leading to a hostile page, sometimes printed on a sticker applied over a legitimate sign | a QR code that resolves to a shortener instead of the organisation's own domain |
| Business email compromise | a compromised or impersonated mailbox requests a change to bank details or a payment | bank details change in a message that is otherwise routine |
| CEO fraud and gift cards | an executive supposedly needs an urgent, secret purchase on a personal card | the request must be kept secret and paid quickly |
| Pretexting | a fabricated scenario earning cooperation, often by phone ("I'm new, can you help me log in?") | the caller asks you to authenticate them rather than the reverse |
| Baiting | free media, downloads or prizes that carry a payload | the offer is unrelated to work and costs nothing |
| Tailgating and shoulder surfing | following people through a door; reading a screen or keyboard in a shared space | someone without a badge walking in behind staff, holding the door "as a courtesy" |
| Watering-hole sites | a site your staff legitimately use is compromised and used to deliver a payload | a professional site asking to run software or install an update |
| Calendar and meeting invites | an invitation with a link in the description, from a genuine-looking sender | an invite you did not expect, with a link instead of a dial-in number |
| Voice or video deepfake | a synthetic version of a person's voice or face authorising a transfer | any instruction to move money that arrives by voice or video alone |
The pattern across the whole table: the ask is small, the context is familiar, and the verification step was skipped. Practical procedures beat vigilance every time, because procedures survive a busy Tuesday and vigilance does not.
Anatomy of a phishing email
When you look at a suspect message, look in this order. It takes about a minute.
| What to inspect | What you are looking for |
|---|---|
| Display name versus actual address | the name says your bank; the address is unrelated. Some clients hide the address until expanded |
| Reply-to mismatch | the reply address differs from the sender's domain, so your answer goes somewhere else |
| Domain age and reputation | a domain a few weeks old at a lookalike spelling is a strong signal; check from your organisation's tooling, not a third-party site you reached from the email |
| Wording and tone | wrong language, wrong formality, or a tone that does not match that person's real writing |
| Unexpected attachments | an invoice, CV or statement you were not expecting β especially if it asks for macros |
| Link destination versus visible text | hover or long-press to reveal the real destination; the anchor text and the href frequently disagree |
| URL construction tricks | a subdomain used as a decoy (a trusted name placed before the real domain), homoglyph characters that look like Latin letters, hyphenated lookalikes such as your-company-portal, and shortened links that hide the destination entirely |
| Attachment types that should alarm | archives containing executables, documents that ask to enable content, single-file web pages, and anything with a double extension such as invoice.pdf.exe |
| The request itself | does it ask for a password, a payment, a bank-detail change or a verification click? Those four asks are the whole game |
| Headers, if you are investigating | your mail system's authentication results tell you whether the message passed SPF, DKIM and DMARC for the claimed domain |
Reading the raw headers is the step most people skip and the one that settles the question fastest. Your mail platform shows these results; if it does not, ask why.
The authentication that lets you check a sender
Sender authentication is the one part of this problem with a genuine technical fix. Three DNS-based mechanisms work together.
| Mechanism | What it proves | How it works in one line |
|---|---|---|
| SPF | that the sending server was allowed to send mail for that domain | a DNS record lists the hosts permitted to send, and the receiver checks the connecting server's address against it |
| DKIM | that the message content was signed by a key belonging to the domain, and has not been altered in transit | the sender signs the message; the receiver fetches the public key from the domain's DNS and verifies it |
| DMARC | what to do when SPF or DKIM fails, and that the domain you are checking matches the one in the visible From line | a policy record says none, quarantine or reject, and where to send reports |
The third one matters most. SPF and DKIM alone are advisory; DMARC is the instruction. And the detail that catches most impersonation is alignment: DMARC checks that an authenticated domain is the same as the domain the user actually sees. A message can pass SPF for a domain that has nothing to do with the one in its display name β DMARC is what closes that gap.
For a small business the practical sequence is: publish SPF and DKIM, publish a DMARC record starting in monitoring mode, read the reports for a few weeks, fix whatever legitimate mail is failing, then move to an enforcing policy. Enforcing DMARC stops anyone spoofing your domain, which protects your customers and suppliers as much as you β and it is the single most valuable email control available to a small organisation. It is not, however, a complete answer: an attacker who registers a lookalike domain passes their own DMARC perfectly, which is why process controls still carry the load.
Defences, in layers
Technical. Filtering at the mail gateway, attachment sandboxing, DMARC at enforcement, external-sender banners on inbound mail, safe-link rewriting that checks a URL at click time, and phishing-resistant MFA β hardware keys or passkeys β so that a stolen password is not enough even if it is typed into a hostile page. Also block legacy authentication methods (older mail and application protocols that cannot present an MFA prompt), because they are the standard route around modern MFA.
Process. A verification procedure for any change of payment or bank details: a callback to a number you already hold β never the number in the message β and a documented rule that this applies to executives and suppliers alike. Two-person approval above a defined amount. A named person who can authorise an urgent payment, and a defined route to reach them that does not depend on the message being answered. These procedures are worth more than any amount of staff vigilance, because they work whether or not the employee suspects anything.
People. Short, regular training rather than one annual production, realistic simulations run with authorisation, and a no-blame reporting culture with a one-click report button. The last point is the one most often got wrong. If people who report a mistake are disciplined, or made to feel foolish, reports stop β and the only person who still knows about the compromise is the attacker. Reward reporting explicitly: a click reported in five minutes is a minor incident; a click concealed for a week is a breach.
You received a suspicious email β the 60-second checklist
- Stop. Do not click, do not open the attachment, do not reply.
- Expand the sender's full address and check it against the display name.
- Hover, or long-press on a phone, to read the real link destination.
- Ask what the message wants: a password, a payment, a bank-detail change, or a verification click.
- Ask whether you were expecting it, from this person, through this channel.
- If your mail client has one, press the report-phishing button; if not, forward it as an attachment to your IT or security contact β forwarding normally can strip the headers that matter.
- Delete it once reported, and tell your colleagues if it looks like an internal-style message, because it was probably sent to others.
If you already clicked
- Disconnect the device from the network β pull the cable or switch off WiFi β if you entered credentials or enabled content.
- Change the password for the affected account from a different, trusted device, and change it anywhere the same password was reused.
- Revoke active sessions for that account, because a stolen cookie does not care that you changed the password afterwards.
- Report immediately, to your IT or security contact, with what you clicked and what you entered. Being early is the entire value you can add.
- Watch for follow-on activity on the account for the next week: new mailbox rules, forwarding addresses, unexpected MFA prompts, unfamiliar sign-ins. Mailbox rules are the classic way an attacker keeps reading your mail after you reset the password.
Attack it / Defend it
| The attack | How it works | The control that stops it |
|---|---|---|
| Bulk phishing | one message, many recipients, generic lure | mail filtering, DMARC enforcement, sandboxing, awareness |
| Spear-phishing | research-driven message aimed at one person | external-sender banners, verification habits, less public personal detail |
| Domain spoofing of your brand | forged mail claiming to be from your domain | SPF, DKIM and DMARC at enforcement |
| Lookalike domain | a similar domain registered by the attacker, passing its own authentication | mail filtering on new domains, user verification, brand monitoring |
| Credential-harvesting page | a convincing login page that captures the password and the MFA prompt | phishing-resistant MFA, safe-link rewriting, session revocation |
| Legacy-authentication bypass | older mail protocols skip the MFA prompt entirely | block legacy authentication at the mail platform |
| Business email compromise | a real or spoofed mailbox redirects a payment | DMARC, callback verification to a known number, two-person approval |
| Invoice and bank-detail fraud | a routine-looking supplier message changes payment details | payment-change procedure, supplier verification by phone, approval thresholds |
| CEO fraud and gift cards | authority plus secrecy plus urgency | no-secrecy rule, spend approval process, awareness |
| QR phishing | a phone is sent to a hostile page, out of sight of desktop controls | treat QR codes as untrusted links, mobile device management, awareness |
| Deepfake voice or video | synthetic authority authorises a transfer | callback on a number you already hold, dual approval, a code word for high-value requests |
| Tailgating | physical entry behind an authorised person | access control, visitor management, staff willing to challenge politely |
| A concealed mistake | a user clicks, fears the consequences, and stays silent | no-blame reporting culture and a one-click report button |
Key takeaways
- Social engineering attacks judgement, not software, so the fix is a procedure people can follow when they are busy β not a hope that they will be suspicious.
- The ask is always small: a password, a payment, a bank-detail change, or a verification click. Recognising the ask is faster than judging the sender.
- DMARC at enforcement is the most valuable email control a small business can deploy, and it protects your customers and suppliers too.
- Phishing-resistant MFA is the difference between a stolen password and a breach. A password plus a prompt the attacker triggered is not protection.
- Punishing people who report destroys the reports. A five-minute report is a minor incident; a concealed one is a breach.
Check yourself
- Name the three components of every social engineering attack, and one control that breaks each.
- A message passes SPF and DKIM but the visible From domain is different. Why is that possible, and which mechanism catches it?
- Your finance team receives a supplier email changing bank details, and it looks completely genuine. What procedure should decide the outcome, and what detail makes it work?
- Why does blocking legacy authentication matter when you already enforce MFA?
- A colleague tells you they clicked a phishing link and entered their password, four days ago, and did not report it. Name the three things you check first and why.