Hacking Email Accounts for BEC

Yep, Business Email Compromise (BEC) is a thing. (If you don’t believe me, read this, this and this.) There’s also an ugly step-sister of BEC that some people are calling Vendor Email Compromise (VEC).

Whatever you call it, a key step in these schemes usually involve an attacker gaining access to someone’s email account. Whether this be the victim’s, their vendor’s or their client’s email account. Why? Well the attacker wants to understand things like how the money flows in the targeted company, who is responsible for making payments and what the prerequisites are for someone in that company to act on payment instructions. Remember, they are trying to trick their target into thinking that they are communicating with a legitimate someone. The end goal usually being to get a victim to act on a fraudulent payment instruction or to change an existing vendor’s or client’s bank account to a new fraudulent account number. Not the most technical hacking ever, but these guys are patient, persistent and effective.

So, before the BEC scam gets into full swing, the attacker needs to get access (hack) their target’s email account. How do they do this? Well, the answer is “it varies” (like with most things in Infosec).

Often times it will start with something like either a bulk or targeted phishing campaign. One example is where an attacker will send an email posing as a supplier with an urgent outstanding invoice, something that will get the average person’s attention. Now, let’s pause for a moment. Before you roll your eyes and mutter ‘you can’t patch stupid!’… humor me for a bit with a story from Hypothetical Jack:

Story Time

It’s just after 14:00 on Monday afternoon. The long weekend from which hypothetical Jack and his family returned on Sunday evening remains a distant memory. Bogged down in his 2×2 cubicle, Jack reminisces about the Certified-Karoo-free-range lamb chops they braaied on Saturday evening under a clear sky. He can still hear the distant howling of a black-backed jackal echoing through the Waterberg mountains, each time the clacking sound of his fingers pounding away at his laptop’s keyboard subsides for a brief moment. Strangely enough, this time the howling seems to get louder, almost like the jackal is stalking his cubicle…. “Jack! Snap out of it!” and like that the harsh voice of his colleague Gertrude abruptly rips him out of his daydream and smacks him down on his high-back orthopedic office chair. “Peter is waiting for your monthly financial report card. He wants it before 4 today. It’s month end, remember…”

Jack reluctantly realigns his grey matter back to the humdrum of checking multiple spreadsheets and adding meaningless Gantt charts to an even more meaningless PowerPoint month-end presentation. Flipping between sheets, his eye catches the Outlook pop-up notification appearing from the right bottom of his screen. He was able to make out something about an outstanding invoice due this week before it disappeared again behind his litter of open spreadsheets.

Jack’s squirrel instinct takes over as he conveniently forgets about his looming month-end deadline and clicks over to Outlook to find the following email:

Jack has never dealt with “New Real Supplies CC” before and concludes that this is likely a new vendor they are dealing with. As he stares at the attachment, he remembers the one thing they taught him in his Information Security Awareness training session: DON’T CLICK LINKS.

“Well, I’ve got 99 problems but the link ain’t one” Jack mumbles as he opens the Payment Invoice.html attachment promising a 25% discount for early payment.

We’ll pause the story here for now. The point is that in a high-stress-multi-tasking-deadline-driven-environment, it doesn’t take much to lure Hypothetical Jack into opening an attachment from an unknown source.

Dodgy HTML Attachments

Let’s look at two real world examples of how attackers use HTML attachments to trick users into revealing their email account credentials. Remember, Jack is expecting to see some sort of invoice as indicated in the email message…

Attachment one: The Blurred Invoice

Have a closer look. The attackers did a great job with this one. Once the attachment is opened in a user’s browser, it shows a blurry ‘invoice’ document in the background. All that now stands between Jack and the un-blurred ‘invoice’, is this box asking for his email address and password:

Let’s have a look what happens when you enter your details in the form and click the “View Document” button.

To do this, we’ll look at the source code of the Payment Invoice.html attachment. Firstly, this shows a poor attempt at hiding the actual code with a <!-- Source code not available ... --> comment at the top of the page:

Scrolling down, you eventually get to the real, but quite hectically obfuscated source code:

Now, you can do either one of two things at this stage:

  1. Spend your Friday afternoon attempting to make sense of the obfuscation OR
  2. Open the attachment in a controlled environment, run something like Fiddler to capture HTTP traffic while you enter an email address and password in the form and hit “View Document”.

Naturally, I opted for Option 2 which gave use the following output in Fiddler:

From the above you can see that whatever the user enters into the “Email ID” and “Email Password” fields gets shipped off to the attackers URL. They now have a username and password to log into the victims email account.

Attachment 2: PDF File Inside

This one is all nice and official looking, even with a fake McAfee “Secured Page” badge. Again it is asking the user to enter their email address and password to access the document.

Having a look at the source code of the above gives the following obfuscated code:

This time it’s fairly easy to de-obfuscate the code. The above conforms to Hexadecimal code, so an easy way to decode this is to pop it into CyberChef. One of the myriad functionalities of CyberChef is to decode hex code to ASCII. Adding the above to the ‘Input’ box in CyberChef while selecting the hex decode recipe, gives you the following: (Note the Output box)

Scrolling through the decoded source code of the attachment brings us to the following section:

Here we again see that all this page does is to capture what the user entered in the form (i.e. email username and password) and ship that off the the attacker’s URL. No actual invoice for the victim to view, while the attackers are helping themselves to an email inbox using the newly acquired username and password.

Final Thoughts

Attackers will continue coming up with innovative ways to target users. As seen in these examples, they are luring users into entering their email credentials in order to get access to an ‘urgent invoice’.

