← Back to list

Investigating a Business Email Compromise (BEC) Attack: A Forensic Analysis of “Operation Phantom…

By Emmanuel Nkwocha

Emmanuel Nkwocha · 2026-06-05 21:40 · 0 claps · 10.3 min read
#business-email-compromise #phishing-email #phishing-awareness #thread-hijacking
Open on Medium ↗
Wiki topics: 🔒 · Cybersecurity 🥊 · Combat Sports

Investigating a Business Email Compromise (BEC) Attack: A Forensic Analysis of “Operation Phantom Invoice”

By Emmanuel Nkwocha

Introduction

Business Email Compromise (BEC) attacks have become one of the most financially damaging cyber threats facing organizations today. Unlike traditional phishing attacks that rely on malicious links or malware attachments, BEC attacks exploit trust, authority, and human psychology to manipulate employees into transferring money or sensitive information.

In this project, I conducted a forensic investigation of a simulated BEC campaign known as Operation Phantom Invoice. The objective was to analyze three suspicious email messages, identify indicators of compromise, trace the attacker’s infrastructure, assess the business impact, and recommend security controls to prevent future attacks.

The investigation revealed how a threat actor attempted to trick the Accounts Payable department of a logistics company into authorizing a fraudulent wire transfer of $47,000 by impersonating both the Chief Financial Officer (CFO) and a trusted vendor.

This article documents my investigative process, findings, lessons learned, and will educate my audience.

Scenario Overview

The target organization, Nexus Logistics Group, experienced a sophisticated phishing campaign spanning three emails over five days.

The attacker’s goal was simple:

Convince the finance department to send $47,000 to a fraudulent bank account controlled by the attacker.

To achieve this, the threat actor:

· Impersonated the company CFO

· Impersonated a trusted vendor

· Created lookalike domains

· Used psychological manipulation

· Avoided attachments and links to evade detection

Fortunately, the payment was intercepted before any money was transferred.

My task was to perform a forensic analysis of the email evidence and determine how the attack was conducted.

Objectives of the Investigation

The investigation focused on:

· Identifying suspicious sender addresses

· Examining email headers

· Verifying SPF, DKIM, and DMARC results

· Tracing email routing paths

· Analyzing social engineering tactics

· Identifying Indicators of Compromise (IOCs)

· Mapping attacker behavior to MITRE ATT&CK

· Recommending mitigation strategies

Step 1: Identifying Domain Spoofing and Typosquatting

Emails 1 & 3

I used Thunderbird to access the .eml files given. Thunderbird is a desktop application that downloads and stores emails locally on the computer. Thunderbird offers proper rendering of the email header for easier analysis, and preserves the original email structure during investigation.

The first email was sent on the 11th of March, 2024

First email (.eml file)

First email (.eml file)

Third email

Third email

To carry out a proper analysis, I opened the email header to have more information about this email. To do this on Thunderbird I used the shortcut ctrl+u to open the header and other details:

The first indicator appeared in the sender’s address:

Legitimate domain: nexus-logistics.com

Malicious domain: nexus-Iogistics.com

At first glance, both domains appear identical. However, the attacker replaced the lowercase letter “l” with an uppercase “I”. This technique is known as a homoglyph attack or typosquatting. The purpose is to deceive users into believing the email originated from a trusted source. It takes patience, attention to details to spot such a trick.

Lesson Learned: Attackers often rely on visual deception rather than technical exploits. Security analysts must carefully inspect domain names character by character when investigating suspicious emails.

Step 2: Examining Email Header Anomalies

One of the most important skills in email forensics is header analysis.

When reviewing the email headers, several inconsistencies emerged.

From Address

Displayed:

j.hargrove@nexus-Iogistics.com

Receiver:

sarahokonkwo@nexuslogistics.com

Reply-To Address

j.hargrove.cfo@gmail.com

Return-Path

bounce@smtp.webmailpro.xyz

This immediately raised suspicion.

Although the email appeared to come from the CFO, any reply would actually be redirected to a Gmail account controlled by the attacker.

This tactic allows attackers to continue the conversation outside the organization’s monitored email infrastructure.

Lesson Learned

The “From” field alone should never be trusted.

Analysts must always compare:

· From

· Reply-To

· Return-Path

to identify redirection attempts.

Step 3: Validating Email Authentication

One of the most valuable parts of the investigation involved analyzing email authentication mechanisms. Using MX ToolBox I examined three critical protocols:

SPF (Sender Policy Framework)

SPF verifies whether the sending mail server is authorized to send email for a domain.

Result:

SPF = Fail

This indicated that the sending server was not approved by the domain owner.

DKIM (DomainKeys Identified Mail)

DKIM uses cryptographic signatures to verify email integrity.

Result:

DKIM = Fail / None

The email lacked a valid digital signature.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC combines SPF and DKIM to determine whether an email should be trusted.

Result:

DMARC = Fail

The sender failed authentication and alignment checks.

Lesson Learned

SPF, DKIM, and DMARC are critical controls for identifying spoofed emails.

