Speaking of Security – The RSA Blog and Podcast

The RSA Research Lab has analyzed one of the most recent SpyEye v1.3 variants and has determined beyond doubt that the new hybrid Trojan is in fact already active in the wild. RSA’s researchers were able to reverse engineer the code and assert that it does indeed contain an exact code piece that has long been part of the Zeus Trojan’s sophisticated HTML injection mechanism. Snapshots of the assembly code are included below (See Figure 1 and Figure 2), courtesy of the RSA Research Lab.

Ever since the initial release of the SpyEye Trojan in December 2009, its coder, who goes by two aliases, “Harderman” and “Gribodemon”, has been working incessantly on upgrading his Trojan, harvesting the fruits of his labor by selling it to fraudsters. Harderman has already released numerous SpyEye versions, often adding unique features which were never used in Trojan codes before it.

SpyEye gained rapid momentum in 2010; it was cheaper than Zeus yet a sophisticated banker Trojan. One of its releases even introduced a “Kill Zeus” feature designed to disable the Zeus Trojan’s control over a machine infected with both Trojans. The number of SpyEye drop servers detected by RSA was increasingly growing, which meant that SpyEye had officially become the most significant rival to the “God of all Trojans.”

Looking back to late October 2010, one can appreciate the surprise factor that marked one of the most significant events recorded in cybercrime history to date: a code merger between the most popular commercially sold Trojan kits – Zeus, and its biggest competitor – SpyEye.

Immediately after the news washed through underground forums and security blogs, fraudsters and security professionals alike turned their attention to Harderman’s announcements. The new owner of both Trojans posted information about his upcoming creation, which he dubbed – “one super Trojan”; a merged code uniting both Trojans and his promise of new features to make it bigger and better than ever.

The Promise of a Hybrid

In November 2010, Harderman took the time to give his existing and future clients a glimpse into what was to come. Intending to turn his efforts to the hybrid code, the Trojan coder mentioned a few improvements his peers could expect:

• SpyEye would be more modular and easier to manage (using separate dll files for each of its malicious capabilities).

• Program the Trojan as a “RingØ” rootkit – aiming to considerably step-up the hybrid code’s hold on infected machines.

• A “Remote control” plugin (VNC) addition

• Revamp HTML Injections – Harderman acknowledged that Zeus’ injections were better written than those developed for SpyEye.

• New admin panel – a hybrid interface supposedly meant to combine both admin panel styles from the Zeus and SpyEye Trojans.

RSA has kept a close watch on every new variant presented by SpyEye’s coder, as new experimental versions were being released often and rapidly. A new pricing scheme is also expected to be released soon.

Enter SpyEye v1.3 with New Features from Zeus

Harderman seems to be hard at work; SpyEye’s new face includes additional changes as analyzed in v1.3 variants:

1. Further integration of Zeus code into the Internet-Explorer HTML injection mechanism.

2. Modified encryption method applied to the SpyEye configuration file;

3. Built like a legitimate program – an encapsulated executable modular architecture;

4. Frequently modified information is now kept inside the PE resources section;

5. Remote thread executes injected code.

The New Logic

Why Use Zeus’ HTML Injection Method?

Internet browsers typically speed-up the process of viewing a page by downloading it from the original site the first time it’s accessed, then keeping it on file inside the “cache” for later viewings. SpyEye had trouble handling that boundary condition and could not inject fake content into those cached pages, resulting in the customer’s viewing the true web page, as it was originally intended.

Harderman’s solution to this problem was to have SpyEye delete all the cache content before it injected additional HTML code into any web page. Conversely, Zeus’ coder had somewhat of a more elegant solution to the cached page issues – upon detecting access to a cached page, Zeus would inject it’s HTML code into the copy of the page already cached on disk. This resulted in Zeus’ notoriously seamless HTML injections. As mentioned earlier in this report, SpyEye has been sporting this new code snippet, extracted directly out of the Zeus source-code.

New Encryption Method – and Still Not Sophisticated Enough

