L66 · Social engineering and phishing

Module 10: People, Governance, and Emerging Threats · ~20 min · Lesson 66 of 71

🎯 What you'll learn

• The recipe behind every social-engineering attack: a pretext, a lever, and a request
• How phishing, BEC, vishing, smishing and deepfakes each work, and how to spot them
• How to read an email's headers: SPF, DKIM, DMARC, and why "pass" doesn't mean "safe"

🔥 Why this matters

In January 2024 a finance employee at the Hong Kong office of Arup, a British engineering firm, got an email from the "CFO" about a confidential transaction. He was suspicious, so he joined a video call. The CFO and several colleagues were on it, and he recognized them. Every one of them was a deepfake. He made 15 transfers, HK$200 million (about US$25 million), to five accounts. Hong Kong police described the case in February; Arup confirmed it was the victim in May 2024. No system was hacked.

1. The recipe: a pretext and a push

Every attack in this lesson has the same three parts:

 1 RESEARCH         2 PRETEXT              3 THE ASK
 LinkedIn, press ─▶ "I'm the CFO / your ─▶ pay this, reset that,
 releases, breach   vendor / IT support"   approve, click, read
 dumps, org charts        │                out a code
                          ▼
                  LEVERS that rush you past the process
                  authority · urgency · secrecy · helpfulness

A pretext is the invented story and identity that makes the request seem normal: the vendor whose bank changed, the executive on a deal, the new hire locked out. Pretexting is building and playing that role, often over several messages.

The levers do the real work. Authority ("the CFO needs this"), urgency ("before the 3 p.m. cut-off"), secrecy ("the deal isn't public") and helpfulness ("I'm stuck, can you help?") all push you to skip the step that would catch it. Almost every attack also tries to move you off the normal process: a new number, a personal email, a payment outside the usual system. That move is your best signal.

2. Phishing and spear phishing

Phishing is a message, usually email, that tricks you into clicking, opening or entering something. Mass phishing goes to thousands of people with a generic lure (a parcel, a password expiry). Spear phishing targets one person or team with researched details: your manager's name, a real project, a vendor you actually pay.

Most phishing wants one of three things:

