Business Email Compromise and Email Header Analysis

Introduction

I have recently had cause to dive into Business Email Compromise (CEO Fraud, Supplier Fraud, email redirect etc.). This then leads to email header analysis as that is your first step in trying to identify the author of the fraudulent emails. So having done the research it would be a shame to let it go to waste. Let’s go!

TL;DR

I can’t shorten down the Business Email Compromise section any further, you’re just going to have to read that.

As for email header analysis, this can be summarised to two main points:

1. Learn how to view the headers in whatever client or service you use.
2. Use an email header analysis tool to analyse the headers. Links below.

Business Email Compromise

Simply put Business Email Compromise (BEC) is a type of fraud which tries to dupe one party into transferring funds to the fraudster in the belief that the transfer is legitimate. There are a number of techniques that fraudsters use to accomplish the duping stage, and they largely rely on social engineering.

Other names for business email compromise include:

• CEO Fraud: Where the fraudsters impersonate the CEO (or other high level staff member) and send an email to a member of staff, with authority to transfer funds, ordering them to make a transfer to a bank account in control of the fraudsters.
• Supplier Fraud: Where the fraudsters impersonate a legitimate supplier to the company they are trying to dupe. The fraudsters send emails demanding payment for services.
• Email Redirect: Fraudsters somehow find a way to intercept emails between a company and a supplier. Once in that position they can then reply to legitimate emails containing invoices with reasonable seeming requests to change bank details.

What is common among these types of fraud is that the fraudsters will try to force the recipient into acting without much time to think by injecting a sense of urgency into the request. In the case of CEO fraud they will also encourage secrecy to prevent a recipient from discussing the matter with other colleagues.

A typical BEC operation runs along 5 main steps:

1. Targeting
2. Reconnaissance
3. Compromise
4. Impersonation
5. Money Transfer

Targeting – Fraudsters choose companies or organisations to target.

Reconnaissance – Fraudsters conduct OSINT on publicly available info about company and staff looking for personal information that they can use as part of an attack. Company websites are often scraped in this phase to pull metadata and other documents to find even more information they can use, such as usernames, email addresses, sensitive documents which are mistakenly publicly accessible.

Compromise – Fraudsters hack into relevant email accounts. They use social engineering techniques e.g. spear phishing. They send emails with malware links or attachments to targeted accounts to attempt to gain access to the email account holder. Once access is gained it allows for further reconnaissance to ascertain which staff members are responsible for fund transfers.

Impersonation – Once access is gained to a relevant email account, fraudsters can send emails impersonating that person. A CEO (or other high level staff member in company) or supplier are common targets. Sent emails composed by the fraudsters contain instructions to pay moneys or change beneficiary bank account details depending on who is being impersonated. Usually, these instructions convey a sense of urgency and or secrecy as discussed above. What’s worse is that email account compromise is not always necessary. Fraudsters send emails from addresses with domains which are very similar to target domain. Fraudsters also use the email redirect technique to direct emails to an account they control, they can then carry out replies to legitimate emails thus increasing their chances of being trusted by the recipients.

Transfer Money – Target is tricked into transferring funds to a fraudster controlled bank account.

Mitigation / Prevention

There’s no point discussing BEC without adding some solid recommendations as to how to deal with BEC. This is not an exhaustive list, but it does represent a good start on the path to protection against BEC.

• Staff awareness training and education. Empower staff to speak up if they receive a suspicious email. Can be tested with security team by use of phishing exercises.
• Stress the importance of vigilance. Timely reporting of suspected fraud. Train staff to not open suspicious links or email attachments.
• Staff should be on alert when senior members of staff send them unusual emails.
• Urgent requests should be viewed with suspicion, especially if they also urge secrecy and particularly if they are contrary to normal policies and procedures.
• Implementation of control procedures should be conducted. For example unusual or large transfer requests should be subject to a secondary confirmation, whether by phone call or in person with the requester. Only previously agreed phone numbers should be used for such confirmations and not the number included in the email expressing urgency.
• Automated detection systems (possibly using AI or ML) should be strongly considered. Could be used to flag suspicious email circumstances such as incorrect domain names, inconsistent “from” and “reply to” fields.
• Configure email systems to display an indicator when an email is received from an external address.
• AI and ML can be used to automate analysis of email contents. Can look for indicators of impersonation by the sender (urgency, secrecy, signed with senior staff signature).
• Review info on company’s website and staff’s social media accounts. Efforts should be made to reduce discoverable footprint.
• Reinforce importance of data security, encrypt all the things.

