The MSP Security Gap
The invoice that paid the wrong company
The scenario:
Your client’s accounts team gets an email from a supplier they pay every month. It arrives inside the existing thread, quoting the genuine invoice, the genuine amounts, the names of people on both sides.
One change. The supplier has “moved banks”, and the payment should go to the new account. The invoice is due Friday.
How it unfolds:
The supplier’s mailbox was compromised weeks ago. The attacker did not send a fake email. They sat inside the real mailbox, read the real thread, and waited for the right invoice.
When it came, they replied from the supplier’s genuine address, inside the genuine conversation, with a doctored PDF and new bank details. Every check the accounts team knew to make passes: right address, right thread, right invoice number, right amount.
The payment goes out Friday. The real supplier chases the unpaid invoice three weeks later, and both businesses discover the money went to an account emptied the day it landed.
Payment diversion fraud runs to nine figures a year, and the supplier-thread variant is its most reliable form because it borrows every trust signal a business has: the relationship, the history, and the thread itself. Money this size rarely comes back. Banks move slower than mule accounts empty.
The warning signs:
Any change of bank details delivered by email, even inside a genuine thread.
A change arriving close to a payment deadline.
Small differences in the attachment: font, layout, a new “remittance contact”.
A reply-to address one character off the real one, though in true mailbox compromises it is identical.
Stop it:
Verify every bank-detail change by phone, on a number from your own records, never one in the email. No exceptions, including for suppliers you trust most.
Make the callback a written step in the payment process, so skipping it is a policy breach rather than a judgment call.
Ask suppliers to agree the same rule in reverse, because your client’s mailbox is somebody else’s supplier thread.
-
P.S. The compromised mailbox belongs to the supplier, so nothing in your client’s stack fires. What you see, when you look, is the sign-in pattern behind the supplier’s sending address changing, and an invoice email with a payment-detail change. The callback is the control. The monitoring tells you when to distrust the thread.
Patch first this week:
Verified exploited vulnerabilities, checked against CISA KEV and NVD.
SonicWall SMA1000 remote access appliances. CVE-2026-15409 and CVE-2026-15410. An unauthenticated attacker reaches the appliance from the internet, no login needed. CVSS 10.0. Added to CISA KEV 14 July with a 3-day federal patch deadline, the strongest urgency signal CISA sends. If you or your clients run SMA1000 remote access, patch to the fixed firmware now and review sign-in logs since early July.
Microsoft SharePoint Server (on-premises). CVE-2026-58644. Unauthenticated remote code execution, actively exploited. CVSS 9.8. Added to KEV 16 July. Applies to SharePoint 2016, 2019, and Subscription Edition, not SharePoint Online. If any client still runs on-prem SharePoint, patch this week and check for unfamiliar processes on the servers.
Microsoft Active Directory Federation Services. CVE-2026-56155. Local privilege escalation on AD FS servers, actively exploited. Added to KEV 14 July. Patch domain-adjacent servers first. If a client still runs AD FS for single sign-on, this is also the moment to raise the migration conversation.
Fortinet FortiSandbox. CVE-2026-25089 and CVE-2026-39808. OS command injection, unauthenticated, CVSS 9.8, added to KEV 16 July. Fixed in 4.4.9 and 5.0.6. Security tooling is a target like everything else. Patch the tools that watch the tools.