Posts

Email trojan horse: application/html entity

We just discovered a new trick that is currently being used to slip malicious html files through email security solutions and,  in some cases, through antivirus engines.
The trick is quite simple: declaring an email entity as “application/html” instead of “text/html”. “application/html” is an invalid type and this allows it to slip through some checks.

 

Background

Emails are composed of many “parts” called “entities”. Each entity has a content-type header that declares the type of it’s content (the textual or the html portion of the email,  the images contained in the message, the attachments which can be of many different file formats). For example the html portion of the mail has content-type “text/html”, the text part is declared as “text/plain”, an image can be “image/png”, an attached office document can be “application/msword”, and so on. There is a list of valid types and “application/html” is not among those.

What happens if you declare an invalid content type? It depends. Email clients try to be helpful and tend to consider as valid the types they don’t know, but security solutions and antivirus engines may behave differently. They make specific security check that depend on the content and when faced with a content type they don’t know in some cases the end up ignoring or not analyzing properly the content of these entities. At least this is what happens with the entity type “application/html” that we tested.

 

Samples in the wild

The samples found in the wild are delivering html files that, as soon as they are opened, redirect to a malicious site (through a meta tag). These very small one-line html files are attached to malicious emails inside an entity of an invalid type “application/html” instead of the correct type “text/html”. All the email clients we tested (including the major webmail services) show these files as normal attachments but all the email security filters we tested (including those of the major wemail services) could not find malicious links contained in these html files if the entity was “application/html”. While they did detect them if contained in a normal “text/html” entity, they could not detect them if the entity type was changed to “application/html”. This trick is actively being used in the wild, this is why it is appropriate to go public with these findings.

 

Our testing

In order to assess how these entities are managed by email services and clients, we created two email samples with an html attachment containing a link to a malicious website. One of the samples has the entity type changed to “application/html” instead of the normal “text/html”. This is the only difference between the two samples.

 

The sample with the “application/html” entity was delivered as clean in the inbox of all the systems we tested (including the major email providers) while the very same email with the entity of type “text/html” was correctly classified as dangerous. Some checks are clearly missing when the entity type is “application/html”.

All it takes to create a “stealth” entity is to change the word “text” into the word “application” in the content-type declaration.

 

All the email clients (including major webmail services) allowed the user to open the html file contained in the “application/html” entity.

Here is the malicious html file inside an application/html entity sent to Gmail:

Clicking on the attachment, it is displayed and offered for clicking.

Here is the same malicious html file sento to Gmail in a normal text/html entity:

The text/html entity is properly analyzed and classified as dangerous, the application/html entity is not.

 

Tests with actual malware

We performed a second test, by embedding a real sample of emotet in the html attachment (inside an href tag). With this sample the results varied: major email providers correctly detected the threat while some email filtering solutions didn’t.

 

The image above shows how we embedded emoted inside the html file.

These samples have been also tested with major and widely used antivirus engines: some of them did not inspect the “application/html” entity even if they could correctly detect the same sample in a “text/html” entity.

The target of this post is to raise awareness so there is no point in naming products here. We just show a test performed with an opensource antivirus engine.

 

In the previous image we have two samples containing emotet embedded in the html file.

entitytext.eml had a normal “text/html” entity while entityapplication.eml had an entity of type “application/html”. The first command (diff entitytext.eml entityapplication.eml) shows that the only difference between the two emails is the word “text” replaced with “application” in the content-type declaration.

As you can see the antivirus detected emotet in the first sample and didn’t detect it in the second. This test used clamav but the same test with major commercial antivirus engines produced similar result.

The sample entityapplication.eml uploaded on virustotal has been classified as malware by 9 engines on 57:

Conclusions

From an email security gateway point of view, blocking emails containing entities of type “application/html” is probably the wisest thing to do and this is what we are currently doing.

This is clearly an attempt to evade security inspection by pretending to be some kind of unkown application-specific data, inducing to perform only broad and general security checks (for example clamav does not decode base64-encoded data embedded in the href tag if declared as “application/html”) while, at the same time, inducing the email client to offer the file to the user as a normal html attachment.

An attempt to evade analysis is a strong signal about the malicious intention of the sender and should be penalized accordingly.

This threat has been added to our email security tester, a tool to assess the performance of emails security protections. This means that you can easily test, right now, whether you are protected or not from this and other common email threat vectors.

Fresh phishing served with AES obfuscation

Obfuscated phishing sites are nothing new (on the same matter check this article Web obfuscation technique using invisible spans ) but the use of AES in an attempt to evade detection from automated detection tools like our URLSand Sandbox service, is not very common.

Despite AES and encryption in general is not a newbie argument, I am surprised how easily this approach can be adopted by anyone with a basic programming knowledge.

The only thing needed is a Javascript library, freely available for download from Movable Type Scripts.

By including this library in your page you can then serve your encrypted webpage, with a few lines:

To explain the above lines:

Line 1) includes the JavaScript AES implementation, which it calls with the embedded password defined at Line 4) and embedded encrypted data at Line 6). The decrypted phishing content is then dynamically written to the page using document.write() after calling the decryption function at Line 8).

This process happens almost instantly when the page is loaded and once decryption is complete, the phishing site is shown as normal.

Note that the use of AES here is very basic, and there is no attempt made to hide the key or anything else. But I would not be surprised if this kind of attacks will become more sophisticated in the near future!

Eng.Paolo Frizzi

Web obfuscation technique using invisible spans

In order to delay detection, phishing and malware websites often use some obfuscation technique.
Obfuscation techniques are double-edged swords. They hide the malicious content from dumb crawlers, bots and sandboxes, but smarter algorithms that know what to look for can detect the malware just by looking at it’s attempts to hide. This is one of the ways we can detect zero-day malware.

In this example we have a fake PayPal website. This page interleaves invisible spans between visible text in order to avoid detection by automated systems that perform heuristic analysis of the web page content.
You’ll get a clearer idea by looking at the following pictures.

This is the fake PayPal website as it is displayed in the browser:

PayPal phishing website

Notice the text just above the login box on the left of the page. The text says “Bitte geben Sie Ihre PayPal-Dated ein”. You will not find this phrase in the source code of the page because the phrase (and especially the word PayPal) has been interleaved with a lot of text enclosed in invisible spans. This text is present in the page but it is not displayed to the user.

Here is a part of the source code of the page (click on the image to enlarge it):

The parts in brown are the invisible spans, they contain a lot of random text that the browser is instructed not to display to the user.

The parts surrounded by yellow boxes are visible and displayed to the user. These parts compose the phrase you see on the webpage but a bot that scans the page and that doesn’t skip the invisible parts cannot find this phrase or even the word PayPal in the whole page.

Invisible content is perfectly normal in legit web pages, often some parts of the page are made visible only on specific events, often most of the page is initially invisible and made visible only when everything has been loaded. Having invisible content is not bad by itself and this is why crawlers and sandboxes don’t ignore it. Using it in this way is certainly suspicious.

Our UrlSand sandbox searches for this and other obfuscation/evasion techniques in order to detect malware.

 

Rodolfo Saccani
Libra Esva R&D Manager