Malware Alerts

Subscribe to Malware Alerts feed Malware Alerts
Online headquarters of Kaspersky Lab security experts.
Updated: 5 hours 43 min ago

Introducing WhiteBear

Wed, 08/30/2017 - 10:43

As a part of our Kaspersky APT Intelligence Reporting subscription, customers received an update in mid-February 2017 on some interesting APT activity that we called WhiteBear. Much of the contents of that report are reproduced here. WhiteBear is a parallel project or second stage of the Skipper Turla cluster of activity documented in another private intelligence report “Skipper Turla – the White Atlas framework” from mid-2016. Like previous Turla activity, WhiteBear leverages compromised websites and hijacked satellite connections for command and control (C2) infrastructure. As a matter of fact, WhiteBear infrastructure has overlap with other Turla campaigns, like those deploying Kopiluwak, as documented in “KopiLuwak – A New JavaScript Payload from Turla” in December 2016. WhiteBear infected systems maintained a dropper (which was typically signed) as well as a complex malicious platform which was always preceded by WhiteAtlas module deployment attempts. However, despite the similarities to previous Turla campaigns, we believe that WhiteBear is a distinct project with a separate focus. We note that this observation of delineated target focus, tooling, and project context is an interesting one that also can be repeated across broadly labeled Turla and Sofacy activity.

From February to September 2016, WhiteBear activity was narrowly focused on embassies and consular operations around the world. All of these early WhiteBear targets were related to embassies and diplomatic/foreign affair organizations. Continued WhiteBear activity later shifted to include defense-related organizations into June 2017. When compared to WhiteAtlas infections, WhiteBear deployments are relatively rare and represent a departure from the broader Skipper Turla target set. Additionally, a comparison of the WhiteAtlas framework to WhiteBear components indicates that the malware is the product of separate development efforts. WhiteBear infections appear to be preceded by a condensed spearphishing dropper, lack Firefox extension installer payloads, and contain several new components signed with a new code signing digital certificate, unlike WhiteAtlas incidents and modules.

The exact delivery vector for WhiteBear components is unknown to us, although we have very strong suspicion the group spearphished targets with malicious pdf files. The decoy pdf document above was likely stolen from a target or partner. And, although WhiteBear components have been consistently identified on a subset of systems previously targeted with the WhiteAtlas framework, and maintain components within the same filepaths and can maintain identical filenames, we were unable to firmly tie delivery to any specific WhiteAtlas component. WhiteBear focused on various embassies and diplomatic entities around the world in early 2016 – tellingly, attempts were made to drop and display decoy pdf’s with full diplomatic headers and content alongside executable droppers on target systems.

Technical Details

The WhiteBear platform implements an elaborate set of messaging and injection components to support full presence on victim hosts. A diagram helps to visualize the reach of injected components on the system.

WhiteBear Binary loader

Sample MD5: b099b82acb860d9a9a571515024b35f0
Type PE EXE
Compilation timestamp 2002.02.05 17:36:10 (GMT)
Linker version 10.0 (MSVC 2010)
Signature “Solid Loop Ldt” UTCTime 15/10/2015 00:00:00 GMT – UTCTime 14/10/2016 23:59:59 GMT

The WhiteBear binary loader maintains several features including two injection methods for its (oddly named) “KernelInjector” subsystem, also named by its developer
– Standart
– WindowInject (includes an unusual technique for remotely placing code into memory for subsequent thread execution)

The loader also maintains two methods for privilege and DEP process protection handling:
– GETSID_METHOD_1
– GETSID_METHOD_2

The binary contains two resources:
– BINARY 201
– File size: 128 bytes
– Contains the string, “explorer.exe”
– BINARY 202
– File size: 403456 bytes
– File Type: PE file (this is the actual payload and is not encrypted)
– This PE file resource stores the “main orchestrator” .dll file

Loader runtime flow

The loader creates the mutex “{531511FA-190D-5D85-8A4A-279F2F592CC7}”, and waits up to two minutes if it is already present while logging the message “IsLoaderAlreadyWork +”. The loader creates the mutex “{531511FA-190D-5D85-8A4A-279F2F592CC7}”, and waits up to two minutes. If it is already present while logging the message “IsLoaderAlreadyWork +”, it extracts the resource BINARY 201. This resource contains a wide string name of processes to inject into (i.e. “explorer.exe”).

The loader makes a pipe named: \\.\pipe\Winsock2\CatalogChangeListener-%03x%01x-%01x

