Uncovering drIBAN fraud operations. Chapter 3: Exploring the drIBAN web inject kit

Here we go to the final chapter of this series. So far, we have discussed the malspam campaign that started spreading sLoad. Then, we discovered that sLoad is a dropper for Ramnit, now representing one of the most prominent threats to corporate banking and its customers. After that, we also described Ramnit’s capabilities, focusing mainly on its injection and persistence techniques. As a final step, we will discuss drIBAN, a sophisticated and modular web-inject kit that can hide resources, masquerade its presence, and perform large-scale ATS attacks.

In the following paragraph, we will describe drIBAN's main features, following its evolution over time until today.

If you missed the previous chapters of the “Uncovering drIBAN fraud operation” series:

• Chapter 1: Introduction and Malspam
• Chapter 2: From sLoad to Ramnit

drIBAN is a web-inject kit that emerged in 2019, mostly written in JavaScript and tailored for multiple targets.
Typically, web injects are part of a MITB attack (Man-in-the-Browser) to modify the content of a legitimate web page in real-time, performing API hooking. They are an extension of the “form-grabbing” technique because they can intercept and manage web responses to alter content before it is displayed in the browser (bypassing TLS protocol).

The core functionality of drIBAN is the ATS engine (Automatic Transfer System), which enables TAs to receive money transfers from the compromised victims’ machines without the need for credentials or 2FA (Two-Factor Authentication) codes, bypassing identity verification mechanisms such as MFA, SCA adopted by banks and financial institutions during login and payment’s authorization phases.  ATS is a class of web injects that alters on-the-fly legitimate banking transfers performed by the user, changing the beneficiary and transferring money to an illegitimate bank account controlled by TA or affiliates, which are then responsible for handling and laundering the stolen money.

This web-inject kit has been dubbed as drIBAN (‘dropper’ + ‘IBAN’), since in the very first variants analyzed by our team, the specific variable that contains one (or more) bank accounts controlled by the group was called drIBAN by its developers.

In this article, we will analyze the main features of drIBAN. More specifically, we will dive deep into its main characteristics related to Mule configuration, SWAP engine, and Visualization module.

‍

drIBAN has been developed and tailored for multiple targets, and typically it will be injected into legitimate web sessions after a successful login performed by the victim. Once injected, it runs silently until a specific element in the DOM, such as the “confirm/authorize” button, is clicked.
‍
drIBAN ATS engine  is composed by three main malicious modules, described as follows:

• Mule configuration: contains one or more money mules controlled by TAs (or affiliates). They are mainly discriminated against the amount of the legitimate transaction issued by the victims;
• Swap engine: retrieves legitimate banking transfers that are going to be completed,  altering them to redirect the payment to a money mule account controlled by TAs;
• Visualization module: activated only when a legitimate money transfer has been successfully redirected and replaces all the mule bank account references (e.g., in the transaction history, etc.) with the legitimate one entered by the victim; in this way, the victim remains unaware of what has happened.

Since the amount of a valid wire transfer cannot be predicted in advance, TAs often include multiple money mules (дропы, “drops” in Russian) and discriminate against them by the amount entered by the victim in the legitimate money transfers.

Once a victim enters a new money transfer, drIBAN intercepts the pressed “confirm/authorize” button and retrieves the data entered. It then checks it against its mule configuration and replaces it accordingly without modifying the original amount. This is a common countermeasure adopted by TAs for scaling operations without triggering unnecessary alerts due to unusual amounts entered.

If the money transfer has been successfully altered, drIBAN will try to hide all the mule details during the authorization process. In fact, under the PSD2 directive, banks operating under the European Economic Area (EEA) require a SCA (Strong Customer Authentication) when a new payment has been requested. This technique reduces its visibility to the victims by persuading them to enter a valid OTP code, typically sent via a custom mobile application or SMS message.

If the victim authorizes the transfer, drIBAN will activate its “Visualization module” and start replacing all references to the mule bank account with the legitimate one entered by the victim.

It has been possible to comprehend the methodologies used by drIBAN over the years by combining indicators collected from technical analysis and incident response activities performed on multiple corporate banks. The main findings are summarized below:

Initially, during Wave 1 (see Figure 4), TA doesn’t use any well-known technique to slow down static analysis at the web-inject level (such as string obfuscations), which is typically the lowest and deepest payload in an infection chain, as described in this series of articles.

First evasion techniques started appearing in June 2021 with “polymorphic techniques”, frequently changing identifiable characteristics, such as specific variable names.

Since ATS payloads are served dynamically from the C2 server through the Ramnit function AddDrop (more details on the previous chapter), TA creates a specific server-side routine responsible for altering with random strings certain variable names before sending the payloads to the victim.
From a high-level perspective, this is what happens:

• The victim visits the corporate banking portal and performs a login inserting credentials and a valid 2FA code;
• Once logged in, Ramnit will retrieve the appropriate ATS configuration performing an HTTP GET request to the designed C2 server. (Ramnit hooks certain web resources typically loaded after a successful login; this simple trick guarantees TAs to inject payloads only on authenticated sessions)
• Once received the payload, it will be injected into the legitimate web session via MitB techniques waiting for the victim to insert a valid money transfer before starting the ATS attack.

Another peculiarity of drIBAN campaigns is the introduction of the extortion paradigm. During the last year, we monitored multiple extortion messages inside web inject payloads, all written in poor English. This monetization attempt, similar to ransomware attacks, was a quick attempt to get in touch with members of targeted banking institutions for price negotiation to stop new attacks on their corporate clients.

This article concludes a very interesting journey throughout one of today’s most sophisticated banking trojan operations against Corporate banking environments.

This has been an occasion to show how modern TAs operate, reconstruct all the adopted infection chains, and create awareness around this threat. We shared our cutting-edge research and approach to modern malware analysis to provide valuable content to all our readers.

In fact, the prevalence of technologies that standardize European banking processes and procedures has created a significant opportunity for cybercriminals to adopt similar Tactics, Techniques, and Procedures (TTPs) across various European countries on a larger scale.

The increasing complexity of multidimensional attack scenarios requires a cyber-oriented approach in the anti-fraud space.

It is crucial for European entities, including the private sector, financial institutions, CERTs, law enforcement agencies, and others, to cooperate effectively against these evolving threats. Proactive prevention measures, such as sharing threat intelligence and implementing robust security measures, are vital to safeguarding corporate bank accounts and mitigating the impact of sophisticated APT campaigns.

By fostering cooperation and implementing a unified defense strategy, we can strengthen our resilience against these malicious activities and defend the integrity of the European banking sector.