Blog Post

On June 7th, two variants of the same Banking Trojan were uploaded to VirusBay, and so I decided to have a look at them to see what exactly the difference was. The trojan I am referring to is known as Karius, which was discovered by a researcher at CheckPoint Software, Israel Gubi (@israel_gubi), and you can find his post on Karius here. After a quick Google search I realized that this was in fact an extremely new strain of malware – so much so that it is still under development. For some weird and wonderful reason, Karius is already being distributed with the RIG Exploit Kit. Probably not the best idea if you want your “highly secretive, one of a kind, Fully Undetectable banking trojan” to remain that way. It turns out that the two variants that were uploaded to VirusBay are for different architectures, one is for x32 bit Windows systems and one is for x64 bit Windows systems. As per usual, you can skip to the end for a brief summary on how the program works.

As my Virtual Machine is a x64 bit machine, I decided to start with the 64 bit version (the PE32+), but as I have only really focused on 32 bit assembly rather than 64, I relied on x64dbg and other dynamic analysis methods. Upon calling strings on the file, you’ll notice this very interesting chunk of text near the bottom:

You can definitely tell from the hardcoded webinjects that it is most definitely a work in progress, because that shouldn’t be showing with a basic strings command. There is also a hardcoded C2 server in the binary, leading to some form of gateway at that address. You can also see the string someLettersHere1, which definitely seems like a placeholder for something.

Sadly the gateway seems to be down, as when I visited the site, it returned a 404 Not Found response – the author probably decided releasing an unfinished trojan was a bad idea in the first place and took it down.

I also found a few other interesting strings:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
AESKey
Explorer.exe
ReflectiveLoader
user_pref("network.http.spdy.enabled.v3-1", false);

The first string hints to a possible Base64 encoding mechanism, as it is the generic Base64 lookup table. The second string shows a possibility of AES encryption at some point – possibly to exfiltrate data or store data. Explorer.exe is there because why would a banking trojan need a handle to Explorer.exe, other then to inject a DLL and hook an API call? This leads to the next string, ReflectiveLoader. This could mean that the program is using Reflective DLL Injection in order to inject a DLL into Explorer.exe. Finally, user_pref(“network.http.spdy.enabled.v3-1”, false). I had never seen a string like this before, and upon googling it, it is in fact part of Firefox, and so the malware could be turning off safeguards/protection for Firefox, enabling web injections. Now that I had finished examining the embedded strings, it was time to analyse the executable.

In order to analyze the file, I opened it up using Professional PE file Explorer (PPEE), which is a fast and easy to use file analyzer that supports parsing of PE, DLL, SYS, SCR and many other file types. I navigated to the Registry section to see if any registry keys were hardcoded in plaintext, and sure enough I found two important keys:

They both revolve around Internet Explorer, but the second one is the most important key – in the Internet settings, there are 5 zones: Local, Intranet, Trusted Sites, Internet Zone, and the Restricted Sites zone. Zone 3 is the Internet zone, and according to a user on SuperUser, Setting a REG_DWORD value named 2500 to 3 will disable Protected Mode for that zone. This will allow a victim to visit a site that has JavaScript injected into it – this mechanism is similar to the user_pref strings for Firefox.

Looking at the Section headers, I noticed a .cfg section, which is quite unusual:

Once I had dumped the section to the disk and opened it up, it was clear that this is the location where the webinject JavaScript code is kept. This is also shown in IDA when you skip to the .cfg section.

I decided to run the file and see what would happen. As it seems the program searches for what seems to be amazon, rather than bank websites, I attempted to use internet explorer to visit Amazon.com – first without an internet connection and if that didn’t work then I would try when I was connected to the internet. I set ProcMon to filter options for Sample_x64.exe (the filename), so I could view any registry edits or file creations. I also ran Process Hacker at the same time, to see what processes were running.

Shortly after I executed the file, I noticed that it had a handle to a thread running in explorer.exe. Perhaps the program is injecting something into Explorer? Nothing seemed out of the ordinary when I viewed the running threads in explorer.exe, so I decided to focus on what the executable was doing. ProcMon picked up two important operations performed by the program – the first was a call to RegCreateKey, and the second was a call to CreateFile.

As you can see, the Zones\3\2500 registry key is being set, and when I checked the registry key, the value had been changed to 3, disabling Protected Mode for Internet Sites. I also had a look at the temp.bin file that is created, which is in fact the webinject:

After this file had been created, the program queried a few more registry keys, and then slowed down – the only operations that occurred were to do with stopping and starting threads. Looking at the running threads in Process Monitor, it showed only one running:

