🐩 👸🏽 🤚🏿 New Silence Bootloader 🙌🏻 🤟🏻 👌🏻

Silence is a group that specializes in stealing funds from bank customers and attacks on banking systems. Unlike other groups (RTM, Carbanak, Buhtrap) Silence is the most selective in choosing a victim, and also has a rich arsenal of tools that it uses depending on the situation and the victim. On February 6, we recorded an interesting malware distribution (malware) targeted at bank customers. As a result of the analysis of the infection chain, we obtained and analyzed a new version of the Silence bootloader.

Download and run the Silence bootloader

Macro document

Attackers distribute malware using letters from a certain Wiki who suggests looking at a record of secret negotiations (subject line: "Tramp novosti posmatri"). A malicious document in the DOC format is attached to the letter.

A DLL is hidden in the body of the malicious document: its contents are hidden in the form of tables (Fig. 1).

Fig. 1. Part of the contents of the DLL hidden in the body of the document

The macro contained in the document converts each field of the table into 4 bytes of the future library: the cell text is processed as an integer value. For instance:

9460301 is converted to 4d 5a 90 00 ;
3 is converted to 03 00 00 00 ;
4 is converted to 04 00 00 00 .

Note that the malicious document contains both 64-bit and 32-bit versions of the library. The contents of the 64-bit library are between the keywords SeasonValue and AppendCell, and the contents of the 32-bit library are between Visions and FindWords. The capacity of the loaded library is selected in accordance with the capacity of the winword.exe process.

The part of the macro loading and executing DLLs is shown in Fig. 2.

Fig. 2. Part of the malicious macro

After building the library, the macro copies it to the% TEMP% directory with the name icutils.dll and loads it. Next, the macro calls the clone function from the library , as a result of which the new version of the Silence loader is downloaded and launched.

As part of a recent newsletter, the contents of the bootloader were downloaded from the address hxxps: // pastebin [.] Com / raw / Jyujxy7z. Soon after the mailing, this resource was unavailable.

Description of the icutils.dll libraries

The 32-bit version of the icutils.dll library writes its code to the address space of the notepad.exe process, and the 64-bit version writes to the address space of the cmd.exe process.

After that, both libraries perform the same sequence of actions:

download content at hxxps: // pastebin [.] com / raw / Jyujxy7z using the InternetReadFile function;
write this content to a file located on the% TEMP% \ <random-hex-string> .dat path;
decode and decrypt the contents of the% TEMP% \ <random-hex-string> .dat file.

If the first 2 bytes of the received buffer match the header of the PE file (MZ), then the buffer is written to the file located on the% TEMP% \ <random-hex-string> .exe path, and this file is executed. With several unsuccessful attempts, the process in the memory of which the library is executed ends.

We will conduct a detailed analysis of the icutils.dll libraries using the example of the 64-bit version. Recall that it operates in the address space of the cmd.exe process.

To get started, consider the clone function, which is responsible for downloading and launching the Silence bootloader.

At the first stage, the code is decrypted (Fig. 3), which will be executed in the address space of the cmd.exe process, as well as the data (Fig. 4) necessary for the code to work correctly.

Fig. 3. Code decryption using XOR

Fig. 4. Decryption of data using XOR

cmd.exe;
cmd.exe;
CreateRemoteThread.

This is clearly illustrated in the pseudocode from the Hex-Rays decompiler (Fig. 5).

Fig. 5. Inject in cmd.exe

