BEC Prevention Case Study: How a 28-Person Firm Caught a $76K Wire Fraud Before It Left the Bank

By Jonathan Fykes, CTO · Published February 21, 2026 · Last updated April 26, 2026

A note on the company

The firm in this story is a composite. The numbers, the timeline, the technical findings, and the human moments are stitched together from real engagements with small businesses that got close to a BEC loss and didn't quite eat one. The construction firm itself doesn't exist. We chose the profile (a 28-person regional construction practice in the Southwest, doing roughly $14M a year, on Microsoft 365 Business Premium) because it's representative of where this attack hits hardest: small enough that nobody's full-time on security, big enough that wires of $50,000 to $200,000 are routine.

If you want the prevention playbook these controls are drawn from, the foundation is in the business email compromise prevention guide. If you want the layered control stack that maps to each of the six items below, that's in the Microsoft 365 email security checklist.

The setup

It's the second Tuesday in March, 9:47 a.m. local. The bookkeeper, who handles AP and payroll for the firm and reports to the CFO, opens Outlook and starts working through the morning queue. She's been with the firm seven years. She's processed somewhere north of four thousand vendor payments in that time and never wired the wrong account.

The CFO had approved a $185,000 wire to a structural-steel vendor the previous Friday. That wire had cleared on Monday. Everyone knew about it. The owners, the project manager on the job, the CFO, the bookkeeper. Standard process. Net 30 against a signed PO, two-signature approval, wire from the operating account.

Microsoft 365 Business Premium across the company. MFA was on for everyone, mandated for finance roles, with Authenticator push as the default factor. Defender for Office 365 was active because it ships with Business Premium. SPF was clean. DKIM was signed on the primary domain. Conditional Access existed but was minimal: one policy that required MFA from outside the office network and a second that blocked legacy auth. DMARC was published at p=none, in monitoring mode, where it had been sitting for fourteen months because nobody had owned moving it forward.

That's the baseline. Better than most 30-seat firms. Not nearly enough.

The attempt

At 9:47 a.m. an email lands in the bookkeeper's inbox. Subject line: Quick wire today — new vendor for the Madison job. Sender display name: the CFO's full name, exactly as it appears in every other email. Sender address (and this is the part that matters): [email protected].

The legitimate domain is thefirmsb.com. The attacker's domain is firmsbd.com. Two characters different, no the, an extra d. Visually, scanning at speed, almost identical. The attacker had registered the lookalike fourteen days before the attack through a privacy-shielded registrar.

The body of the email read like the CFO. Same sentence rhythm, same sign-off, no obvious grammar tells. It referenced a real project ("the Madison job"), used the actual subcontractor naming convention, and asked the bookkeeper to wire $76,000 to a "new vendor account" the next morning. The justification was plausible: a steel sub the firm had used twice before had supposedly switched banks and needed payment routed to the new account before a Wednesday delivery.

Everything about the message was tuned. The amount was small enough not to trigger the firm's two-signature rule (the threshold was $100,000). The timing was tight enough that hesitation felt obstructive. The context was specific enough that "is this real?" felt like a stupid question.

Three things were wrong, and the bookkeeper saw exactly one of them.

What caught it

Defender for Office 365 displayed an anti-impersonation banner at the top of the message: This sender appears to be impersonating someone in your organization. The CFO had been added as a "protected user" in the anti-phishing policy, which Defender uses to flag inbound mail where the display name closely matches a protected user but the sender mailbox doesn't belong to the tenant. The banner was the visible flag.

The bookkeeper had been through phishing training the previous October. The training emphasized one rule above all others: any email asking for a wire, a banking change, or a vendor-account update gets a phone call to the sender's cell phone, on a number from the contacts list, before any action. Five minutes. No exceptions.

She paused. She read the banner. She picked up the desk phone, called the CFO's cell from memory, and asked if she'd sent a wire request that morning. The CFO had not. The CFO was, in fact, on a job site forty minutes away and hadn't been at her keyboard since 8:15.

That's the entire prevention story. One Defender banner, one piece of training that the bookkeeper had taken seriously, one phone call. Total elapsed time between the email arriving and the attack being neutralized: about twelve minutes. Total dollar value of the controls that did the work: zero, because both were already in place. The firm just had to use them.

The forensics