Where the “%x” parameter is replaced with the values 0xFFFFFFFF 0xEEEEEEEE 0xDDDDDDDD, or if it has successfully obtained the user’s SID:
\\.\pipe\Winsock2\CatalogChangeListener-%02x%02x-%01x
With “%x” parameters replaced with numbers calculated from the current date and a munged user SID.

The pipe is used to communicate with the target process and the transport module; the running code also reads its own image body and writes it to the pipe. The loader then obtains the payload body from resource BINARY 202. It finds the running process that matches the target name, copies the buffer containing the payload into the process, then starts its copy in the target process.

There are some interesting, juvenile, and non-native English-speaker debug messages compiled into the code:
– i cunt waiting anymore #%d
– lights aint turnt off with #%d
– Not find process
– CMessageProcessingSystem::Receive_NO_CONNECT_TO_GAYZER
– CMessageProcessingSystem::Receive_TAKE_LAST_CONNECTION
– CMessageProcessingSystem::Send_TAKE_FIN

WhiteBear Main module/orchestrator

Sample MD5: 06bd89448a10aa5c2f4ca46b4709a879
Type, size: PE DLL, 394 kb
Compilation timestamp: 2002.02.05 17:31:28 (GMT)
Linker version: 10.0 (MSVC 2010)
Unsigned Code

The main module has no exports, only a DllMain entry which spawns one thread and returns. The main module maintains multiple BINARY resources that include executable, configurations, and encryption data:

101 – RSA private (!) key
102 – RSA public key
103 – empty
104 – 16 encrypted bytes
105 – location (“%HOMEPATH%\ntuser.dat.LOG3”)
106 – process names (e.g. “iexplore.exe, firefox.exe, chrome.exe, outlook.exe, safari.exe, opera.exe”) to inject into
107 – Transport module for interaction with C&C
108 – C2 configuration
109 – Registry location (“\HKCU\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Explorer\Screen Saver”)
110 – no information
111 – 8 zero bytes

Values 104 – 111 are encrypted with the RSA private key (resource 101) and compressed with bzip2.4. The RSA key is stored with header stripped in a format similar to Microsoft’s PVK; the RSA PRIVATE KEY header is appended by the loader before reading the keys into the encryption code. Resource 109 points to a registry location called “external storage”, built-in resources are called “PE Storage”.

In addition to storing code, crypto resources, and configuration data in PE resources, WhiteBear copies much of this data to the victim host’s registry. Registry storage is located in the following keys. Subkeys and stored values listed below:
[HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ScreenSaver] [HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Explorer\ScreenSaver]

Registry subkeys:
{629336E3-58D6-633B-5182-576588CF702A} Contains the RSA private key used to encrypt/decrypt other resources / resource 101
{3CDC155D-398A-646E-1021-23047D9B4366} Resource 105 – current file location
{81A03BF8-60AA-4A56-253C-449121D61CAF} Resource 106 – process names
{31AC34A1-2DE2-36AC-1F6E-86F43772841F} Contains the internet C&C transport module / resource 107
{8E9810C5-3014-4678-27EE-3B7A7AC346AF} Resource 108 – C&C config
{28E74BDA-4327-31B0-17B9-56A66A818C1D} Resource 110 “plugins”
{4A3130BD-2608-730F-31A7-86D16CE66100} Resource 111
{119D263D-68FC-1942-3CA3-46B23FA652A0} Unique Guid (“ObjectID”)
{1DC12691-2B24-2265-435D-735D3B118A70} “Task Queue”
{6CEE6FE1-10A2-4C33-7E7F-855A51733C77} “Result Queue”
{56594FEA-5774-746D-4496-6361266C40D0}  unknown
{831511FA-190D-5D85-8A4A-279F2F592CC7}  unknown

Finally, if the main WhiteBear module fails to use registry storage, it uses “FS Storage” in file %TEMP%\KB943729.log. The module reads all of its data and binary components from one of the storages and then verifies the integrity of data (RSA+bzip2 compression+signature).

The module maintains functionality which is divided into a set of subsystems that are loosely named by the developers:
• result queue
• task queue
• message processing system
• autorun manager
• execution subsystem
• inject manager
• PEStorage
• local transport manager/internal transport channel

It creates the following temporary files:
%TEMP%\CVRG72B5.tmp.cvr
%TEMP%\CVRG1A6B.tmp.cvr
%TEMP%\CVRG38D9.tmp.cvr

