Case Study 2: Anatomy of a $1.2M Wire-Fraud BEC

"There was no malware to find. There was no exploit. There was a careful liar and a process with one missing step." — Incident lead, Harborview Construction (constructed)

Executive Summary

To understand why business email compromise steals more money than ransomware while triggering no antivirus alert, we leave the bank and walk through a single incident at a company in a completely different sector: Harborview Construction, a mid-size general contractor with about 600 employees that manages large commercial building projects and moves money to subcontractors in seven-figure progress payments. This is a detection and analysis case study — the mirror of Case Study 1's build. Rather than deploy controls, you will reconstruct an attack that already happened, follow the evidence through the email headers and logs, identify the exact moment the defense should have held, and extract the controls that would have changed the outcome. The incident cost Harborview $1.2 million and recovered $340,000 of it; the difference between those numbers is also a lesson.

The attack used no zero-day, no ransomware, no credential-stealing implant on Harborview's network. It used a compromised mailbox at a subcontractor, weeks of patient reading, a perfectly timed lie, and a payment process that trusted email. Every technical control Harborview owned was working correctly. The attack still succeeded, because BEC does not attack technology — it attacks trust and process. All details are constructed for teaching (Tier 3); domains and IPs use documentation ranges.

Skills applied: reconstructing a BEC timeline from email headers and logs; distinguishing spoofing from genuine-mailbox compromise; reading SPF/DKIM/DMARC results in an attack that passes them; identifying the process control (out-of-band verification) that is the true defense; mapping a financial fraud to the email and DNS telemetry that would have caught it.

Background

Harborview Construction is not a technology company and does not pretend to be. Its IT is a small internal team plus a managed service provider; its security posture is "we have email filtering and antivirus." It does, however, move enormous sums: a single progress payment to a steel subcontractor on a large project can be $1–2 million, wired on instructions that arrive — as they do across the construction industry — by email.

Harborview's accounts-payable process, before the incident, looked reasonable on paper:

  1. A subcontractor emails an invoice and payment instructions.
  2. The project manager approves the work as complete.
  3. Accounts payable wires the funds to the bank details on the invoice.

There is no step that independently verifies the bank details against anything but the email itself. That missing step is the entire vulnerability, and it is a process vulnerability, not a technical one. No firewall rule or email filter addresses it, because every message involved can be perfectly legitimate-looking — and in this case, one of them came from a genuinely trusted account.

🚪 Threshold Concept: The most expensive attacks in this chapter do not break into your network at all. BEC frequently compromises a third party you trust — a vendor, a client, a law firm — and then abuses that trust against you. Your perimeter, your endpoint security, your DMARC enforcement: all working, all irrelevant, because the malicious instruction arrives through a relationship you have deliberately chosen to trust. Defending against BEC means hardening processes that involve money and trusted parties, not just hardening machines. Internalize this and you will stop looking for the malware that is not there.

The Analysis

Phase 1 — The compromise that happened somewhere else

The incident did not begin at Harborview. Six weeks earlier, an employee at Coastal Steel, one of Harborview's subcontractors, fell for an ordinary credential-phishing email and entered their Microsoft 365 password into a fake login page. Coastal Steel had no MFA on email. The attacker now had full, real access to a legitimate Coastal Steel mailbox — and, crucially, they did nothing loud with it. They did not send spam. They did not deploy malware. They set up a quiet mailbox rule to hide certain replies, and they read.

For weeks the attacker studied the rhythm of the Coastal Steel–Harborview relationship: the project name (the Harbor Point development), the names of the project manager and the AP clerk, the cadence of invoices, the tone of the staff, the dollar amounts. This reconnaissance is what separates BEC from crude phishing. By the time the attacker acted, they could impersonate the relationship perfectly because they had been inside it.

🛡️ Defender's Lens: From Harborview's seat, the early-warning signal for this kind of attack is not on Harborview's network at all — which is exactly why it is so hard. But there are still tells a vigilant AP team or email system can catch: a reply-to address that differs from the from address, a sudden change in bank details, slightly off phrasing, or pressure to bypass normal steps. The defense cannot be purely technical because the compromise is at a trusted third party; it must include a human process that treats "change of payment details" as a hard checkpoint regardless of how trusted the sender appears.