Here are 2 ways that could assist in mitigating these type of attacks:

  1. Secure your email. One step that can go a long way is to enable 2FA / MFA (Multiple forms of authentication). This will assist in preventing an attacker from logging into an email account, even though they were able to obtain the username and password of the account. They’ll still need an additional form of authentication (such as a uniquely generated code sent to a trusted device) to be able to log in.
  2. Review your payment processes. Put extra validation processes in place to ensure payment instructions received via email is actually coming from who they say they are coming from. The following scenarios are often used by attackers:
    • A request is sent to a company to change banking details for an “existing” client. Attackers attempt to get them to pay a legitimate invoice into a fraudulent bank account.
    • An urgent payment needs to be made to a new account. Attackers attempt to impersonate a supplier or even the company’s CFO, requesting his staff to urgently act on a fraudulent payment instruction.

DON’T CLICK THAT LINK (Unless it’s us)

Don’t do it!

A common piece of advice we often give to users is:

Do not click any links in unexpected emails.

Good advice. Let’s put it to the test:

The South African Revenue Service (SARS) brand is notorious for being used in Phishing attacks, trying to trick users into divulging banking or other personal information.

See some of the samples here: (Yes, I know it’s a link…) http://www.sars.gov.za/TargTaxCrime/Pages/Scams-and-Phishing.aspx?k=

SARS also shares warnings for things to look out regarding phishing mails:

  • “Members of the public are randomly emailed with false “spoofed” emails made to look as if these emails were sent from SARS, but are in fact fraudulent emails aimed at enticing unsuspecting taxpayers to part with personal information such as bank account details.”
  • “Importantly, SARS will not send you any hyperlinks to other websites – even those of banks.”

Good advise, however, the following happened:


It is a Phish?

Yesterday, I received an email message with subject “Please rate your SARS experience“. Now, if you’re a law abiding citizen of the Republic, you’ll know that your online eFiling deadline was 31 October 2018. So emails like these could be expected, but could also be phishing:

In this instance, Gmail is kind enough to show us that the email did not originate from SARS, but came in via bounce.mkt2356[.]com:

South African Revenue Service (SARS) noreply@sars.gov.za via bounce.mkt2356.com 

And they are asking me to click on a link, which is bad. So let’s investigate further…


The Post Office

For this analogy, we’ll run with the idea that I have a letter that I’d like to send to the friendly people at Eskom to enquire about their power generating capability as we are having Stage2 load shedding today.

I decide to drop my well worded letter off at the big red metal post box at the Hatfield Post Office in Pretoria, South Africa.

Upon receiving my letter, the Post Office adds something called an email header to it. An email header keeps track of (among others) all those stamps added to your envelope as it travels past different post offices and mail sorting stations on its way to the friendly folks at Eskom.


Message IDs

One of the many fields contained in the email header is called the Message-ID. This field can help us in our quest to determine where the email originated from. This is in essence the name and serial number of the post box at Hatfield Post Office, as well as a uniquely created tracking number for my letter.

Our SARS email had the following Message-ID:

Message-ID: <1500063631.36076041543493254864.JavaMail.app@rbg13.atlis1>

Normally, you’d expect the portion after the “@” sign to denote a legitimate domain. For example, emails sent from Gmail will have something like this for a Message-ID:

Message-ID: <CAB-Uxrs+=TRDDCMHgtbGAwru+trd@mail.gmail.com>

However, in our case rbg13.atlis1 isn’t a valid domain, which is odd for an email received from SARS.


Received Fields

Next, lets look at the “Received” field. This field records all the email servers which handles an email on it’s way to it’s destination.

For our letter we sent to Eskom, the Received fields will look something like this (simplified, I know):

Received: by Hatfield Post Office from Some Guy; 29 Nov 2018 13:15

Received: by Tshwane Distribution Center  from Hatfield Post Office; 29 Nov 2018 16:00

Received: by Midrand Distribution Center from Tshwane Distribution Center; 30 Nov 2018 09:00

Received: by Midrand Post Office from Midrand Distribution Center; 30 Nov 2018 12:15

Received: by Eskom Offices from Midrand Post Office; 30 Nov 2018 16:15

In our case, the Received fields show the SARS email traveled the following path to my Gmail account:

1. mail6613.grapevine.mkt7212[.]com
2. mx.google.com

Yes, that shows a pretty short path. Basically one hop from the mkt7212[.]com server to Gmail’s server.


The Link

Next up is the link in the email (the reason I wrote this whole thing).

If you scroll up and look at the screenshot again, you’ll see that the email contains a “Survey Link” to click and complete.

This link in the email shows that it’s for:


(I’ve changed the URL a bit as it’s most likely unique to each address the mail was sent to)

But mkt2356[.]com isn’t SARS. Let’s take a look where you’ll end up if you clicked it:

So, clicking that link for http://links.mkt2356[.]com would actually get you to the legitimate SARS website https://tools.sars[.]gov.za/SatisfactionSurvey/Surveys/Index/32

However, to make things worse, mkt2356[.]com has a Certificate Name Mismatch error, which will be cause lots of security products to warn you before visiting the site:

And here’s what it looks like when you eventually end at the actual SARS website:

So, it turns out that the MKTxxx domains are owned by IBM’s Watson Campaign Automation digital marketing solution.

So What??

Ok, so at this point you are asking the following: “Come on dude, it’s just SARS using a marketing company to send out emails with unique links so that they can track who actually clicks it after which it take you to the actual SARS page so no need for all this screenshots and stuff so get of your horse and enjoy your load shedding.

Well, my point is this:

This is not helpful.

We can’t be telling people “DON’T CLICK ON ANYTHING! JUST DON’T” and then send them crappy survey emails with links we want them to click. So the message becomes:


*Unless we send you stuff via a third party, so then please go ahead and click it, even if it was set up crappy, don’t worry, it’s fine, trust us.


That my friend, is confusing.