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.
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  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:
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.
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.
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:
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.
 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.
Latest posts by Clemens Kolbitsch (see all)
- Ransomware: Too Overt to Hide [Part 2] - April 13, 2017
- Party like it’s 1999: Comeback of VBA Malware Downloaders [Part 3] - November 10, 2016
- Lifting the Seams of the Shifu “Patchwork” Malware - September 4, 2015