Malware that steals banking credentials is still one of today’s most lucrative cybercrime schemes. It’s not unusual for a banking Trojan to evolve over the years, and Ramnit is a perfect example. It was active for several years until it was disrupted in early 2015 by Europol working with several tech companies. It resurfaced in late 2015, and again in mid-2016.

Recently, while investigating Ramnit’s webinjects mechanism, I found that the malware deletes the configuration within a few minutes of downloading it from the command and control (C&C) server. The malicious JavaScript ceases to be injected into the targeted web pages and the configuration is gone from memory.

I was surprised by this behavior because the challenge for investigating malware usually lies in fetching the configuration from the C&C server. Typically, after the configuration is fetched, it is stored on the infected machine until an update is due. However, based on user data sent from the Trojan, the C&C server might decide not to fetch the configuration for a variety of reasons (for example, because it’s running on a virtual machine). In any case, it is unusual for the configuration to be fetched and then deleted.

Could this behavior of deleting the configuration mean that Ramnit is now adding more complexity to make it more difficult to detect during execution? Or, could this indicate a bug in the malware functionality?

Whatever the reason might be, I didn’t want to theorize before having complete data. I had to find a way to preserve the configuration data to continue my web inject research. Before I could do that, I had to understand the exact flow of the configuration data within the Ramnit processes and modules and find out which process was responsible for deleting the configuration.

Ramnit’s Processes

During its execution, Ramnit creates and injects its modules into several processes:

• Svchost.exe #1
• Svchost.exe #2
• Explorer.exe
• Browser processes

Investigating the Browser Process

I started by checking how the configuration finds its way to the browser’s memory. The module that is responsible for Ramnit’s webinject capability is hooker.dll. This module is originally injected into explorer.exe, and when the browser is launched, the module is propagated into the browser’s memory by copying its own code from explorer.exe’s memory.

The propagation method that hooker.dll uses is as follows:

1. Generally, whenever a new process is created, the (Zw/Nt)ResumeThread API is eventually called to run a first thread.
2. The hooker.dll module within explorer.exe hooks the ZwResumeThread API and uses it to inject code into newly created processes.