SpyEye’s newest version does not hide the configuration file’s encryption key. Instead of keeping the password out of sight, Harderman relied entirely on the hope that fraudsters would not figure out his encryption algorithm. As it turns, and unlike the Zeus Trojan’s encryption, this is not one of the aspects Harderman invested much into.

SpyEye’s encryption is rather mediocre in comparison to its general level of sophistication. It is also possible that the simplicity was intentional. This current encryption level provides adequate levels of protection against automated security products, bearing in mind that any encryption method is bound to eventually succumb to manual analysis.

SpyEye’s decryption algorithm follows the logic described below:

From the second byte and up, each byte that follows is ‘xored’ with the value ØxC4. The previous byte gets subtracted from the result. This produces an encrypted zip file whose key is the SpyEye encryption key; this key is stored in the resources section of each SpyEye variant.

An Encapsulated EXE File

Much like the genuine programs one would buy from a legitimate software provider, SpyEye now has a modular architecture; as part of that architecture SpyEye’s new variants come as en executable file embedded into another executable file. This encapsulation method ensures that the first EXE (the external layer) prepares the necessary resources, the ‘installation environment’ for the embedded EXE (the internal layer); the latter representing the actual Trojan’s core files and its functionality layer. SpyEye’s core EXE is written into the data section of the external layer. The external EXE does not get deleted after it runs.

Why embed an EXE into an EXE? This method makes the Trojan more modular – in terms of developing software it eases the code writer’s work, provides for better design options, simplifies work on the highly complicated code and can even be used to divide the development work between programmers. The embedded EXE technique improves the code injection mechanism in SpyEye.

PE Resources[1]

In this new version of his hybrid Trojan, Harderman moved SpyEye’s configurations encryption key, the configuration file and parts of the code into the PE resources section of the file. It is likely he expects those pieces of data to need frequent modifications. This particular method of resource storage facilitates the creation of new SpyEye variants by simplifying the code that has to be implemented in the Trojan’s builder.

This also opens up a window for further development of encryption and obfuscation of these sensitive parts of the Trojan. Moreover, this feature could possibly be used in the future to allow for more customization by SpyEye operators, via integration in the SpyEye SDK[2].

New Remote Process Injection Method Makes SpyEye Harder to Detect

The SpyEye hybrid now has a new injection mechanism; instead of injecting itself into a target process (for example, into an IE process), SpyEye will inject the embedded EXE into a completely different process, using that process’ memory space and resources. SpyEye loads its embedded (core) executable into that “borrowed” process’ memory space, and then creates a remote thread that will actually execute the loaded code from that location.

What’s the logic behind this change? Well, when it comes to Trojans the purpose is always to keep the file hidden and ensure it does not get detected by AV software or other security tools. On top of creating a file packing effect, the remote thread technique ensures that the suspicious injected code would never equal the binary code of the Trojan binary on disk. This in turn means that even if the code was detected and flagged in a scan (on disk), the injected code running inside another process will not appear related and vice versa.

Conclusion

And so the perpetual Trojan arms race continues. It appears that the more security features are put in place to protect online banking environments, the further Trojan developers will go in their attempts to infiltrate the systems, compromise security, and better hide their activities within infected computers.

Although one may assume that the new SpyEye hybrid, or super-Trojan if you will, is going to be Harderman’s (and cybercrime’s) main focus going forward, security researchers hold different forecasts concerning the subsequent Zeus and SpyEye versions to come. RSA believes that the Zeus Trojan may gradually become a relic of the past. Although the old Zeus may still be the subject of new underground upgrades, it will most likely begin fading away as fraudsters turn to SpyEye – a Trojan code offering both technical support and future upgrades.

Figure 1: Zeus Trojan (v2.0.8.9) HTML Injection Code (Taken from Zeus’ Assembly Code)

Figure 2: The Identical Zeus code Snippet Used in the New SpyEye Hybrid’s (v1.3.5) Assembly Code

---

[1] Information embedded into the executable file, editable and accessible via Windows APIs.

[2] SDK: Software Development Kit