The Ramnit Web Browser Specialist: Hooker Number II

trojan-horse The Ramnit ecosystem is certainly something not so easy to explain. It is one of the oldest trojan bankers on the cyber-crime landscape. Indeed, we can trace back its activity to 2010, when it started to spread as a simple worm to subsequently acquire “financial” and “banking” features when its developers included into it parts of leaked Zeus source code, giving it the possibility to operate as a fully featured Banking Trojan.

 

In the italian panorama, among the banks where customers are targeted by Ramnit we can found Banca Intesa Sanpaolo, BNP Paribas, Inbank, Monte Dei Paschi di Siena, and UniCredit. 

Regarding the spreading mechanisms, it’s delivered by malspam campaigns often in conjunction with a powershell downloader known as Sload. This article does not include the analysis of the full Ramnit infection chain, however if you want to know more about sLoad, I can suggest one of the first research articles about it from Certego researchers, dated back


Over time many amazing research articles have been made that are very useful to understand the behavior of this malware. (for example, https://www.vkremez.com/2018/08/lets-learn-in-depth-into-latest-ramnit.html).

However, my 2 cents for the “Ramnit case” will be focused on some features of the modules that are responsible for the process injection and for the API hooks once loaded into browser processes.

It’s internally referenced as “hooker2.dll“.

// Overview

Hooker #2, as Ramnit plugin, relies on the Ramnit malicious infrastructure to be downloaded and stored on disk. According with persistence mechanisms already dcoumented by other research articles, at system reboot the plugin is started with all other installed plugins.

The main module itself seems to be composed of different binaries. The following is a non-exhaustive list that describes some of them:

#1 – The main binary.

#2 – Implanter binary.

#3 – 32 and 64 bit binaries aimed at hijacking HTTP[S] communications.

// Hooker #2 : Main module

According to what observed, the primary functions of this module are the following:

#1  – Communicate to Command & Control (CnC) servers to send exfiltrated information.

#2 – Provide for the injection of 32 or 64 bit binaries in order to hijack HTTP[S] communications.

#3 – Modify the security settings of targeted browsers.

The main module also has the task of interfacing with the communication hijackers code blocks designed to collect data obtained from victim browsers.

// Hooker #2 : Communication Hijackers

They are designed to achive the following tasks:

#1 – Perform API hooks into HTTP[S] send/reicv functions of the targeted browser.

#2 – Inject arbitrary data into connection streams.

#3 – Disabling security software eventually present and perform Ring-3 “rootkit-like” hooks in order to hide itself.

The exaustive list of browser that this module is designed to compromise is the following:

#1 – Chrome

#2 – Firefox

#3 – Internet Explorer

#4 – Microsoft Edge

The target browsers are found comparing case-insensitive internal strings with the running process names. The following is a simplified schema aimed at generally explaining the interaction process having as example firefox.exe:

image_hooker

On the basis of browser detected, several function hooks are implemented. The following is an exaustive list of hooked function for each of the targeted web browsers:

#1 – Microsoft Browsers (wininet.dll)

• HttpSendRequestExA

• InternetReadFile

• InternetOpenUrlA

• HttpSendRequestExW

• InternetWriteFile

• HttpSendRequestA

• HttpSendRequestW

• InternetOpenUrlW

• HttpEndRequestW

• HttpEndRequestA

• HttpOpenRequestA

• HttpOpenRequestW

#2 – Mozilla Firefox (nss3.dll)

• PR_Write

• PR_Read

• PR_OpenTCPSocket

• PR_Close

#3 – Chrome (chrome.dll, non-exported API, hooks by finding module image base and searching for code section)

• SSL_read

• SSL_write

• SSL_new

• SSL_free

Interesting enough to highlight is the mechanism that allows inter-processes communications for the module. Normally, in most malware samples I observe, this task is archived through the use of the function CreateNamedPipe(). The main Hooker #2 module uses instead RpcServerRegisterIfEx(),  exported by the library rpcrt4.dll, with RpcServerUseProtseqEpA() having “ncacn_np” as parameter (this keyword identifies named pipes as the protocol family) to communicate with com hijacker modules. The following images show the related code segments:

image6RpcServerUseProtseqEpA() with proto seq “ncacn_np”
image_2Subsequent RpcServerRegisterIfEx() call

// LUA Webinject

The module uses LUA scripting language in order to better handle web injects. As security researcher Vitali Kremez has already stated in his blog post reported above, this is an “interesting” feature. In my opinion, the most important factor when looking at the relationship between the primary module and the LUA script is their interaction; looking at them individually, in fact, it is possible to realize that they could not work alone, but that they are part of a suite designed to operate with a certain degree of mutual trust. This is because:

#1 –  The main module calls and executes functions coming from the LUA script.

#2 – The main module presents global variables accessed from the LUA script.

The following image shows several of the implemented functions in the main plugin module:

image3

// Anti-Detection

If we perform a strings extraction of the main module, it’s possible immediatly to note the reference to two specific libraries, named RapportGP.dll and RapportGP_x64.dll. They are part of a suite called “Trusteer Rapport” marketed by IBM. A description is available here:

https://www.ibm.com/us-en/marketplace/phishing-and-malware-protection

The main module looks for the presence of this software when injected into the targeted process and all times a new library is loaded into it through the hook of LdrLoadDll(). If found, it parse the corresponding RapportGP.dll PE header and it relies mainly on the functions CreateToolhelp32Snapshot() and SuspendThread() in order to suspend the thread aimed at providing the security scanning feature.

aswhook.dll (associated with Avast Security Suite) is targeted by malware self-protecting features as well.

Another interesting feature is the one that comes from the hooking of the NtQueryVirtualMemory () function performed by communication hijacker modules.

It was designed to verify accesses to memory areas included in the memory space occupied by the malware itself at that time. It denies access to its own memory areas returing 1 (error occured while retrieving information).

Another self-protecting / detection evasion feature of the malware is the ability to inject its 64-bit modules into 64-bit processes from its 32-bit main module (I hope the concept is clear enough :>). This technique, known as 0x33 Segment Selector or Heaven’s Gate, is usually put in place in order to execute 64-bit code in an 32-bit process. Generically speaking, it allows to switch between 32 and 64 bit code within the same process and permits to evade most security solutions and malware sandboxes.

If interested to know more about, i can suggest to read the article by @MalwareTechBlog available here:

https://www.malwaretech.com/2014/02/the-0x33-segment-selector-heavens-gate.html

// Techniques, Tactics, Procedures

[ + ] Malware lowers the security settings of targeted browsers.

[ + ] Malware uses 0x33 Segment Selector to evade detection.

[ + ] Malware hooks NtQueryVirtualMemory() as self-protecting feature.

[ + ] Malware looks for IBM Trusteer Rapport presence in the targeted processes.

[ + ] Malware looks for Avast Security Suite presence in the targeted processes.

// Indicators of Compromise

SHA256 [Artifact]: 2ffff7a3930812193f2b73bcf387ab293229aa2e6439ce2987114fb6a002abaa

File Name [Artifact]: [%appdata%]\Local\[a-y]{8}\[a-y]{8}.exe

File Name [Artifact]: [%appdata%]\Local\[a-y]{8}\[a-y]{8}.log

File Name [Artifact]: [%userprofile%]\[a-y]{8}\[a-y]{8}.log

// YARA Detection Rule

rule Ramnit_Hooker_v13 : RAMNIT Browser Hooker Plugin {
meta:
description = "Detects Ramnit Browser Hooker plugin"
author = "Emanuele De Lucia"
tlp = "white"
strings:
/* INTER-PROCESS COMS */
$fcode1 = {68 91 7B 0D 10 57 6A 10 56 56 68 ?? ?? ?? ?? FF 15 3C 13 0E 10 85 C0}
$fcode2 = {56 57 33 F6 BF D2 04 00 00 56 51 57 68 1C 66 0F 10 FF 15 34 13 0E 10}
/* STRINGS */
$string1 = "SELECT ProcessId,CommandLine,ExecutablePath FROM Win32_Process" fullword wide
$string2 = "RapportGP.dll" fullword wide
$string3 = "RapportGP_x64.dll" fullword wide
$string4 = "SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\App Paths\\firefox.exe" fullword ascii
$string5 = "SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\App Paths\\chrome.exe" fullword ascii
$string6 = "MicrosoftEdge.exe" fullword ascii
$string7 = "hooker2.dll" fullword ascii
$string8 = "aswhook.dll" fullword wide
$string9 = "firefox.exe" fullword ascii
condition:
(uint16(0) == 0x5a4d and filesize < 8000KB and ( 6 of ($string*) and 2 of ($fcode*)))
}

2 Comments

  1. Alessandro M.

    Ciao Emanuele, da professionista impegnato nella sicurezza ti leggo spesso ma stavolta ho deciso di scriverti dopo l’ennesimo contenuto di altissima qualita’ da te prodotto. Devo dire che anche stavolta sono rimasto impressionato dalla tua analisi e dalle tue considerazioni se penso ai livelli di abilita’ richiesti per produrle. Un gran bel lavoro. Come sempre. Alessandro

Leave a Reply

Your email address will not be published. Required fields are marked *