This spring, the author of the NukeBot banking Trojan published the source code of his creation. He most probably did so to restore his reputation on a number of hacker forums: earlier, he had been promoting his development so aggressively and behaving so erratically that he was eventually suspected of being a scammer. Now, three months after the source code was published, we decided to have a look at what has changed in the banking malware landscape.
NukeBot in the wild
The publication of malware source code may be nothing new, but it still attracts attention from across the IT community and some of that attention usually goes beyond just inspecting the code.
The NukeBot case was no exception: we managed to get our hands on a number of compiled samples of the Trojan. Most of them were of no interest, as they stated local subnet addresses or ‘localhost/127.0.0.1’ as the CC address.
Far fewer samples had ‘genuine’ addresses and were ‘operational’.
The main functionality of this banking Trojan is to make web injections into specific pages to steal user data, but even from operational servers we only received ‘test’ injections that were included in the source code as examples.
Test injections from the NukeBot source code
The NukeBot samples that we got hold of can be divided into two main types: one with plain text strings, and the other with encrypted strings.
The test samples typically belong to type 1, so we didn’t have any problems extracting the CC addresses and other information required for analysis from the Trojan body.
It was a bit more complicated with the encrypted versions – the encryption keys had to be extracted first and only after that could the string values be established. Naturally, all the above was done automatically, using scripts we had developed.
The data itself is concentrated in the Trojan’s one and only procedure that is called at the very beginning of execution.
A comparison of the string initialization procedure in plain text and with encryption.
Decryption (function sub_4049F6 in the screenshot) is performed using XOR with a key.
Implementation of string decryption in Python
In order to trigger web injections, we had to imitate interaction with CC servers.
The CC addresses can be obtained from the string initialization procedure.
When first contacting a CC, the bot is sent an RC4 key which it uses to decrypt injections. We used this simple logic when implementing an imitation bot, and managed to collect web injections from a large number of servers.
Initially, the majority of botnets only received test injects that were of no interest to us. Later, however, we identified a number of NukeBot’s ‘combat versions’.
Based on an analysis of the injections we obtained, we presume the cybercriminals’ main targets were French and US banks.
Example of ‘combat-grade’ web injections
Of all the Trojan samples we obtained, 2-5% were ‘combat-grade’. However, it is still unclear if these versions were created by a few motivated cybercriminals and the use of NukeBot will taper off soon, or if the source code has fallen into the hands of an organized group (or groups) and the number of combat-grade samples is set to grow. We will continue to monitor the situation.
We also managed to detect several NukeBot modifications that didn’t have web injection functionality, and were designed to steal mail client and browser passwords. We received those samples exclusively within droppers: after unpacking, they downloaded the required utilities (such as ‘Email Password Recovery’) from a remote malicious server.
Kaspersky Lab products detect the banking Trojans of the NukeBot family as Trojan-Banker.Win32.TinyNuke.
Droppers containing this banking Trojan were assigned the verdict Trojan-PSW.Win32.TinyNuke.