Email Header Analysis – The Crawling Method

Below we’ll look at two examples of headers to see what to look out for.

So you’ve received a suspicious email, now you want to try to establish its author. In the early days of email and the internet this was much easier. There was also a lot less cyber crime and so it was not as necessary. However, in Today’s world of privacy and GDPR it’s more difficult to find anything useful in an email header. A lot of that is to do with companies email services, like Gmail for example, stripping or obfuscating originating IP addresses from emails. Email analysis, therefore, is much more effective if you have some visibility into the platform used to send the suspect email.

Nevertheless, email header analysis is still the first step in fraud cases involving email, because you must not overlook the possibility that the fraudster may have used a service that does not obfuscate all data that could be used to identify them.

There’s a video linked below which is quite informative on this subject, and you should go there when you’re finished this post.

Recently a colleague asked for assistance with the analysis of email headers. He was trying to gain more information about the author to get a step closer to identifying them. To carry out the analysis you first must know how to get the headers for the email as they are not surfaced by default.

• View email headers in Thunderbird
• View email headers in outlook
• View email headers in gmail
• View email headers in proton

The list above links to instruction for a sample of the email clients/services available. If you have a different client/service just do a search on your favourite search engine for “view headers in {insert client/service here}”. The top result is usually good.

Here is a sample header:

This is the header for a test email I sent from the email address I have for this blog to my personal gmail address. The gmail address has been changed, but as is hinted at within, it’s not really that hard to guess. This wall of text seems fairly inscrutable at first glance. Let’s try to focus in on something usable. First I should note that this email was sent using Amazon’s online webmail service.

Each line of the header relates to a separate header field. There are hundreds of formally defined possible header fields, not to mention that the ones beginning with “X-” are user defined, and can theoretically have any name. You might be able to see, if you squint hard enough, that some of the header fields correspond with the fields you actually fill out when drafting an email, such as “To:” and “Subject:”. For clarity:

The image above highlights the Subject, From, To and Date header fields. These fields will be present in every email you look at. These are formally defined fields that you will find defined in an RFC somewhere. I will refer to this block as the “very common header block” throughout this post.

Howsoever an email is sent, before you can ascertain who sent it, you need to find out where it was sent from. For that we need to look at the “Received:” headers. These “Received:” headers will usually all appear above the block of headers seen in Figure 2. However, depending on the technologies used in sending the email (SPF, DKIM) it can get pretty crowded up there. (SPF and DKIM are beyond the scope of this post, but suffice to say they are useful in verifying the validity of emails in general.) These “Received:” headers each represent a hop that the email took from sender to recipient. See Figure 3 below which has the “Recieved:” headers from our sample email masterfully highlighted.

These received headers are added to the headers as the email makes it’s way from sender to recipient. They appear chronologically with the bottom one being the earliest and the top being the most recent. How does that help? It means that the most relevant one to our investigation is the one that appears first as you work your way above the common fields block (Subject, From, To, Date). In our case that is:

Received: from a2-24.smtp-out.eu-west-1.amazonses.com (a2-24.smtp-out.eu-west-1.amazonses.com. [54.240.2.24])
by mx.google.com with ESMTPS id s25si730939wrb.389.2020.05.26.12.58.28
for notthathardtoguess@gmail.com
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128);
Tue, 26 May 2020 12:58:28 -0700 (PDT)

I can tell you that the IP address “54.240.2.24” is not the IP address that I sent the email from. What does nslookup have to say?

It appears that the initial IP address that the email was issued from is part of the Amazon infrastructure. This makes a lot of sense since, as I said earlier, this email was sent using their own online webmail service.

So this doesn’t help.

Let’s examine our second example. This time I will again send the email to my personal gmail account, but I will send it from a college email account through a Thunderbird email client. The college email account is operated over the Microsoft suite of applications.

First, to note, I have again obfuscated non discoveringdata.org email addresses and some other data. Clearly this second email header seems evne more inscrutable than the first email, and it’s mostly because of a bunch of additional “X-” headers that Microsoft services regularly add to their emails. Let’s narrow it down to the top part, so from the very common headers and above.

And again to hone in on the earliest “Received” header: “Received: from DB7PR02MB5049.eurprd02.prod.outlook.com ([fe80::7422:8290:aceb:aa94]) by DB7PR02MB5049.eurprd02.prod.outlook.com ([fe80::7422:8290:aceb:aa94%3]) with mapi id 15.20.3066.023; Mon, 8 Jun 2020 09:48:16 +0000“. Now that doesn’t make sense, because it was sent from my computer, not anywhere on the outlook.com infrastructure. What gives?

