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.

 

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.

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!

10 very practical suggestions for choosing an email archiving solution

What makes a good archiving solution? Count 1 to 10:

 

1- No vendor lock-in

email archiver dashboard

Dashboard

Archiving email is a long term commitment, you need to think long term and make sure that you will be able, in 10 or 20 years from now, to autonomously, easily and reliably make use of your email archive.

If the data is stored in a proprietary format you will not be able to move it to a different archiving solution, you may not be able to even read it without the software provided by the vendor, who may not be around anymore at that time.

This is why it is important that your emails are stored in an open format, a format that you can read with open tools and without any special knowledge: your current staff may not be around at the time you will need to recover the archive.

In 10 or 20 years from now any proprietary tool may not work anymore on whatever will be a current operating system, if it does you may encounter technical issues for which you need the support of a vendor who does not exist anymore. When it will happen you will probably be in a hurry and will find out that everything is much more complicated, expensive and time consuming than you expected.

Having all the archive in an open and standard format, that you can easily recover without any specialized tool is crucial. The best solution allows you to retrieve the email you are searching for with the bare minimum of the tools: a file manager.

Our email archiver stores plain EML files inside Zip files, one Zip file per day or every 4000 email. The filename of the zipfile clearly tells the archive date so that the minimum tool you need to search and recover email is a filemanager.

Why this choice? The Zip file is a standard format, supported now and tomorrow by a big number of open tools. It provides compression, de-duplication and state-of-the-art encryption (AES256). There is no need to re-invent the wheel, unless you are aiming to lock your customers in a proprietary format.

 

2- Legal validity

RFC3161 certified timestamps

Certified timestamps

It is important that your stored email can be used as a legal evidence, should you need it. This means being able to legally prove that:

  1. the email has been received and archived at a specific time
  2. it has not been modified afterwards

There is a standard, formalized in RFC3161, called “certified time-stamping”. This is an open an documented standard, supported by many open tools that can be used for the verification of authenticity.

Our archiver ships with an embedded certification authority that certifies every single email that is stored. This is done automatically out of the box, no configuration is needed.

Whenever an email is retrieved from the archive, the archiver also automatically verifies its integrity.

Legal value should just be, without any configuration burden, and this is the way we designed it.

 

3- Multiple copies

email archiver volumes

Volumes

Storing all of your stuff in a single place is not wise. This applies to backups and especially to email archiving, which is much more than a set of backups. You must be able to store multiple copies of your archive in multiple locations, automatically and continuously.

Our archiver supports an unlimited number of volumes of different types: local disks, LAN drives, object storage (supporting virtually all providers and protocols), ftp and sftp.

Email is automatically stored in multiple copies on different volumes which can exist in many different geographical locations (archives are encrypted with AES256). You can also define different retention times for different volumes. For example you can decide that a local volume stores the last 5 years while a remote object storage volume stores the last 20 years worth of email.

 

4- Usability

email archiver outlook addin

Outlook Addin

Email archiving is not just for compliance, it’s also a tool to improve the productivity of the company. Users should be able to use it for retrieving their own archived email. In order for this to be achieved, the user interaction must be straightforward.

We provide an outlook plugin (it works also in OWA and O365) which can be automatically deployed, an iOS and an Android app, a webapp. Users can not only work with their own email archive: delegation is supported and saved searches can be shared with other users providing an easy way to delegate access to a well specified subset of email.

Slow mail server? The archiver can automatically delete old email from your mailserver, after having verified that it is safely stored in the archive.

The archiver provides a full-text search engine that is much faster than any mailserver. In terms of user interactions the standard definition of what is perceived as “instantaneous” is below 100ms and this is the response time of a standard search query on a big archive of millions of email messages on our archiver.

 

5- Privacy

Privacy management

OPT request for privacy access

Of course you need to make sure that privacy is properly enforced, that email can be seen only by the legit owners and that nobody else, including administrators if that’s your policy, can read it.

On our archiver a tenant can be protected by a privacy officer, which means that also the administrator must ask for authorization in order to access email contents.

