Uncovering drIBAN fraud operations. Chapter 2: From sLoad to Ramnit

Here we are again with another chapter of our journey in the malware wonderland. In “Chapter 1: Introduction and Malspam”,  we have seen that TAs will spread malicious files through a quite classic method, malspam. These files, once downloaded, start monitoring the victim’s machine. Then, if the operator managing the attack chooses the machine as a good valid candidate for further steps (no VM processes, no monitoring tools, clean environment variables, etc.), it instructs the sLoad script to download the Ramnit banking trojan.

In this new chapter, we will explore deeper techniques that led us to discover the connections among sLoad, Ramnit, and drIBAN. More specifically, we will present some Ramnit characteristics and the techniques used to perform the MiTB attack and deliver its injection kit.

Ramnit emerged in 2010 as a worm, and evolved into a modern banking trojan by including part of the leaked modules of Zeus as part of its main source code. Over the years, it also survived a major disruption plan operated by Europol in 2015. It continues to evolve, improving its features, adopting new tactics and experimenting with multiple infection chains.

Its main features include:

• Advanced evasion mechanisms;
• A Domain Generation Algorithm (DGA) routine for producing new domains on the fly in case of server takedowns;
• Performing advanced MiTB attacks through web-injects on modern browsers with ATS techniques.

As described in the previous chapter, before proceeding to the final installation of Ramnit, TAs heavily inspect infected bots leveraging multiple sLoad (“computer name”, “network details”, “list of running processes”, “screenshots”, “DNS cache checks”, etc.). We refer to those processes as the “enrichment phase”, which could continue for days or weeks, resulting in a more solid and consistent botnet. The main goal behind drIBAN fraud operations is to access corporate banking accounts by identifying potential Windows workstations used to access these accounts.

Ramnit is installed using an interesting routine enabled by TA, which leverages a custom version of a Powersploit module for injecting the proper Ramnit core module in-memory via sLoad, as follow:

The unpacked code appears to be strongly based on PowerSploit, a PowerShell post-exploitation framework which TAs have customized for reflectively loads a Windows PE file (.dll/.exe) into the Powershell process, or reflectively injects a .dll into a remote process.

TAs create two-byte arrays containing the two versions of Ramnit .dll (respectively 32bit and 64bit versions) and hardcode those byte arrays into the script. Once executed, it checks the proper version against OS, injecting the proper payload, as follows (the code snipped has been then reconstructed to make it more readable):

According to the information retrieved, the Ramnit.dll module is responsible for multiple core malicious activities that are related to the network and communication of the banking Trojan. Once loaded, it starts the WmiPrvSE.exe that performs a reflective DLL injection, spawning a new process from the following list:  

• ImaginDevices.exe
• Wab.exe
• Wabimg.exe

From that point, it starts monitoring users actions to hook target processes that are going to be used to perform the Man-In-The-Browser technique. Tracks of this information could also be retrieved in memory within one of the target processes mentioned above.

Since most of the Internet traffic is routed through HTTPS, getting access to the victim’s web traffic is typically reached by banking trojans by injecting themself (or a specific module) inside the browser’s process, where specific API hooks can be overwritten by including malicious JavaScript code. As modern browsers have built-in settings that can mess with those techniques, malware developers manage to get in by simply disabling those settings before starting to inject code.

In the previous Figure,  after launching the browser Chrome on an infected machine, we observed that the underlying Chrome process has been spawned with a couple of arguments:

• disable-http2: disable HTTP/2. This network protocol performs compression of HTTP-transmitted data.  Note that a process that turns this setting off is a good indicator for defenders and can also be leveraged during dynamic malware analysis as confirmation to understand that the injection into the browser was successful.    
• disable-quic: disable QUIC, a transport protocol designed to accelerate HTTP traffic using UDP connections which typically works hand-in-hand with HTTP/2's connections.
• disk-cache-size=1: it will disable caching browser data, limiting the disk cache size to a very small number (1 byte).

Moreover, at this stage of infection, it is also possible to dynamically extract interesting indicators from memory, for example, a list of Ramnit C2 controllers generated from their DGA algorithm, as shown in the following figure:

The Ramnit persistence mechanism is based on a classic technique that is related to the autorun program that starts the infection chain from scratch. Once the malware is installed on the victim's machine, it creates three files that will be executed each time the victim’s machine is rebooted.

The first file contains a few lines of Powershell that are in charge of executing wMBgJoL.log.

The resembled command is going to follow this syntax:

powershell.exe -ExecutionPolicy bypass wMBgJoL.log.

It’s worth mentioning that the execution policy isn't a security system that restricts user actions. In this case, bypass is designed for configurations in which a PowerShell script is built into a larger application or for configurations in which PowerShell is the foundation for a program with its security model (that is the case where our malware is going to configure itself.).

The wMBgJoL.log file has been then reconstructed to make it more readable.

This file will take the Security System context to execute the DataProtectionScope in charge of decrypting the information within the variable path representing the KTYMrFaGh.log file. To avoid configuration issues within the decryption phase, the scope is set to LocalMachine (the protected data is associated with the machine context. Any process running on the computer can unprotect data).

That said, once the process is completed, the variable $v1 will be executed (the value of $v1 is nothing but the same content of the file that started the Ramnit infection.)

It’s worth noting that this mechanism, especially the encryption of the actual code related to Ramnit, it's a strategy that pays off, since the code is well protected and unnoticed by most of the anti-malware solutions. In fact, at the time of writing, Ramnit’s installer is barely detected.

‍

Web injects were introduced on Ramnit around 2016, following the standard Zeus format. During 2018, a significant change in its web inject kit was described by Vitali Kremez, since TAs were moving from the initial Zeus format to a fairly-new Lua-coded web inject configuration with different setups.

Lua is considered one of the fastest programming languages among interpreted scripting languages: it is robust, lightweight, rarely used as a standalone programming language, and highly portable - as its interpreter is written in ANSI C.

Apparently, today TAs still use a Lua-coded web inject configuration, which  integrates multiple variants of the drIBAN web inject kittailored for each of the targeted websites. The Lua-coded web inject configuration uses a hybrid approach:

• Local payloads: are specific web injects that interact with static resources of targeted websites, such as .css, typically for masking their malicious activities during a fraud attempt. Those web injects are entirely stored in the Lua configuration.

• Remote payloads: these are specific web injects served in real-time through a dedicated C2 infrastructure, typically for serving the ATS modules and money mules details. Since the money mule network  is one of the most expensive assets for TA, their information is stored server-side and served only on targeted machines during a fraud attempt.

While moving to a brand-new Lua-coded kit, TAs maintain some of the Zeus keywords on its logic. An example is the web injects “hooking” mechanism, which identifies the specific portion of the webpage where malicious contents will be added, as Zeus did:

• data_before: identify the portion of webpage code before the injection
• data_inject: malicious code to be injected into the webpage
• data_after: identify the portion of webpage code after the injection

For each of the targeted corporate banking web applications, multiple features have been defined by TA. A subset of those features is described in the following table:

Dear reader, we have come to the end of this new LABS bulletin. Through this article we shared an overview of Ramnit and its capabilities, trying also to embrace demanding readers with technical details about injection and persistence methods. Speaking about injection, we have also introduced something related to the Ramnit web injection kit, giving details about the structure of the code and its meta-language.

However, in order to not overwhelm readers with too much information, we have preferred to dedicate a whole article to the web injection, using this report and  the previous one, to provide all the information required to understand the last piece of the puzzle: drIBAN. The web injection, that was used to steal more than 10Mln from corporate banking institutions.

Stay tuned, the best is yet to come.

‍

‍

Appendix 1: IOCs