Inside the Kronos malware – part 1

Recently, a researcher nicknamed MalwareTech famous from stopping the WannaCry ransomware, got arrested for his alleged contribution into creating the Kronos banking malware. We are still not having a clear picture whether the the allegations are true or not – but let’s have a look at Kronos itself.
Background
This malware has been first advertised on the black market since around July 2014, by an individual nicknamed VinnyK, writing in Russian:

Source: https://twitter.com/x0rz/status/893191612662153216
The full text of the advertisement, translated to English, has been included in the IBM’s Security Intelligence article.
We found Kronos being spread by various exploit kits, i.e. Sundown (more information here). The malware is being distributed up to now – some of the recent samples has been captured about a month ago, dropped from Rig EK.
Nowadays, Kronos is often used for the purpose of downloading other malware. One of the campaigns using Kronos as a downloader was described by Proofpoint.
Analyzed samples
Samples from 2014:
01901882c4c01625fd2eeecdd7e6745a  – first observed sample of Kronos (thanks to Kevin Beaumont)
f085395253a40ce8ca077228c2322010 – sample from the Lexsi article
a81ba5f3c22e80c25763fe428c52c758 – Kronos (final payload)
6c64c708ebe14c9675813bf38bc071cf – injlib-client.dll (module of Kronos)

Sample #1 (from 2016)
2452089b4a9d889f94843430a35fa34f – packed
9818958e65a0a71e29a2f5e7ffa650ca – Kronos (final payload) NtQuerySystemInformation

The numbers of syscalls are stored in variables, xored with a constant. Fragment of the code responsible for extracting raw syscalls from the DLL:

In order to use them further, for every used syscall Kronos implements it’s own wrapper function with appropriate number of parameters. You can see an example below:

The EAX registry contains the number of the syscall. In the given example, it represents the following function:
00000105 -> NtQuerySystemInformation

Kronos uses raw syscalls to call the functions that are related to injections to other processes, because they usually trigger alerts. Functions that are called by this way are listed below:
NtAllocateVirtualMemory
NtCreateFile
NtCreateSection
NtGetContextThread
NtOpenProcess
NtProtectVirtualMemory
NtQueryInformationProcess
NtQuerySystemInformation
NtResumeThread
NtSetContextThread
NtSetValueKey

It matches the black market advertisement, stating: “The Trojan uses an undetected injection method” (source).
Rootkit and the hooking engine
One of the features that malware provides is a userland rootkit. Kronos hooks API of the processes, so that they will not be able to notice its presence. The hooking is done by a specially crafted block of the shellcode, that is implanted in each accessible running process.
First, Kronos prepares the block of shellcode to be implanted. It fills all the neccessery data: addresses of functions that are going to be used, and the data specific to the malware installation, that are intended to be hidden.
Then, it searches through the running processes and tries to make injection wherever it is possible. Interestingly, explorer.exe and chrome.exe are ommitted:

The shellcode is deployed in a new thread within the infected process:

Below you can see the shellocode inside the memory of the infected process:

When it runs, it hooks the following functions in the address space of the infected process:
ZwCreateFile
NtOpenFile
ZwQueryDirectoryFile
NtEnumerateValueKey
RtlGetNativeSystemInformation
NtSetValueKey
ZwDeleteValueKey
ZwQueryValueKey
NtOpenProcess

The interesting thing about this part of Kronos is its similarity with a hooking engine described by MalwareTech on his blog in January 2015. Later, he complained in his tweet, that cybercriminals stolen and adopted his code. Looking at the hooking engine of Kronos we can see a big overlap, that made us suspect that this part of Kronos could be indeed based on his ideas. However, it turned out that this technique was described much earlier (i.e. here, //thanks to  @xorsthings for the link ), and both authors learned it from other sources rather than inventing it.
Let’s have a look at the technique itself. During hooking, one may experience concurrency issues. If a half-overwritten function will start to be used by another thread, the application will crash. To avoid this, it is best to install a hook by a single assembly instruction. MalwareTech described a idea of utilizing for this purpose an instruction lock cmpxch8b. The same trick and similar implementation can be found in Kronos.
The hooking function used by Kronos takes two parameters – the address of function to be hooked, and the address of function used as a proxy. This is the fragment of the implanted shellcode where the hooking function is being called:

First, the hooking function searches the suitable place in the code of the attacked function, where the hook can be installed:

The above code is an equivalent of the following:
https://github.com/MalwareTech/BasicHook/blob/master/BasicHook/hook.cpp#L103
Then, it installs the hook:

As we can see, the used method of  installing hook is almost identical to:
https://github.com/MalwareTech/BasicHook/blob/master/BasicHook/hook.cpp#L77
Below you can see an example of Kronos hooking a function ZwResumeThread in the memory of the attacked process. Instruction lock cmxch8b is indeed used to overwrite the function’s beginning:

After the hook installation, whenever the infected process calls the hooked function, the execution is redirected to the proxy code inside the malicious module:

The hooking engine used in Kronos is overall more sophisticated. First of all, even the fact that it is a shellcode not a PE file makes a difficulty level of implementing it higher. The author must have taken care of filling all the functions addresses by his own. But also, the author of Kronos shown some more experience in predicting possible real-life scenarios. For example he took additional care for checking if the code was not already hooked (i.e. by other trojans or monitoring tools):

Attacking browsers
The malware injects into a browser an additional module (injlib-client.dll). Below we can see an example of the DLL injected into Firefox address space:

The malware starts the injected module with the help of the injected shellcode:

We an see some API redirections added by the malware. Some of the functions imported by the attacked browser are hooked, so that all the data that passes through them is tapped by the Kronos module.
The data that is being grabbed using the hooked browser API is then sent to the main module, that is coordinating malware’s work and reporting to the CnC server.
Conclusion
An overall look at the tricks used by Kronos shows that the author has a prior knowledge in implementing malware solutions. The code is well obfuscated, and also uses various tricks that requires understanding of some low-level workings of the operating system. The author not only used interesting tricks, but used them in a logical and fitting way. The level of precision lead us to the hypothesis, that Kronos is the work of a mature developer, rather than an experimenting youngster.
Appendix
https://www.lexsi.com/securityhub/overview-kronos-banking-malware-rootkit/?lang=en – “Overview of the Kronos banking malware rootkit” by Lexsi
https://www.lexsi.com/securityhub/kronos-decrypting-the-configuration-file-and-injects/?lang=en – Decrypting the configuration
The post Inside the Kronos malware – part 1 appeared first on Malwarebytes Labs.
Click here for best antivirus and antispyware software

Powered by WPeMatico

This entry was posted in Antivirus. Bookmark the permalink.