by Paul Schnackenburg
Abstract
The article discusses the significant cyber risks faced by Managed Service Providers (MSPs) and their clients, emphasizing that while ransomware is a prominent threat, Business Email Compromise (BEC) poses a more insidious risk. Ransomware attacks are loud and involve clear incident responses, but BEC is subtle, often going unnoticed until the money is gone. Criminals exploit hacked email accounts to redirect payments, leading to substantial financial losses without the need for high-profile attacks. The article most importantly provides detailed results of a test run on previously trained clients and highlights the importance of robust email hygiene, regular training, and stringent verification processes to mitigate these risks, urging MSPs to test and reinforce their clients’ defenses regularly.
Introduction
As MSPs we’re scared of ransomware hitting our clients – and if you’re not, you should be. It’s a blight on our clients and makes our job harder. Even if you outsource the daily monitoring and remediation of cyber incidents, you must still spend time and effort configuring your client’s tenants securely and keep checking as the threat landscape changes.
But ransomware is “loud”. When the message pops up on your client’s screens and it’s time to enact your well-practiced Incident Response Plan (you have those – right?) and start the eviction and restoration of business services, there’s no doubt about what’s going on. When a cybersecurity insurance company gets involved, negotiation experts are brought in, and they can often reduce the ransom payment significantly. All this is to say, it is time consuming for both you and the criminals, and a payout for the bad guys isn’t guaranteed (at least if you have backups that have been tested, stored on immutable storage).
The Rise of Business Email Compromise (BEC)
Thus, many criminal gangs instead opt for the simpler solution – just ask for the money. In some reports, Business Email Compromise (BEC) outpaces the overall economic loss from ransomware. There are many variations, but the canonical one is where an account gets hacked, and the criminals watch the email flow (a simple forwarding rule will be the only sign of this) for a while. Once they understand who’s emailing whom with account details, they’ll insert themselves into the conversation with a simple “we’ve changed our account, please pay here instead”, or “here’s our invoice with account details”. Businesses small and large fall for this (as does individuals in our personal lives), one of the largest ones might be Evaldas Rimasauskas who scammed Facebook and Google out of $ 122 million. He got five years and had to pay back the money. He’s unusual because he got caught, most criminals that target our SMB clients aren’t likely to ever face the music for their crimes.
BEC isn’t “loud”, generally doesn’t involve a full-on incident response engagement, and since the money is almost always already gone, there’s no negotiation. And most clients will feel embarrassment, rather than the shock, anger and turmoil associated with a large-scale ransomware attack. In most jurisdictions, it also doesn’t involve reporting the incident to regulatory bodies, unlike ransomware payments. In many organizations the reaction is simply to provide some extra training for staff, change processes and in worst case scenarios, scapegoat someone and fire them.
Mitigating BEC Risks
So, what can we do as MSPs? Obviously, you provide a strong email hygiene solution that filters out most of the scams in the first place, and you’ve made sure SPF, DMARC and DKIM records are correct. On top of that, regular training, and phishing simulations will have some impact. However, many miss the first step – make sure that the people processing payments and accounts at your clients NEVER accept a change in payment destination or an invoice via email. They MUST pick up the phone and call the other party on a known number to verify that this is a valid change.
This isn’t just a good idea, it’s (at least here in Australia) a point on most cyber security insurance questionnaires that I’ve helped clients fill in, where the client guarantees that they will do a follow up phone call for any account changes.
Testing and Real-World Scenarios
As a solo MSP in Australia, I had taken all of the above precautions with the small handful of clients I have, but a nagging thought told me that the process people tell me they follow, isn’t actually the one that happens in reality. So, I decided to test it.
We have four major banks here in Australia, and I happened to have an account with a different one than I’d been using for business banking for the last several years. Thus, when I sent my monthly invoice to each of them, I used my personal Hotmail email address (to make it more obvious that this was a simulated scam) and sent them the following email:
The expected result was that I would receive phone calls within a day or two. I heard NOTHING from anyone. After a few days I realized that my defenses had worked as they should, these emails had been quarantined as high confidence phish by Defender for Office 365. I released them, waited and still received no calls.
Lessons Learned
I did, however, get paid by three of the clients to the new account. The fourth client paid the invoice into my old account! Theoretical security protection for my clients = 100%, practical cyber security process = 0% success.
Obviously, I followed up with each of them, saying “what if my personal email account that you normally never receive emails from me from had been hacked or wasn’t mine in the first place?”
Client 1 said “that sounds like a good idea (I helped him with the insurance questionnaire a few months prior), I will do that from now on”.
Client 2 said he’d didn’t realize how important that was, and Client 3 said he “did think about it, but figured the amount wasn’t large enough that he’d be upset if it was a scam”. Client 4 (who paid to the old account) had another look at the email and realized she hadn’t even looked at the account change. To her credit, she did follow up with a phone call a few weeks later for my next invoice and confirmed the new account details.
The lesson for all of us MSPs is that we need to test the people, process and technology defenses of our clients. And that’s not just sending phishing simulations every now and again, that’s testing these sorts of processes. I suggest you implement a similar approach to what I did here and then schedule a repeat every year or two, as staff rotate in account roles.
Conclusion
Bottom line, suppliers changing accounts, or payment options aren’t a common occurrence (most likely to happen during change of ownership, mergers and the like) and adding a few minutes of a phone call isn’t an onerous extra step for accounts staff.
Also – someone will point out that AI powered voice cloning and even fake real time video is now possible. Yes, and if your clients are routinely handling large money transfers, more rigorous validation than a phone call might be required (real estate sales come to mind), but for most of your clients, criminals aren’t going to go through setting up an elaborate scam to intercept phone calls and clone voices to sound like someone you trust, at least not yet.
And if this is something you’re already enforcing with your clients, gold star. I’m doing some training delivery for a medium-sized MSP in Brisbane for their clients. When I sent them my first invoice, with my account details on it, I got a call from their accounts department, and she verified the account by having me read it back to her. At least internally, they’ve got their house in order.
Good luck with the never-ending work of keeping your clients safe – just don’t forget the people and process risks.
Paul Schnackenburg is a member of the Third Tier Mastermind group for solopreneurs and has been working in IT for over 35 years and has been teaching for over 25 years. He runs Expert IT Solutions, an IT consultancy in Australia. Paul focuses on cloud technologies such as Azure and Microsoft 365 and how to secure IT. He’s a frequent speaker at conferences and writes for several sites, including virtualizationreview.com. Find him at @paulschnack on Bluesky or on his blog at TellITasITis.com.au.