As shown on the screenshot in parameter lpStartAddress written code from inj_func_start , and the structure lpParameter comprises decrypted data from inj_data_start (including address hxxps: // pastebin com / raw / Jyujxy7z [.]).

Now consider the function code inj_func_start .

The addresses of the imported functions are obtained from the CRC32 values from their names (Fig. 6).

Fig. 6. Obtaining addresses of imported functions (constants with CRC32 values are replaced by the names of the corresponding API functions)

Next, the content is downloaded from the hxxps: // pastebin [.] Com / raw / Jyujxy7z resource and this content is written to a file with the .dat extension (Fig. 7).

Fig. 7. Downloading and writing to a DAT file content from the resource hxxps: // pastebin [.] Com / raw / Jyujxy7z

After receiving the DAT file, it is decoded from base64, decrypted with XOR and, if correct, written to the file - the DecryptAndSave function is responsible for all this. Finally, using the CreateProcessW function, the executable file is launched (Fig. 8).

Fig. 8. Getting and running the executable file

It should be noted that the DecryptAndSave function is only successful if the first 2 bytes of the received content are “MZ”. This helps to avoid downloading incorrect content, for example, if the contents of the resource hxxps: // pastebin [.] Com / raw / Jyujxy7z were deleted (and this eventually happened). After several unsuccessful attempts, the process ends.

New version of Silence bootloader

The previous Silence bootloader, also known as TrueBot, did the following:

collecting information about the infected system using Windows system utilities and writing the received information to a file;
uploading the received file to the management server and waiting for a command from the server;
self-removal or downloading and launching additional software depending on the received command.

The new Silence bootloader combines the features of TrueBot and the main Silence module. In particular, they coincide with the main module:

the practice of assigning an identifier to infected users;
a way to get imported functions and decrypted strings.

The general process of executing the bootloader is shown in Fig. 9.

Fig. 9. Process graph during bootloader execution

Getting Unpacked Bootloader

Like the 64-bit icutils.dll library, the loader writes its code to the address space of the cmd.exe process (# 2 in Fig. 9). Unlike the library, the loader does this twice.

Malicious code and data for the first injection are decrypted using XOR (Fig. 10).

Fig. 10. The function of decrypting code and data for the first malware injection

creates a child process cmd.exe (# 2) in a suspended state. Next, the malware overwrites the entry point of the created process (Fig. 11), and also writes the decrypted code and data to the allocated memory area.

Fig. 11. Code that overwrites the entry point of the cmd.exe process (# 2)

Before resuming the cmd.exe process (# 2), the constant 0xCBCBCBCBB (see Fig. 11) is replaced by the address of the allocated memory area where malicious code and data were previously written.

The malicious code that works as a result of the first injection has significant similarities with the code of the icutils.dll malicious library. The addresses of the imported functions are obtained from the CRC32 values from their names (Fig. 12).

Fig. 12. Obtaining addresses of imported functions

As a result of executing malicious code, the malware downloads the image from the resource hxxps: //i.imgur [.] Com / sGD7lrl.png and saves it to a file on disk along the path% TEMP% / <random-hex-string > .png.

The section of code responsible for downloading (Fig. 13) is also similar to the loading code of the executable file by the icutils.dll malicious library. This shows that attackers reuse the code at certain stages of malware download.

Fig. 13. Image download code The

content of the downloaded image is used to obtain the Silence boot loader executable file, as well as the code and data executing it in the address space of the cmd.exe child process (# 7 in Fig. 9).

The resulting code registers the file downloaded from hxxps: // pastebin [.] Com / raw / Jyujxy7z into autoload. It happens like this:

during execution of the received code, the executable file is copied to disk in an arbitrary folder located in the% TEMP% directory with the name local.exe;
a shortcut is created in the% TEMP% directory with the name <random-hex-string> .lnk, which is then copied with the name local.lnk to the% UserProfile% \ AppData \ Roaming \ Microsoft \ Windows \ Start Menu \ Programs \ Startup folder.

After that, the Silence loader executes the malicious code in the address space of the child process cmd.exe (# 7).

Unpacked bootloader analysis

The main cycle of communication with the management server is shown in Fig. 14.

Fig. 14. The main cycle of communication with the management server

Communication between the bootloader and the management server is based on the following principle:

the bootloader addresses hxxp (s): // minkolado [.] top / and receives a number - the victim's serial number;
all subsequent calls are made to the address hxxp (s): // minkolado [.] top / {num} ;
the response of the management server will contain a command for the bootloader.

Obtaining addresses of imported functions and decoding strings

The function pseudo-code for receiving the addresses of API functions is shown in Fig. 15.

Fig. 15. Function pseudo-code for receiving the addresses of API functions

A similar code was present in the samples of the main Silence module.

As in the main Silence module, strings are obtained by identifier and decrypted using XOR.

A list of all decrypted lines is presented in the table below (not all decrypted lines are used in reality).

Identifier	Line
0	pcinfo.txt
1	log.txt
2	Kernel32.dll
3	CreateProcessW
4	Wininet.dll
5	InternetOpenW
6	Mozilla / 5.0 (Macintosh; Intel Mac OS X xy; rv: 42.0) Gecko / 20101111 Firefox / 42.0
7	Internetconnectw
8	HttpSendRequestExW
9	HttpOpenRequestW
10	cmd /C %s %s \"%s\"
11	InternetReadFile
12	HttpQueryInfoW
13	HttpSendRequestW
14	InternetQueryDataAvailable
15	InternetWriteFile
16	InternetSetOptionW
17	InternetCloseHandle
18	InternetQueryOptionW
19	HttpEndRequestW
20	GET
21	POST
22	minkolado.top
23	443
24	80
25	MSCF
26	URLDownloadToFileW
27	Urlmon.dll
28	cmd /c makecab /V3 \"%s\" \"%s\"
29	temp.cab
30	cmd /c expand \"%s\" \"%s\"
31	/content/%s
32	/%d/%s
33	introduce.dat
34	CreateThread
35	GetModuleFileNameW
36	Shell32.dll
37	SHGetFolderPathW
38	>>
39	echo ---%d---
40	netstat -na
41	ipconfig
42	whoami
43	hostname
44	tasklist
45	systeminfo
46	/
47	/%d
48	/%d/%s
49	svchost.exe
50	jest
51	praktycznie
52	poligraficznym
53	nasz
54	cmd / c ping localhost -n 15> nul & del \ "% s \"
55	ShlWApi.dll
56	Pathcombinew
57	Sleep

Description of commands from the management server

Commands from the management server are processed in the CommandHandler function (Fig. 16).

Fig. 16. CommandHandler function pseudo-code

The bootloader supports the following commands:

new_identity_command
nop_command
download_and_execute_command
set_destroy_command
pc_info_command

The names of the commands are taken in accordance with the names of the classes inherited from the server_command_bas e class (Fig. 17). The server_command_base class contains a 4-byte field for the command identifier from the managing server (in Fig. 16 it is defined as command_code ).

Fig. 17. Some classes defined by cybercriminals.

Below is a detailed description of each command.

new_identity_command

The command is executed if a string converted to an integer value was received from the management server. After receiving this command, the loader changes the serial number of the user, that is, the relative address at which the interaction with the management server takes place.

For example, if the server sent the string “01337”, then the address of interaction with C&C for this infected user will change to hxxp (s): // minkolado [.] Top / 1337 .

nop_command

The command is executed if the jest string ("yes" in Polish) is received from the control server . When this command is received, the bootloader does nothing.

download_and_execute_command

The command is executed if the string nasz ("ours" in Polish) is received from the control server . Along with the nasz line , the relative address for downloading additional malware is transmitted.

Upon receipt of this command, the loader performs the following actions:

Loads data from the received address;
checks the header of the downloaded data - the first 4 bytes should be the header of the CAB file (MSCF);
if the downloaded data has the correct header, saves it in the file% UserProfile% \ AppData \ Local \ temp.cab;
Using the standard Windows utility, expand extracts the svchost.exe file from the temp.cab CAB archive .

If the svchost.exe file is successfully extracted, it is launched from the same directory.

set_destroy_command

The command is executed if the string praktycznie ("practically" in Polish) is received from the control server .

Upon receipt of this command, the bootloader self-destructs using the ping localhost -n 15> nul & del {self_file_name} command .

pc_info_command

, poligraficznym («» -). . :

netstat -na, ipconfig, whoami, hostname, tasklist, systeminfo %UserProfile%\AppData\Local\pcinfo.txt;
Windows makecab pcinfo.txt temp.cab;
before the next command request from the management server (this happens every three seconds), the temp.cab file will be uploaded to C&C with the name introduce.dat (hxxp (s): // minkolado [.] top / {num} /introduce.dat).

undefined_command

It should be noted that in the bootloader code there is another handler class for the command from the server - undefined_command . It is used if incorrect data came from C&C.

Attackers called this typo class - undefinded_command (Fig. 18).

Fig. 18. class undefinded_command

Summary table

For clarity, we summarize everything in one table.

Handler class name	The string that comes from the server	Short description
new_identity_command	String convertible to integer value	,
nop_command	jest
download_and_execute_command	nasz	CAB- ,
set_destroy_command	praktycznie
pc_info_command	poligraficznym	Windows CAB-
undefinded_command	−	−

New Silence Bootloader