Phase 2 — The timed strike

The attacker waited for a real trigger. When Coastal Steel's genuine project manager (whose mailbox was compromised) prepared to send a legitimate $1.2M progress invoice for the Harbor Point steel package, the attacker struck — sending, from the real Coastal Steel mailbox, a message to Harborview's AP clerk:

From: "Mark Reyes" <mark.reyes@coastalsteel.example>
Reply-To: mark.reyes@coastalsteel.example
Subject: RE: Harbor Point — Invoice #4471 (updated remittance)
Date: Thu, 09 May 2024 09:14:33 +0000
Authentication-Results: spf=pass dkim=pass dmarc=pass
  (mailfrom and From align with coastalsteel.example)

Hi — quick note before you process #4471. We've changed banks; please send
this payment to our new account below. Same total, $1,200,000.00. Let me know
when it's out so I can confirm on our end. Appreciate it.
  Bank: First Harbor Trust  Acct: ...  Routing: ...

Read the Authentication-Results line carefully, because it is the heart of why this attack is so dangerous. SPF passed. DKIM passed. DMARC passed. Every email-authentication control this book spent §9.4 building reported green. And they were correct to: the message genuinely came from the coastalsteel.example domain, signed with Coastal Steel's real key, from Coastal Steel's real mailbox. There was nothing forged. Authentication answers "did this really come from the domain it claims?" — and here, devastatingly, the honest answer was yes.

⚠️ Common Pitfall: Believing that "SPF/DKIM/DMARC all passed" means "this email is safe." It means only that the sending domain is authentic — not that the request is legitimate or that the mailbox is in the right hands. Account-takeover BEC, where the attacker sends from a genuinely compromised mailbox, sails through authentication. Treating a green authentication result as a safety guarantee is exactly the gap these attackers exploit. Authentication is necessary; it is nowhere near sufficient.

The one technical tell in this message — and it is subtle — is that the first version sent by the attacker (in some variants of this attack) uses a reply-to or a look-alike domain. In this incident the attacker did not even need that, because they had the real mailbox. The only remaining signal was behavioral: an unexpected change of bank details, conveyed with mild urgency, on a large payment. That behavioral signal is the one a process must be built to catch.

Phase 3 — The wire, and the missing step

The Harborview AP clerk did everything their process required. The project manager had approved the work. The invoice came from the known, trusted Coastal Steel contact, and it authenticated. The clerk updated the remittance details as instructed and wired $1.2 million to the attacker's account. The funds were moved onward and largely cashed out within hours.

The missing step — the one control that would have stopped the entire attack — was an out-of-band verification of the bank-detail change: a phone call to Mark Reyes at a known, previously established phone number (not one from the email) to confirm "did you really change banks?" That single call would have reached the real Mark Reyes, who would have said "no, we didn't change anything," and the fraud would have collapsed. The attacker controlled the email channel completely; they did not control the phone. Out-of-band — using a second, independent channel — is the defining property that defeats single-channel deception.

  WHAT HAPPENED                          WHAT SHOULD HAVE HAPPENED
  ─────────────                          ─────────────────────────
  Email: "change of bank details"        Email: "change of bank details"
        │                                       │
        ▼                                       ▼
  AP updates details from email          AP flags: payment-detail change!
        │                                       │
        ▼                                       ▼ (out-of-band)
  Wire $1.2M  ──► attacker                Call Mark at KNOWN number
                                                │
                                                ▼
                                          "We never changed banks."  ──► fraud stopped

Figure CS9.1 — The single missing checkpoint. The attacker owned the email channel end to end; an out-of-band confirmation through an independently known phone number reaches the real party and breaks the deception. The defense is a process step, not a product.

Phase 4 — Detection, recovery, and what the telemetry could have shown

Harborview discovered the fraud only when the real Coastal Steel called two weeks later asking where their $1.2M payment was. The incident response then focused on recovery: Harborview's bank initiated a SWIFT recall and a fraud claim, law enforcement (and, in the U.S., the FBI's IC3) were notified within the critical first 72 hours, and through the recall process $340,000 still sitting in the receiving account was frozen and returned. The remaining $860,000 was gone. Speed of detection directly determined how much was recoverable — the same MTTD-matters lesson that runs through Part V.

