Business Email Compromise (BEC) Attacks and Countermeasures

Introduction

Recently, the WithSecure Incident Response teams identified an increase in the number of cases related to Business Email Compromise (BEC). This type of attack by threat actors uses social engineering techniques, such as phishing emails, to trick users into compromising their accounts and leveraging that to compromise high-value assets, or even impersonating the user. It then requests fraudulent changes on bank details. In most cases, the threat targets specific individuals within organizations and shares personalized emails with the intended victim.

Business Email Compromise

Business email compromise often starts with threat actors sending phishing emails to the target, most likely targeting high-value or privileged users. Once the victim clicks on the link, the threat actor tries to steal the credentials, and in more advanced phishing campaigns, the threat actors use a proxy connection to steal the token, even if the victim has MFA (multi-factor authentication) enabled. This is done in real-time, meaning all traffic from the victim to the target application, such as Microsoft 365, goes through the threat actor’s proxy, meaning the adversary can steal the access token to authenticate on behalf of the victim (This technique is detailed in tmore detail below).

Threat actors use personalized email messages that do not contain any malicious files. Instead, they include a clean link that points to the threat actor’s newly built infrastructure. As this infrastructure is relatively new, and no threat intelligence or other detection mechanisms will flag it as malicious, it makes the BEC quite difficult to detect.

Once the threat actors successfully compromise one or two users, they then try to initiate another phishing campaign internally to compromise an additional set of users within the organization or the partner organization. The likelihood of success is higher since the emails originate from known users or organizations.

Attack scenarios

There are multiple ways that threat actors can get hold of user credentials. If the enterprise has not enabled MFA, it becomes easier - either through phishing, purchasing information from the dark web, or by using compromised credentials from other third-party or social media websites if the user is reusing the same credentials.

In more advanced attacks where MFA is enabled, the threat actor can perform various attacks such as push notification fatigue or man-in-the-middle (also known as adversarial-in-the-middle) attacks, in which the threat actor steals the session token and reuses it to impersonate the user.

Here are some of the key techniques adversaries use to obtain credentials or session tokens:

• Multi-factor authentication (MFA) Prompt Bombing or MFA fatigue
• Adversary-in-the-middle (AiTM) phishing campaigns
• Credentials obtained from other breaches (in the case of credential reuse)
• Credentials obtained by exploiting vulnerabilities on servers such as MS Exchange

Adversary-in-the-middle (AiTM)

In most cases, this begins with a simple phishing email targeted at end users. The threat actor sets up an AiTM infrastructure using tools such as Evilginx to route the victim’s traffic through an attacker-owned proxy. This setup allows the threat actor to intercept all traffic to legitimate websites and relay the response back to the victim.

From the end user’s perspective, they see the expected login UI are prompted to complete their MFA. Once the MFA token has been entered, the threat actor relays it to the legitimate website and captures the session token issued to the end user. The stolen token is then reused to access the compromised user’s email and other resources, potentially escalating privileges if those compromised resources have additional setup privileges.

It is often observed that threat actors create mailbox rules and start sending phishing emails to other users within the organization and partners. Since these emails come from known internal users, the likelihood of success is much higher.

Stealing tokens is one of the key attack vectors when using regular MFA. Sending a high number of push notifications is also common when the threat actor has the victim's credentials. They will keep sending push notifications so that sometimes the end user clicks on “yes," - at that time, the threat actor gains authentication. 

Regular Multi-factor Authentication (MFA)

One of the most important steps an organization can take to reduce the risk of credential compromise is by implementing multi-factor authentication (MFA). Once enabled, this requires an additional set of validation to allow users to successfully log on to the system. So, even when a threat actor obtains the credentials, they won’t be able to impersonate the user.

Phishing Resistance Multi-factor Authentication (MFA)

Phishing Resistance Multi-Factor Authentication (MFA), such as FIDO2 keys, helps prevent session token stealing through attacks like AiTM. Ideally, organizations should enable FIDO2 authentication for all users in its enterprise; however, it can be quite expensive. If an organization is able, they should go for it - or at least enable FIDO2 authentication for administrator roles and high-value targets.

External email forwarding

In BEC cases, threat actors often create forwarding rules to auto-forward all incoming mail to an external email address, to which the threat actor has access. In this way, the adversary receives copies of all emails - even after end users reset their credentials. This also helps the adversary to exfiltrate data. Administrators can then create different rules to suit their needs. 

Point-on-Click analysis

