Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

5/1/2015
02:00 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
100%
0%

Dyre Trojan Adds New Sandbox-Evasion Feature

New tactic makes it that much harder to detect, says Seculert.

The Dyre malware tool, which has emerged as one of the most significant banking Trojans since the takedown of the Gameover Zeus botnet last June, has added an effective new trick for avoiding detection by anti-malware tools.

Security researchers at Seculert recently discovered a new version of Dyre that is able to evade sandbox detection tools by checking how many processor cores the machine has.

If it discovers the machine has just one core it immediately terminates on the system it has infected before it can be spotted, Seculert’s CTO and co-founder Aviv Raff, said in a blog Thursday.

 A security sandbox is basically a secure virtualized environment for executing and running unfamiliar or untrusted code to see if it contains any malware. Several security tools are currently available that offer sandboxing as a technique for detecting and blocking malicious code.

Typically, sandboxes are configured with just one processor and one core, to save system resources, Raff said in his blog. So checking the number of cores present on a system, like the latest version of Dyre does, is a simple and effective way for the malware to know if it is running in a sandbox environment or not.

Typically, modern malware tools employ multiple techniques to try and avoid being caught in the sandbox Raff said pointing to a research paper that enumerates some of the methods.

For example, a malware tool might search for a specific process name on the system it has infected to see if it can detect the presence of a sandbox or virtual machine. The goal is to try and find process names like vmsrvc.exe, or vmtoolsd.exe and similar that suggests to the malware that it is running in a virtual environment, the paper noted.

Similarly, some malware tools might look for specific registry entries or publicly known module names used by security sandboxes to detect the presence of one. Others look to see if they can find the backdoor that many virtual machines use to communicate with the guest operating system, the paper noted.

The latest version of Dyre that Seculert observed however relies just on the processor core counting technique to make a determination of whether it is running in a sandbox, Raff said. The reason could be that the malware authors have determined this one particular technique is good enough, he noted.

When Seculert tested several commercial and non-commercial sandbox technologies to see if they could detect the new version of Dyre, not one of them did, Raff said.

It is possible the [the malware authors] conducted their own research and determined that this one particular technique or check was the key to remaining undetected by sandboxing solutions,” he said. He added that Seculert had provided details of its discovery to relevant security vendors.

The new sandbox evasion technique is part of a string of modifications and tweaks that have made Dyre an increasingly potent threat since it first emerged last year. Earlier this year, IBM researchers spotted a new malware campaign where attackers used a Dyre variant dubbed Dyre Wolf to steal more than $1 million from businesses.

In a recent report Dell SecureWorks highlighted Dyre as one of the major new banking Trojans to have emerged in the post-Zeus era.

 

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
RetiredUser
0%
100%
RetiredUser,
User Rank: Ninja
5/3/2015 | 5:13:28 PM
Variability in Programming: Overhead or Security?
The ability for malicious code to examine the host and perform data collection and analysis based upon known process naming conventions is something that goes back quite some time.  Just as with writing complex debug code during development to aid software bug tracking during testing is a topic of divide amongst some programmers and management (there is overhead involved, both time to write the debug code and in some cases run it), so too is the question at the software application architecture level of whether to program variability into software when it comes to process, file, and directory structure naming.  

In fact, beyond the idea of writing a piece of security software that can dynamically change the names of key elements of the program that malware might search for to determine if a system it is attacking is protected by such security applications, there are other features that could be programmed such as encryption and masking/cloaking (taking on attributes of other non-security programs not installed on the system, but that pose no threat to the malware).

To write antivirus software with such capabilities is the future of InfoSec, I believe, but is the overhead it will take to get such applications there worth it?  I think so.  Think about it:  Your antivirus software to any other observer is an instance of Adobe Acrobat, and your sandbox is programmed such that it mirrors a normal OS with no references to VM or similar processes.  The ultimate cloaking device.   

Virus and malware writers are already thinking ahead of InfoSec professionals by engaging creative thinking like this.  Let's get ahead of them and build the perfect mouse trap.
News
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Edge-DRsplash-10-edge-articles
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
News
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-25284
PUBLISHED: 2021-02-27
An issue was discovered in through SaltStack Salt before 3002.5. salt.modules.cmdmod can log credentials to the info or error log level.
CVE-2021-3144
PUBLISHED: 2021-02-27
In SaltStack Salt before 3002.5, eauth tokens can be used once after expiration. (They might be used to run command against the salt master or minions.)
CVE-2021-3148
PUBLISHED: 2021-02-27
An issue was discovered in SaltStack Salt before 3002.5. Sending crafted web requests to the Salt API can result in salt.utils.thin.gen_thin() command injection because of different handling of single versus double quotes. This is related to salt/utils/thin.py.
CVE-2021-3151
PUBLISHED: 2021-02-27
i-doit before 1.16.0 is affected by Stored Cross-Site Scripting (XSS) issues that could allow remote authenticated attackers to inject arbitrary web script or HTML via C__MONITORING__CONFIG__TITLE, SM2__C__MONITORING__CONFIG__TITLE, C__MONITORING__CONFIG__PATH, SM2__C__MONITORING__CONFIG__PATH, C__M...
CVE-2021-3197
PUBLISHED: 2021-02-27
An issue was discovered in SaltStack Salt before 3002.5. The salt-api's ssh client is vulnerable to a shell injection by including ProxyCommand in an argument, or via ssh_options provided in an API request.