The authorization process is fast and straightforward: time-based OTP (think Google Authenticator). Six digits that can easily be dictated over the phone for a lean but strong privacy enforcement. Once obtained the authorization everything is logged and reported back to the privacy officer.

 

6- Flexible ingestion

Ingestion options

Ingestion options

The email archive will follow you over time. The archiver system must be very flexible in terms of ingestion so that you can easily move to different email systems, migrate to or from the cloud, without having to re-think your archiving strategy.

Supported ingestion methods must include SMTP journaling, SMTP forwarding, IMAP, POP3, native O365 and Exchange connectors.

Import of PST or EML archives should be supported as well as exporting to the same formats.

We’ve also implemented batch import for a painless bootstrap: you can provide entire disks full of PSTs or EML archives and they will be imported automatically no matter how big they are.

 

7- Integration

API documentation

API documentation

A full API is important when you need to make some integrations with your infrastructure, especially if you are an ISP or an MSP and you want to integrate the email archiving service with your existing web panels.

All the features that our archiver provides are available through a complete REST API. It is so complete that all of our front-ends (web-app, the mobile apps and the outlook plugin) only interact with the archiver through the API, so all functionalities are naturally exposed via API.

You can use the archiver in complete headless mode if you want, you can perform any integration you will ever need.

 

8- Ease of deployment

Current version

Current version

Cloud? On-prem? That should all be covered. Who knows how your infrastructure will evolve in 10 or 20 years.

A virtual appliance provides the maximum flexibility: you can run it in the cloud, on premise, you can easily migrate it around and increase resources over time, you have no proprietary hardware to replace, move around or repair.

The virtual app automatically updates itself, new features are automatically installed.

 

9- Archiving flexibility

Archiving rules

Archiving rules

You should be able to choose what you want to archive and what you don’t want to archive. You should be able to choose different retention times for different emails: newsletters? One year may be enough. Lawyer? 10 years minimum. And so on.

Talking about lawyers: legal hold is the capability of locking some email (for example related to a legal case) until a specified date. This is what you need to make sure that absolutely nothing happens to it until the case is over.

Archiving rules, retention rules, legal hold: all of these are covered by our archiver and can be configured with high precision and granularity taking advantage of an advanced graphical query builder.

 

10- Granular permissions

Granular role management

Granular role management

Who can do what? You should get to choose, without any limitation. The permission system must adapt to your current and future policies, not the other way around.

Besides the “standard” roles of admin, auditor and user, on our archiver you can create custom roles in a very granular way. A role is basically a collection of capabilities and there are about 80 different capabilities that you can assign to any role you need.

 

Phishing campaign uses Google reCAPTCHA to avoid Sandbox detection

Recent email phishing campaigns are using Google reCAPTCHA as part of their efforts to bypass click-time protection sandboxing, requiring user interaction before delivering the actual contents of the phishing page.

We have seen two different instances of such campaigns, both are targeting Office 365 users in order to collect their credentials. Implementation details suggest that the two campaigns are not coming from the same actors.

In both instances, as soon as the user clicks on the link contained in the email and the browser lands on the page, a Google reCAPTCHA is displayed in an otherwise empty page:

This is intended to act as a barrier for automated scanning services, letting only humans go through this first step.

The phishing web application is built using React, a widely used javascript framework. The level of skills required is well above the average for such phishing campaigns.

The source code of the reactjs phishing application

After the reCAPTCHA has successfully confirmed that the visit comes from a human, then the real phishing page is displayed:

Phishing campaigns keep improving. Evading the inspection from bots increases the longevity of the phishing site by delaying the moment the website is blacklisted and browsers start displaying red warnings to users visiting it. In this case the phishing site is still online and not blacklisted after more than 5 days at the following domain infiniteaudiovisual[.]com.

Here is a video of the whole process:

 

URL sandboxing services like Libraesva URLSand, by visiting the page at click-time, can afford to make deeper checks on the contents of the website and on it’s behavior in reaction to real clicks originated from real phishing emails.

Besides searching for phishing toolkits and patterns, besides semantic analysis and heuristics, besides reputation checks and machine learning, our URLSand actively seeks for evasion and obfuscation attempts.

Evading detection is crucial but it provides useful signals to the expert analysis of specialized automated security systems which are continuously kept up to date by our Esvalabs team.

