Jimmy Nukebot: from Neutrino with love

“You FOOL! This isn’t even my final form!”

In one of our previous articles, we analyzed the NeutrinoPOS banker as an example of a constantly evolving malware family. A week after publication, this Neutrino modification delivered up a new malicious program classified by Kaspersky Lab as Trojan-Banker.Win32.Jimmy.

NeutrinoPOS vs Jimmy

The authors seriously rewrote the Trojan – the main body was restructured, the functions were moved to the modules. One small difference that immediately stands out is in the calculation of checksums from the names of API functions/libraries and strings. In the first case, the checksums are used to find the necessary API calls; in the second case, for a comparison of strings (commands, process names). This approach makes static analysis much more complicated: for example, to identify which detected process halts the Trojan operation, it’s necessary to calculate the checksums from a huge list of strings, or to bruteforce the symbols in a certain length range. NeutrinoPOS uses two different algorithms to calculate checksums for the names of API calls, libraries and for the strings. They look like this:

Restored NeutrinoPOS code to calculate checksums for arbitrary strings and for API calls

In Jimmy, only one algorithm is used for these purposes – a slight modification of CalcCS from NeutrinoPOS. The final XOR with the fixed two-byte value was added to the pseudo-random generator.

Calculation of checksums in Jimmy

The Trojan has completely lost the functionality for stealing bank card data from the memory of an infected device; now, its task is limited solely to receiving modules from a remote node and installing them into the system. The scan of the infected host has been extended: in addition to the checks inherited from Neutrino, the Trojan also examines its own name – it should not be a checksum in the MD5, SHA-1, SHA-256 format. Or, alternatively, it should contain the ‘.’ symbol, indicating a subsequent extension (for example, ‘exe’). Plus, by using the assembly command cpuid, the Trojan gets information about the processor and compares it with the list of checksums “embedded” into it.

Additional Jimmy checks

The communication protocol with the C&C server also remains unchanged: the same exchange of “enter”, “success” in base64 commands is used, but now the answer is encrypted with RC4 beforehand and the key hardcoded in the body of the Trojan (a8A5QfZk3r7FHy9o6C2WpBc44TiXg93Y for the sample in question). The code for extracting the encryption key is here.

Analysis of modules

As mentioned above, the main body of the Trojan only receives modules – these contain the payload. We managed to get hold of new modules for web-injects, mining and a large number of updates for the main module in various droppers.

The miner is designed to extract the Monero currency (XMR). In the module code there is an identifier associated with a wallet for which the crypto currency is extracted, as well as the address of the pool. Monero is very popular with virus writers – it’s mined by SambaCry, which we described in June and Trojan.Win32.DiscordiaMiner that appeared shortly afterwards. By the way, the source code of the latter was made publicly available by the author. The reason for doing so was the same that prompted the author of NukeBot to do likewise: an attempt to stifle disagreements in forums and to avoid accusations of fraud (the repository with the code is currently unavailable).

Thanks to the identifier/pool pair, we got statistics on all the nodes working for this wallet. The start date of mining – 4 July – coincides with the compilation of the main body of the first discovered sample and is extremely close to the date of compilation of the dropper (06 July 13:14:55 2017 UTC), the main body (02 July 14:19:03 2017 UTC) and the modules for web injects (July 02, 14:18:39 2017 UTC). So it’s safe to say that Jimmy began to proliferate in early July.

It’s worth noting that the amount of money in the wallet is small – only ~ 0.55 XMR, which as of 21 August is only $45. Judging by the general decline and absence of payments, the authors quickly abandoned the use of miners or changed their wallet.

The web-inject modules are so called for their primary intended use, although they are also able to perform functions similar to those in NeutrinoPOS, i.e., take screenshots, set up proxy servers, etc. These modules are distributed in the form of libraries and their functions vary depending on the name of the process in which they are located. As you can see from the screenshot below, in three cases out of five the ChromeHook procedure is called for browsers. This is not surprising, considering the large number of Chrome-based browsers. Unfortunately, it was possible to restore the name from the checksum for only one of them – chrome.exe (0xFC0C7619). Checksums are calculated using the algorithm described in the previous section.

Restored code of the main procedure in the module of Jimmy web injects

Like NeutrinoPOS, Jimmy stores a number of parameters in the registry. In the sample in question, the data is in the HKEY_CURRENT_USER\Software\c2Fsb21vbkBleHBsb2l0Lmlt branch. For example, this is where the web-inject module receives the address of the currently used DNS server from – this is critical when using NamCoin-like addresses as a C&C server.

For Firefox and Internet Explorer, the function hook is performed by the straightforward substitution of the called function addresses in the loaded libraries (etc. InternetConnectW / PR_Read). With Chrome, things are a bit more complicated – the necessary libraries are linked statically. But the subsequent substitution of data using web injects coincides.

Restored web-inject processing code

So far we have only managed to get a test sample of the web injects (in the screenshot below); in the future the Trojan will most likely acquire ‘combat’ versions. Here you can find examples of web injects and the keys used. To recap, decryption entails decoding the string using base64 and then decrypting with RC4.

Request from Jimmy for web injects

Example of the Jimmy test web injects

In the pictures below several procedures in the source code of NukeBot and the restored code of Jimmy are compared. It can clearly be seen that they completely coincide.

Conclusion

In isolation from the previous modifications, the newly created Jimmy would not be of much interest to researchers. However, in this context, it is an excellent example of what can be done with the source code of a quality Trojan, namely, flexibly adapt to the goals and tasks set before a botnet to take advantage of a new source.

MD5

Droppers
c989d501460a8e8e381b81b807ccbe90
E584C6E999A509AC21583D9543492EF4
2e55bd0d409bf9658887e02a7c578019
bccd77cf0269da7dc914885cda626c6c
86d7d3b50e4dc4181c28ccbaafb89ab3

Main body
174256b5f1ee80be1b847d428c5180e2
336841d91c37b07134adba135828e66e
FE9A46CEFDB41095F10D459BB9943682

Modules
380356b8297893b4fc9273d42f15e9db
2fa18456e14bea53ec0d7c898d94043b
7040b5ac432064780a17024ab0a3792a
629a4d2b79abe48fb21afd625f674354
05846839DAA851006B119A2B4F9687BF
2362E3BEBAD1089DDFE40C8996B0BF45
380356B8297893B4FC9273D42F15E9DB
4042C27F082F48E253BE66528938640C
443831A3057E9A62455D4BD3C7E04144
4762B90C0305A2681CE42B9D05B9E741
CB01E3A0799D4C318F74E439CCE0413F
D9F58167A9A22BD1FA9AA0F991AEAF11
E991936E09697DE8495D05B484F3A3E2