{"id":58246,"date":"2025-03-05T00:00:00","date_gmt":"2025-03-05T00:00:00","guid":{"rendered":"urn:uuid:bda21144-e6f1-939b-937b-1a8844d92521"},"modified":"2025-03-05T00:00:00","modified_gmt":"2025-03-05T00:00:00","slug":"from-event-to-insight-unpacking-a-b2b-business-email-compromise-bec-scenario","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/from-event-to-insight-unpacking-a-b2b-business-email-compromise-bec-scenario\/","title":{"rendered":"From Event to Insight: Unpacking a B2B Business Email Compromise (BEC) Scenario"},"content":{"rendered":"

<\/p>\n

<\/div>\n

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.<\/p>\n

To seem legitimate, the \u201cFrom\u201d field of the email contained the intended recipient between Partner A or Partner B, but the \u201cReply-To\u201d was still the threat actor\u2019s email address \u2013 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.<\/p>\n

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.<\/p>\n

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\u2019s bank account.<\/p>\n

The scheme looks planned and deliberate, as can be seen in the timeline below:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Time<\/td>\nDetails<\/td>\n<\/tr>\n
The email threads below were sent between Wednesday and Thursday.<\/i><\/td>\n<\/tr>\n
T+0:00<\/td>\nPartner A sends an email reminder to Partner B, copying (CC) Partner C.<\/td>\n<\/tr>\n
T+4:30<\/td>\nThreat Actor \u201creplies\u201d to the same email meant for Partner B, with updated bank information.<\/p>\n

This is not a reply though; it\u2019s a new email as evidenced by the Message-ID<\/b> 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<\/b> also was defined to be under the threat actor\u2019s control.<\/p>\n<\/td>\n<\/tr>\n

T+11:00<\/td>\nThreat Actor \u201creplies\u201d again, but this time through the compromised email account of Partner C. The email has the same content as the previous reply.<\/td>\n<\/tr>\n
T+15:00<\/td>\nPartner B confirms the invoice and informs \u201cPartner A\u201d (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. <\/td>\n<\/tr>\n
Friday, Saturday, and Sunday passes.<\/td>\n<\/tr>\n
T+5.02 days<\/td>\nPartner A replies with the correct business details to \u201cPartner B\u201d (disguised threat actor). This is the same email where 5 out of the 6 recipients are threat actor-controlled addresses.<\/td>\n<\/tr>\n
T+5.17 days<\/td>\n\u201cPartner A\u201d (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.<\/td>\n<\/tr>\n
T+5.64 days<\/td>\nPartner B deposits the money to the Threat Actor’s bank account.<\/td>\n<\/tr>\n
T+5.66 days<\/td>\nPartner B informs \u201cPartner A\u201d (disguised threat actor) that the deposit has been made.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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.<\/p>\n

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.<\/p>\n

We\u2019ve 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 \u201creal\u201d 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. <\/p>\n

Can this be avoided? Not entirely, but it can be made difficult to accomplish.<\/b><\/p>\n

Before we address that question, let\u2019s look at this incident through MITRE ATT&CK<\/a> techniques:<\/p>\n