The Invoice Was Real

Ridgeline Manufacturing makes custom industrial packaging. Eighty-five employees. Grand Rapids, Michigan. They invoice clients by email, net-30, wire or ACH. Karen Bledsoe has been sending those invoices for nine years. Clients know her by name.

On a Tuesday in March, Karen clicked a link in an email that looked like a Microsoft 365 password expiration notice. The page was a proxy. It passed her credentials and MFA code through to Microsoft in real time and captured the authenticated session cookie. MFA was on. It didn't matter. The attacker had Karen's active session.

Within an hour, two inbox rules were created. Emails containing "invoice," "payment," or "remittance" were moved to the RSS Subscriptions folder and marked as read. Emails from three client domains were forwarded to an external address and deleted from Karen's inbox. Karen never saw the rules. She had no reason to look.

The rules did more than steal information. They gave the attacker control of the conversation. If Tom had replied to Karen's real address with a question about the payment, Karen would never have seen it. The attacker would have. And the attacker would have replied.

For two weeks, the attacker read everything. Invoice formats. Payment terms. Dollar amounts. Client names. Karen's writing style and signature. They knew Ridgeline had sent Invoice #4471 to Lakeview Hospital System for $287,000 in sterile packaging containers. Net-30. Wire transfer. Due in 12 days.

Then they stopped watching and started operating.

The attacker registered ridgeiinemanufacturing.com. Two lowercase i's where the L's should be. A $12 domain. They emailed Tom Maddox in Lakeview's accounts payable:

Hi Tom, just wanted to give you a heads up that we've updated our banking details. New wire instructions are attached for the outstanding invoice #4471. Please use these going forward. Let me know if you have any questions. Thanks, Karen

Right logo. Right signature. Right invoice number. Right dollar amount. Right tone. Everything the attacker needed to write that email, they learned from Karen's inbox. Tom had been processing payments to Karen for three years. He routed the wire.

$12 in. $287,000 out. It left Lakeview's bank on a Thursday. Wire recalls have roughly a 24-hour window. Nobody knew to call. By Friday the money had moved through two intermediary accounts. By Saturday it was gone.

Three weeks later, Ridgeline's AR clerk sent a past-due notice on #4471. Tom replied: "We paid that three weeks ago. Karen sent us updated wire instructions."

What Ridgeline lost

Lakeview paid the correct amount for the correct invoice. They have a wire confirmation. They are not paying twice. Ridgeline is out $287,000.

Lakeview's bank flagged the wire. New beneficiary, large amount. They called Tom. Tom confirmed. That confirmation is why the bank won't reverse it. The bank did its job. Tom did what he always did. The system worked exactly as designed, and the money is gone.

Ridgeline's cyber insurance denied the claim. The policy excludes "voluntary transfer of funds by a third party." Lakeview's insurer took the same position: the fraudulent instruction came from Ridgeline's compromised email. Both insurers were right. Neither company was covered.

The business relationship ended three months later. Lakeview, a $1.4 million annual account over 12 years, moved to a competitor whose invoicing runs through a payment portal with bank verification built in.

Total cost: $287,000 in uncollectable revenue. $38,000 in legal fees. The $1.4 million annual account, gone.

People

Karen clicked a phishing link. Her last security training was a single module during a software rollout 18 months earlier. It covered password hygiene. It did not cover session cookie theft or how a proxy page can bypass MFA.

Tom at Lakeview processed the bank change because the email looked like every other email Karen had ever sent. His bank called to verify the wire. He confirmed it. He had no reason not to. No one had ever told him that a vendor's banking details sent by email should be verified by phone.

Ridgeline's owner declined a monitoring package from their MSP when the Microsoft 365 tenant was set up. The package included alerts on inbox rule changes, impossible travel sign-ins, and external forwarding. It was a line item he passed on. He was managing costs. He had no way to know that was the difference between catching a compromise in minutes and discovering it three weeks later.

