Ciberamenazas
From Event to Insight: Unpacking a B2B Business Email Compromise (BEC) Scenario
Trend Micro™ Managed XDR assisted in an investigation of a B2B BEC attack that unveiled an entangled mesh weaved by the threat actor with the help of a compromised server, ensnaring three business partners in a scheme that spanned for days. This article features investigation insights, a proposed incident timeline, and recommended security practices.
Save to Folio
Key takeaways:
- We recently investigated a B2B BEC attack. This more advanced version of the typical BEC entails an intricately crafted scheme manipulating several entities.
- The incident involves the threat actor taking advantage of a compromised email server to send fraudulent emails.
- Out of the details we have gathered, we constructed a presumed incident timeline showing how the entire operation spanned for days.
- We also identified the MITRE ATT&CK techniques used in this scenario, as well as additional security controls that could be implemented.
- This article also provides recommendations that help organizations proactively secure their systems and mitigate the risks from a B2B BEC attack.
When an organization is subject to a Business Email Compromise (BEC), a single email could result in substantial monetary losses. Threat actors employing such tactics could employ different techniques, ranging from simple to advanced, and have seen increased activities yearly.
A recent investigation examined not a typical BEC scenario where a threat actor simply sends a fraudulent email in the hopes of tricking a victim. Instead, this B2B BEC scheme involved abusing the implicit trust between relationships amongst business partners, patiently weaved by the threat actor within days.
The main components of the incident are as follows:
- Three business partners (Partner A, Partner B, and Partner C) exchanging business transactions via email
- A compromised email server used to send the BEC emails, controlled by the threat actor
- The threat actor, who has full visibility of all email conversations between the three business partners
In this compromise, several methods were exploited, which include gaining access to various email accounts, resembling an account takeover (ATO). Analyzing the entire email compromise entails looking at multiple copies of the same emails from all parties, emphasizing the complexity of analyzing such an incident, as a partial analysis (one set of sender/receiver) doesn’t give a full picture of the entire email flow.
Read on to discover more about the presumed incident timeline, our recommendations on making such compromises harder accomplish, and some ideas that can help in detecting and mitigating such attacks should one be carried out against your organization.
Incident timeline
When the Managed XDR team was asked to assist in investigating this B2B BEC incident, we analyzed the telemetry collected by the Trend Micro Email Sensor using Trend Vision One™ as well as email headers exported from several users (both senders and recipients of the email conversations). These helped in reconstructing certain key details about the incident. The compromise comes in two phases, as shown in the diagrams below:
As only Partner B is visible from our end, the initial compromises to take over different portions of the conversation had likely occurred outside our visibility. Also, the third-party email server is owned by another legitimate organization, and while it is not part of the email conversation, it was used to send the BEC emails.
What is noteworthy about the entire conversation is that the threat actor seemingly had visibility for all the email exchanges across the three business partners. In fact, between step 2 and step 3, we have found evidence that suggests that the reason why the threat actor sent the same email again is because Partner B’s email system rejected the initial email that the threat actor sent through the compromised third-party email server.
Another important aspect is that the threat actor waited around 4.5 hours later to start positioning themselves into the email conversation. The recipient in Partner B, receiving the email later in the day, assumed that Partner A discovered a problem with their initial bank. Rather than sending the new (and fraudulent) banking information from the initial email which would’ve caused a concern, the threat actor waited for a conversation line to be built. However, both emails in Step 2 and Step 3 contained an updated set of wiring instructions from Partner A, asking the recipient in Partner B to send the money to the fraudulent account instead.
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.
- 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