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 C&C 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 C&C 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 C&C servers. The C&C addresses can be obtained from the string initialization procedure.
When first contacting a C&C, 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.
MD5
626438C88642AFB21D2C3466B30F2312
697A7037D30D8412DF6A796A3297F37E
031A8139F1E0F8802FF55BACE423284F
93B14905D3B8FE67C2D552A85F06DEC9
A06A16BD77A0FCB95C2C4321BE0D2B26
0633024162D9096794324094935C62C0
9E469E1ADF9AAE06BAE6017A392B4AA9
078AA893C6963AAC76B63018EE4ECBD3
44230DB078D5F1AEB7AD844590DDC13E
FAF24FC768C43B95C744DDE551D1E191
8EBEC2892D033DA58A8082C0C949C718
6DC91FC2157A9504ABB883110AF90CC9
36EB9BDEFB3899531BA49DB65CE9894D
D2F56D6132F4B6CA38B906DACBC28AC7
79E6F689EECB8208869D37EA3AF8A7CA
9831B1092D9ACAEB30351E1DB30E8521
Source: Cyber Security by Kaperski Labs