%TEMP%\~DF1E05.tmp contains the updated body of the loader during an update.

Every day (as specified by local time) the main module restarts the transport subsystem which includes:
• message processing
• named pipe transport (“NPTransport”)

If the registry/file storage is empty, the module performs a ‘migration’ of hardcoded modules and settings to the storage location. This data is encrypted with a new RSA key (which is also stored in the registry).

The data in the registry is prepended with a 0xC byte header. The maximum size of each registry item is 921,600 bytes; if the maximum size is exceeded, it is split into several items. The format of the header is shown below:
[4:service DWORD][4:chunk index][4:chunk size including header]

Every time the orchestrator module is loaded it validates that the storage area contains the appropriate data and that all of the components can be decrypted and validated. If these checks fail the module reinstalls a configuration from the resource “REINSTALL”.

Pipe Transport

The module generates the pipe name (with the same prefix as the loader); waits for incoming connections; receives data and pushes it to the ‘message processing system’. The module generates the pipe name (with the same prefix as the loader); waits for incoming connections; receives data and pushes it to the ‘message processing system’. Every packet is expected to be at least 6 bytes and contain the following header:      [4:ID][2:command]

List of commands:
1 : new task
2 : update the loader + orchestrator file
4 : send task result
5 : send settings
6 : write results to registry/file storage
7 : enable / disable c2 transport / update status
8 : uninstall
9 : nop
10 : “CMessageProcessingSystem::Receive_NO_CONNECT_TO_GAYZER”; write results to registry
11: write the last connection data ‘{56594FEA-5774-746D-4496-6361266C40D0}’ aka “last connection” storage value
12: “give cache” – write cached commands from the C&C
13: “take cache” – append C&C commands to the cache

Depending on the command, the module returns the results from previously run tasks, the configuration of the module, or a confirmation message.

An example of these tasks is shown below:
• write a file and execute it with CreateProcess() capturing all of the standard output
• update C&C configuration, plugin storage, etc
• update autoruns
• write arbitrary files to the filesystem (“File Upload”)
• read arbitrary files from the filesystem (“File Download”)
• update itself
• uninstall
• push task results to C2 servers

The “LocalTransport manager” handles named pipe communication and identifies if the packet received is designated to the current instance or to someone else (down the route). In the latter scenario the LocalTansport manager re-encrypts the packet, serializes it (again), and pushes the packet via a named pipe on the local network to another hop, (NullSessionPipes). This effectively makes each infected node a packet router.

The Autorun manager subsystem is responsible for tracking the way that the malicious module starts in the system and it maintains several different methods for starting automatically (shown below):
LinkAutorun The subsystem searches for a LNK file in the target directory, changes the path to “cmd.exe” and the description to ‘ /q /c start “” “%s” && start “” “%s” ‘
TaskScheduler20Autorun The subsystem creates the ITaskService (works only on Windows Vista+) and uses the ITaskService interface to create a new task with a logon trigger
StartupAutorun The subsystem creates a LNK file in %STARTUP%
ScreenSaverAutorun The subsystem installs as a current screensaver with a hidden window
HiddenTaskAutorun The subsystem creates the task ITaskScheduler (works only on pre-Vista NT). The task trigger start date is set to the creation date of the Windows directory
ShellAutorun Winlogon registry [HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon] Shell=”explorer.exe, …”

File Uninstallation is done in a discreet manner. The file is filled with zeroes, then renamed to a temporary filename before being deleted

WhiteBear Transport library (aka “Internet Relations”, “Pipe Relations”)

Sample MD5: 19ce5c912768958aa3ee7bc19b2b032c
Type: PE DLL
Linker timestamp: 2002.02.05 17:58:22 (GMT)
Linker version: 10.0
Signature “Solid Loop Ldt” UTCTime 15/10/2015 00:00:00 GMT – UTCTime 14/10/2016 23:59:59 GMT

This transport library does not appear on disk in its PE format. It is maintained as encrypted resource 107 in the orchestrator module, then decrypted and loaded by the orchestrator directly into the memory of the target process. This C2 interaction module is independent, once started, it interacts with the orchestrator using its local named pipe.

To communicate with its C2 server, the transport library uses the system user agent or default “Mozilla/4.0 (compatible; MSIE 6.0)”.