The CFO called the firm's MSP within the hour. The MSP pulled message headers and ran the lookalike domain through a few WHOIS and threat-intel sources. The domain had been registered on February 26 through Namecheap with a privacy shield, and the MX record pointed to a Mailgun-style relay. The sending IP geolocated to a hosting provider in Germany. None of that matched the firm's normal mail flow.

What the MSP didn't expect was the second finding. The bookkeeper, walking through her recent inbox, mentioned that the vendor referenced in the fake email (the steel subcontractor on the Madison job) had been "weird" lately. A couple of their replies had taken longer than usual. One invoice had arrived with slightly different formatting. The bookkeeper had chalked it up to the vendor's office manager being on vacation.

The MSP got the vendor on the phone. Within two hours the vendor's IT confirmed what the firm had started to suspect: the vendor's accounting clerk's mailbox had been compromised six weeks earlier through a phishing kit that proxied a Microsoft sign-in page and harvested both the password and the post-MFA session cookie. The attacker had been quietly reading her mail since late January. They'd pulled invoice templates, project names, the firm's PO numbering convention, and the rough cadence of payments. They'd built a profile of the construction firm as a target without ever touching the firm's tenant.

That's the part most BEC stories miss. The compromise that enabled this attack didn't happen at the firm. It happened at a vendor the firm had no visibility into. From the firm's tenant logs, there was nothing to find. No anomalous sign-ins. No suspicious OAuth grants. No forwarding rules. The lateral path was entirely through an external mailbox the firm couldn't see.

The six controls that made the difference (and which were already in place)

Working backward from the moment the attack failed, six controls had to line up. Two of them did the visible work. Four were quiet preconditions that meant the attacker only had one shot.

