Like many other financial Trojans, the notorious Dridex malware keeps evolving and strengthening its presence in the financial threat landscape. The Dridex campaign attributed to Botnet 220 is very focused on UK financials and tries to accomplish its scam by utilizing different mechanics.
Webinjects
For certain targeted banks’ pages, Botnet 220 uses classic webinjects in which it injects a malicious script from an attacker’s domain directly into the original bank page.
The injected code has thousands of lines of code and is mostly focused on stealing login credentials, including one-time passwords, grabbing personal details and account balances. It also contains automatic transaction infrastructure which was not invoked in the malicious scripts that we have analyzed, but could be easily leveraged once the fraudsters decide to act.
A certain bank was targeted by a dedicated malicious script containing slightly different automatic transactions functionality. The injected script ships with two “fake pages” that are shown to the victim instead of the original page. The first one asks for the answer to the security question and asks to generate a security code using a Secure Key device with an excuse that the victim has entered incorrect information in one or more fields.
The second page is presented under the pretense that the user has exceeded the maximum number of login attempts. It show the last 4 digits of the target mule account number as a “temporary password” and ask the victim to type it in his Secure Key device (appearing to the user to be the bank’s process for “confirming” a transaction). Once the user submits the Secure Key device-generated secure code, the transaction is automatically submitted.
For certain bank pages, the Trojan injects an interesting script called “news-podmena” (“podmena” means “substitution” in Russian), and it actually replace the bank’s original security best practices guidelines for its customers with its own fake ones. For a certain bank, it was intended to trick clients with smart card authentication.
However, for most of the banks, it shows a generic security warning recommending not to ignore any pop-up windows and to follow the process step by step. This increases the fraudster’s chances of running their code and installing more components while bypassing all the security warnings.
Another interesting injection type is intended to be injected in any page delivered over HTTPs to grab credit card information. This script is not intended to be injected in the targeted banks’ pages. Once injected in an arbitrary page, the first code snippet of the malicious script tries to match the URL against a list of websites (mostly search engines, banks, and webmails) and if a match is found, the script deletes itself. We assume this is done in order to avoid overloading the command and control server (C&C) with unwanted traffic.
Fake Pages
An attack vector that strongly identified the Dyre malware is massively used now by Dridex authors. To accomplish that, the latest uses the same old “redirection” technique. The malware part that resides inside the browser implementation (“Man-in-the-Browser”) is able to intercept the browser’s requests sent to any domain and redirect them to the attacker’s controlled server. The redirection details of which requests to redirect and their exact destination are controlled using the “redirect” directive in the malware configuration.
By using this redirection technique, attackers could fetch an external malicious script in their code by using the bank’s domain name in the script’s source URL. For example, the malware can inject a script with a source of “www.mybank.com/evil_script.js”. This request is intercepted by the Trojan in the browser and the bank’s domain name is replaced with the fraudster’s domain, like “www.evil.com/evil_script.js”. This way the fraudsters could avoid exposing their domain name in the code injected to the bank’s page and make the request to the external malicious script look legitimate. By observing the attributes of the “redirect” directive in the configuration, it seems also to be related to the VNC and SOCKS functionality of the malware.
This redirection functionality was leveraged to also redirect requests for login pages.
In the above example, we can see that by using the “redirect” directive in the malware configuration, requests that are made to a certain bank login page are redirected to attacker’s server and retrieve a fake page of the bank that was manually crafted by the attackers.
We detected the experimental phase of this fake page technique on several UK banks, starting in April 2015.
Who is Next?
In analyzing the Trojan, it is noticeable that it is configured to take screenshots of many French banks. We can only assume that those are preparations for their next campaign. A single Spanish and single Australian bank are targeted as well.
