A new Trojan mainly composed of Node.js and native C++ code currently targets a few French online banking website. This Trojan, embedded in a bootkit from the Cidox/Rovnix family, fully qualifies as a banking malware; and more so by inheriting its search and code injects mechanisms from the infamous Zeus Trojan.
Its main characteristics are:
- infects the VBR (Volume Boot Record) of the bootable NFTS partition
- Its Node.JS and C++ payload as well as its associated configuration file, respectively 5.4Mo and 28Ko in size, are encrypted and stored within registry keys.
- injects malicious code within Internet browsers as well as services.exe, csrss.exe, explorer.exe
- Deploys furtive mechanism by hiding injections in a DLL and its VBS compromise
- Wire its communications via WSS (WebSocket)
All French banks targeted by this attack, as noticed by CERT-LEXSI, have been alerted.
As always the dropper initiates the compromise; with the particularity this time, to wipe itself from the victim’s system once the job done.
It initially creates the driver file “ScsiPassThrough.sys “ within C:WindowsSystem32drivers and makes it a starting service at boot time. This file takes no part in the latter stages of the compromise therefore is probably just a remainder from a late version.
The dropper is also in charge of infecting the VBR (Volume Boot Record) with a polymorphic code of the bootkit as demonstrated in the following screenshot of 2 different compromised VBR.
Anti-forensic wipe out
As no file is written on the hard drive, its forensic analysis becomes problematic. Moreover, as discovered during the analysis, this dropper wipes itself clean from the system using an interesting anti-forensic technic.
When the function MoveFileExW() is called using NewName=NULL and Flags=DELAY_UNTIL_REBOOT as parameters, the file is erased as soon as the boot process is initiated.
Once the file is erased (or more precisely renamed with a null value) it can no longer be noticed within the output of forensic tools such as fls from The Sleuth Kit
As we were able to notice, only the Prefetch files remain as an indication of the dropper presence once it has completed its tasks. All versions of the dropper identified have been found to be created within the %TEMP% folder of the infected users with a numerical name output of the kernel32.dll.GetTickCount() function.
At this stage of the compromise, no payload is created. The bootkit will take over and download it during the following step.
The bootkit component ensures the payload is executed upon booting as well as keeps the whole compromise furtive.
When the system boots, a driver is loaded in memory and its code executed. When attached to a debugger, the following strings are revealed:
- Krebs, ya tvoi dom truba shatal. (a Russian insult directed at Brian Krebs)
- Just pick a dead end and chill out till you die. (The Simpsons, season 22, episode 6)
This part of the code as well as the Simpson quote point towards the Cidox/Rovnix/Mayachok bootkit family and also matches the analysis performed by Dr.Web.
Several hooks, including the one on the IRP (Interrupt Request Packet) IRP_MJ_INTERNAL_DEVICE_CONTROL on the Driveratapi driver, are done to ensure the VBR compromise stays quiet.
The following external peripheral devices are created for the atapi.sys driver:
This mechanism allows impairing the output of the disk’s driver by replacing it with null bytes. All sectors of the VBR (excluding the first) appear empty.
As there is no any malicious code execution at boot, the malware uses existing processes to execute its malicious paylods. Those will be injected within:
- navigateurs web
Usually the Client/Server Runtime SubSystem process (CSRSS) only purpose is to pass on to application executed in user land a subsystem Win32. Its size on disk barely exceeds a few kilobytes (6Lb for Windows XP Pro SP3)
A memory page with read, write, execute rights containing calls to the following functions is created within that process (the hash values prevent the imported string function names from appearing in plaintext):
In the next step, the ntdll.dll.NtOpenThread() function is called so that a handle is gathered on the already injected services.exe process. A later call to the function csrsrv.dll.CsrCreateRemoteThread() will duplicate this handle before the thread is terminated using the ntdll.NtClose() function. The Windows process will finally resume normally after the ntdll.NtTerminateThread() call.
Following the first ever boot past the compromise, the thread injected within services.exe will download the malicious payload from the C&C server and store it, cyphered, within the registry hives. The payload is never written on the disk therefore complicating the forensic analysis.
The following registry key HKLMSOFTWAREcxsw contains two encrypted entries:
- binaryImage32 or binaryImage64 : PE formatted payload injected into different processes
- inject.js : Configuration file
Two memory pages are added to services.exe. One executable, containing the payload and the other one containing the deciphered configuration file. service.exe then starts acting as a master process and fulfils the following actions:
- Communication with the C&C server
- Code injections into the explorer.exe process and the web browser
- Communication with the slave processes
- Malicious processes activity logging
While the C&C domain names are hardcoded in the driver, the network communications are first encrypted before being sent over the wire.
Once the communications are established, they can transit through HTTP and HTTPS
The following C&Cs have been discovered as part of the analysis:
- pplauseadsho.com – 18.104.22.168/22.214.171.124 (campaign #1)
- paradiseadsfilt.com – 126.96.36.199 (campaign #1)
- adsadventpromo.com – 188.8.131.52/184.108.40.206 (campaign #1)
- cdnspeedconnect.net – 220.127.116.11 (campaign #2)
- newageconnections.biz – no associated IP (campaign #2)
Once the payload is extracted from the registry, decrypted, and injected into the targeted processes, it acts differently depending on where it was injected. If injected into service.exe it will act as a Master or will otherwise as a Slave.
Two different injections were identified when analysing the different variants:
- A thread: executed from a memory page with read, write, execute rights;
- A DLL: When opengl32.dll is loaded, a fake DLL is inserted in the list of LDR_DATA_TABLE_ENTRY (referencing all loaded DLLs) where points InLoadOrderModuleList from the PEB. That fake DLL, named randomly, never appears written on the disk.
Note : Only versions v.74 et v.75 of the payload were analysed.
Master process (services.exe)
In addition to the injection provided by the bootkit, the payload also injects itself into the service.exe process. This injection gives it the means to communicate with the different slave processes as well as logging its activity into a file.
The communication between MASTER and SLAVES processes is based on the WSS (WebSocket) protocol. Depending on the version, the pipe used to tunnel the communication is named:
When the debug option is set in the payload analysed, the information is written into a file in the %TEMP% folder of the current user. All created files are named gtkdbg_%d.txt:
No mechanisms were implemented in the analysed versions to clear the logs once written on the disk.
The slave processes (explorer.exe and the web browsers)
When the payload is injected into a web browser process, it will be used as a proxy server tunnelling its own HTTP traffic on a TCP port.
Other functionalities are implemented such as the ability to download and execute new files.
The HTTPS flow hijack
By hooking the library in charge of validating the certificates, the payload is able to hijack the HTTPS communications and replace a legitimate certificate with a faked one.
For applications, such as Internet Explorer or Google Chrome, based on the SSL library provided by Microsoft Windows, the following functions are hooked:
The fake certificate provided for www.microsoft.com, 06 bd 49 aa 1d b8 6a 6c 53 9b f2 6a 5a 5b 3f 05 cf 57 38 7a, stays the same for all HTTPS websites visited.
For example when browsing to www.lexsi-leblog.fr using Internet Explorer, one can clearly notice the certificate exchange.
In addition to the ability to read all HTTPS traffic, some arbitrary code can also be injected during the attack.
Even though the payload was written in Node.JS, the heritance from Zeus is clearly noticeable. The following capture shows the functions used to search and insert the injections recoded from the C language (notice also the insult to the ZEUS creator)
zeusSearchContentIndex() and zeusExecuteInjection() allow respectively to search for the location in a HTML page where to inject the malicious code and to inject said code.
Before anything, the payload checks if the browser used includes any of the following:
- Internet Explorer engine: iexplore.exe, maxthon.exe, avant.exe
- Webkit/Chromium engine: opera.exe, chrome.exe, iron.exe, browser.exe
- Gecko engine: firefox.exe.
One of the easiest indicators of compromise to be noticed is the banner being displayed in most of the cases we worked on. “Travaux de maintenance. Veuillez reesayer plus tard.” (Maintenance in progress. Try again later)
This malware also has the capabilities to drop further executable files after the compromise. In some of the cases we worked on, a packaged version of VideoLan VLC was dropped and executed to record 5 minutes videos of the action performed by the user (another way to obtain credentials when a virtual keyboard is used on online banking sites)
The video recorded are dropped in the %TEMP% folder using the name AXZ1_%JJMMAA_%HHMM_%SS.tmp.
Other malicious actions such as form grabbing, screenshots or keylogging are also implemented in the payload.
This analysis allowed the CERT-LEXSI to identify the different modules put in motion in this malware. Based on this new set of information, it is now possible to implement new indicators of compromise as well as deploying counter-measures directly on banking portals to avoid further frauds to be successful.