A failed result across all three mechanisms is a strong indicator of phishing or impersonation. But it is not always the case. There can be instances where an email fails these mechanisms but is not really malicious, it requires the skills of the analyst to dig deeper to find out more before arriving at a conclusion.

It is also possible for a malicious mail to scale through these mechanisms and pass even while being phishing. One of the reasons is that these attackers can get a domain and properly set their domain to pass these mechanisms to evade any trace. Attackers are smarter now and the attack landscape is evolving, so defenders must also evolve.

Step 4: Tracing the Email Route

Using the “Received” headers, I traced the origin of the email.

Findings

Originating IP:

185.234.219.101

Host:

smtp.webmailpro.xyz

Geolocation:

Austria

The infrastructure had no connection to either Nexus Logistics Group or the legitimate vendor. This strongly suggested that the emails originated from attacker-controlled infrastructure or a rented VPS.

The 0 detection score above should not be taken to mean the IP is not malicious. It is possible to see an IP with 0 detection score but still end up being malicious. One of the reasons for this might be because that IP is new and has not been officially reported as malicious to the right authorities. In such a case, a deeper analysis is necessary, just as I did here. I opened the “Relations” page and found several red flags.

Lesson Learned

Email headers often reveal the true origin of a message even when the visible sender information has been spoofed.

Email 2

Steps 1 to 4 were conducted on the second email as well.

The second email, dated 12 March 2024 at 15:33:39, was sent to **sarah.okonkwo@nexuslogistics.com as a follow-up to the phishing email delivered the previous day. Unlike the first email, which impersonated James Hargrove, CFO of Nexus Logistics, this message adopted a different identity, claiming to originate from “Meridian Freight Solutions — Accounts” using the email address [billing@meridian-freight-solutions.net](mailto:billing@meridian-freight-solutions.net)**.

A comparison of both emails reveals a notable change in sender identity while maintaining several underlying infrastructure similarities. This tactic is commonly used by threat actors to reinforce legitimacy and increase the likelihood of user engagement by creating the appearance of an ongoing business conversation involving multiple parties.

Authentication Analysis

The email failed all major email authentication checks:

· SPF: Fail

· DKIM: No signature present

· DMARC: Fail

The absence of valid authentication mechanisms significantly reduces trust in the sender’s identity and indicates that the message was not authorized by the purported sending domain. The lack of a DKIM signature further suggests that the message integrity could not be verified.

Infrastructure Analysis

Analysis of the email headers identified the following Indicators of Compromise (IOCs):

· Google Mail Server: 209.85.208.45

· Internal Private IP: 10.0.0.22

· Originating Mail Server: smtp.webmailpro.xyz (185.234.219.101)

A key finding is that the originating mail server IP address (185.234.219.101) is identical to the infrastructure observed in the first phishing email. Despite the change in sender identity and domain, both messages originated from the same underlying server, strongly suggesting that they are part of the same phishing campaign.

Reputation and Threat Intelligence Findings

Initial reputation checks showed a 0-detection score for the infrastructure, which may appear benign at first glance. However, a lack of detections should not be interpreted as evidence of legitimacy.

Threat actors frequently register new domains and deploy fresh infrastructure specifically to evade reputation-based detection systems. Since such assets have little historical activity, security vendors may not yet have classified them as malicious.

Further investigation revealed associations between this infrastructure and previously identified suspicious or malicious systems, increasing confidence that the activity forms part of a coordinated phishing operation.

WHOIS and Hosting Analysis

WHOIS investigation of the originating mail server (185.234.219.101) revealed several noteworthy observations:

· The IP address is the same infrastructure used in the first phishing email.

· Geolocation places the server in Austria.

· The IP range belongs to 185.234.219.0/24.

· The infrastructure is hosted by IT Business Solutions MB.

· The registrar is located in Lithuania.

· The hosting organization operates as a Local Internet Registry (LIR).

These findings raise additional concerns. The email claims to originate from a U.S.-based logistics company, yet the supporting infrastructure is hosted through a relatively small provider in Eastern Europe. While this alone does not prove malicious intent, it represents an unusual mismatch that warrants further scrutiny.

The infrastructure was created on 24 November 2023, making it relatively new at the time of the phishing campaign. Newly established infrastructure is frequently leveraged by threat actors because it has not yet accumulated sufficient reputation data to trigger automated security controls.

Further Analysis

Understanding Why There Were No Attachments

Interestingly, none of the emails contained:

· Malicious attachments

· Hyperlinks

· Executables

· PDFs

At first, this appeared unusual. However, it demonstrated a modern BEC technique. Rather than delivering malware, the attacker relied entirely on human manipulation.

This approach helps bypass:

· Antivirus solutions

· Attachment sandboxes

· URL reputation filters

· Secure Email Gateways

Lesson Learned

Not all phishing attacks contain malware. Some of the most dangerous attacks are purely text-based.

Step 6: Analyzing Social Engineering Tactics

The attacker carefully crafted the message to pressure the finance manager into bypassing normal procedures.

Several psychological triggers were identified.

Urgency

“Vendor Payment Authorization Required Today”

The attacker created a false emergency.

Authority

