Does Dyre malware play nice in your sandbox?

Does Dyre malware play nice in your sandbox?

Recent media coverage drew a lot of attention to a new variant of the Dyre/Dyreza malware family that is evading traditional sandbox-based analysis systems. At the same time, F-Secure highlighted similar tricks found in Tinba malware. Not only are individual families starting to detect and evade traditional sandboxes – it’s becoming a much more global and mainstream trend, as we covered recently at RSA.

A recent post in our series The Hammer Strikes describes how we allow any security solution to play in our sandbox, which allows integration of the Lastline platform with other technologies already present in a customer environment.

But what if malware doesn’t want to play in your sandbox?

In this post, we highlight how malware behaves in a FUSE (full-system emulation) analysis environment, how even evasive samples can still be detected, and that it’s time to let go of traditional sandboxing approaches, as they are falling further and further behind.

Full-System Emulation

What do we mean with FUSE? Isn’t any sandbox providing a completely virtualized environment? Sadly, the answer is no.

Most traditional sandboxes use off-the-shelf hypervisors to contain the execution of malware inside a virtual environment. On top of this, they add a mechanism for recording the behavior of the program under analysis.

One crucial part this approach completely neglects is that the CPU is not fully virtualized, although it is the only part that directly interacts with malware code. Instead, the malware runs on a real CPU (using hypervisor extensions), exposing it to fingerprinting and, in turn, evasion.

A true full-system emulator includes every component of the virtual environment, ranging from the CPU executing instructions of a malware program, the virtualized peripherals (such as disks, network controllers, IO devices, etc), a virtual network (providing all services that might be used by malware to communicate, but, at the same time, enforcing containment), all the way to a user interacting with programs inside the sandbox.

Dyre versus FUSE

One of the tricks recently added to Dyre [1] is to check for the number of CPU cores present on a host. Most systems today make use of multiple cores, so if only one core is present on the host, chances of running inside a sandbox are high.

In a FUSE solution, the CPU, like everything else, is virtual and thus under control of the analysis engine. Thus, the system can emulate any number of CPUs that it wants. Your network is full of high-end machines running 8 cores each?… the analysis system adapts to your profile and bypasses evasions against single-core machines. Your network is full of 1982 single-core dinosaurs?… let’s emulate and mimic an environment resembling that instead. This way, your FUSE solution identifies threats that are attacking you, and not what your sandbox vendor configured.

As a result, running Dyre samples in FUSE reveals the interesting behavior that we need for detection:

Dyre Malware Full-System Emulation Analysis
Analyzing Dyre in a FUSE analysis solution (View Full-size)

Dyre versus Virtual Users

Typically, when a real user is logged into a system, one can expect certain behaviors to take place. Examples are mouse activity (a user clicking on links in a browser), new programs being launched every once in a while, files being opened, etc.

Another interesting trick used by Dyre is to check if the running system suspiciously lacks this type of user behaviors: It uses CountClipboardFormats to check if there is any data in the clipboard of the operating system.

Dyre Malware Execution
(View Full-size)

Interesting technical side note: When Dyre is executed in a system without any clipboard content, a logic error in the malware code causes it to crash. The number of elements in the clipboard is used to allocate a buffer in memory, resulting in a NULL pointer if the clipboard is empty.

Users VS Dyre Malware
(View Full-size)

Clearly, a real user would use copy-paste functionality at least every once in a while, but a virtual user might not.

No clipboard content, no behavior.

This is very similar to what we covered in the past about detecting key-loggers: If malware does not find interesting activity on a host, it will not reveal its malicious intentions.

Tinba versus Virtual Users

Identifying sandboxes based on user-behavior is similar to an evasion trick used by Tinba, as posted recently by F-Secure: If there is no interaction between users and running applications, malware can decide that the host is not an interesting target. More precisely, if the user does not move the mouse or does not switch between multiple program windows, the malware refuses to reveal its bad intentions.

As we say above, a true FUSE system controls everything – including the user interactions that take place within the virtual system, eliciting the behavior necessary for detecting Tinba:

Tinba malware vs. virtual users
(View Full-size)

Summary

Dyre and Tinba are two recent examples that show how evasive malware has gone mainstream. Traditional sandboxing approaches are fundamentally unable to address all these issues raised by modern malware.

Lastline uses full-system emulation that is in control of all aspects of the analysis environment, ranging from a virtual CPU, all the way to a virtual user, and can force malware to execute the way it would on a real target machine. This elicits the interesting behavior the system needs to classify malware and protect users.

[1] Dyre is a banking trojan that was first seen in June of 2014. The family is relatively new considering that Zeus was first identified in 2007. Even though the family of malware is new, it is quite prominent compared to other families. In October of 2014 the US-CERT issued an alert on the family due to its high volume of attacks. Many of these attack occur as spam campaigns that contains an Upatre executable (lightweight downloader) that downloads and executes Dyre. Since its initial release, it has added features such as the use of domain generation algorithms and access to Invisible Internet Project (I2P) to prevent attempts to take down its command and control.

Clemens Kolbitsch

Clemens Kolbitsch

Clemens is a Security Researcher and engine developer at Lastline. As a lead-developer of Anubis, he has gained profound expertise in analyzing current, malicious code found in the wild. He has observed various trends in the malware community and successfully published peer-reviewed research papers. In the past, he also investigated offensive technologies presenting results at conferences such as BlackHat.
Clemens Kolbitsch