From Event to Insight: Unpacking a B2B Business Email Compromise (BEC) Scenario

In the second phase, the threat actor has fully inserted themselves to separate the conversations between the two companies. It is important to note that there are about 4-6 recipients in this running email thread, and the threat actor was gradually swapping out the recipients to an email account they can control.

To seem legitimate, the “From” field of the email contained the intended recipient between Partner A or Partner B, but the “Reply-To” was still the threat actor’s email address – for both emails going to Partner A and Partner B, as well as Partner C. As for the email content, the threat actor mimicked either Partner A or Partner B, utilizing the same writing style (salutation, email footer, and choice of words), often keeping it short.

Several BEC emails were sent through the third-party email server. The said server seems to have an insecure configuration, causing the email to pass the Sender Policy Framework (SPF) authentication. Whether or not this was due to an initial misconfiguration of the third-party email server or the threat actor had the capability to compromise the email server configuration is unknown.

At this point, the threat actor then confirmed to Partner B details that Partner A had shared, modifying the information to have the updated (and fraudulent) banking information from the first phase. However, Partner A and Partner B believed they were talking to the correct email recipients. This led to Partner B eventually depositing the funds into the threat actor’s bank account.

The scheme looks planned and deliberate, as can be seen in the timeline below:

Time	Details
The email threads below were sent between Wednesday and Thursday.
T+0:00	Partner A sends an email reminder to Partner B, copying (CC) Partner C.
T+4:30	Threat Actor “replies” to the same email meant for Partner B, with updated bank information. This is not a reply though; it’s a new email as evidenced by the Message-ID and relative email headers, sent through the compromised email server. While preserving the same display name, 1 out of the 6 email addresses was replaced with a threat actor-controlled one. Reply-To also was defined to be under the threat actor’s control.
T+11:00	Threat Actor “replies” again, but this time through the compromised email account of Partner C. The email has the same content as the previous reply.
T+15:00	Partner B confirms the invoice and informs “Partner A” (disguised threat actor) that they will review the submitted information, asking for business details. The actual replies go to the Threat Actor, and the email that Partner A (the real one) gets has 5 out of 6 original recipients replaced already.
Friday, Saturday, and Sunday passes.
T+5.02 days	Partner A replies with the correct business details to “Partner B” (disguised threat actor). This is the same email where 5 out of the 6 recipients are threat actor-controlled addresses.
T+5.17 days	“Partner A” (disguised threat actor) sends a follow-up email to Partner B, confirming the business details required and the updated banking information that was formerly (the previous week) requested.
T+5.64 days	Partner B deposits the money to the Threat Actor’s bank account.
T+5.66 days	Partner B informs “Partner A” (disguised threat actor) that the deposit has been made.

At the end of this timeline, Partner A prompted Partner B for the confirmation of the transfer about 12 days after the initial reminder of the invoice. By then, the funds have been fully transferred to the threat actor.

It should also be noted that the recipients from both Partner A and Partner B were still sending emails to and from each other, in separate conversations from this email thread. For most email clients, auto-completed email addresses are populated if an end-user has replied to that email address once before. Thus, the threat actor selectively replaced the auto-completed email addresses with the real and intended recipients, so that the conversations would happen naturally.

We’ve counted about 5 other email threads, beyond the initial invoicing (where funds were transferred), and where the original sender from either Partner A or Partner B was sending emails to threat actor-controlled email addresses, but the “real” and intended email recipient would get the email later. But again, since Partner A, Partner B, and Partner C are expected email senders and recipients, all parties saw was that the email conversations were flowing. 

Can this be avoided? Not entirely, but it can be made difficult to accomplish.

Before we address that question, let’s look at this incident through MITRE ATT&CK techniques:

• Having various means of email collection (T1114) of their targets, the threat actor would have been informed of such an opportunity when such conversation is happening within the target organizations.
  • While it was not directly confirmed in this incident, one very common way this could happen is to have valid domain accounts taken over (T1078), and then utilize some form of email forwarding rule (T1114.003).
• To further facilitate email sending, the threat actor also compromised a third-party email server (T1584.004) that had little to no restrictions. The compromised email server was of a valid organization too, so everything about it seems legitimate, but it had very little control for outbound emails.
• Email accounts are set up to mimic the email login – e.g., instead of having user1[@] partnerA.com, it would be user1[@] free-email-domain.com that would be used.  These were previously established (T1585.002) based on the knowledge of the Threat Actor for each entity involved in this incident as they were able to create various email addresses for different individuals across Partner A, Partner B, and Partner C, setting the display name of such email addresses to mimic the real individual.
• The threat actor utilizes the Trusted Relationship between all parties (T1199) and is heavily reliant on this to be pre-existing throughout the entire B2B BEC incident.
• The result is financial theft (T1657) and, for the owner of the compromised email server, resource hijacking (T1496).

