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.