1. Defender for Office 365 anti-impersonation, with the CFO as a named protected user. This is the one that produced the banner. Defender doesn't catch every lookalike domain by default; it catches them when you've explicitly told it which user accounts to protect. The firm had added the CFO and the controller a year earlier as part of a one-hour MSP touch-up. That was the one specific configuration choice that made the visible flag possible.
2. The bookkeeper's training on out-of-band verification. The Defender banner only mattered because somebody read it and acted on it. The training said: any wire request, any banking change, phone the sender's known cell. The bookkeeper followed the rule. That's the cultural control, and it's the one nobody wants to talk about because it depends on humans choosing to pause.
3. MFA on the firm's tenant, blocking the easy version of this attack. If the firm hadn't had MFA, the attacker's likely first move would have been a credential-stuffing attempt against the bookkeeper or the CFO directly. With MFA on, that route was closed and the attacker had to fall back to the lookalike-domain external attack, which is louder.
4. No external auto-forwarding on the CFO's mailbox. If the CFO's mailbox had been quietly compromised at any point and a forwarding rule had been set up, the attacker would have had access to internal context that would have made the spoofed email even more convincing. The firm's outbound spam policy blocked external forwarding by default, which capped the blast radius.
5. Defender Safe Links neutralizing the follow-up phishing wave. Within 48 hours of the failed wire attempt, the same attacker tried a Safe-Links-protected phishing email aimed at the bookkeeper directly, masquerading as a DocuSign payment confirmation. Safe Links rewrote the URL, detonated it in the cloud sandbox, and quarantined the message. The MSP saw the alert in the Defender portal that afternoon.
6. DMARC at p=none in monitoring mode (the one that didn't help here, but would have on a different attack pattern). Worth noting because it's the most common confusion. DMARC at any policy level only blocks spoofs of your own domain. The lookalike attack used a different domain entirely (firmsbd.com instead of thefirmsb.com), so DMARC had nothing to evaluate. If the attacker had spoofed the firm's actual domain in the From header, p=quarantine or p=reject would have stopped it cold. p=none would have logged it and let it through.

The honest read: two controls did the catching, three controls made sure the attacker only got one shot, and one control was a misunderstanding the firm had to correct in the post-mortem.

What they hardened in the six weeks afterward

The firm's owners gave the MSP a small budget and a six-week window. Five changes came out of the post-mortem. None of them were exotic. All of them were things the firm could have done a year earlier.

1. DMARC moved from p=none to p=quarantine, then to p=reject over six weeks. The migration took longer than the technical work because the firm had three legitimate third-party senders pushing mail as the firm's domain: a marketing platform, a project-bidding tool, and a payroll provider. Each one had to be brought into the SPF record and have DKIM signing configured on its end before the policy could move. DMARC reports were collected through a free DMARCian tier so the MSP could see who was passing and who was failing. Total elapsed time: 41 days. Actual config work: about six hours.

2. Defender anti-impersonation tuned for named users, not just role-based defaults. The CFO and controller were already protected. The post-mortem added the two project managers who handle subcontractor wires, the company president, and the AP bookkeeper herself. Five named users total. Action set to Quarantine, threshold set to Aggressive. Domain impersonation protection added the firm's primary domain plus the four largest vendor domains. Time to configure: about 90 minutes.

3. Out-of-band verification formalized into a written process for any wire change over $5,000. The previous training had been verbal. The new policy was a one-page document, signed by every person with AP authority, that required a callback to a phone number on file from the vendor record (not a number in the email, not a number on a new invoice) before any change to banking details could be processed. The threshold was deliberately low to make the rule a habit, not an exception. The bookkeeper's manager keeps a callback log and the firm's external CPA reviews it during the annual audit.

4. Phishing simulation program with finance-specific content. The firm enrolled in a quarterly simulation service and asked for templates that mimicked vendor invoices, banking-change requests, and CFO impersonation specifically. The first round caught two clicks out of 28 employees. By the third round (nine months in), the click rate was zero and the report-suspicious rate was 78%. The simulation cost about $1,800 a year on top of the existing M365 spend.

5. New vendor verification workflow. Any new vendor (or any banking change to an existing vendor) gets a callback to the vendor's main switchboard, not a number in the email or on the proposed invoice. If the switchboard can't confirm the change, the wire doesn't go. Two new vendors got delayed by a day during the rollout. Both turned out to be legitimate. Neither complained.

One thing the firm explicitly did not do: buy a third-party email security tool. Their MSP ran the numbers and concluded that for a 28-seat tenant on Business Premium, the controls already in the box were sufficient if configured. The diagnostic playbook for that decision is in our deep dive on detecting M365 email compromise, which walks through the audit-log queries the MSP ran on the CFO and bookkeeper mailboxes during the post-mortem.

Five things this story teaches that generalize

Pull the firm out of the picture. What's left is a pattern that shows up in roughly four out of five small-business BEC cases we see. Five lessons that any 25-to-100-seat M365 tenant can take from this one.

1. The technical control flagged it; the cultural control caught it. Both are needed. Defender's banner without the bookkeeper's training would have been ignored. The bookkeeper's training without the banner would have meant relying on her gut to notice a one-character domain difference at 9:47 on a Tuesday. The two layered together. Either one alone fails about half the time.

2. DMARC at p=none doesn't block lookalike domains. It only protects your own domain from being spoofed. A surprising number of small-business owners think DMARC is "the spam control" and assume any policy level helps. p=none is monitoring only, and even p=reject doesn't touch a different domain that happens to look like yours. Lookalike-domain attacks are caught by anti-impersonation policies, not DMARC.

3. Vendor mailbox compromise is the lateral attack you can't see from your own tenant. The firm's audit logs were clean throughout. The attacker never touched the firm's M365. Everything that made the spoofed email convincing came from a vendor's mailbox the firm had no visibility into. The defense for that isn't more telemetry. It's assuming any contextual detail in an inbound email could have come from a compromised counterparty, and verifying out of band on anything that moves money.

4. Anti-impersonation needs named protection for the actual high-value names, not just role-based defaults. Defender's "protected users" list is empty by default. If the CFO and controller aren't explicitly named, the impersonation banner doesn't fire. This is the single configuration choice that produced the visible flag in this case. Ninety minutes of MSP time to add the right names to the policy and set the threshold to Aggressive.

5. The "cost" of a five-minute callback is nothing. The cost of a missed callback is six figures. The bookkeeper's phone call took less time than reading this paragraph. Even if she'd been wrong about the callback being warranted (she wasn't), the worst case was a slightly annoyed CFO. The math on that trade is so lopsided that it's the easiest cultural rule to install and the easiest one to skip when things get busy. Don't skip it.

The cost math

If the wire had gone through, the loss for a 28-person firm doing $14M a year shakes out roughly like this. The wire itself: $76,000. The 72-hour wire-recall window almost never fully recovers the funds for a money-mule transfer, so realistic recovery: maybe $10,000 to $20,000 if you're lucky and fast. Net wire loss: about $60,000.

Add the recovery costs. Forensics engagement to confirm whether the firm's tenant was also compromised (it wasn't, but you have to verify): about $12,000. Cyber-insurance carrier engagement, including the legal and notification touchpoints required by the policy: about $8,000 in deductible plus $5,000 to $10,000 in attorney time. Customer-confidence cost (the firm would have had to disclose to current customers who'd been pulled into the attacker's reconnaissance): hard to price but real, plausibly $20,000 to $40,000 in delayed receivables and one or two awkward conversations with project managers at customer accounts.

Realistic all-in cost of the loss had it landed: about $110,000. Could be higher. The number that's quoted as the average wire-fraud loss in BEC reporting (around $137,000 per incident in the FBI's IC3 data) includes those second-order costs, not just the wire itself.