• Credentials: a lookalike sign-in page. Modern kits relay your MFA code or push in real time and steal the session cookie (L21's deep dive). Only phishing-resistant MFA, such as passkeys, stops that.
• Malware: an attachment or download, often an infostealer that takes every browser session (that's how L65's tabletop started).
• Consent: a real OAuth prompt that grants a malicious app access to your mailbox (L23).

Lures increasingly avoid links your filter can scan: a QR code in a PDF moves the click to your phone, outside corporate controls.

3. Business email compromise: the email that asks for money

Business email compromise (BEC) is fraud by email, aimed at getting money or data rather than a foothold. The FBI's Internet Crime Complaint Center (IC3) puts reported BEC losses at about US$2.9 billion in 2023 and US$2.8 billion in 2024, far more than reported ransomware losses. Three patterns are common in any industry, and especially costly in financial services:

• CEO fraud: "the CEO" asks finance for an urgent, confidential wire.
• Vendor bank-change fraud: "a vendor" says its bank account changed. The next real invoice is paid to the attacker. When the attacker sends this from the vendor's real, compromised mailbox, it's called vendor email compromise, and it continues a genuine thread.
• Payroll diversion: "an employee" asks HR to change their direct-deposit account.

 ATTACKER                    NORTHWIND AP             BANK
    │ 1. "new bank details,      │                     │
    │    see attached letter"    │                     │
    │ ─────────────────────────▶ │                     │
    │                            │ 2. CALLBACK to the  │
    │                            │ number already on   │
    │                            │ file, never the one │
    │                            │ in the email        │
    │                            │ ──▶ real vendor:    │
    │                            │     "we didn't      │
    │                            │      change it"     │
    │      no callback? ──────── │ 3. pays new account │
    │ ◀──────────── funds ────── │ ──────────────────▶ │

The fix is a process, not a filter: verify payment-detail changes by calling a number you already had, and require a second approver (L04).

4. Voice, text and push

Vishing is voice phishing. The most damaging version targets the IT help desk: the caller plays an employee who's locked out and asks for a password reset or a new MFA device. The attackers behind the September 2023 attack on MGM Resorts claimed they did exactly that after finding an employee on LinkedIn. MGM never confirmed how they got in, but its SEC filing estimated about US$100 million of impact. CISA's advisory on the group, Scattered Spider, describes the same help-desk calls. L28's first deep dive covers defending the help desk.

Smishing is SMS phishing: "Your card is locked, call this number", or a fake toll fee. Caller ID and SMS sender names can be spoofed, so the number proves nothing.

MFA fatigue (push bombing) floods someone with sign-in prompts until they tap Approve, often with a "this is IT" message to help. It's how Uber was breached in 2022 (L28). Number matching and passkeys defeat it.

5. Deepfakes: when seeing isn't believing

A deepfake is AI-generated audio or video that imitates a real person. Arup's attackers likely built theirs from public videos of the executives. Voice cloning needs only a short sample, which a conference talk or earnings call provides.

Don't plan on spotting deepfakes by eye; the fakes keep improving. Defend with process: payment instructions given on any call, video or message are verified on a channel you start, to a known number, and approved by a second person in the payment system.

🧪 Worked example: an annotated phishing email

Northwind Mutual's accounts-payable inbox gets this. The real vendor is Ridgeway Data at ridgeway-data.example. Here are the headers (from "Show original"), trimmed:

Return-Path: <ar@ridgevvay-data.example>                     [1]
Received: from mx.ridgevvay-data.example (203.0.113.66)
  by mx1.northwind-mutual.example; Mon, 9 Nov 2026 14:02:11
Authentication-Results: mx1.northwind-mutual.example;
  spf=pass smtp.mailfrom=ridgevvay-data.example              [2]
  dkim=pass header.d=ridgevvay-data.example                  [2]
  dmarc=pass header.from=ridgevvay-data.example              [2]
From: "Alicia Moreno | Ridgeway Data" <ar@ridgevvay-data.example>
Reply-To: alicia.moreno.ar@freemail.example                  [3]
Subject: RE: INV-20931 updated remittance details            [4]

1. The lookalike domain. ridgevvay uses two v's for a w. Others swap rn for m, add a hyphen, or use Unicode letters that look identical (homographs). A domain lookup would show it was registered three days ago.
2. Everything passes. SPF (Sender Policy Framework) checks the sending IP is allowed by the envelope domain's DNS. DKIM (DomainKeys Identified Mail) checks a signature from the domain in d=. DMARC (Domain-based Message Authentication, Reporting and Conformance) checks that one of those passed and matches the From: domain, and tells receivers what to do if not. All three prove the mail came from ridgevvay-data.example. The attacker owns that domain, so of course it passes. Authentication proves which domain, not which person or good intent.
3. Reply-To differs from From, so your reply goes to a free mailbox.
4. "RE:" fakes an existing thread; the invoice number may be real.

The body pulls every lever: "Due to our annual audit, our bank has changed. Please update before Friday's payment run. Kindly keep this between us, as the transition is confidential."

Compare a spoof of the real domain, From: ar@ridgeway-data.example, sent from the attacker's server:

Authentication-Results: mx1.northwind-mutual.example;
  spf=fail smtp.mailfrom=ridgeway-data.example
  dkim=none
  dmarc=fail (p=reject) header.from=ridgeway-data.example

If Ridgeway publishes DMARC p=reject, this is rejected before anyone sees it. That's why attackers use lookalikes, or a real compromised mailbox, where every check passes and the domain is right. Only the callback catches that one. (Header formats vary between mail providers.)

🛠 Try it (optional, ~5 min)

Use an email in your own inbox, ideally a newsletter. In Gmail choose Show original; in Outlook, View message source. Find Authentication-Results and check:

1. Do SPF, DKIM and DMARC say pass?
2. Does header.d= (DKIM) or smtp.mailfrom= (SPF) match the From: domain? Newsletters often sign with their email provider's domain; that's what DMARC alignment checks.
3. Look up the sender's policy (public DNS, read-only): dig +short TXT _dmarc.<sender-domain>. Is it p=none, quarantine or reject?

🧠 Key takeaways

• Social engineering is a pretext plus a lever (authority, urgency, secrecy, helpfulness) plus a request; the move off the normal process is the strongest signal.
• BEC is the costliest fraud by email; callbacks to known numbers and dual approval beat it.
• SPF, DKIM and DMARC prove which domain sent a message, not that it's honest.
• Vishing targets help desks and smishing targets phones; verify on a channel you start.
• Deepfakes defeat "I saw them on video"; defend with process, not perception.

📖 Words to know

⏭ Next time

L67 compares the frameworks companies use to organize security: NIST CSF 2.0, ISO 27001 and the CIS Controls.

The main lesson said "verify with a callback". In a financial firm, that rule should live in the software that holds vendor and payee bank details, not only in a training slide. If you build or maintain that system, here's what the workflow looks like.

The rule as a state machine

A bank-detail change is never a field update. It's a request that has to earn its way to active:

 PUT /v1/vendors/V-1042/bank-account
          │
          ▼
 ┌──────────────────┐ callback to number   ┌──────────────────┐
 │ PENDING_CALLBACK │ ─on file, logged ──▶ │ PENDING_APPROVAL │
 └──────────────────┘ by person A          └────────┬─────────┘
          │ vendor says "not us"                    │ person B,
          ▼                                         │ not A, not
 ┌──────────────────┐                               │ requester
 │ REJECTED + alert │                               ▼
 └──────────────────┘                     ┌──────────────────┐
                                          │ ACTIVE, with a   │
                                          │ hold on 1st pay  │
                                          └──────────────────┘

Each control blocks a different trick:

• Callback to the number already on file, recorded with who called and when. Numbers in the email, the letterhead or the signature belong to the attacker.
• A second approver who isn't the requester or the caller (four eyes, L04). Enforce it in the code, as in L27's can_approve(), not in a checklist.
• Notify the old contact on the old details: the real vendor learns about a change they didn't make.
• Hold or limit the first payment to a new account, and flag a change made shortly before a large payment.
• Account-ownership checks, where your bank or a verification service offers them, confirm the account belongs to the vendor's legal name. Coverage varies by country and provider.

Worked example: enforcing it in the service

def approve_bank_change(req: BankChange, user: User) -> None:
    if req.status != "PENDING_APPROVAL":
        raise Conflict("callback not completed")
    if user.id in {req.requested_by, req.callback_by}:
        raise Forbidden("needs an independent approver")
    if req.callback_number != vendor_phone_on_file(req.vendor_id):
        raise Forbidden("callback number not from vendor master")
    req.status = "ACTIVE"
    req.first_payment_hold_until = now() + timedelta(days=2)
    notify_old_contact(req.vendor_id, req.old_account_last4)
    audit.log("vendor.bank.activate", req.id, by=user.id)

Two things to test: an approver who did the callback is refused, and a callback number that came from the request itself is refused. Also protect the vendor-master phone number like the bank account: an attacker who can change the phone first can then "pass" the callback.

When money has already gone

Speed is everything. Call your bank's fraud line at once and ask it to recall the payment and contact the receiving bank. File at ic3.gov: the FBI's Recovery Asset Team works with banks to freeze funds, and its results are best when reports arrive within days. Then treat it as an incident (L63): whose mailbox was compromised, yours or the vendor's?

🧠 Extra takeaways

• Model bank-detail changes as a request with states, not a field update.
• Callback numbers come from the vendor master, never from the request.
• Enforce independent approval in code, and protect the phone number like the account.
• If funds left, call the bank and file with IC3 the same day.

The worked example showed DMARC protecting Ridgeway's domain. Here's how a company gets its own domain to p=reject, so attackers can't send mail as northwind-mutual.example.

The three DNS records

;; SPF: who may send
northwind-mutual.example.  TXT
  "v=spf1 include:_spf.mailhost.example ip4:203.0.113.25 -all"
;; DKIM: public key for selector s1
s1._domainkey.northwind-mutual.example.  TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
;; DMARC: the policy and where to send reports
_dmarc.northwind-mutual.example.  TXT
  "v=DMARC1; p=none; rua=mailto:dmarc@northwind-mutual.example"

• SPF lists sending servers. It has a hard limit of 10 DNS lookups (include: counts), and it checks the hidden envelope sender, not the From: you see.
• DKIM publishes a public key under a selector (s1). Each sending service signs with its own key and selector.
• DMARC requires that SPF or DKIM passes and that its domain aligns with the From: domain. Relaxed alignment (the default) accepts subdomains; strict needs an exact match.

The rollout

 1 INVENTORY      2 p=none          3 p=quarantine     4 p=reject
 every service ─▶ collect rua    ─▶ suspicious mail ─▶ spoofs are
 that sends as    reports, fix      goes to spam;      refused at
 your domain      each sender's     watch for          the door
 (HR, marketing,  SPF and DKIM      complaints
  ticketing)      (weeks)           (weeks)

The slow part is step 1. Payroll, marketing, ticketing and alerting services all send "as" you, and each must be fixed (signing with your domain, or moving to a subdomain such as mail.northwind-mutual.example) before you tighten. Since February 2024, Google and Yahoo require bulk senders (around 5,000+ messages a day to their users) to publish DMARC, at least p=none.

Many teams ramp with pct= (apply the policy to a percentage of failing mail). The IETF's revision of DMARC ("DMARCbis") drops pct in favor of a simpler t= test flag, so check which tags your receivers and tools support before relying on either.

Worked example: reading an aggregate report

Receivers send daily XML aggregate reports to your rua address. One record, trimmed:

<record>
  <row>
    <source_ip>203.0.113.140</source_ip>
    <count>1240</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim><spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>northwind-mutual.example</header_from>
  </identifiers>
</record>

1,240 messages claimed to be from you, from an IP you don't recognize, and failed both checks. disposition: none means they were delivered, because you're still at p=none. Two possibilities: a forgotten legitimate sender (look up who owns the IP; perhaps a new survey tool), or someone spoofing you. Either way it's a finding. Once every legitimate source passes, rows like this are pure spoofing, and p=reject stops them.

Don't forget parked domains

Domains that never send mail are easy to spoof and easy to protect:

parked-brand.example.         TXT "v=spf1 -all"
_dmarc.parked-brand.example.  TXT "v=DMARC1; p=reject;"

Also set sp=reject on the main domain's DMARC record once you're ready, so made-up subdomains like payments.northwind-mutual.example are covered.

🧠 Extra takeaways

• DMARC needs SPF or DKIM to pass and align with the visible From: domain.
• Start at p=none with reports, fix every legitimate sender, then quarantine and reject.
• Aggregate reports show who sends as you, including spoofers and forgotten tools.
• DMARC stops exact-domain spoofing only; lookalike domains need monitoring and process.