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
However, this purely web-based DOM scan method can be subverted in many ways:
- Exploiting invalid memory reference patterns
- 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
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.
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.