Business Email Compromise (BEC) Attacks and Countermeasures

Introduction

Recently the WithSecure Incident Response team has identified an increase on the number of cases related with Business email compromise (BEC),  this type of attack the threat actor 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 and uses that to request 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, and the adversary can steal the access token to authenticate on behalf of the victim (This technique is detailed in the advisory in the middle section below.).

The 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. Since this infrastructure is relatively new, and none of the threat intelligence or other detection mechanisms will flag it as malicious, it makes the business email compromise 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 threat actors can get hold of user credentials. If the enterprise has not enabled MFA, it becomes easier for them to obtain the credentials, either through phishing, purchasing them from dark web markets where credentials are sold, 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 for the account, the threat actor can perform various attacks such as push notification fatigue or man-in-the-middle (also known as adversarial-in-the-middle attack), where the threat actor steals the session token and reuses it to impersonate the user.

Here are some of the key technique’s adversaries use to obtain the 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 a man-in-the-middle 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 UI for the login and are prompted for MFA. Once the MFA token is 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 credentials of the victim. They keep sending push notifications so that sometimes the end user clicks on “yes,” and at that time, the threat actor gains authentication.

Regular Multi-factor Authentication (MFA)

One of the 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)

Stealing tokens is one of the key attack vectors when using regular MFA. 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.

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

External Email Forwarding

In business email compromise 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 all copies of emails even after end users reset their credentials. This also helps the adversary to exfiltrate the data. Administrators can create rules such that if the sender is located inside the organization, the recipient is located outside the organization, and the message type is auto-forward, then reject the message.

Point of 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 instead of 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 business email compromise 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 approach to flag emails to the end user. This can be configured on Office 365 and can add the disclaimer text. These may seem like simple change, but they are quite effective.

Content Disarm & Reconstruction (CDR)

Threat actors leverage Microsoft Office or PDF files in phishing emails in order 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 types and components, then stripping certain content before 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 known-good parts of the original files.

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 business email compromise. One layer is based on technology, while the other relies on employee awareness. End users should be able to distinguish between legitimate emails and phishing attempts; otherwise, relying solely on technical controls may not suffice in defending against these threats. End-user awareness training and periodic assessments are key differentiators in effectively combating business email compromise.

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 on-prem Exchange servers, where administrators add the application server’s IP address as a trusted SMTP relay to send email notifications/ 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 the list of all email addresses configured on the AD), leading to business email compromise. 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 coming from a trusted partner organization. Having the following settings on the email gateway of the organization and its partners can help eliminate emails claiming to be from trusted partners.

SPF

SPF stands for (Sender Policy Framework) .By adding an SPF record, you are telling the recipient organization what email infrastructure you are using. So, when someone receives an email from you, it will first check where the email is coming from and then check the SPF records to determine where this email is supposed to come from. 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 the email systems, it tells the recipient email gateway what to do with the email if it has no SPF and 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 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 business email compromise-related attacks.

The following are a few basic hygiene conditional access policies that help the organization to prevent threats related to BEC (business email compromise).

• [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