As it happens in this particular set of headers the earliest “Received” is below the block of very common headers. This header is:

Received: from [192.168.xxx.xxx] (212.xxx.xxx.xxx) by DB6PR0801CA0058.eurprd08.prod.outlook.com (2603:10a6:4:2b::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Mon, 8 Jun 2020 09:48:16 +0000

Now we have a result to talk about, because this does reveal my IP address beginning with “212.”. It even gives you the private IP address on the LAN that the email originated from. Let this be a warning, don’t assume that all “Received” headers will be above the very common header block.

But wait, there’s more. Do not dismiss out of hand those “X-” style headers. They can often contain very useful information. For example in this case there is a “X-originating-IP” header that would have been useful even if the useful “Received” header above hadn’t been present:

X-Originating-IP: [212.xxx.xxx.xxx]

Again, my IP is exposed. And in fact when I sent an email from the webmail interface for this email address, there is no “Received” header that exposes my IP address. However, it still included a “X-originating-IP” header which did reveal my IP

Email Header Analysis – The Walking Method

So, that was a look at manual analysis, it’s painstaking. There’s a far easier way. That is to use some of the online email header analysis services. Google have made such a service available. I have also found two other services I find useful called MxToolbox and MHA.

• Google’s service
• MxToolbox’s service
• MHA’s service

Word of Warning: This should not be seen as an endorsement of these services. I do not know exactly how these services operate. I do not know whether they retain a copy of any headers they are sent. If you have a particularly sensitive set of headers you need analysed, you need to consider carefully whether to use these services or not.

These services do pretty much the same job as each other, although their results are laid out slightly differently. For the purposes of identifying an email sender, you need to look for the “hops” section. The Google service is a bit cleaner to view so I’ll focus on that, for now.

As you can see from Figure 7, as is consistent with the manual analysis. Amazon’s webmail service has not exposed my IP.

Moving to the second email sample we get:

You can see in Figure 8 that there is a bit of an error in the analysis. It only shows the private IP address in hop 0 as the originating address. This mistake was also made on the MxToolbox service. However, MHA surfaced both the private and public IP addresses.

This is yet another important lesson that you should not rely solely on one tool. Cross validation of tools is important, as some of them might never have come across the case that there are two IP addresses given in the “Received” header and as a result only surface the first one they encounter.

Bear in mind that Google’s tool only really deals with hops, the other tools also list all of the headers. These headers are separated from each other in their reports, so they’re not just a wall of text as is seen up in Figures 4 and 6. I encourage you to play around with them and see how useful you find them.

Email Header Analysis – The Running Method

Advanced forensics tools such as AccessData’s Forensic Toolkit, Magnet’s Axiom and Guidance Software’s EnCase will allow for the processing of and analysis of emails with relative ease. If you’re going to be analysing emails en masse you may need either one of these tools or a similar tool to make your life much easier.

Which reminds me, possibly the only good thing about this Covid-19 pandemic situation is the fact that a lot of training and certifications have been made available by vendors absolutely free. This paragraph is going to be more of a self-pat on the back for me, but in my time in the Garda National Cyber Crime Bureau I was exposed to the forensics tools mentioned above. I was able to use my exposure to AccessData’s Forensic toolkit to bag the “AccessData Certified Investigator” credential which they had made free to access. This took a bit of a review of the documentation to freshen up when I really should have been focusing on something else, but I think it’s worth it to level up when possible.

Conclusions

I didn’t cover the impact of BEC but it needs to be mentioned. The FBI issued a Public Service Announcement in September 2019 that stated that between June 2016 and July 2019 that the dollar loss internationally as a result of BEC was in excess of $26 billion. BEC is a problem that should be taken very seriously.

Email header analysis won’t always bear fruit. But you’d be wrong to dismiss it out of hand. I wasn’t even expecting the result that I got in the second sample message where I got the private as well as the public IP address. If you get this kind of evidence it could lead not just to a physical address but also to the exact device that sent the message.

Analysis of emails by hand is painstaking work, but it doesn’t have to be. Use the free tools mentioned above. If you find yourself undertaking a heavy load of email analysis you should also consider a dedicated piece of software for the job.

I have barely scratched the surface in relation to header analysis. Watch the video linked below for a bit of a deeper dive, and then go forth to find other resources if you need to go even deeper.

Sources

https://av.sc.com/corp-en/content/docs/FFC-Microsite-Business-E-mail-Comprise-20190911-v2.1.pdf

Youtube: Email Header Analysis and Forensic Investigation