Threat actors often embed malicious URLs in phishing emails within the mail body, which may not be flagged as malicious domains by the email gateway at the time of sending. Leading email gateways offer URL rewrite features for links embedded in the email body. They check the reputation of the URL when the user clicks on that particular link, rather than when the email passes through the gateway. This technical feature is often referred to as URL sandboxing or point-on-click analysis..

External email labeling

In most BEC cases, the threat actor tries to spoof the email address or use a similar sounding domain to trick the end user. Having a label on external emails can be a good way to flag emails to the end user. This can be configured on Office 365 alongside disclaimer text. This may seem a like simple change, but it is quite effective.

Content Disarm & Reconstruction (CDR)

Threat actors leverage Microsoft Office or PDF files in phishing emails to infect end users. These attachments may contain macros that may not be detected by the email gateway antivirus or malware scanner. Content disarm and reconstruction (CDR) offers a safe alternative, instead of simply blocking those files by including only the safe elements from the original file.

This is a multi-stage process involving scanning and identifying the file type and its components, before stripping certain content and reconstructing the file. The policy can be as simple as converting Microsoft Word files to PDF files. This way, the end user receives the file, but none of the attack vectors applicable to Microsoft Word files will work because the original file was converted to PDF. There are quite a few techniques available, such as Flat-file Conversion, Content Stripping, and copying only parts of the original files known to be good. 

Organizations can create policies on the email gateway to enforce this, at least for the most commonly used files such as Microsoft Office files, PDFs, etc.

User awareness training & assessments

Organizations need a multi-layered approach to defend against the growing threat of BEC. One layer is based on technology, while the others rely on employee awareness. End users should be able to distinguish between legitimate emails and phishing attempts - relying solely on technical controls may not suffice when defending against these threats. End-user awareness training and periodic assessments are key differentiators when it comes to effectively combating BEC.

Authorized Relay for Applications

Sometimes, email compromise can originate from another breach. For example, if threat actors breach the organization and gain access to some servers, which could be production or test servers, they might discover email configurations set up for some business use cases. These configurations often exist in on-prem Exchange servers, where administrators add the application server’s IP address as a trusted SMTP relay to send email notifications and/or health checks.

The vulnerability mainly exists when administrators configure SMTP relay based solely on the server IP address. Threat actors can leverage such configuration flaws by sending phishing emails from the authorized application server, which they have already compromised, to internal users (a simple LDAP query can get a list of all email addresses configured on the AD), leading to BEC. Wherever possible, organizations should avoid configuring SMTP relay based solely on the application server IP address.

Sender verification

Threat actors often create similar-sounding domains that appear to be from the same organization or a trusted partner organization. Having the following settings on the email gateway of both the organization and its partners can help eliminate emails claiming to be from trusted sources.

SPF

SPF stands for Sender Policy Framework. By adding an SPF record, you are telling the recipient organization which email infrastructure you are using. So, when someone receives an email from you, it will first check where the email has come from and then the SPF records to determine where this email is supposed to have originated. If both match, then the email passes the SPF check.

DKIM

DKIM stands for Domain Keys Identified Mail. It uses digital signatures to ensure that the content of the email is not tampered with.

DMARC

DMRC stands for Domain-based Message Authentication, Reporting & Conformance. When DMARC is confirmed on email systems, it tells the recipient email gateway what to do with the email if it has no SPF or DKIM records attached; for example, reject that email.

In order to achieve the intended objective, both the recipient and the sender organization should configure these settings on their respective email gateways and DNS records.

Baseline conditional access policy

Conditional access monitors signals such as the devices you are using to connect, the application you are trying to access, the geolocation you are connecting from, and many more.

Microsoft Azure monitors these signals and determines whether to provide access or not. In certain scenarios, it requires additional checks such as MFA or Intune enrollment before granting access. Microsoft provides the flexibility to create simple or complex conditional access policies based on various parameters, and this is one of the key defense mechanisms when it comes to BEC-related attacks.

The following are a few basic hygiene conditional access policies that help the organization prevent BEC-related threats.

• [P1] Conditional access policy for Administrator Roles.
• [P2] Conditional access policy for all Standard Users.
• [P3] Conditional access policy for Guests / External Users.
• [P4] Conditional access policy for Legacy Applications
• [P5] Conditional access policy for User Enrollments
• [P6] Conditional access policy for Device compliance
• [P7] Conditional access policy for Risky users and Sign-ins