Using Attackers' Tactics To Battle Banking Trojans

Sometimes becoming like your enemy isn't a bad thing.

In a world where malware authors use obfuscation to mask their malicious intent, security researchers may do well to do the same. It is this idea Trustwave researchers Ziv Mador and Ryan Barnett are planning to build on in their upcoming presentation at the RSA Conference in San Francisco next month.

According to Mador, Trustwave's director of security research, the presentation is about leveraging the tactics of attackers in ways that can help an organization's defense -- starting with taking the concept of obfuscation and turning it against the attacker. The ultimate goal, the researchers explain, is to break the Web injection functionality of Trojans, such as ZeuS.

"ZeuS' Web injects functionality happens by hooking into various Windows processes, including wininet.dll," says Barnett, lead security researcher at Trustwave. "This provides raw access to the HTTP data as if it is going across the network. It is at this point, before the data reaches the actual Internet Explorer Web browser process, that ZeuS attempts to modify the HTTP data.

"What we show is that by using even basic HTML/[JavaScript] obfuscation -- we used a basic Caesar Cipher -- it can break the Web injects. Our payloads are automatically decoded by the Web browser and rendered appropriately to the end user. In order to get access to the deobfuscated version of the HTML, banking Trojans would need to hook directly into the Web browser itself and have access to the DOM data."

Even if the Trojan runs within the browser, the obfuscation can protect it, Mador adds, unless it is configured to run after the deobfuscation loop executes.

"Most banking Trojans are not programmed that way," he says. "I would add that exploit kits often use dynamic variable names to randomize the content between different web requests. For example, random variable names are used as randomization seeds for the obfuscation. Web fraud detection code can use similar techniques for protecting itself. For example, the Web inject is configured to remove the protective code from certain location in the page. By randomizing the content of the Web page the same way, Web injects is expected to break. Improving the banking Trojans to remove them from random locations in the page adds complexity to the authors of banking Trojans."

There are some examples of banking Trojans that work as plugins for Mozilla Firefox or Google Chrome that may be able to access the DOM and circumvent the technique, Barnett concedes.

"Web fraud detection vendors have software that can work as extensions/plugins for the user's Web browser," he says. "This is another area where security researchers/vendors can reverse-engineer banking Trojan plugins to better detect and prevent them from working by monitoring and protecting registering these hooks."

In some ways, the idea is similar to the concept of a Russian Matryoshka doll, where a doll is placed inside a larger doll, Barnett says. In this case, the HTML of the bank login page is placed inside a virtual Russian doll, which provides a layer of obfuscation ZeuS is not currently prepared to handle.

"[ZeuS] is looking for that raw HTML, and if it doesn't see it, the Web inject does not work," he says. "So it breaks it."

"What we're saying is look to tactics ... attacker groups are using," he adds. "Perhaps you can use that in a different way, or apply it in a different area."

The presentation is scheduled for Feb. 26. Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.