Before attempting a connection with its configured C2 server, the module checks if the victim system is connected to Internet by sending HTTP 1.1 GET / requests to the following servers (this process stops after the first successful connection):
• update.microsoft.com
• microsoft.com
• windowsupdate.microsoft.com
• yahoo.com
• google.com

If there is no Internet connection available, the module changes state to, “CANNOT_WORK” and notifies the peer by sending command “7” over the local pipe.

The C2 configuration is obtained from the main module with the command “5”. This checks whether the module complies with the schedule specified in the C2 settings (which includes inactivity time and the interval between connections). The C2 interaction stages have interesting function names and an odd misspelling, indicating that the developer may not be a native English speaker (or may have learned the English language in a British setting):
“InternetRelations::GetInetConnectToGazer”
“InternetRelations::ReceiveMessageFromCentre”
“InternetRelations::SendMessageToCentre”
“PipeRelations::CommunicationTpansportPipe”

The module writes the encrypted log to %TEMP%\CVRG38D9.tmp.cvr The module sends a HTTP 1.0 GET request through a randomly generated path to the C2 server. The server’s reply is expected to have its MD5 checksum appended to the packet. If C2 interaction fails, the module sends the command “10” (“NO_CONNECT_TO_GAYZER”) to the orchestrator.

Unusual WhiteBear Encryption

The encryption implemented in the WhiteBear orchestrator is particularly interesting. We note that the resource section is encrypted/decrypted and packed/decompressed with RSA+3DES+BZIP2. This implementation is unique and includes the format of the private key as stored in the resource section. 3DES is present in Sofacy and Duqu2 components, however they are missing in this Microsoft-centric RSA encryption technique. The private key format used in this schema and RSA crypto combination with 3DES is (currently) unique to this threat actor.

The private key itself is stored as a raw binary blob, in a format similar to the one Microsoft code uses in PVK format. This format is not officially documented, but its structures and handling are coded into OpenSSL. This private key value is stored in the orchestrator resources without valid headers. The orchestrator code prepends valid headers and passes the results to OpenSSL functions that parse the blob.

Digital Code-Signing Certificate – Fictional Corporation or Assumed Identity?

Most WhiteBear samples are signed with a valid code signing certificate issued for “Solid Loop Ltd”, a once-registered British organization. Solid Loop is likely a phony front organization or a defunct organization and actors assumed its identity to abuse the name and trust, in order to attain deceptive code-signing digital certificates.

WhiteBear Command and Control

The WhiteBear C2 servers are consistent with long standing Turla infrastructure management practices, so the backdoors callback to a mix of compromised servers and hijacked destination satellite IP hosts. For example, direct, hardcoded Turla satellite IP C2 addresses are shown below:

C2 IP Address               Geolocation                            IP Space Owner
169.255.137[.]203         South Sudan                           IPTEC, VSAT
217.171.86[.]137           Congo                                     Global Broadband Solution, Kinshasa VSAT
66.178.107[.]140           Unknown – Likely Africa          SES/New Skies Satellites

Targeting and Victims

WhiteBear targets over the course of a couple years are related to government foreign affairs, international organizations, and later, defense organizations. The geolocation of the incidents are below:

  • Europe
  • South Asia
  • Central Asia
  • East Asia
  • South America
Conclusions

WhiteBear activity reliant on this toolset seems to have diminished in June 2017. But Turla efforts continue to be run as multiple subgroups and campaigns. This one started targeting diplomatic entities and later included defense related organizations. Infrastructure overlap with other Turla campaigns, code artifacts, and targeting are consistent with past Turla efforts. With this subset of 2016-2017 WhiteBear activity, Turla continues to be one of the most prolific, longstanding, and advanced APT we have researched, and continues to be the subject of much of our research. Links to publicly reported research are below.

Reference Set
Full IOC and powerful YARA rules delivered with private report subscription

Md5
b099b82acb860d9a9a571515024b35f0
19ce5c912768958aa3ee7bc19b2b032c
06bd89448a10aa5c2f4ca46b4709a879

IP
169.255.137[.]203
217.171.86[.]137
66.178.107[.]140

Domain(s)
soligro[.]com – interesting because the domain is used in another Turla operation (KopiLuwak), and is the C2 server for the WhiteBear transport library
mydreamhoroscope[.]com

Example log upon successful injection

