Security services have a problem and it’s called BEC 3.0.
Last week, we wrote about the BEC 2.0 variant. To be clear, 2.0 is the dominant variant and remains a significant problem for security services and companies. It’s no wonder BEC is the most financially devastating attack out there.
To recap, BEC 2.0 is as follows:
- A hacker compromises an account, either at your organization or, more likely, a vendor’s organization.
- They use that account to insert themselves into legitimate email threads, responding as if they were employees.
- If it involves an invoice, they can tweak the bank information, and the money will be routed into their account. The end-user is none the wiser.
These attacks are very difficult, although not impossible, to stop. Profiling users and organizations, creating baselines to understand what is typical behavior, and then using AI and ML to detect variations is key. Beyond that, having that same understanding for your partners is key, as is the ability to institute rules and policies, such as DLP warnings, to warn users that something might be amiss.
BEC 2.0 is bad. BEC 3.0 represents an incredible challenge.
What’s BEC 3.0? Simply put, it’s the use of legitimate service to unleash an attack. Instead of a fake invoice, you’ll get a legitimate invoice with malicious instructions, coming directly from PayPal. Instead of RingCentral meeting invite that goes to a conference call, it’s weaponized to redirect to a malicious site.
In short, hackers are able to take something that doesn’t just appear to be legitimate–it is legitimate. In the email message, there will be nothing malicious and in fact it will be trusted by security services and users alike.
In this attack brief, researchers at Avanan, a Check Point Software company, will discuss how hackers are utilizing Google’s services within comments on Google Workspace documents to redirect users to a fake cryptocurrency site. This attack, still ongoing, has been targeted at nearly 1,000 companies in the last two weeks.
In this attack, hackers utilize the comments feature in Google Workspace to send malicious redirects. The link used is a Google Scripts URL. Google Scripts is a coding platform hosted by Google. The link then redirects users to a fake cryptocurrency page.
- Vector: Email
- Type: Phishing
- Techniques: BEC 3.0
- Target: Any end-user
Email Example #1
Does this type of email look familiar? It is a legitimate email. Here, the hacker has added a comment in Google Sheets. All the hacker has to do is create a free Google account. Then, they can create a Google sheet, and mention the intended target. The recipient gets an email notification.
To the end-user, this is a fairly typical email, especially if they use Google Workspace. (And even if they don’t, it’s fairly typical, as many organizations use Google Workspace and Microsoft 365).
Here’s another example, this time using Google Docs.
This comes from a legitimate sender–Google. The URL, which is a script.google.com URL, is also legitimate upon the first scan. That's because that domain is legitimate.
It’s only when you click on it does it get redirected to a fake cryptocurrency site. These fake cryptocurrency sites work in a few ways. They can be straight phishing sites, where credentials will be stolen. Or, there’s a variety of other options, whether it’s straight theft or crypto mining.
In short, this attack is incredibly well-crafted. It takes advantage of a legitimate site, like Google. The sender address and reputation will be perfect. This attack has a deficiency, in that the text used by the actor is stilted and unnatural. (“Hello users of the system” is not incredibly convincing).
But, as with all variants, it may not have reached peak form yet. Also, some hackers are just better than others. But this attack variant has the potential to take over and spread across the world.
BEC 2.0 attacks often have a tip-off. Maybe it’s the language being used in the email; maybe it’s unusual behavior, like impossible travel logins. AI and ML can often suss these out. BEC 3.0 can be a lot tougher.
To stop BEC 3.0 attacks, many things are needed. One of them is Click-Time Protection and URL emulation.
Every time an end-user clicks on a link, the Click-Time Protection engine tests the website for reputation using HEC's URL Reputation and emulates the target website to detect zero-day phishing indicators using URL Emulation. Emails that detonate post-delivery are designed to land in the inbox as clean and are only dangerous after clicking. If you don't re-write every URL, end-users will be affected by this.
Proper URL scanning has the following benefits:
- Another layer of post-delivery protection
- Anti-malware and enhanced protection for zero-day attacks, as sometimes it takes a few minutes to detect malicious emails
To do this, you need click-time protection, and the best–and really, only–way to deploy CTP is by being inline.
Many solutions will selectively re-write links that are suspicious. But these links are not suspicious. That’s why it’s not only important to rewrite all links, but then emulate those links and look for phishing indicators and analyze any further links nested within the page.
We’ve been following these BEC 3.0 attacks and are starting to see more and more bubbling up to the surface.
The next wave is here. Are you ready?
Best Practices: Guidance and Recommendations
To guard against these attacks, security professionals can do the following:
- Before clicking on Google Docs comments, encourage end-users to cross-reference the email address in the comment to ensure it’s legitimate
- Remind end-users to utilize standard cyber hygiene, including scrutinizing links and inspecting grammar
- If unsure, reach out to the legitimate sender and confirm they meant to send that document