Winning the Online Banking War

Detecting banking malware has become part and parcel of the security industry, so cybercriminals are continuously looking to gain the upper hand in the battle against the financial industry and security vendors. In the BlackHat presentation Winning the Online Banking War last August 5, Sean Park proposed the use of a new online banking security framework for banks and web app developers called “Malware Inject Prevention System.”

The advent of ZeuS ignited the renaissance of banking Trojans a few years ago. The ZeuS source leak enabled the underground community to competitively develop new variants and even pushed the creation of fresh banking Trojan families such as Carberp. This boom of banking Trojans was possible because the ZeuS model was a modular approach that separates the malware from its money-stealing web application logic—which is called the ‘webinject’ or sometimes, ‘injects’ or ‘injections’. This enables cybercriminals to steal online banking customer credentials and to perform transaction manipulation and webinjects while bypassing two-factor authentication. (See also Automating Online Banking Fraud.)

Although a significant part of the cat-and-mouse battle between the security industry and cybercriminals has to do with detecting the malware binary and evading detection, the detection of webinjects and the subsequent creation of evasion tactics has become a hot new battle ground between the banking industry and cybercriminals.

Battling it out in the DOM space

Currently, many security products and financial institutions rely on online banking page integrity checks to detect the presence of banking malware. This technique works due to the inherent mechanics of banking malware injecting itself into the browser’s Document Object Model (DOM) space. For instance, it is quite common for an online banking victim to give away the secure code when he encounters the message below during an online banking session.

Figure 1. Sample webinject

An HTML message that’s combined with a piece of JavaScript code injected by the banking malware renders the above screen. It is this injected JavaScript that many banks or vendors use as an artefact in order to detect the infected online banking session via DOM scan.

However, this purely web-based DOM scan method can be subverted in many ways:

Exploiting invalid memory reference patterns

The webinject can go undetected by exploiting invalid memory reference patterns. When the webinject removes its own script node from the DOM while its reference is kept elsewhere, it causes an invalid memory reference. This is because JavaScript’s garbage collector won’t be able to free the memory object whose reference count is positive. Using this technique, a webinject can register an event handler to an object within the online banking page, remove itself from DOM, and still remain “alive.” More importantly, the naïve script enumeration technique will not be able to see the removed script node.

Detection script evasion

One of the major attack vectors in this threat environment is manipulating the detection script. Once the attackers reverse engineer the detection script, they can forge the intelligence transmitted by the detection script through a replay attack and manipulate the functions implemented by the detection script. This is possible because the banking malware has full visibility and access to all online banking web applications as well as the detection script. The attackers can insert their code at an arbitrary location, replace the detection script functions, or manipulate the detection code. This renders the detection script unable to perform its intended function, unless further remediation is taken.

Use of rootkits

In the world of operating systems, rootkits allow malware to hide malicious components by intercepting the normal control flow of API functions. Rootkit are therefore another viable technique the fraudsters can take advantage of. The webinject can hook functions provided by DOM and the libraries (i.e. jQuery), and tamper with the information they return. This is what I call DOM rootkit (or JavaScript rootkit). For instance, evading the naïve script scan method is as easy as hooking getElementsByTagName DOM function and removing the malicious script from the list before it gets returned. Likewise, this rootkit technique can be applied to any functions used by the detection script. Therefore, it is critical that the detection script runs with a correct view of the operating environment (i.e., without any malicious code interfering with its control flow).

The need for a paradigm shift

Any complex code included in the detection script is fully exposed to the attacker. This makes it subject to reverse-engineering and subsequent evasion techiniques on the part of the cybercriminals. Defenders can defeat this by randomization of the detection script with algorithmically heterogeneous implementations with the goal of increasing the attack cost per randomization. In effect, the detection script is obfuscated from the attacker, and attempts to remove this obfuscation would impose a significant computational burden.

The blind application of traditional metamorphism and polymorphism won’t help increase the difficulty of the attack. Carefully designed strategic defense mechanisms are necessary for each attack vector as described in the paper. In addition, it is critical to acquire a correct system view and ensure that existing defense mechanisms aren’t being subverted. Rootkit detection and code integrity checks can help here.

Conclusion

In the BlackHat paper, the author outlined the different stealth and evasion techniques that cybercriminals use and the appropriate defensive measures that the banking industry should implement. The author also introduced the creation of MIPS, a hypothetical online banking security framework that works in the web application level instead of the operating system level. This means that instead of trying to discover webinjects in the browser’s virtual memory space, MIPS attempts to find out the JavaScript and associated artefacts injected by the malware. The full presentation is available for download [PDF] at the BlackHat 2015 briefings page.

Banks need to go through a rigid set of tests before any change is released, which can take up more time than a banking malware’s webinject release cycle. In order to win the online banking war, it is crucial to set up strategic defense rather than short term ad-hoc patching since the overall update structure is not in favor of the defenders in the online banking war.

When it comes to addressing online banking malware, it is not enough to be reactive to incidents as they occur. Strategic planning and the use of multiple layers of defense can go a long way.