The email appeared to come from the CFO, the attacker tried to use an appeal to authority here. Employees are naturally inclined to comply with executive requests.

Secrecy

The attacker instructed the recipient (Sarah Okokwo) not to discuss the request with others.

Unavailability

The sender claimed to be in meetings and unreachable by phone. This prevented verification.

Lesson Learned

Social engineering is often more effective than technical exploitation. Many successful attacks exploit human behavior rather than software vulnerabilities.

Investigating Domain Registration

WHOIS analysis revealed:

· All the three emails sent, despite having different sender names and contents are from the same domain, with the IP 185.234.219.101. Domains were less than 14 days old

· Registered using privacy protection services

· Had no established reputation

Freshly registered domains are commonly used in phishing operations because they have little historical data available for security systems to evaluate.

Lesson Learned

Domain age can be a valuable threat intelligence indicator when assessing email legitimacy.

Evaluating the Email Client

The headers revealed the following X-Mailer value:

The Bat! 10.3 (UNREG)

This was unusual because legitimate enterprises typically use:

· Microsoft Outlook

· Microsoft 365

· Google Workspace

The use of an unregistered email client further supported the likelihood of malicious activity.

Lesson Learned

Even seemingly minor header fields can provide useful forensic clues.

Mapping the Attack to MITRE ATT&CK

To understand the adversary’s behavior, I mapped the observed activities to the MITRE ATT&CK framework.

Techniques Identified

T1566.002 — Spearphishing

T1583.001 — Domain Registration

T1656 — Social Engineering

T1036 — Masquerading

This exercise helped translate raw forensic evidence into standardized threat intelligence terminology.

Lesson Learned

MITRE ATT&CK provides a structured method for describing attacker behavior and communicating findings across security teams.

Indicators of Compromise (IOCs)

The investigation uncovered several high-confidence indicators:

· nexus-Iogistics.com

· meridianfreight-solutions.net

· smtp.webmailpro.xyz

· 185.234.219.101

· j.hargrove@nexus-Iogistics.com

· billing@meridianfreight-solutions.net

· j.hargrove.cfo@gmail.com

These indicators could be used to:

· Block future attacks

· Create SIEM detection rules

· Enhance threat intelligence feeds

Security Recommendations

Based on the findings, I recommended several controls.

Technical Controls

· Enforce DMARC policy with p=reject

· Implement lookalike domain detection

· Deploy advanced email security solutions

· Enable external sender warning banners

Operational Controls

· Require out-of-band verification for payment requests

· Enforce dual approval for wire transfers

· Conduct regular BEC simulation exercises

· Improve security awareness training

Key Skills Demonstrated

This project strengthened my practical experience in:

· Email Forensics

· Phishing Analysis

· Business Email Compromise Investigation

· Threat Intelligence

· MITRE ATT&CK Mapping

· Header Analysis

· IOC Identification

· Incident Response

· Security Control Recommendations

· Risk Assessment

Email Thread Hijacking

Email thread hijacking takes place when a third party places himself/herself in between an ongoing conversation between two or more parties and eventually hijacks the conversation from one of the parties, pretending to be that party going forward.

In the course of this project, one thing I was to look out for was the trace of thread hijacking in this attack. At first, I was of the opinion that thread hijacking was taking place when I saw a different domain continuing the conversation and requesting for the same money. But giving it a second thought, several things corrected that thought pattern. Why would a new attacker who had intercepted a communication provide the same account details with the original attacker? They would definitely try to redirect the money by providing a different account.

Another point worthy of note is that there was no concrete evidence to show that the CFO’s email was breached, thereby giving the attacker access to an ongoing conversation that would be prey to hijacking. In this case, all three emails were crafted by the attacker.

While it showed patterns of how email thread hijacking works, it does not show any proof to that effect.

Conclusion

Operation Phantom Invoice demonstrates how modern cybercriminals increasingly rely on deception rather than malware. Through domain impersonation, spoofed identities, psychological manipulation, and carefully crafted email infrastructure, the attacker nearly convinced the finance department to authorize a fraudulent $47,000 payment.

By analyzing email headers, authentication failures, infrastructure artifacts, and social engineering techniques, I was able to reconstruct the attack chain and identify the weaknesses that enabled the campaign to progress.

The exercise reinforced an important lesson:

Organizations must protect not only their systems but also their business processes. Strong email authentication, financial verification procedures, and employee awareness remain some of the most effective defenses against Business Email Compromise attacks.


메타데이터
post_id
16f6f2b7dbe3
slug
investigating-a-business-email-compromise-bec-attack-a-forensic-analysis-of-operation-phantom-16f6f2b7dbe3
url
https://medium.com/@emmanuel.nkwocha00/investigating-a-business-email-compromise-bec-attack-a-forensic-analysis-of-operation-phantom-16f6f2b7dbe3
canonical_url
https://medium.com/@emmanuel.nkwocha00/investigating-a-business-email-compromise-bec-attack-a-forensic-analysis-of-operation-phantom-16f6f2b7dbe3
author_url
https://medium.com/@emmanuel.nkwocha00
status
ok
fetched_at
2026-08-09 19:35:47