|01:58:10:216|.[0208|WinMain ]..
|01:58:14:982|.[0209|WinMain ].******************************************************************************************
|01:58:15:826|.[0212|WinMain ].DATE: 01.01.2017
|01:58:21:716|.[0215|WinMain ].PID=2344.TID=1433.Heaps=3
|01:58:22:701|.[0238|WinMain ].CreateMutex = {521555FA-170C-4AA7-8B2D-159C2F491AA4}
|01:58:25:513|.[0286|GetCurrentUserSID ]._GETSID_METHOD_1_
|01:58:26:388|.[0425|GetUserSidByName ].22 15 1284404594 111
|01:58:27:404|.[0463|GetUserSidByName ].S-1-5-31-4261848827-3118844265-2233733001-1000
|01:58:28:263|.[0471|GetUserSidByName ].
|01:58:29:060|.[0165|GeneratePipeName ].\\.\pipe\Winsock2\CatalogChangeListener-5623-b
|01:58:29:763|.[0275|WinMain ].PipeName = \\.\pipe\Winsock2\CatalogChangeListener-5623-b
|01:58:30:701|.[0277|WinMain ].Checking for existence…
|01:58:31:419|.[0308|WinMain ].— Pipe is not installed yet
|01:58:32:044|.[0286|GetCurrentUserSID ]._GETSID_METHOD_1_
|01:58:32:841|.[0425|GetUserSidByName ].22 15 1284404594 111
|01:58:33:701|.[0463|GetUserSidByName ].S-1-5-31-4261848827-3118844265-2233733001-1000
|01:58:34:419|.[0471|GetUserSidByName ].
|01:58:35:201|.[0318|WinMain ].Loading…
|01:58:35:763|.[0026|KernelInjector::KernelInjector ].Address of marker: 0x0025F96C and cProcName: 0x0025F860
|01:58:36:513|.[0031|KernelInjector::KernelInjector ].Value of marker = 0xFFFFFEF4
|01:58:37:279|.[0088|KernelInjector::SetMethod ].m_bAntiDEPMethod = 1
|01:58:38:419|.[0564|QueryProcessesInformation ].OK
|01:58:41:169|.[0286|GetCurrentUserSID ]._GETSID_METHOD_1_
|01:58:42:076|.[0425|GetUserSidByName ].22 15 1284404594 111
|01:58:42:748|.[0463|GetUserSidByName ].S-1-5-31-4261848827-3118844265-2233733001-1000
|01:58:43:169|.[0471|GetUserSidByName ].
|01:58:43:701|.[0309|FindProcesses ].dwPID[0] = 1260
|01:58:44:560|.[0345|WinMain ].try to load dll to process (pid=1260))
|01:58:45:013|.[0088|KernelInjector::SetMethod ].m_bAntiDEPMethod = 1
|01:58:45:873|.[0094|KernelInjector::LoadDllToProcess ].MethodToUse = 1
|01:58:46:544|.[0171|KernelInjector::GetProcHandle ].pid = 1260
|01:58:47:279|.[0314|KernelInjector::CopyDllFromBuffer ].Trying to allocate space at address 0x20020000
|01:58:48:404|.[0332|KernelInjector::CopyDllFromBuffer ].IMAGEBASE = 0x20020000.ENTRYPOINT = 0x2002168B
|01:58:48:763|.[0342|KernelInjector::CopyDllFromBuffer ].ANTIDEP INJECT
|01:58:49:419|.[0345|KernelInjector::CopyDllFromBuffer ].Writing memory to target process….
|01:58:49:935|.[0353|KernelInjector::CopyDllFromBuffer ].Calling to entry point….
|01:58:51:185|.[0598|KernelInjector::CallEntryPoint ].CODE = 0x01FA0000, ENTRY = 0x2002168B, CURR = 0x77A465A5, TID = 1132
|01:58:55:544|.[0786|KernelInjector::CallEntryPoint ]._FINISH_ = 1
|01:58:56:654|.[0372|KernelInjector::CopyDllFromBuffer ].CTRLPROC = 0
|01:58:57:607|.[0375|KernelInjector::CopyDllFromBuffer ].+ INJECTED +
|01:58:58:419|.[0351|WinMain ].+++ Load in 1260

References – past Turla research

The Epic Turla Operation
Satellite Turla: APT Command and Control in the Sky
Agent.btz: a Source of Inspiration?
The ‘Penquin’ Turla
Penquin’s Moonlit Maze
KopiLuwak: A New JavaScript Payload from Turla

Uroburos: the snake rootkit [pdf]
The Snake Campaign

Jimmy Nukebot: from Neutrino with love

Tue, 08/29/2017 - 05:00

“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