This is the approach that allows our URLSand to block this and similar threats.

 

 

What is the Libraesva QuickSand Sandbox

The Libraesva Quicksand Sandbox is a security service that protects the Libraesva customers from malicious active content in Microsoft Office and PDF Files.

  • What is active content?

Active content is any executable code embedded in a document, like macros, JavaScript code and ActiveX applications.

Quicksand runs on our Email Security Gateway, for free, meaning that files never leave the gateway.

As the name suggests, the sandbox is very quick and efficient, the attachments are analysed at the same time as the generic email analysis with no delays and isn’t vulnerable to traditional sandbox evasion techniques.

Quicksand identifies active content inside documents and classifies it based on the behaviour, these categories of behaviour are categorised as:

  • Safe: Active content is present and it does not perform any critical operation in respect to security
  • Suspicious: Potentially critical actions are performed by the active content like downloading data from the internet, launching programs, performing actions on the file system and so on
  • Indeterminate: Active content is present but for technical reasons it’s behaviour cannot be categorised with enough accuracy
  • Encrypted: The document is encrypted and therefore it is not possible to tell whether there is active content inside

For each of these categories, you can choose what to do with the file:

  • Deliver: deliver the file as is
  • Sanitize and deliver: disarm the active content and deliver the disarmed document
  • Block: do not deliver the file, it will be removed from the email

Not all of the actions are available for all of the categories, for safety reasons. You can also define fallback actions in case the document cannot be sanitised for technical reasons.

Hopefully this blog post helped you understand a bit more behind our key product feature QuickSand. Please contact us if you need any additional information, or follow this URL here

Which will showcase the feature in a bit more technical depth.

What’s the difference between email backup and email archiving?

Lots of differences, actually.

An email backup is a snapshot of a specific point in time, it’s purpose is for recovery in case of a disaster. Email archiving does not archive a series snapshots but it preserves all data history. The purpose of the archiver is much broader: discovery, compliance, legal, search, analysis and for regulatory and policy obligations.

For example: emails that have been sent or received and then deleted before the backup has been taken, are not available while they are present in the email archiver. Every email enters the email archiver in real time, as soon it is transmitted or received, and frozen there. Quite different from a snapshot.

While a backup data retention policy can only be based on age of data, the data retention policy of the email archiver is very flexible and can be based on age, content, metatada and legal-hold status.

There are also practical conveniences in using the archiver: emails can be automatically deleted from the mailserver in order to reduce it’s load. You can keep only one or two years of email in your mailserver, older emails are still are available on the archiver with even greater search speed and more flexibility of access: the Outlook plugin, the mobile apps, the web interface.

Basically, you can think at the backup as something for administrators while archiving is mostly for users.

As soon as an email is received by the archiver it is hashed, timestamped and certified (RFC3161) providing historicity and valid legal proof of existence and integrity. Whenever that email is retrieved the certified timestamp is verified. The validity of the certified timestamp can also be assessed by third parties using non-proprietary tools.

Full-text search on email content, attributes and metadata enables efficient discovery. Complex searches returning hundreds of thousands of items are performed typically within 0.1 seconds.

Retention periods can be optimized for different email categories: for example email pertaining the organization core business can have a different retention time than bulk email.

Legal hold allows preventing email related to legal cases from being deleted for any reason, until the specified period.

Summarizing: the email archiver provides much more than a backup: not a recovery tool in the hands of the administrators but a production and compliance tool for the whole company.

Whaling, Business Email Compromise and CEO Fraud

Whaling, Business Email Compromise and CEO Fraud

You’re probably familiar with Whaling and Phishing attacks by now, the simple fact that you either are a security professional or work in the cyber sector probably means you are actively facing this threat day in, day out. We at Libraesva fancy shedding a little light as to what makes whaling… whaling.

Let’s start with why, why are these attacks happening, well the first reason is because they are pretty easy to do, simply spoofing the email address is one way of attack, impersonation can be done using a wide range of techniques both technical and social. With name similarities, domain similarities, social engineering and so on. This type of attack can be devastating for organizations and quite lucrative for the attacker with little to no effort needed on the bad guy’s part.

