Recently Tessian’s Threat Engineering Group identified an emerging threat detected by Tessian Defender targeting around 45 of our customers. The campaign was an email credential harvesting attack and was not detected by Microsoft Exchange Online Protection (EOP) when the attack began. 

Anatomy of the attack

The attack email was able to bypass legacy security solutions, like secure email gateways, as well as Microsoft 365. Let’s explore some of the reasons why it was able to do that:

Firstly, the email was ‘sent’ by Amazon Simple Email Service (SES), which is a common tool leveraged by attackers to send automated attacks. However, the display name impersonated the company being targeted, no doubt attempting to add legitimacy,

• The display name was actually dynamically generated, taking the first three letters of the recipient address and pretending to be the company name.

• This is done to avoid basic aggregation and detection methods by secure email gateways and native security controls of email providers.

• Looking at the subject of the email, it’s fairly innocuous, and again a rule in a SEG to flag the word ‘payment’ would trigger hundreds of false positives.

• Finally, the body of the email itself is benign, simply stating “Please consider the environment before printing this email”.

If anything, the attack attempt is a little too spartan in content, which might have raised suspicions in the user that received it.

Let’s now look at the HTM attachment, which contains JavaScript, which is encoded (below)

And when decoded twice it looks like this. Note that some of the content is still encoded.

All this encoding and obfuscation is attempting to hide the fact that the script redirects the user to a credential harvesting form. The form is hosted on a domain registered one day before the first phishing email was seen on the Tessian network.

What’s more, to add legitimacy, the customer’s logo is hosted at the top of the form. Remember, this attack went to several organizations, so the logo must be dynamic. It’s therefore likely that it was scraped by the attacker using automated tooling.

The user the “username” field is already pre-populated with the recipient’s email address. Again, adding legitimacy and lower the amount of effort for the recipient to share their password.

Finally, when the password is entered, it is posted to a PHP script hosted on the same domain.

How did Tessian Defender detect this threat?

So how did Tessian Defender stop this threat when SEGs and Microsoft 365 didn’t? Well, as well as detecting unusual file characteristics, Tessian’s Behavioural Intelligence models detected additional anomalies increasing our confidence score to 100/100. They are as follows:

1. The recipient company name was used in the display name. 
2. The recipient has no historical relationship with the sender.
3. Multiple emails were sent to each customer in a short period of time, to unconnected employees, this is known as a bust attack. 
4. Tessian’s Natural Language Processing (NLP) models classified the email as being payments-related
5. Depending on the specific customer configuration, Tessian Defender either hard-quarantined this email or displayed the following warning message to end users, coaching them and raising their security awareness

Indicators of Compromise (IOCs)

Tessian Threat Engineering Group reacted to add the below IOCs to the Tessian Unified Threat Interface. We recommend readers do the same

Sender Address: jorgezamora@powderiverdev[.]com

Credential Harvesting Site Domain: https://emdghouseltd4[.]pro

Contributors: Ed Bishop and Catalin Giana.