Nobody was careless. Everybody did what their organization set them up to do.

Process

Three documents could have stopped this. None of them existed.

A vendor communication policy. One sentence from Ridgeline to every client: "We will never change banking details by email." That gives Tom a reason to stop and call. Without it, the fraudulent request looked like every legitimate one.

An AP verification procedure. Lakeview's accounts payable process was: receive invoice, match to PO, process payment. Built for accuracy, not fraud resistance. No callback requirement for bank changes. No secondary approval for new beneficiary accounts. No threshold that triggers a second set of eyes.

A liability clause in the contract. The agreement between Ridgeline and Lakeview didn't address responsibility for fraudulent payment instructions. When the lawyers got involved, neither side's contract covered what happens when a compromised email causes a misdirected wire. The 12-year business relationship ended because there was no framework to resolve who owed what.

Technology

MFA was on. The attacker bypassed it with an adversary-in-the-middle proxy (AiTM) that captures the session cookie in real time. The cookie grants access without re-authentication until it expires. Microsoft's default session lifetime is 90 days.

Conditional access policies were not configured. They could have restricted sign-ins to managed devices, making the stolen cookie harder to use from the attacker's infrastructure. Not a guarantee. But a layer that narrows the window.

Exchange Online logs inbox rule changes by default. The logs existed. Nobody was watching. The MSP's monitoring package would have triggered an alert the moment the rules were created. The rules ran for 14 days because the system that could have detected them in minutes was the line item sitting in a declined quote.

Email authentication (DMARC) was configured on Ridgeline's real domain. It would have blocked a spoofed email from ridgelinemanufacturing.com. The attacker didn't spoof. They registered a lookalike domain. DMARC doesn't catch that. Only a human reading the domain letter by letter catches ridgeiinemanufacturing.com. Tom was reading the display name.

What would have stopped it

The monitoring alert. An alert on "new inbox rule created" would have surfaced the compromise within minutes. The entire attack depended on 14 days of silent email access. That alert collapses the window to zero. What makes it fail: an alert that lands in a ticket queue triaged once a week. The alert has to reach a person who acts on it within hours, not days. Monitoring without response is not monitoring.

One sentence in the vendor agreement. "Banking details will never be changed via email. Any change in payment instructions must be confirmed by phone using the number on file in your vendor master record." Not the number in the email. Not the number in the signature. The number you already have. That sentence gives Tom Maddox a reason to pick up the phone. He calls the main Ridgeline number, reaches the real Karen, and the wire never sends.

Layered controls. Conditional access restricts where the stolen cookie works. The monitoring alert catches the inbox rules. The callback process catches the payment. Each layer has gaps. Together they close them. No single control stops this attack. The companies that survive BEC are running all three. Ridgeline was running none.

What to do tomorrow

Open your M365 admin console or call your MSP. Check whether alerts on inbox rule changes and external forwarding are enabled. If they are, verify who receives them and how fast that person acts. If they aren't, turn them on today. That is the single control with the highest return in this case study. It costs minutes to enable and would have caught this attack on Day 1.

Then pull one vendor agreement at random. Search for language about how payment instructions change. If it says nothing, your organization is in the same position Ridgeline was. Talk to your lawyer about adding it to your next contract renewal.

Discussion questions

1. If your MSP offered monitoring for inbox rule changes, would you know? Did you decline it? Is it in the quote you didn't sign?

2. Do your client-facing communications contain language establishing that payment details will never change via email? If one of your clients received a bank change request from your domain tomorrow, do they have a written basis to stop and call?

3. When your team needs to verify a vendor's identity, where do they get the phone number? From the email they're verifying, or from a record that existed before the email arrived?

4. If a forwarding rule was created on your finance team's mailbox right now, how long would it run before someone noticed? Who would notice? Is that person checking today?

5. Read your cyber insurance policy's "voluntary transfer" exclusion. If your compromised email caused a client to wire money to an attacker, are you covered? Is your client?