How a Business Email Compromise Begins

Introduction

Last week I wrote about email forensics and how seemingly normal messages can play a role in larger investigations. A few days after publishing that article, I received a textbook example of a phishing email that serves as the starting point for a business email compromise, with the potential to lead to financial loss, business disruption, and other downstream impacts.

The Email

The message read:

There is absolutely nothing threatening or malicious here. If it reached my inbox through contact forms on website referrals, it would have passed without any second thoughts.

There is not a hint of any kind of malicious intent either:

• It has no malware in it
• There are no links to click
• There are no attachments to download
• There is no urgency to act
• There is no request for any kind of action at all

What actually matters is how well crafted this email is. It reads as a potential client inquiry, hence making it seem innocent.

Why This Is Business Email Compromise

This email is not a fraud itself. It is the first stage in a process known as business email compromise.

During this stage the attacker is attempting to:

• Identify the person who would be interested in responding to an email
• Start a conversation with that person
• Build some sort of credibility

Once the response comes, the attacker will keep engaging and eventually present his or her fraudulent scenario. That scenario could be related to some sort of transaction, or even simply a business matter, something that would prompt the victim to trust the other party.

The conversation will eventually lead to an actual fraud attempt, which is typically masked by previous conversation.

That is why the initial email is not a threatening thing at all. The attacker needs to start a discussion first.

The Detail That Triggered Further Examination

One might assume that this email came from a real, trusted domain:

cconciliacion@personeriacartagena.gov.co

Notice how the domain is real and belongs to a public entity. There are no typos or lookalikes.

Also, this email had passed all necessary tests:

• SPF confirms the authenticity of the server sending the email
• DKIM confirms that the email was not altered when reaching the mailbox
• DMARC confirms the authenticity of the sender

As one would expect, most of the people would take it for granted that this email came from a trusted source.

However, one thing bothered me:

Reply To: joseph.d@bernicsolarenergy.com

That was the thing that did not make any sense.

Email Header Analysis

Next thing to do after noticing this is analyzing email header.

And what header told us?

It told us that:

• Email was delivered through a trusted mail server from a legitimate domain
• Message was sent via authenticated SMTP channel, which means someone actually logged into the account to send the message
• The computer used to send the email is not part of the organization domain

This is crucial information.

Email was not spoofed in any way, it was sent through a real email server using real user credentials. That is how the SPF, DKIM, and DMARC tests passed.

But if someone used a system of an external nature to do it, that means someone else accessed the email account in question.

Open Source Forensic Analysis

To get a better understanding of where this email actually came from, I took a closer look at three things: the sending domain and mail server, the originating IP address, and the Reply To domain.

The sender address, cconciliacion@personeriacartagena.gov.co, belongs to a legitimate Colombian government entity. The domain itself has a live website and checks out. This is not a fake or lookalike domain. The email really did come from that domain, which is what makes this more convincing.

From the email header, I was able to identify the mail server that sent the message. That server also ties back to the same domain, which explains why the email passed SPF, the server is allowed to send email for that domain, DKIM, the message was not altered, and DMARC, everything lines up with the sender. In other words, from a technical standpoint, the email looks legitimate.

That is where most people would stop.

I took it a step further and looked at how that mail server is set up using open source tools. The server is running multiple services on a single machine, including email, web hosting, FTP, DNS, and even database services. That kind of setup is more typical of shared or lower cost hosting than a locked down environment. Systems like that tend to have more exposure and are more likely to run into issues like credential compromise.

Next, I looked at the originating IP address listed in the header. This is the system that actually sent the email to the mail server. That IP does not belong to the government organization and does not resolve back to anything tied to them. Instead, it looks like it is coming from external hosting infrastructure. Put simply, the email was sent through a legitimate server, but it was initiated from outside of that organization.

Finally, I checked the Reply To domain, bernicsolarenergy.com. Based on public registration data, it is a recently created domain and has no connection to the government entity in the sender address. That is important, because it shows where the conversation is supposed to go if someone replies.

When you put all of that together, the picture becomes pretty clear:

• The domain is real and belongs to a legitimate organization
• The email was sent through an authorized mail server and passed all standard checks
• The message itself was submitted from an external system
• Any reply gets redirected to a completely separate, newly registered domain

At that point, the most likely explanation is that a legitimate mailbox was accessed by someone who should not have access to it. The attacker is using that trust to get the conversation started, and then moving it over to infrastructure they control once someone responds.

That combination is very common in business email compromise cases, and it is exactly why emails like this can slip past both technical controls and initial human judgment.

Conclusion

The email in question is not the actual attack. It was the beginning of one.

It contains neither malicious software, nor any links or request to provide funds; it is simply an invitation to have a discussion. As it is typical for cases of a business email compromise attack, its objective at this stage is to elicit a reply from a recipient.

From a forensic point of view, the lesson that can be learned here is simple. SPF, DKIM, and DMARC verify whether the sender is actually able to send messages from the particular server but do not verify that the person who uses the server is indeed authorized to do it.

In the case of regular users, the lesson can be put differently. There was nothing suspicious about this particular email until it was analyzed by professionals but it might have led to serious problems had the recipient responded to it.

Obviously, the present example provides a simplified description of just one email, and it does not give a comprehensive idea of the process of email forensics that usually involves header analysis and infrastructure investigation and comparison of data from different sources.

It should suffice to say that one should not ignore anything that seems odd in a message.