Dyre Banking Trojan Jumps Out of Sandbox

Researchers at Seculert have found a new version of the Dyre banking malware, one that is adept at avoiding sandbox detection.

A number of unidentified commercial and freely available sandboxes fail to detect a new version of the Dyre banking Trojan, which was recently blamed for more than $1 million in losses to financial institutions and enterprises.

The new strain of Dyre, also known as Dyreza, uses a fairly new technique to avoid detection that is one of many established ways to elude sandbox protections already in place.

“There are many other ways to do that, some are publicly known and some are not, therefore it will be very challenging for the vendors to address this specific evasion technique,” said Aviv Raff, CTO of Seculert, which yesterday published a report on the Dyre update. “This is why Sandbox alone should not be used for detection of such threats.”

Raff said Seculert tested four non-commercial publicly available sandboxes, and four commercial products—all of which failed to detect the virulent banking malware. Dyre’s elusiveness is from a new feature that checks for the number of processor cores running on the infected machine; if there’s only one, it terminates before executing.

“Most of the machines today have more than one-processor core. On the other hand, sandboxes use only one core in order to save resources,” Raff said, refusing to reveal the affected vendors by name. “We don’t want to help the bad guys’ evasion efforts in this, so we decided not to reveal the vendor names. We notified the relevant vendors, and currently working with the ones responded.

“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,” Raff said.

In April, researchers at IBM published a report that said they had seen fraudulent money transfers from corporate banking accounts exceeding $1 million. The criminals behind Dyre had invested in a significant social engineering scam to help bypass two-factor authentication by adding a call-center operation where victims were enticed to call support to help unlock their accounts and were tricked into giving up passwords and 2FA PIN codes.

In addition to the phony support call, IBM researchers said that within seconds of moving money out of a high-value bank account, the criminals launched a denial-of-service attack against the bank or targeted organization in order to get IT security resources and attention away from the theft. IBM said the number of infections through the first quarter of 2015 swelled to the thousands from a few hundred at the end of 2014.

Seculert’s report indicates an additional change to Dyre—a new user agent, which is described in the report.

“Changing user agents is a known technique in order to avoid detection by signature-based systems,” the Seculert report said. “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.’

A similar user agent change was made to the Upatre downloader, which infects a system first then establishes a connection before downloading Dyre onto a compromised computer. Seculert said the new version of Upatre it spotted has a more generic user agent that helps it avoid detection. Seculert said Upatre’s communication path also 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,” the report said. “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.”

Suggested articles

Discussion

  • Anonymous on

    This article is mistitled. "Jumping out" of a sandbox and sandbox evasion are entirely different concepts. One concept explores how to bypass detection, while another explains how a program can execute code outside of the original sandbox environment. I suggest editing this article.
  • Christopher on

    Would like to see a list of public tools used and MD5s of the samples tested please
  • Anonymous on

    The subject of the article is misleading, one might think that Dyre has found a way to execute its code outside of the Sandbox environment, which isn't the case here. This article describes a Dyre variant which has implemented anti VM techniques, this is not unique as we’ve already encountered ZeuS and Citadel variants in the past which wouldn’t run in a Virtual Machine. Cuckoo Sandbox supports bare metal clients, meaning it can manage “real” machines, so this Dyre variant actually can be analyzed in a sandbox environment. Good PR for Seculert though, spreading Fear, Uncertainty and Doubt across the infosec media.
  • Josh on

    I agree. I thought I was going to read about a true jump out technique, not evasion.
  • Karen Bannan on

    This just shows that you need to be working with your security provider and constantly watching out for the next big thing. --KB Karen J. Bannan, commenting on behalf of IDG and FireEye.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.