Mimecast® for Microsoft 365™ hacked

A few days ago, Microsoft® informed that a Mimecast® for Microsoft 365™ certificate has been hacked and is being used against Mimecast’s customers.

This certificate allows full administrative access to the Microsoft 365Exchange Web Services of some Mimecast’s customers, estimated to be around 10% of their global install base, who had configured the integration between Mimecast® and Microsoft 365.

Since this announcement was made, we have been asked by our channel partners and customers if the integration between Libraesva’s products and Microsoft 365 can be abused in the same way.

The short answer is no. The long answer is no, because…

1) We do not use a single certificate to authenticate against our customer’s Microsoft 365 tenants.

Libraesva products (Email Security Gateway and Email Archiver) authenticate to Microsoft 365 using credentials that are unique for each tenant.

A single certificate that acts as a passe-partout key for full access to many customer’s tenants is a bad design choice from a security standpoint. This is, of course, our opinion.

2) We instruct our customers to provide to Libraesva with the minimum set of permissions we require.

Libraesva asks for the minimum set of permissions required to provide the services we provide. We do not advise our customers to provide complete access to their own tenants. We ask them to only provide the permissions that they need, based on how they use our products.

3) We have a de-centralized architecture.

Libraesva’s products are designed for full isolation between customers. Each customer ‘lives’ in a separate virtual appliance, with a unique IP address. We do not store access credentials in any central repository.

As Libraesva is a security company, we know that security is difficult and that anybody can fail. Our architectural and software design choices are based on strict security principles, among which is avoiding any single point of failure.

What is a secure email gateway and why you need it

The last year, maybe like no year before, demonstrated clearly just how much every moment and aspect of our day-to-day lives depend on the Internet. This dependence leads to an increase of risks and threats to our “online security”.

According to the latest Data Breach Investigation Report, email is still the main vehicle for delivering cyber threats, with particular reference to malicious links and attachments which are developed in order to carry malware. 46% of those surveyed included companies who said they had received the bulk of malware delivery attempts via email. Social Engineering attacks also remain very high, around 96%, and phishing is confirmed the favourite form, while successful Business Email Compromise deliveries has led to an average loss of $ 44,000 per company.

Why email?

According to a Radicati Group’s study, there will be more than 4.2 billion email users within the first months of 2022; this means that about half of the global population will be using email to communicate. Consequently, a cyber attack delivered via email has a high chance of being successful and spreading like wildfire.

For example, let’s think about the Account Takeover phenomenon, a fraudulent identity theft attack method: cybercriminals obtain a victimis’ account credentials through brand impersonation, phishing and social engineering techniques and then monitor an organisations activities to learn how the company does business, manages financial transactions and even communicate with one another. This allows the cybercriminal to glean valuable information to resell to competitors, damage a companies reputation or bottom line, generate and spread further cyber attacks or acquire further credential logins, creating an endless cycle.

A single malicious email can cause a significant amount of damage to networks and, in some cases, completely halt business growth. This is exactly why email protection should be considered a crucial part of any businesses cyber-security strategy. Investing in email security is not an expense, but a saving. While it may seem convenient to use free secure email gateways, there are drawbacks to consider, such as the lack of real-time updates to block emerging threats or a lack of comprehensive security features. During the last year we have witnessed how cybercriminals rapidly change their strategies to become more effecient at delivering succesful attacks, circumventing free and simple to manouvere security platforms, negating cost saving benefits realised by implementing free email protection there resulting in larger costs to fix and recover from them – bringing the total cost of a free solution, to many thousands of pounds more expensive than if they had paid for one which can offer real-time protection and the use of a combination of advanced technologies, including artificial intelligence and machine learning, enabling predictive threat analysis.

What is a secure email gateway?

A secure email gateway is essentially a firewall that scans your incoming email in order to protect your mailbox from email-borne cyber threats, such as phishing attacks, compromised business emails, malware, next-generation spam, or fraudulent content of various kinds. But a secure email gateway can also scan outgoing messages to prevent sensitive data from leaving an organization.