With multiple aspects to consider, a single organization can only implement controls within an environment that it has an influence on. However, for a single organization, it would be advantageous to look at ways to make it at least a bit more difficult for threat actors to launch successful B2B BECs.

The recommendations below would mostly apply if your organization had been targeted in a similar fashion:

1.      Check with your email security vendor about implementing additional email security controls, such as DMARC (Domain-based Message Authentication, Reporting & Conformance), DKIM (DomainKeys Identified Mail), and SPF (Sender Policy Framework)

In this incident, the emails that the threat actor had created had obvious signs of those emails failing these checks:

ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=softfail (sender ip
is 11.22.33.44) smtp.rcpttodomain=PartnerA.com smtp.mailfrom=PartnerB.com;
dmarc=fail (p=none sp=none pct=100) action=none header.from=PartnerB.com;
dkim=none (message not signed); arc=pass (0 oda=0 ltdi=0 93)
ARC-Authentication-Results: i=1; rspamd-587694846-cqc8b; auth=pass
smtp.auth=spamcontrol26 smtp.mailfrom=finance-person@PartnerB.com
Authentication-Results: spf=softfail (sender IP is xx.yy.aa.bb)
smtp.mailfrom=PartnerB.com; dkim=none (message not signed)
header.d=none;dmarc=fail action=none header.from=PartnerB.com;compauth=other
reason=501
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
PartnerB.com discourages use of xx.yy.aa.bb as permitted sender)

(note: IP addresses and email domains are masked or removed)

But because the DMARC policy for emails that fail validation was set to “action=none”, then such emails are simply granted passage and arrived at Partner A’s mailbox. A strict DMARC policy would’ve helped in this case, as these emails would not pass the verification or, at the very least, the email should have been tagged in the subject line with labels such as [SPAM] or [Suspicious] and delivered to the spam or junk folder.

Setting this globally for all email domains should be discussed with business stakeholders, as it will affect the deliverability of emails sent from the domain names. However, in this case for B2B transactions, the two organizations may agree to implement such email controls for email conversations that involve monetary transactions.

2.      Consider digitally signing the emails, especially between individuals who transact financially through email

The emails that the threat actor had sent through the compromised email server had the following email headers:

Received: by webmail.emailsrvr.tld (Authenticated sender:
compromised-account@compromised.email.server, from: finance-person[@]PartnerB.com)  with HTTP
Authentication-Results: spf=pass (sender IP is xx.yy.aa.bb)
smtp.mailfrom=compromised.email.server; dkim=none (message not signed)
header.d=none;dmarc=fail action=none header.from=PartnerB.com;compauth=fail
reason=001
Received-SPF: Pass (protection.outlook.com: domain of compromised.email.server designates
xx.yy.aa.bb as permitted sender) receiver=protection.outlook.com;
client-ip=xx.yy.aa.bb; helo=smtp116.sub.emailsrvr.tld; pr=C
X-Auth-ID: compromised-account@compromised.email.server
Reply-To: finance-person[@]free-email-domain.com

(note: IP addresses and email domains are masked or removed)

It is evident in the headers above that the email passed SPF, even though the sender was not using their designated email address and had a different Reply-To.

The DMARC settings mentioned above would have helped similarly. Another measure that could be considered would be the use of email digital signatures, enhancing an email conversation’s confidentiality and integrity. This would validate the email sender’s authenticity while ensuring that the email was not altered from its original form.

Combined with best practices such as enabling multi-factor authentication (MFA) for network and auditing logins, emails stamped with digital signatures would make it difficult to craft messages claiming to be coming from someone when it was actually sent from another source.

Again, setting this company-wide and globally for all email domains could be a good idea, but this should be discussed with business stakeholders. For B2B transactions, the partner organizations might enforce such email controls to ensure that emails are not tampered with and are coming from an email account that has the correct and valid digital signature.

3.      Extended auditing for specific individuals, especially those who transact financially through emails

The lucrative targets for B2B BEC, or even just BEC in the usual sense, are the high-profile members of the organization. Thus, extended monitoring and alerting might be warranted. Depending on the capability of your security tools, the following alerting use cases may be possible:

• MFA has been disabled
• Anomalous events in the logon platform (such as Impossible Travel)
• Monitor for suspicious activities such as unprompted creation of forwarding rules, as this is one of the early indicators observed in BEC operations

Organizations could check with their email service or security provider for BEC use cases, ATO monitoring, or similar activities such as identity protection, and ask them to prioritize this for the company.

4.      Target specific education and processes for these high-profile users

As one of the exploited factors in this situation is implicit trust between certain individuals within two or more organizations, those sets of high-profile users may be subject to another subset of education and training. Organizations could go through phishing training, and specific to high-profile users, conduct B2B BEC-type simulations. This will allow them to be more vigilant instead of just trusting a name that comes across their inbox, embedding a practice of scrutinizing emailed instructions that mention changes in accounts for sending money.