ntdll.dll!TpIsTimerSet+0x7c0

I waited a bit longer, to see if anything had changed, but there was nothing. I decided to open up Internet Explorer, to see if the program would react at all. However, simply searching “google” into the address bar and hitting enter caused Internet Explorer to constantly crash.

But there was no change in the running threads for the program – maybe this was just my version of Internet Explorer? I reverted the virtual machine to its clean state, and ran Internet Explorer. Nothing caused it to crash at all. So the unfinished malware was doing something to affect Internet Explorer. As the running threads did not change, it must be due to something injected into explorer.exe. I downloaded Firefox to see if the same problem would occur, and it sure did. I decided it was time to put the sample in a debugger, to see what exactly was happening.

I located the section where temp.bin is dropped to the disk. First, GetTempPathA is called and then temp.bin is moved from memory, into a register. lstrcat is then called, with the arguments being the path to the TEMP Directory, and the file name “temp.bin“.

After the full file path is formed, CreateFile is called, creating temp.bin in the TEMP directory. Shortly afterwards, WriteFile is called – this will fill in temp.bin with the webinject code.

At this point, I decided to see what the 32 bit sample had to offer, in hopes that it would be more developed than the 64 bit sample – whenever I got to a certain function it jumped to the NTDLL TpIsTimerSet, so it was time for a change. To begin with, I executed the file to see if I would have the same problem as before. The icon of this sample resembled the Java logo – in a real situation this could be imitating a Java installer. During the execution, I noticed the file “restart” 4 times – the first execution of the program began and created a child process of itself (executed the sample). The parent process was killed, and the child process copied the original file to the Music directory, and named it temp.exe. The child process then executes the copied file and exits. Finally, temp.exe creates a child process of the same file and then exits, leaving the final malicious process, temp.exe, running. Take note of the extremely high CPU usage shown in Process Hacker – this only occurs for the first 3 processes, and then the final process has a much lower CPU Usage.

After the second process has begun, the original executable is deleted off of your system, so the only file left is temp.bin. Whilst I was analyzing the execution flow, I also left Wireshark running in order to capture any packets sent to C2 servers. Sure enough, according to Process Hacker, there were two total connections made to the same site: customer.clientshostname.com. However upon following this URL, the site was completely down – yet Process Hacker said that the connection was established?

I checked Wireshark and discovered a different address – this time it was called http://proxyservice.site/ with the command point at /updates/gateway.php. I attempted to access this site and received a blank screen – so this site is still up. I checked the main URL to see if there was any panel, but there was just an image showing 404 (it is an image – the site still exists and can be found, so it was obviously put there to trick people). I checked the /updates folder and I was excited to find that I was finally analyzing a live sample – and managed to locate the user logon panel:

Sadly the username and password were not “root“, and so I decided to focus on analyzing the rest of the malware. I checked the rest of the Wireshark Captures, and the data that was sent from my system seemed to have been encrypted:

So it was about time to start debugging and analyzing it in depth, rather than viewing packet captures. I ran the file, which caused it to run three times before getting to the final process, which I attached x32dbg to. Whilst going through the malware, I noticed the program call DeleteFileA to a file in the Temp directory. The file that was deleted was completely empty – perhaps it will eventually be filled in a newer version?

This empty file was created using GetTempFileNameA, which creates a unique filename and creates that file, as long as it does not exist already. I checked the strings of the file, to see if anything stood out – and it did. I noticed a System.dll in a randomly named folder inside the TEMP directory.

Process Hacker listed the 8 total exports of the DLL:

Alloc
Call
Copy
Free
Get
Int64Op
Store
StrAlloc

This could possibly be extensions to current commands available in the program – but as it is still under development we can’t be too sure. I also managed to locate an embedded batch script, hidden in memory:

(del %0 should be under the goto) This file is basically responsible for removing the original file from the system. At this point I had hit a brick wall, so I decided to have a look at the article by CheckPoint, and I noticed mentions to 2 DLLs that were used for injecting into Internet Explorer – but I could not find them in the modules list anywhere. After some rummaging around, I managed to locate two very suspicious private Read Write Execute files, both around 80 KB. After viewing the source code, it was obvious that these two files were malicious:

You can see information about a pipe – this is how the injected DLL’s communicate with the main executable – as well as a chrome.dll. If the file was legitimate, why is it referencing Chrome’s DLL in an Internet Explorer process? I also located a few of the strings in this DLL in the main executable. I dumped both of the DLL’s and put them in PEStudio:

Definitely looks suspicious with the string “inject” being stored in the binary. At this point I was thinking “What if I say this is the injected DLL when it is merely an addition to Internet Explorer??“, but after scrolling down a bit, this popped up:

So the DLL refers to the term “inject“, contains strings such as “HookIE_HttpSendRequest” and “mod64.dll” – this is 100% the malicious DLL that we are looking for. So now that I am sure that DLL’s have infected my Internet Explorer process, let’s try using Amazon again. (Whilst it doesn’t show my cursor in the GIF, I attempted to click Sign In several times, and the page did nothing – only when I hit enter did it work – this could be evidence of a webinject, or it may be a side effect from the API hooking)

So, now I had 2 DLL’s and an Executable, I wanted to find the DLL that was injected into explorer.exe. Once again, looking under the RWX (Read, Write, Execute) section, I found another file, containing some more strings that linked to the malicious file:

Not only did I find one injected DLL – I found 2, again. I checked the files using CFF Explorer, and whilst they showed different file sizes, the PE size was the same for the first two DLL’s I found (Internet Explorer), and the second two DLL’s (Explorer), which could be an indication to a failsafe method?  I restarted the machine so that I could exfiltrate the DLL’s back to my Linux Machine, and as soon as I had logged in, I opened Process Hacker and what a surprise, the program had booted up again – so there is a persistence mechanism too. I checked the CurrentVersion\Run registry key, but nothing had been written to it. After waiting to see if anything would be added, I checked the Startup Folder, and there it was:

As you can see, it is linked to the executable stored in the Music folder. Once the malware is fully rooted to the system, it pretty much hooks all of your internet requests and sends them back to the C2 server, so now the analysis is pretty much over, the summary is up next. If I’ve got anything wrong, feel free to comment or contact me on Twitter (@0verfl0w_), and if you have any questions I will gladly answer them as best as I can. As always, you can find all of the files up on VirusBay.

Summary (of x32 bit – x64 bit fails to run properly):

• Program is executed
• The program then creates a child process of itself, and then exits
• The child process copies itself to the %USERPROFILE%/Music/ folder, under the name temp.exe
• The child process executes temp.exe, and then exits
• temp.exe creates a child process of itself, and then exits.
  • The program left running is temp.exe
• A total of three registry keys are modified:
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3\2500 – The value is set to 3
    • This disables Protected Mode for Internet Sites
  • HKCU \Software\Microsoft\Internet Explorer\Main\TabProcGrowth – The value is set to 0
  • HKCU \Software\Microsoft\Internet Explorer\Main\NoProtectedModeBanner – The value is set to 1
• temp.exe creates Temp application.lnk in the Startup folder, enabling the program to remain persistent
  • This links to %USERPROFILE%/Music/temp.exe
• temp.exe creates a Batch script and writes it to disk, in order to delete the original executable
  • This also deletes the Batch script
• temp.bin is written to the %TEMP% directory – this contains webinjects that are received from the C2 Server
  • For the x64 version, the WebInject is hardcoded into the executable
• 1 or 2 DLL’s are injected into Explorer.exe, and hook CreateProcessInternalW, in order to detect whether firefox.exe, iexplore.exe, chrome.exe or microsoftedgecp.exe are executed.
• When either of the processes are executed above (here I am talking about iexplore.exe), the program injects 1 or 2 DLL’s into the process, and hook the important API calls, such as HttpSendRequest, in order to gather your plaintext credentials when logging into a site.
• This information is then passed back to the main program from the DLL’s, through a pipe that is created.
• The program then sends the data back to the C2 server, encrypting the data with RC4 encryption.
  • Also note, the program is able to detect the architecture of the specific application, and can inject either x64 or x32 bit DLL’s – this could be why we see 2 of each DLL in a file.
• The loop continues, until you restart and the program boots up again.

IOCs:

• C2 Server: hxxp://proxyservice.site/updates/gateway.php
• Hashes (MD5)
  • Main Program (x32): 728911a915d9ec3b6defa430d24bc0d5
  • Main Program (x64): 857430b8c9dc78ce4eabbe57cb3ae134
  • Program DLL (System.dll): 3f176d1ee13b0d7d6bd92e1c7a0b9bae
  • Explorer.exe (mod64.dll) DLL 1: 0bf9577803001f69f8a45853ae533c06
  • Explorer.exe (mod64.dll) DLL 2: ac026bf3ae60f3b78acfc2931acfca60
  • Web Browser (proxy64.dll) DLL 1: 1c57027cae485933848efa4f2c70f8da
  • Web Browser (proxy64.dll)  DLL 2: d1457f248a5d0b6eab47841178774221