What do you need to consider when choosing a secure email gateway?

Choosing a secure email gateway can be a long and difficult process. There are many gateways available on the market and, even if they look very similar, there are numerous differences. To help you along this path, we have suggested some points that you should take in consideration:

  • Deployment: it is important to have the possibility to choose between a cloud and local service, based on the needs of your organization
  • Threat intelligence, artificial intelligence and machine learning technologies, to detect and block both emerging & known threats and help administrators to understand which attack techniques and strategies are used the most against their company
  • Active analysis of URLs and attachments, to quickly and accurately block various types of malware spread in this way, thus preventing phishing attacks
  • Response capabilities, to recognise a malicious email and automatically identify and block all subsequent ones
  • Control of outgoing content to prevent sensitive data from being released

What are the advantages of using a secure email gateway?

First and foremost, a secure email gateway helps to plug gaps in email security. It is a big mistake to think that installing an antivirus engine will protect you against threats delivered via email, or to believe that solutions such as Microsoft365™ (formerly Office365™), offer a complete and secure email gateway service. A recent test carried out on numerous implementations of Microsoft365™ lasting for 1321 days across 175.110 users and 109.284.844 emails, demonstrated that a large number of threats were not intercepted by security filters included in the solution. Unfortunately, cybercriminals have become very good at finding strategies to circumvent software such as antivirus and multi-vector attacks, which use evasion techniques, such as anti-forensics and encryption, expanding significantly in recent years; exactly why nearly 35% of organizations that have switched to Microsoft365™ are integrating their native email security features with a third-party product that combines threat intelligence with traditional filters.

Furthermore, these malicious actos are well aware that employees are the weak link in the chain and the main vehicle for intrusion into corporate networks: the presence of a secure email gateway allows companies to improve employee safety by blocking unsafe URLs and malicious attachments, which are capable of spreading phishing attacks, compromised business emails, malware, and more.

Another advantage of using a secure email gateway is the ability to preserve the operational continuity of email; in the unlikely instance of a primary server experiencing downtime, a secure email gateway can allow users to send and receive email messages through their web interface.

Another feature that a secure email gateway should offer is quarantine management, to allow users to examine blocked messages and log search in a flexible and customizable way, providing comprehensive reports and useful information to help them decide which messages to release, which senders to blacklist and much more.

Finally, the right email gateway offers maximum security, requires minimal maintenance and operates largely in the background in a “set and forget” manner, guaranteeing continuous protection with minimal use of human and time resource.

Why it’s important to test your email security

The significance of email communication in the modern business world cannot be overstated – hundreds of email messages are sent and received daily by even the smallest companies, containing confidential and personal information such as clients’ data, competitive advantages, financial data or just private information.

The global shift to remotely working culture due to the COVID-19 pandemic has empowered cybercriminals to launch highly sophisticated cyberattacks. Moreover, ransomware, phishing, BEC attacks, etc. are amongst the most common types of data breaches that we have witnessed this year, till now.

Over the years, attackers have looked for new ways to gain access to an organization’s network. Years ago, it was SQL Injection attacks. More recently the industry has been plagued with remote desktop-based attacks. But throughout the years, one attack vector has remained near or at the top of the list: email.

According to a study done by Radicati Group in 2020, there will be more than 4.2 billion email users by the start of 2022. Bringing it closer, it means that about half the entire planet uses email right now!

So it’s no surprise that email is still the number one attack vector also in 2020. That’s why it’s important to test your email security. And you will be impressed by how many different ways there are to steal personal information or install malware with an email message: attachments, links, scripts, tracking bugs, macro enabled Office documents, macro-less ones, PDFs or viruses, just to mention a few.

Many IT security professionals assume their email security is performing reasonably enough, until a user reports that he has received a phishing email or when their Security Incident and Event Management (SIEM) solution alerts that your network has been breached.

If you are among the lucky minority that hasn’t seen an attack recently, don’t assume that your email security is just fine because an attack has not been discovered, or just because you have an email security solution in place: test it!