Could telemetry have caught it earlier? Partly, and instructively:

  • Email behavioral analytics at Harborview's secure email gateway could have flagged the message: while it authenticated, it contained a change of bank details plus financial urgency on a large payment — a high-risk combination a modern BEC-detection model scores even when authentication passes.
  • A reply-to / from mismatch rule would have caught the variants where the attacker redirected replies, though not this exact genuine-mailbox case.
  • Newly-registered-domain and look-alike detection (the §9.6 signals) would have caught the cheaper version of this attack, where the criminal registers coastalstee1.example instead of compromising the real mailbox — a reminder that the same fraud comes in both a high-effort (account takeover) and low-effort (look-alike) form, and you must defend against both.

📟 War Story: The same week, Harborview's filters did stop a second, cruder BEC attempt: an email from coastalstee1.example (digit one for the letter L) demanding an urgent payment. That one failed DMARC (it was a look-alike domain the attacker did not control) and tripped the gateway's newly-registered-domain rule, and it never reached a human. The contrast is the whole lesson: the low-effort BEC that spoofs or registers a look-alike is exactly what SPF/DKIM/DMARC and domain-age detection are built to stop — and they did. The high-effort BEC that takes over a real mailbox slips past every authentication check, and only a process control (out-of-band verification) stands in its way. Defense in depth means having both layers, because attackers use both methods.

Discussion Questions

  1. Every email-authentication control passed, and the attack still succeeded. Does this mean SPF/DKIM/ DMARC are useless against BEC? Argue carefully, distinguishing the account-takeover variant from the spoofing/look-alike variant.
  2. The decisive control was an out-of-band verification of payment-detail changes. Why must it be out-of-band (a different channel), and why must the phone number come from a previously known source rather than from the email?
  3. Harborview recovered $340K of $1.2M purely because of how fast (or slow) they detected the fraud. Connect this to the broader principle that detection speed determines impact. What single change to Harborview's process would most improve detection time?
  4. The compromise originated at a subcontractor with no MFA, entirely outside Harborview's control. How should an organization manage the security risk introduced by trusted third parties whose security it cannot directly enforce? (This previews the third-party-risk material of Chapter 29.)
  5. Compare this incident to Case Study 1's Meridian rollout. One is a build (deploy controls), one is an analysis (reconstruct an attack). What does each teach about the limits of technical controls against an attack that targets people and process?

Your Turn

Reconstruct a BEC defense for a small organization that pays vendors by wire. (a) Write the current (vulnerable) payment process as a numbered list, then insert the single out-of-band verification step that would defeat the attack in this case study, specifying exactly when it triggers and what channel it uses. (b) Draft three email-detection signals (from §9.6) you would deploy to catch the look-alike variant of the attack, with a sensible threshold or condition for each. (c) Write a one-paragraph "red-flag" guidance for accounts-payable staff that would make them pause on a message like the one in Phase 2 — without relying on any technology. Keep it to two pages.

Key Takeaways

  • BEC frequently passes SPF/DKIM/DMARC when the attacker sends from a genuinely compromised mailbox; a green authentication result proves the domain is real, not that the request or the mailbox owner is legitimate. Authentication is necessary but nowhere near sufficient.
  • The decisive defense against account-takeover BEC is a process control: out-of-band verification of any change to payment details or large/urgent payments, using an independently known channel the attacker does not control.
  • The same fraud comes in two forms — high-effort account takeover (defeats authentication) and low-effort spoofing/look-alike (defeated by DMARC and domain-age detection). Defense in depth requires layers for both.
  • Detection speed determines recoverable loss. Harborview recovered only the funds it could freeze in the narrow window before cash-out; faster detection (behavioral analytics, a verification step) directly reduces impact.
  • BEC often originates at a trusted third party whose security you cannot control, which is why vendor/third-party risk (Chapter 29) and a culture of verifying money movements (Chapter 30) are part of the real defense — not just hardened machines.