Cost of the prevention upgrade: about $8,000 in MSP labor for the DMARC migration, the anti-impersonation tuning, the process documentation, and the rollout of the phishing simulation program. Ongoing cost: $1,800 a year for the simulation service. No new licenses, no new tools.

The ROI math is roughly 14x return on the upgrade in the year it's deployed, against a single avoided incident. The firm's owners didn't need that math to approve the work, because they'd just lived through the dress rehearsal. Most firms don't get that wake-up call before the loss. The point of writing this case study is to give it to you anyway.

If you want a wider lens on what hardening looks like end-to-end for a tenant in roughly the same shape as the firm in this story, the parallel M365 security implementation case study on SecureYourTenant follows a 35-person firm through a six-week baseline deployment, including the dollar costs and the elapsed-time math. And for the unhappier path (what it looks like when the wire does go through and you're inside the 90-day recovery window), the M365 breach recovery case study on BreachShield365 is the operator-grade walkthrough.

Common questions

Why didn't DMARC stop this attack?

DMARC only evaluates messages that claim to come from your own domain. The attack used a different domain entirely (firmsbd.com), one designed to look like the firm's domain when scanned quickly. From DMARC's perspective there was nothing to check, because the From header didn't claim to be the firm. DMARC at p=reject would have stopped a different attack pattern (a spoof of thefirmsb.com from an unauthorized server), but it can't help against a lookalike domain. That's what anti-impersonation policies in Defender are for.

Would Microsoft 365 Business Standard have caught this?

Probably not on the technical side. The Defender for Office 365 anti-impersonation feature is part of the Business Premium SKU (and the standalone Defender for Office 365 add-ons). Business Standard ships with Exchange Online Protection but not the impersonation-protection layer. The cultural control (the bookkeeper's training and the callback rule) would still have worked, and in this case it would have had to do all the work alone. That's a thinner margin than most owners realize they're running on.

How did the attacker know about the Madison job and the steel vendor?

From the vendor's compromised mailbox. The accounting clerk at the steel subcontractor had been receiving invoice copies, project correspondence, and PO emails for six weeks while the attacker was reading her inbox. By the time the attacker was ready to pivot to the firm, they had project names, vendor relationships, dollar amounts, and the rough cadence of payments. Nothing about the firm's own tenant had been compromised. This is why "we have MFA, we're fine" is the wrong mental model. Your security depends on your vendors' security too.

What would have happened if the bookkeeper hadn't called?

The wire would have been sent at 8:00 the next morning, against a vendor record the bookkeeper would have created on the fly to match the email instructions. By the time the real CFO walked into the office and asked about the steel sub's payment status, the funds would have been moving through the first leg of the mule chain. The firm's bank would have initiated wire recall within six hours of the discovery, but the second-leg transfer (typically to an offshore account) almost always clears before recall lands. Realistic recovery in that scenario: 15 to 25 cents on the dollar.

Is this story representative, or is it cherry-picked?

The mechanics are representative. The ratio of "near miss" to "full loss" we see in 25-to-100-seat M365 tenants leans more toward full loss than this case study suggests, mostly because the cultural control (the trained callback) is the rarest of the six. The firms that catch BEC before money moves are almost always the ones that took an hour of finance-team training seriously and had at least one named user added to anti-impersonation protection. Tenants without those two pieces lose the wire about three quarters of the time, in our anecdotal experience. Roughly the same ratio shows up in the FBI IC3 reporting on confirmed-loss versus reported-attempt for BEC.