Banking Trojans traditionally use configuration files that have been stored on the computer being attacked. These configuration files contain the addresses of the compromised websites, and the code, called the Webinject, which they are seeking to add to these websites via the banking Trojans. This code is then responsible for stealing access data and personal information, for example.
Fortunately, this technique brings with it two critical disadvantages for the cyber criminals: it is relatively simple for the analysts to extract the configurations from the stored file and work out which websites are being attacked in which way. It is a well-known fact that analysts do this to study attacks and detect the locations responsible for them, so that ultimately the operators can take countermeasures against the compromised websites.
The second disadvantage is that the attack targets for the webinjects must be known in advance. This means that the attackers have to list every website from which they want to steal data in the configuration file for the information stealer, and have to supply the webinjects — the injected code — for the relevant websites in the configuration data.
Consequently, updating the webinject or making a change to the compromised website involves updating the entire configuration file.
The cyber criminals are now using Cloud technology to circumvent these disadvantages.
The first step: special configuration of ZeuS
One example of this is a special configuration of the well-known banking Trojan ZeuS, discovered a few days ago by G Data analysts.
In this scenario, the configuration file contains a list of URLs to be attacked and the code to be injected, as usual. The code here is special and interesting, here shown in an unobscured form:
Instead of directly adding the entire malware code as usual, here only a small piece of malware in the form of Javascript is used. This piece has the exclusive purpose of using the LoadInjectScript function to dynamically download more Javascript from a website operated by the attacker. In this specific case, this was a script targeting PayPal. It asked for the user's credit card data to be re-entered, allegedly for security reasons.
Of course, any entered data is immediately sent to the attacker. This has nothing at all to do with an official PayPal process.
The technology used here for dynamic downloading from the Cloud entails several advantages: for example, when the layout of the compromised website is updated, the attacker can adapt his own layout without having to send new configuration files to every infected computer. Any change to the relevant HTML code can be responded to in the same way. Each time a website that is targeted for attack is called up, the actual malware is downloaded in real time from the attacker's server in the form of Javascript. This means that it can be adapted at any time to match the malware returned by the server.
This also enables the use of so-called "logic bombs". These ensure that the malware is only downloaded under specific conditions. For example, filters can be applied based on time or location. As the locations of many security companies are known, they can be specifically excluded in this way, making analyses and countermeasures more difficult.
Perfecting the dynamic principle: Ciavax
A Trojan called Ciavax that has been active since August has perfected this principle. In this case, even the list of sites to be attacked is kept secret.
The following generic Javascript code is injected into every website that is called up:
This relatively short code dynamically downloads the actual malware in a second step, via a PHP site controlled by the attacker. In this case the ID of the user making the enquiry, the URL (document.URL) and the referer (document.referer) are all transmitted.
This technology boasts all the advantages of the ZeuS variant mentioned above, but goes even further. It is no longer possible for analysts to detect which sites are actually earmarked for attack. It would ultimately be possible to work out which sites are involved by using brute force to check out a list of URLs that are particularly at risk because of their subject matter. However, besides the sheer effort involved, there is another disadvantage to this: the massive number of queries would probably attract the attention of the attacker, allowing them to exclude the analysts concerned from any delivery of code.
In addition, the attacker can see every site accessed by the victim in real time and can decide whom he wants to attack with which additional malware.
The "digital movement profiles" of victims that the attacker accumulates in real time can also provide him with important information when developing new webinjects. This makes it possible to track down websites not currently being targeted, to work out whether they are used frequently by the victims and, as such, whether they represent attractive targets.
In conclusion, the ability of these attacks to restrict analysis of the targeted websites will make life significantly more difficult for analysts in future. And in addition to this, spying on potential targets before an actual attack takes place is evidence of the increasing professionalism of the attackers. Equally noteworthy is the possibility of using webinjects to attack victims in real time and in a targeted manner.
G Data protects
G Data detects these and other Trojans by using CloseGap, Behaviour Blocker and BankGuard.
For research colleagues: The samples dealt with here have the following checksums:
ZeuS 54f731c4aabf23ed637259218946a438869b93fe454d45b154515bda914fe4ac
Ciavax 14f6f19356c35834efaca6eb95d00f02de3fcb255d7555a098ed2904c265f7c2