Low-Code Security and Business Email Compromise via Email Auto-Forwarding

Overview

Many low-code applications are built for the purpose of moving data from one place to another usually as a result of some external trigger, such as the arrival of a new email message. In the case of an email-triggering low-code application, if low-code security best practices are not strictly followed, attackers may abuse the application to set rogue automated email forwarding rules, which can be used to steal data, impersonate as corporate users and mount phishing campaigns.  

Business Email Compromise and Auto-Forwarding Attacks

According to the US Federal Bureau of Investigation (FBI), business email compromise (BEC) – also known as email account compromise (EAC) – is one of the most financially damaging online crimes. BEC exploits the fact that so many of us rely on email to conduct business, both personal and professional. 

One type of BEC attack vector is known as an auto-forwarding attack, in which BEC actors create auto-forwarding rules within email accounts after they obtain employee credentials to decrease the victims’ ability to observe fraudulent communications. After obtaining access to a victim’s email account, cyber criminals update the auto-forwarding email rules in the web-based client. If administrators do not actively sync their web and desktop email clients, the auto-forwarding rules may only appear in the web client, limiting the rules’ visibility to security administrators.

BEC and Low-Code Applications

In a recent cyber attack, hackers were able to compromise an email account owned by the victim company’s accounting team. By setting a simple auto-forward and deleting the original email message from the victim’s inbox, they were able to hijack the conversation with one of the company’s vendors. When it was time to execute the transaction, the attackers provided their own routing instructions and even confirmed those instructions by simply replying to the email.

Companies are trying to control or even prevent email-forwarding attacks with various methods. Data loss prevention (DLP) solutions and email providers themselves try to solve the issue by instrumenting either the email application or the email server itself. In this endless cat and mouse game, attackers always try to find the next loophole to forward emails, given its massive lucrativity. Recently, attackers were able to bypass all of those defense mechanisms by leveraging low-code applications.

A vast majority of low-code applications are essentially data movers. They trigger on every file change, new email, or button press; they log the event, alert the file owner or store the data elsewhere and then continue to wait for the next event. Hackers leverage these types of low-code applications to subscribe to an email address, copy the content of the new email and send it to themselves from a different email account. Note that the trick here is copying the data, rather than simply forwarding the email.

The email server has no idea that something like this ever happened. From the email server’s side, it looks as if the low-code platform triggered some app following the email’s arrival, but that’s it. The email app of course knows nothing as well, since it was never even used in this case. And just like that, emails are forwarded while all existing security solutions are bypassed.

Some low-code vendors have tried addressing the forwarding issue, alluding to the fact that their customers are worried about it. Microsoft ,for example, recently introduced special headers (i.e ‘x-ms-mail-application’ header set as ‘Microsoft Power Automate’ value) that get added to every email that is created using their platform, allowing administrators to monitor and ban emails coming into or going from their email server. However, this does not address the attack scenario described above, since, unfortunately, email servers outside of the organization are also outside of IT’s control.

Moreover, since copying data is at the root of this new attack vector, any solution would have to go down either to the data layer to find the sensitive email, or the identity layer to find out where data is flowing.

Options for Mitigating the Risk

One alternative you could use is to simply block low-code access to corporate email. This would cure the disease, but kill the patient in the process. There are many different use cases for which low-code apps need access to corporate email: to automate customer support, streamline internal processes and boost productivity.

Another option would be to block low-code access to external accounts, but again, this would have the unfortunate side effect of disrupting business. Vendors and contractors are often a vital part of an organization’s ecosystem, and their low-code ecosystem in particular.

A better solution would be to make sure that a corporate identity is never mixed with an external identity. By going down to the identity layer, you can make sure applications can either use corporate data OR they use external data – but not both.

To do this in your environment, you will need to:

1. List all low-code applications that use an email connector
2. Review each application, and make note of identities being used by the app
3. Identify and address apps that mix corporate and external identities