What is Business Email Compromise (BEC)?

Business Email Compromise (BEC) is a type of targeted cybercrime attack where the attacker uses compromised email access and tailored email messages to trick someone into sending money or providing confidential company info.

This attack is very difficult to detect, because the attackers very often acquire valid credentials via other attacks: phishing campaigns, malware etc.

Types of Business Email Compromise (BEC) attack:

The FBI describes 5 types of BEC attack:

1. CEO/Executive Impersonation:

Attackers are trying to present themselves as the CEO or high-ranked executive of a company and then send a targeted email to an employee within the finance department with the request to transfer funds into the account of the attacker. Common social engineering tactics like a sense of urgency and authority are being used.

2. Valid Account Compromise:

An employee’s email account is compromised by other attacks: phishing, malware etc., and is used to request payments from vendors. Payments are then sent to the bank accounts owned by the attacker.

3. False Invoice Scheme:

Attackers commonly target foreign suppliers through this tactic. The attackers impersonate the supplier and request fund transfers to their bank accounts.

4. Attorney Impersonation:

This is when an attacker impersonates a lawyer or legal representative. Similar scenario to a CEO impersonation, but this is more targeted to the employees working at the lower positions.

5. Data Theft:

These types of attacks typically target HR employees in an attempt to obtain personal or sensitive information about individuals within the company such as CEOs and executives. This data can then be leveraged for future attacks.

Why BEC attacks are so effective?

These attacks are difficult to detect because they don’t use malware or malicious URLs that can be prevented with standard cyber defences. Instead, BEC attacks rely on impersonation and other social engineering techniques to trick people into interacting with the attacker.

The attacker puts themselves into a position of trust—typically a colleague, boss, supplier or vendor. The attacker may also create a false sense of urgency to push through a transaction and avoid further scrutiny.

Because of their targeted nature and use of social engineering, manual investigation and remediation of these attacks is difficult and time-consuming.

Detection:

These attacks are difficult to detect but there are some cases where a SOC can play a key role in surfacing indicators that may eventually raise the alarm.

Situation Context (An Example):

An employee working in the financial department of an organisation received an email from their supplier requesting changes to their bank details. The supplier email used a spoofed domain, but ultimately the employee raised an alarm about the transaction because the new banking details were pointing to a bank situated in another country from the supplier. 

At first glance, this looked like a case of an external spoofed domain and email impersonation attack, but the issue was much more serious. A detailed investigation revealed that there had been a successful login to the employee's email application from a mobile phone and since MFA wasn’t enabled this allow the attacker in without incident. The attacker knew the credentials and had likely sourced these from the Dark Web - scraped through a key logger, for example.

The organisation's SIEM generated a low-level alarm for the user's login which was observed from two different countries in a short time period. This alarm type can have a high rate of false positives because of remote work and increased usage of VPN services.

This was exacerbated by the fact that the user’s normal pattern of activity occurs in two geographies and the attacker's login occurred from a third geography, but again, this could just indicate that the user going was travelling on business, going on holiday abroad etc.

At this point, it is still very difficult to label the alarm as malicious since the attacker, after successfully logging in, just went completely quiet. Its likely the attacker spent this time analysing the employee's email communications, trying to figure out relationships between people, etc.

After a few days, the first suspicious inbox rules started to appear. The attacker learned the information about people involved in the payment processing process and put the plan in motion to pose as a supplier and request a change to their banking details. All the legitimate responses from the supplier were intercepted by the newly created inbox rules, marked as read and moved to a separate folder, effectively hiding them from the employee.

The attacker simply inserted himself into the middle of the email communications, manipulating the conversation with both sides. Had the attacker been successful, the future payments processed by the employee from the financial department would have landed up in the bank account of the attacker (or their mule - as is the case too these days).

New inbox rules should be taken very seriously and investigated by the SOC with high priority. One of the very useful O365 attributes that can be used by SOC analysts during investigations is the “Session ID”, which tracks all the events of a user since their successful login. If filtering by the “Session ID”, all the events are revealed in the timeline manner.

Summary of the events and indicators:

1. Low-level alarm (Users login from 2 different countries).
2. New inbox rules redirecting email to inconspicuous folders (Archive, Spam etc.)
3. Email messages contain words (“bank details”, “request”, “change” etc.) in the Subject field.
4. Email messages with spoofed domains.
5. Mailbox activity shows a mix of legitimate and suspicious activity.

Looking at the summary of the events, it is clear that the malicious activity can be confirmed during the inbox rule creation, even if it difficult to confirm the malicious activity at login.

Prevention:

The mixing of legitimate and suspicious transactions in O365 made the investigation difficult. Remember, the SOC sees the activity as a single legitimate user, because the attacker logged in with valid employee credentials. Separating events by their “Session ID” made a significant difference, because each actor – legitimate and malicious - is going to have their own unique “Session ID”.

Ultimately, this attack was made possible by the lack of Multifactor Authentication (MFA) on the user’s account. Everyone (especially employees in positions of trust such as in HR, finance, executive, etc.) should be enrolled in Multifactor Authentication (MFA) and Active Directory rules should enforce this authentication requirement. Even though Multifactor Authentication (MFA) isn’t a silver bullet, it helps a great deal in preventing initial access to malicious actors.

Let’s put in the summary the prevention controls:

• Multifactor Authentication (MFA).
• User training to identify phishing and illegitimate emails.
• Email filtering rules, preventing emails from spoofed domains.
• User and Entity Behavior Analytics (UEBA) on logins, mailbox behaviours etc.

These controls provide a strong multi-layer defence against BEC attacks and yet, it is still very difficult to defend against this attack type because of the targeted nature and heavy involvement of social engineering techniques.