In the incident discussed in this article, several email addresses between the different partner organizations included in the carbon copy (CC) on the email thread were replaced with other addresses based on a free email service. While it would understandably be difficult for the users to notice anything unusual, it still helps to pay attention to suspicious changes such as this, especially when the email requests a fund transfer.

5.      Establish a validation protocol between your partners

Analyzing the incident timeline, it would have been possible to verify the instructions if there was a way to confirm the sender’s identity through other means on the first day, literally minutes after the threat actor sent the instructions. For example, if there had been an agreement between Partner B and Partner A to validate the email transaction through video/phone calls, then the instructions could’ve been double-checked on the spot.  

As outlined by MITRE’s M1060 guidance, by implementing secure out-of-band communication channels, these alternative paths that are independent of the potentially compromised network might help ensure the continuity and security of critical communications, reducing the risk that adversaries may be able to intercept or tamper sensitive data in the event an attack takes place. Various forms of this exist today, like encrypted messaging apps, secure phone lines, etc.

It could also be process control, whereby account changes, would require verifying the authenticity beforehand – e.g., before sending the email for instructions that affect financial transactions, it would require something more than just an email beforehand. Thus, if an email instruction arrives requiring the change of banking information, this raises an alert since technically they violate a pre-agreed process.

6.      Hunt through emails for violation of processes, amongst high-profile individuals

Performed at least internally within the organization, the standard process should be enforced and monitored. Consider this example:

From: invoicing[@]partner_organizationA.com
To: accounts_payable[@]partner_organizationB.com
Subject: Invoice from <Partner Organization> – reference ticket number
Email characteristics:

• SPF and DKIM configured
• DMARC enforced, with Block Permanently

If that is the pre-agreed standards, then alerting logic can be created if it falls outside those parameters. For Trend Vision One using the Trend Micro Email Sensor, alerting rules can be set with this logic:

(mailFromAddresses: invoicing[@]partner_organizationA.com OR
mailToAddresses: accounts_payable[@]partner_organizationB.com)  AND
(mailMsgSubject:Invoice) AND (mailWantedHeaderValue:dmarc=fail OR
mailWantedHeaderValue:dkim=none) AND (mailDirection:3)

This hunting rule can be expanded or changed depending on the requirements, but it would look for:

• Any emails that are inbound,
• Coming from either invoicing[@]partner_organizationA.com or  destined for accounts_payable[@]partner_organizationB.com,
• Has the pre-agreed email subject, and
• Characteristics of the email – such as SPF, DKIM, or DMARC – that violate the business rules between the two organizations.

More hunting queries are available for Trend Vision One customers with Threat Insights Entitlement enabled

Conclusion

If successful, a business email compromise (BEC) that has been carried out in the right time is costly for an organization. However, it is highly possible that the existing technology implemented by an organization may already have certain email protection features that can help limit the effectiveness of such attacks. Therefore, businesses are encouraged to be mindful of assessing the proper cybersecurity measures with their email service provider and their email security vendor, alongside being aware of the normal business practices – even among trusted business partners.

For example, implementing proper DMARC settings can be an essential safeguard for minimizing the success of BEC. But it’s important to note that while the technology is highly effective, it’s only part of a broader security framework. Specifically, DMARC builds on SPF and DomainKeys Identified Mail (DKIM), which are also core best practices recommended by industry groups like M3AAWG and endorsed by Google. However, organizations looking to implement DMARC may face challenges due to its complexity. In such cases, it’s crucial for organizations to collaborate with their email, messaging, and collaboration vendors to ensure proper configuration and integration.

It might also help to use specifications such as BIMI allow displaying an organization’s brand logo on emails that pass DMARC validation. This helps recipients distinguish the emails that legitimately came from a trusted source from the messages from unauthenticated resources.

Proactive security with Trend Vision One

Trend Vision One is an enterprise cybersecurity platform that simplifies security and helps enterprises detect and stop threats faster by consolidating multiple security capabilities, enabling greater command of the enterprise’s attack surface, and providing complete visibility into its cyber risk posture. The cloud-based platform leverages AI and threat intelligence from 250 million sensors and 16 threat research centers around the globe to provide comprehensive risk insights, earlier threat detection, and automated risk and threat response options in a single solution. 

Trend Vision One Threat Intelligence 

To stay ahead of emerging threats, Trend Vision One customers can access a range of Intelligence Reports and Threat Insights. Threat Insights helps customers stay ahead of cyber threats before they happen and allows them to prepare for emerging threats by offering comprehensive information on threat actors, their malicious activities, and their techniques. By leveraging this intelligence, customers can take proactive steps to protect their environments, mitigate risks, and effectively respond to threats. 

Trend Vision One Threat Insights App

Read More HERE