We at Libraesva, developed a free, exclusive Email Security Tester (https://emailsecuritytester.com) that you can use as email self assessment tool, so you can discover where the holes and gaps are in your defenses. Once you know where they are you can do something about it. Don’t wait for someone else to discover it!

We are dedicated only to email security problems, and we are constantly updating our test with the latest tricks that we see in the wild, so you can effectively test your email security. The Test is non-intrusive and private, no client integration or installation is required. It’s completely safe and will not disrupt operations. Minimal details are required to begin the test, so low impact on resources. The test is free and there’s no obligation to buy anything.

Do test your email security now!

The mysterious protocols: SPF, DKIM and DMARC explained

Email is an ancient thing, it was born much longer before the Internet.

The first email system was born in 1965 at MIT. At that time email communication was limited within the boundaries of a single mainframe, those huge and very expensive and delicate multi-user computers that occupied entire air-conditioned rooms and required continuous supervision.

In 1971, the first transmission of an email between connected computers happened. It was a small step for a single email, but a first huge step for humankind.

In 1982, the SMTP protocol was born, this is the protocol we still use today to exchange email on the internet.

The main issue about email (and SMTP) is that, being born in a collaborative environment where security wasn’t an issue at all, being designed at a time where abuse was not even an theoretical option, the protocol did not have any security at all among it’s design requisites.
No authentication of the sender: anybody could pretend to be anyone.
No confidentiality: messages were exchanged and stored in clear.
No integrity checks: manipulations of the email content along the path could not be prevented or even detected.
No protection about unsolicited messages: anybody could send any amount of email to any recipient.

Then email became popular and these issues started quickly to pop up.

It became clear that we needed to do something in order to address this lack of security in the protocol. Nobody had thought about it earlier because nobody envisioned that email would become what it is today: the main form of electronic communication that our societies are based on, something that all organizations, businesses and individuals rely on every day in order to run their lives.

As we all learned the hard way in the following years, adding security afterwards is much more difficult than putting it in at design time. This is one of the most important principles of GDPR: if you want real security you need it by design.

Adding security as an afterthought is hard. It is even harder if you have to guarantee backward-compatibility. Email is the most clear example of how hard is to add security to something that is already deployed worldwide—where you have to guarantee that email can still be exchanged with servers that are not upgraded to the new standards.

This is where the acronyms that are in the title of this article come into play: SPF, DKIM and DMARC are three standards that have been added to the email in the attempt to make it more secure.

SPF has a very simple task: prevent domain spoofing. Your organization can declare to the world a subset of IP addresses authorized to send email on behalf of your organization’s domain. By defining this policy, you can prevent malicious actors sending email pretending to be your organization.
The configuration of an SPF policy is very easy and relatively risk-free: you just need to map all the IP addresses that your organization uses to send email. A little effort for what you receive in exchange, and if you correctly enumerated all your legitimate IP addresses you send email from, no email will get lost.
SPF isn’t perfect, though, and it is not sufficient to prevent all types of spoofing, but it is still much better than nothing.

DKIM has a main purpose: guarantee the integrity of the email content. Integrity means that the recipient can detect if the email has been modified or tampered with along the path. This is done through an electronic signature: if the signature is valid, you know that you can rely on the content of the email. If the signature is invalid, then the message has probably been tampered with. This signature is automatically added and checked by mail servers, and the user doesn’t need to do anything.
Setting up DKIM requires a little more effort than SPF but it is safe: if you misconfigure it, email will not get lost.

SPF and DKIM still don’t completely solve the phishing problem. Email is a little bit like a plain paper letter: the sender and the recipient written on the envelope are used for the delivery, but the recipient does not see the envelope. The recipient just sees the letter inside the envelope, and in that letter the name and address of the sender can be spoofed. Basically, the email client shows the sender that is written in the letter, not the one on the envelope (which can be protected with SPF).

DMARC has been designed exactly for this purpose: making sure that the sender that your email client shows is reliable. This is done by publishing a DMARC policy that instructs the recipients to check if the sender displayed to the recipient matches either with SPF or DKIM. The email must be sent from an authorized IP address for that domain (SPF is ok), or it must be signed with a legitimate key of that domain (the DKIM signature is ok), otherwise it will not be delivered.

DMARC must be configured on a domain by domain basis by the email administrator of the sending domain. It provides great protection against spoofing and impersonation, but the configuration is not straight-forward and mistakes in the configuration can lead to email loss. Therefore, configuring DMARC must be done with expertise, without improvising.

There are other standards that have been introduced in email, like TLS (to encrypt the email in transit) and S/MIME or PGP for end-to-end encryption. These are things you don’t need to care about. TLS is automatically managed by mail servers. S/MIME and PGP have minuscule adoption because of the complexities related to the key management by the end users.

Should you care about SPF, DKIM an DMARC for your organization? Yes, you should.
Start with SPF, then proceed with DKIM and finally evaluate DMARC.

These configurations will not solve all email security problems, but they will make your email communication much more secure and reliable.
Keep in mind that under the hood email is much more complex than it looks on the surface, so consult with an email expert in order to be effective and avoid trouble.

Libraesva ESG v4.8 Release Notes

New wave of EXCEL 4.0 malware campaigns abusing FORMULA macro function

VBA has been introduced in Excel 5.0. Before then Excel only had XLM macros, which are still supported today.

XLM macros allow writing code by entering statements directly into cells, just like normal formulas. In fact they are called macro-formulas.

In case you are curious, the reference document of the Excel 4.0 macro functions is here.

There are a few statements among these macro-formulas that allow executing malicious code, these are named EXEC, RUN and CALL. Last month, in April 2020, a wave of malware abusing these calls has circulated.

In May we’ve seen a new wave that apparently still abused XLM macros but without calling EXEC, RUN or CALL. At the time we got them, most of these samples had a 0 detection rate on virustotal, so they seemed to be worth investigating.

Some of these files were using additional tricks to confuse the analysis, like putting the macros in “hidden” sheets. Some others used “very hidden” sheets, some were protected with the “VelvetSweatshop” password (which is a trick used by Microsoft to define read-only documents). There is also a great variability in file names and email campaigns. I won’t waste time on these details and will get straight to the point.

Here is what you see when opening one of these samples:

macro promt

This is the macro prompt shown by Excel when opening the document

This is the usual Macro prompt from Excel. Nothing unusual.

Then this is how the document appears after either accepting or declining the “enable macro” prompt.

The malicious document as soon as it is opened

Again, nothing unusual here. This is just one of the samples, there are of course many variants but, again, we don’t care.

In this case the sample has two visible sheets. As I said before some of the sample have invisible sheets but this is also not important for our analysis.

What all these samples have in common is the abuse of the FORMULA macro-formula. The recursive naming may create some confusion so let me provide a bit of clarification: just like any other formula statement (like IF or SUM for example), the statement FORMULA can be entered into a cell in the form of a formula. This particular statement happens to be named FORMULA itself.

What does this FORMULA statement do? It enters a formula in the active cell (or in a reference). Basically what is given as a parameter to this call becomes a fomula.

Indirect formula generation if you wish and, yes, it is dangerous as it sounds.

While it is quite clear that the following formula may be dangerous

=EXEC("C:\tools\nc.exe 443 -e cmd.exe") 

it may not be immediately clear that the following one is


An this is basically how these malicious samples behave: they crate a formula by gathering data from lots of different cells and making some transformations. Then they apply the formula by using the FORMULA.FILL statement (or one of it’s variants, see the functions reference linked above if you are interested).

The exact text of the FORMULA is built at runtime and this ensures obfuscation which seems to be effective given the zero or very low scores that these samples got on Virustotal.

This is a glance of what you see by analyzing one of these samples with Decalage‘s olevba:

Tiny portion of the olevba output for one of these samples

I’ve highlighted the FORMULA.FILL function call. There are tens of these calls in any given sample.

We are not interested in reverse-engineering each sample in order to find out the details of the behavior. As an email security company we focus on the methods and the tools used by the attackers rather than on the specific malware variant.

Our job is to block these threats on the gateway, we know that the approach of recognizing known malicious stuff is not effective and therefore we focus on removing the tools that the attackers use.

The philosophy of our QuickSand sandbox is more similar to a firewall: when our systems see a pattern like these they don’t really care about reverse-engineering the actual behavior, they don’t even care about recognizing whether this is a known malware variant or a new one.

Whether it is direct or indirect, any way of executing stuff is not allowed for documents delivered via email. This approach is less prone to evasion and it is proactive: it blocks current and future, known and unknown variants.

The low detection rate of these samples on virustotal and on many sandboxing services based on virtualization confirms that in order to be effective with ever-changing threats this is a better approach.


Rodolfo Saccani / Security R&D Manager @ Libraesva

Exploiting Fear as a Threat Actor

One of Libraesva’s Security Researchers recently discovered, along with other security vendors, targeted phishing and whaling campaigns all based around the Coronavirus outbreak, we don’t believe in playing on the fear, but its always good to see how these attacks work and why they work.

Figure 1 shows the email in question we received and blocked, the attackers in this case pretended to be the director of Milan University, warning internal users of the outbreak and steps to take to prevent further spread. As it turns out in fact, the email was spoofed and sent by a trusted sender from a fellow university, typical whaling attack, instead this time the call to action wasn’t transferring funds, but instead helping fight this infectious disease.

Figure 1 – Email Spoof of Director of Milan University, sent from a University of Bologna compromised account.

The interesting thing about this attack is that the sender of the email is trusted by the university and states on many occasions about the dangers of the virus 2019-nCoV as a respiratory epidemic, the call to action here is to quickly, look into the attached document which is a simple docx file with a link shown in Figure 2.

Figure 2 – The Document “Documento condiviso dell’Universita di Milano.docx” Attached.

Here in Figure 2 we can see the document in all its glory, feigning the need to access the file via a link which takes you to the screen in figure 3, obviously trying and failing to spoof an Office 365 login page

Figure 3 – The landing page when following the link from the attached document

Once Download file is selected you can clearly see when this becomes a true phishing scam, asking for passwords.

Figure 4 – After selecting download file, we can clearly see credential harvesting fields.

The Coronavirus is a great opportunity for any hacker worth their salt, but there are a few essential things considered when Libraesva decides that this is malicious

How we spotted it:

Whaling Protection: Our first observation was that the Director of Milan University is in our Business Email Compromise protection list, so we took additional checks to stop this user’s name and email being used against their own organisation. Effectively protecting this specific customer from any BEC/Whaling Attacks

Adaptive Trust Engine: Next we saw that the trust between these two organisations was quite high using the Adaptive Trust Engine’s relationship monitoring, but the trust between the two individual user’s was low, we didn’t let the organisational trust get in the way of understand the true nature of the email.

Sandboxing: Libraesva’s uniquely designed and built-in sandboxes disarm any docx, xlsx and pdf documents creating zero risk files meaning this attack, even if delivered to user’s would be unable to ex-filtrate information due to there being no links, no code, nothing in that document.

To Conclude:

Hopefully you learnt a little bit about how these business email compromise attacks look, and how threat actors work off the fear that the public have, Libraesva spotted this early and stopped it from reaching anyone. Thanks for reading and let us know if you have any questions at all.

What is an Evasion Technique?

What exactly are Evasion Techniques?

Evasion techniques are what malicious payloads use to avoid detection from Sandboxing services, Malware authors have two priorities when creating malware, being silent and being deadly, getting as much as they can for as little effort as possible.

We thought it’d be wise to talk about how effective these evasion techniques are against traditional sandboxes and how we as Libraesva handle them in our Email Security Gateway.

My Top Evasion Techniques

Polymorphic Code – Code commonly used to bypass pattern and hash based detection, the malware modifies itself in delivery to other locations, thus effectively being really hard to track and detect. Polymorphic attacks don’t have a single detectable signature, Shikata ga nai meaning (“It cannot be helped”) is a popular polymorphic encoder inside metasploit’s framework making it relatively easy to turn malicious code into polymorphic code.

This technique specifically involves encoding the payload in some fashion, then placing a decoder to undo that mess in front of the payload before sending it. When the target executes the polymorphic code, the decoder is run first which rewrites the subsequent payload into its original, malicious and nasty form before executing.


User and System Interaction Detection – Users interact with computer systems in different ways, they are unpredictable in some essence, which makes them obvious to spot. They press keys on a keyboard in a specific way, scroll with the mouse wheel and click on things with the mouse. However, there are no interactions this bespoke in a Traditional Sandboxed environment. Malicious hackers teach malware to wait for a specific user interaction before exhibiting their malicious behaviors.

Examples of this is executing after you scroll to a particular place within a word document, using paragraph codes in Word files, Trojan.APT.BaneChan activates only after a certain number of mouse clicks are made by a user, other examples of this are timing the speed of the mouse movement and halting all code unless the mouse moves at a human’s speed.

Other system checks malware perform can be the Core Count technique, allowing malware to find differences between virtual and physical system CPU cores. Many sandbox vendors hide their system settings and hardware so when the system check is done, the coded malware is returned with null, which is a good sign for malware to stop running.

Lastly one of my personal favourite checks is the reboot check, where the malware checks to see if reboot triggers are executed in full, Sandboxes can try to emulate a reboot by logging out and back in as users and sleeping the system, however these never fully run all reboot triggers. The main reason this is such a useful evasion technique is due to most Sandboxes not being able to survive true reboots. So if you make your malware run after you switch the machine off and back on, you’ll rarely detonate on a sandbox environment!


Obfuscation of Internal Data – Some sandbox evasion techniques consist of malware being allowed to change and encrypt, similar to the polymorphic examples referenced above, however this is more simple to run and can help you target attacks to specific organizations.

Fast Flux is a technique of changing DNS names and IP addresses rapidly, mainly used by large botnets that aim to hide themselves from phishing detection systems. It allows malware to bypass blacklists that most security solutions create. Some malware is known to change its domain names as fast as every 10 minutes.

Data Encryption can be a quick way to win big, encrypting API calls so that traditional sandboxes can’t read the APIs, usually multiple encryption keys are used to protect the malware from brute force decryption detection.


How does Libraesva’s Sandbox get around this?

Traditional sandboxes are in a constant fight to catch up with malware authors in understanding their evasion techniques and the malware’s specific behaviors. This is sometimes known as a cat and mouse game.

Malware constantly evolves and security teams constantly research.

Libraesva’s QuickSand Sandbox deploys a pragmatic method to stopping these threats by looking directly at the evasion techniques and signs that things could be malicious, not the malicious act itself. QuickSand is a preventative sandbox which utilizes evasion techniques to protect you and your users.

Our Head of Research and Development Rodolfo Saccani told me once “A man walks into a bank with a mask over his head, does the bank care what the man plans to do? No, they’ve already alerted the police.” This way of explaining evasion techniques and how to use them as identifiers sticks with me and helps me define what Libraesva’s threat approach is like, we look less at who he points the gun at or why is he asking for the bank’s money, but more at the identifiers of the man being malicious i.e. the mask over his head and the gun in his hand.

QuickSand directly looks at things within documents that scream “I’m a bad document” an example of this is if a word document you’ve been sent has JavaScript embedded inside of is, we don’t care what the JavaScript is doing, we’ve already cleaned the document and disarmed it of any active java code because in a typical working environment, this isn’t a legitimate use of JavaScript.

QuickSand is also available directly on the appliance, meaning your files and data don’t leave the Libraesva appliance, we aren’t sending anything to a cloud virtual machine sandbox, we process everything in seconds on your own Libra machine.

So next time you are cleaning up a breach or patching holes in your network, try finding new ways to prevent threats, preferably looking at them before they are detonated, to try and find patterns and warning signs of them being malicious!

Did I mention that our sandbox is included in Libraesva’s Email Security Gateway?


Thanks for reading this! If you think it was beneficial let me know, and provide any feedback you can to me and the team over on LinkedIn or YouTube!

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.



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:


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.

Five things admins forget when using Libraesva ESG

I get it, you’re a hot shot Libraesva ESG admin who knows everything about the system, but even the best of us make mistakes and forget the basics, even me! In a recent certification course we held in the UK we discovered some fairly obvious shortcomings in basic configuration and management of the solution that most admins adhere to and we thought right now is a great time to inform you of them, so you can continue being a pro Libraesva ESG admin.

  • Libraesva ESG does the leg work for you

Libraesva ESG is built from the ground up to be set and forget meaning you really don’t need to reinvent email security, some of the first things administrators like to do is change the anti-spam scoring, the default rule sets and even switch off the sandboxes (I know, weird right!?). However, this isn’t optimal or even required at all.

Libraesva ESG comes setup out the box in its most optimal and secure mode, it links directly back to Libraesva HQ to get up to date analysis statistics and rule sets so you don’t have to, at most the Libraesva system will need input from users in the quarantine section and threat submissions. The Libraesva team are constantly updating the ESG platform, rule sets, and our security engines to make your life easier and lessen the management load of you and your admins.

  • Always check the Technical Message Details

The first place you should always be checking is the Message Technical Details section, here you can find the Dangerous checks and the Anti-Spam analysis, in these sections you will find all the information and rules that were parsed against the email you are analysing. You can see all of the anti-spam rules, QuickSand and URLSand status and even Virus Signatures.

We want administrators to understand completely and transparently why we did or didn’t block something, if we are wrong then you can tell us, if we are spot on, you now know exactly why we stopped a threat or email.

  • Threat Remediation is here for you

If you’re one of the lucky ones who are on Office 365, Exchange or Zimbra email servers, you have unadulterated access to Threat Remediation, a free tool used in the event of a categorisation fail on Libraesva’s side, if something slips past Libraesva, which rarely happens, you can jump into the reports section and immediately remove the threat or unwanted email from your user’s inboxes.

You have a few options after you’ve re-mediated the threat, you can analyse it yourself using number 2 and then if you deem the email to be safe, you can simply release the email back to your users.

  • Recipient Verification handles Licensing

So licensing isn’t that complicated in Libraesva, but here is a quick rundown,

Libraesva ESG Yearly Subscriptions licenses unique email addresses, this means aliases, mailboxes, distribution lists and all other unique email addresses will take up a license, Secondly a license is only consumed when Libraesva accepts mail on its behalf and scans it.

So if you don’t verify or validate who the recipients are within your organisation, Libraesva will accept email to any address that is referencing your domain, an example:

[email protected] doesn’t exist, but Libraesva ESG will accept this email and scan it because the system isn’t verifying recipients, thus using a license. So always remember to switch this on, link the ESG to your LDAP or O365 system and validate those recipients! A full guide on how to link LDAP or O365 can be found here and here respectively.

  • QuickSand’s sanitised files can be recovered

When you look into your quarantine report at the end of a long hard day you might see something that looks odd, a quicksand message in your quarantine with a score lower than your spam score threshold, don’t panic. This is just telling you that you have the original pre-sanitised and possibly unsafe document, there ready to be released if you need it.

See the way QuickSand works if you aren’t familiar is that it takes active content on PDFs and Office documents and tries to completely remove the content and sanitise the document, leaving you with a plain old PDF or Office document with no content that can cause harm to you or your users, this could be disabling links, removing JavaScript and disabling macros.

However sometimes documents will no longer function, or you might want to access the JavaScript hidden in a PDF for reasons only your organisation know, and we give you that access in the quarantine report.

  • In Conclusion

Don’t panic next time you see a quicksand message in the quarantine, these are still getting delivered in a sanitised and safe method, And always remember to leave the heavy security lifting to us and the software, we are here to help make sure the performance of the system is always exemplary.

Thanks for reading! Make sure you follow us on LinkedIn and YouTube for more blogs, videos and other useful content!