Last fall, we posted about the new tricks of the Tinba trojan. Now, the Dyre malware, another trojan has some new tricks of its own.
The Dyre Wolf malware campaign made headlines in early April as a banking trojan that bypassed 2 factor authentication in order to steal over $1 million from corporate bank accounts. The Dyre Wolf campaign used a combination of malware and social engineering and remained undetected by the majority of anti-virus products.
Having closely monitored the activities of the cyber gang behind the Dyre malware, we recently detected some new changes to the malware. The changes prompted further investigation by our Research Lab.
Anti-Sandboxing Techniques
This version of the Dyre malware is able to evade analysis by sandboxing solutions by checking how many processor cores the machine has. If the machine has only one core it immediately terminates. While this is not the only way to avoid sandboxes, the attackers behind Dyre decided to pick this specific known and openly available technique. As many sandboxes are configured with only one processor with one core as a way to save resources, the check (Figure 1) performed by Dyre is a good and effective way to avoid being analyzed. On the other hand, most of the machines (PCs) in use today have more than one core.
Figure 1: Dyre malware checks the number of processors
One Check to Fool Them All (Most)
In general, most malware families looking to avoid detection by sandboxes use multiple techniques to fool the system. As this new version of Dyre malware has only one anti-sandboxing technique, we dove deeper to figure out why this specific one was chosen. We first began by testing a number of non-commercial, publicly available sandboxes. When four in a row failed to successfully analyze the malware, we knew we were on to something. We continued to test additional known sandbox technologies and four commercially available sandboxes failed to analyze the Dyre malware as well. Trying to put ourselves in the mindset of the cyber criminals, it is possible that they conducted their own research and determined that this one particular technique or check was the key to remaining undetected by sandboxing solutions. Subsequently, we have provided the details to the relevant security vendors.
![example of failed sandbox analysis]()
Figure 2: A sandbox failing to analyze the malware
Dyre’s Additional Tricks
This was not the only change made to the Dyre malware in order to help it avoid detection. While the communication path Dyre followed might have stayed the same, it did switch user agents (Figure 3). Changing user agents is a known technique in order to avoid detection by signature-based systems. Additionally, some minor changes were made to the way the malware behaves in the system also as a means to avoid signature-based detection products.
Old - Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36 New - Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0E; .NET4.0C; rv:11.0) like Gecko
Figure 3: Old and new user agent for Dyre
Dyre, Not the Lone Wolf
In this instance, Dyre did not operate on its own. The Dyre malware ran in conjunction with the Upatre malware, a known downloader. Upatre also experienced some updates, somewhat similar in nature to Dyre’s updates and with the same goal in mind– avoid detection.
In the past Upatre, used a very unique and distinctive user agent that had a “typo.” The typo is Mazilla/5.0; Mozilla/5.0 is what would have been a “correct” and legitimate user agent.
The new version of the Upatre malware has a more generic user agent. Additionally, it now uses two different user agents where in the past it only had one (Figure 4). The two new user agents appear to be common, but the regularity could be deceiving. Both of these updates to Upatre’s user agent is a way to avoid signature-based detection.
Old - Mazilla/5.0 New1 - Mozilla/5.0 (Windows NT 6.1) New2 - Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0
Figure 4: Old and new user agents for Upatre
Additionally, the Upatre downloader’s communication path changed. In previous versions of Upatre malware, its URI path was almost identical to the Dyre malware’s path. It used a particular campaign ID naming convention based on date and location, as shown in Figure 5a. In the new Upatre version, the communication path naming convention is not based on identifiable characteristics, rather it appears to be a more obscure naming convention.
Old - https://141.105.141.87:13970/1004uk21//0/51-SP3/0/LFBEMMBEIDBJD New - https://81.7.109.65:13383/TUSR13//0/51-SP3/0/IBIJBEJBK
Figure 5: New URI/path for Upatre
Figure 5a: Breakdown of the naming convention used by the old version of Upatre
The Dyre malware’s success at evading sandboxes is just another example of why sandboxing, as a standalone, is an incomplete security approach. Rather the ability to detect evasive malware needs to include machine learning and the analysis of outbound traffic over time. This approach will provide a much more comprehensive security posture in today’s worsening threat landscape.
Contributors: Yevgeniy Kulakov and Shimon Zvirin
MD5s of the new Dyre version
999bc5e16312db6abff5f6c9e54c546f
b44634d90a9ff2ed8a9d0304c11bf612
dd207384b31d118745ebc83203a4b04a
The post New Dyre Version- Yet Another Malware Evading Sandboxes appeared first on Seculert Blog on Breach Detection.