The attack usually starts with a brief email pretending to come from a C-level executive. “Are you in the office?” is a typical approach. If the victim replies, then the attacker knows that his email slipped through the defenses and that the victim didn’t spot the scam. The attack can now proceed toward the final target: a wire transfer or divulging sensitive data.

From an email security perspective, this kind of attack is particularly difficult to block because the emails do not have links or attachments, they are brief, the messages use a type of language that is common in business emails.

The number of these attacks is quickly rising, and it is reaching companies of all sizes. It is also being semi-automated, at least for the initial email approach. Huge losses have been caused by these types of targeted attacks.

Libraesva designed a specific engine in order to intercept these attacks. The required configuration is minimal: the names and the legit email addresses of the company executives. Email addresses on external email providers are supported if the emails are DKIM-signed in order to protect against spoofing. Knowing the legitimate names and email addresses of the C-level executives, the engine can perform deep content analysis that would not be feasible to be performed on all messages.

 

Outlook comments abused to deliver malware

It’s no secret that Microsoft’s Office features are so nice and powerful that attract the attention of the bad guys, always trying new ways to get into your data.

Getting an email to look good with Microsoft Outlook, with it’s terrible CSS support, can be difficult at the best of times, unless you take advantage of Microsoft’s Conditional Tags!

All you need is to insert a special HTML comment that Microsoft’s client can decode and execute:

This code will simply  be ignored by other email clients, as it’s a comment by definition. Simple and powerful!

So powerful that the bad guys already exploited this feature, coding the malware link into HTML comments that are ignored by many email security gateways as well, so passing through the filters.

Let’s see an example to make it clear how it works:

In the above example the link has been defined inside an HTML comment. Should be accordingly ignored by all HTML rendering engines, but as said Microsoft Outlook client (all Windows versions) is an exception.

This is how the email is visualized on a generic email client (Mozilla Thunderbird):

 

And this is how the email is rendered to a Microsoft Outlook user:

 

 

The above link could be used to drive the user to a phishing or malware website!

This is a real life example of what we see in our labs on a daily basis, malware guys are always trying different technics to evade detection.

How to be protected against this attack?

A good Email Security Gateway should be able to disarm HTML comments in email!

Unsure if you are protected?

You can safely and easily run our Libraesva Email Security Test that will simulate most common email threats, including this one!

 

 

Ramnit apparently still spreading after 9 years

It might be a targeted attack, given that we detected it only in one organization, or it might just be an ancient infection still attempting to propagate. In both cases it is an interesting case.

The attack is coming via email, which is interesting given that it is a vbscript attack. Here is how the email looks like:

The email has a spoofed envelope-from and header-from: [email protected] (the mispelling is original)

The email contains vbscript code that creates a file named svchost.exe and executes it:

The variable WriteData is 174592 characters long and contains the payload that will be written to a file named svchost.exe and then executed. The final binary file is 56320 bytes long and it’s sha265 hash is
fd6c69c345f1e32924f0a5bb7393e191b393a78d58e2c6413b03ced7482f2320.

It is a well know trojan, first detected in 2010.
Here is what virustotal knows about it:
https://www.virustotal.com/#/file/fd6c69c345f1e32924f0a5bb7393e191b393a78d58e2c6413b03ced7482f2320/details
And here is the analysis performed by the sandbox at hybrid-analysis:
https://www.hybrid-analysis.com/sample/fd6c69c345f1e32924f0a5bb7393e191b393a78d58e2c6413b03ced7482f2320?environmentId=110

Interestingly, the text-only entity of the email also contains the part of the script that is in the html commented area:

This is likely due to a sloppy auto-generation of the text entity that greatly increases the email size for no reason.

Our systems detected this attack yesterday in a single organization in the UK, making us wonder whether this is a targeted attack.
But, really, a targeted attack using a 9 year old malware?
It looks quite strange especially considering that the payload is delivered through a vbscript embedded in the html entity of the email, which is something that virtually every email security solution detects and disarms.

Curious things happen. If you detected something similar recently, feel free to get in touch with me.

If this is a 9 year old infection still propagating, it is by itself worth of some thoughts.