Gazer: backdoor of the second stage of the Turla ART group
ESET performed an analysis of a new, previously undocumented backdoor, which is most likely used by Turla ART. The backdoor is seen in attacks on government and diplomatic institutions in Europe. Turla is a cyber group that specializes in cyber espionage operations. Typical Turla hacker methods are watering hole attacks and targeted phishing. The new backdoor has been actively used since at least 2016. Based on the strings found in the studied samples, we named it Gazer.
Recently, the press remembered Turla hackers, which has not happened for a long time. Journalists of The Interceptrecalled the presentation of the Communication Security Establishment Office of Canada (CSE), which lists Turla operator errors. The authors of the presentation call the cybergroup MAKERSMARK, a brief summary on the slide below:
Gazer, like other Turla tools, uses advanced methods for espionage and ensuring stability in target systems. We talk about attacks using Gazer and present a technical analysis of the backdoor functionality.
According to ESET telemetry, Gazer infected computers in several countries around the world, but mainly in Europe. Technique, tactics and procedures ( TTPs ) correspond to the indicators that we usually observe in Turla: a backdoor of the first stage (such as Skipper ), probably delivered by targeted phishing; the appearance of a second stage backdoor in the infected system, in this case Gazer. According to our research, the main goals of Gazer are in Southeast Europe and the former Soviet republics.
We currently do not have comprehensive evidence of Gazer belonging to the Turla group, but this is indicated by a few tips. Firstly, the target objects are in the sphere of interests of Turla - the Ministry of Foreign Affairs and the Embassy. Secondly, Turla is indicated by methods - targeted phishing, installing a backdoor of the first stage, a hidden backdoor of the second stage. In most cases, along with Gazer, a Skipper first stage backdoor is found, also associated with Turla. Thirdly, there are a number of similarities between Gazer and other second-stage backdoors used by Turla, such as Carbon and Kazuar .
As usual, Turla strives to avoid tool discovery by safely deleting files, changing lines, and randomizing. In the last studied version, Gazer authors modified most of the lines by adding video game related sentences to the code. An example in the figure below:
Gazer is written in C ++ and has similarities with other Turla tools. Backdoors Gazer, Carbon and Kazuar receive encrypted tasks from a remote C&C server, which can be performed both on the infected system and on another machine in the network. All of them use encrypted storage for the components and configuration of the malicious program, and also record operations in a file.
The list of C&C servers is encrypted and embedded in the resources of PE Gazer. These are legitimate compromised sites (mainly on Wordpress) that act as first-level proxies. Tactics characteristic of the Turla group.
Another interesting connection is that one of the C&C servers built into the Gazer sample was used by a backdoor on JScript KopiLuwak , disassembled by Kaspersky Lab.
Last but not least. Three families of malware (Gazer, Carbon, and Kazuar) have a similar list of processes that can be used as a target for introducing a module for communication with a C & C server. The resource containing this list may vary from one sample to another. It is most likely adapted to what is installed on the system (for example, the safari.exe process appears in some samples in the list).
Gazer authors are actively using encryption. It seems that instead of the Windows Crypto API and other public libraries, they use their own library for 3DES and RSA.
The RSA keys embedded in the resources contain the attackers' public key, which is used to encrypt the data sent to the C&C server, and the private key for decrypting the resources in a binary file. Each sample has its own unique keys.
These resources are structured in the same way as RSA from OpenSSL , but their values (p, q, etc.) are calculated in the custom implementation of Gazer authors.
В разделе мы опишем в деталях компоненты Gazer — его архитектура представлена на рисунке ниже:
Загрузчик
Загрузчик – первый компонент вредоносной программы, который выполняется в системе. Два ресурса сохраняются незашифрованными в двоичном файле:
101: имя процесса, в который внедряется оркестратор
102: оркестратор
Следующий мьютекс обеспечивает выполнение только одного экземпляра вредоносной программы:
Создание именованного канала
Чтобы установить канал связи между компонентами Gazer, запущен именованный канал. Он создается из этой строки:
Шаблон FFFF-F заменяется значениями, вычисленными из идентификатора безопасности (SID) текущего пользователя и метки времени.
Рассмотрим, например, текущую дату 2017/04/24 и SID:
To create a template at the end of a named channel, the following calculations are performed: Named channel in this case: If the SID of the current user cannot be restored, the following named channel is used by default: Injecting code through a stream intercept To use the orchestrator in a remote process, the not very common method is used . An executable thread from a remote process is intercepted to run a shellcode that will execute the entry point of the communication module. 1. The module and shell code are copied to the remote process; 2. The function is used to extract the total number of threads in the target process; 3. The following operations are performed in each thread:
4. If one of the previous operations is not performed, the thread resumes and the same operations are performed in another thread. The shell code is the loader that will execute the module entry point in the new thread. Saving data The loader sends binary data through a named pipe to the orchestra. Blob contains:
When a message is received by the orchestra, the bootloader is safely deleted by overwriting the contents of the file and using the function
Persistence information is retrieved from resource 105 and stored in Gazer. Among this data, there is a value
Resource 105 is structured as follows:
There are six different data storage modes.
0: ShellAutorun
Persistence is achieved through the Windows registry by adding a Shell parameter with a value
1: HiddenTaskAutorun
Very similar to the TaskScheduler Autorun (4) method described below. The main difference is that the task is hidden from the user with the help of the attribute
2: ScreenSaverAutorun
In this mode, Gazer provides persistence by installing an executable file used as a screensaver in the Windows registry.
Most parameters are created in the registry branch
3: StartupAutorun
If resource 105 starts with a value of
The interface is
4: TaskSchedulerAutorun
The method is used to achieve persistence by creating a scheduled task.
A task is created and configured through the COM interfaces associated with tasks (
Some information, in particular, the name of the task and its description, is extracted from the resource. For example, in one of the sample resources, the data storage mode is set to 04 (
1. Task name:
2. Executable file: The
orchestra will copy the bootloader received on the named pipe in this location
3. Task description:
4. Task folder: Finally, the task is configured to start the task scheduler at any time after the scheduled time has passed. The task will be launched when the current user logs in. 5: LinkAutorun Method modifies existing LNK files to execute malware through cmd.exe. For each LNK file in the folder specified in the resource, the icon and arguments are deleted. The path to cmd.exe is specified with the argument: In most of the samples we studied, the configuration file indicates that the TaskSchedulerAutorun method should be used. Magazines
All three Gazer components write actions to log files. They are encrypted using the same algorithm - 3DES.
In some versions of Gazer, it is easy to get these files, since their names are hard-coded in binary files:
Each log file is structured as follows:
[LOGSIZE] [DECRYPTION_KEY] [ENCRYPTED_LOG]
After decryption, each log entry is formatted as follows:
| Hour: Min: Sec: Ms | [log ID] [log]
The following is an example of a decrypted orchestrator log file: Note that in older versions of Gazer, "log ID" is replaced with the name of the current function.
Using the Windows registry
All files related to Gazer (except logs) are stored in encrypted form in the registry.
The resource of the orchestrator 109 contains the root path of the vault (called in the report
If this resource is empty, the registry key is used by default. With the exception of RSA keys, all data in the storage is encrypted.
Several subdirectories are created (their names are hardcoded in binary format):
Object ID: unique ID for identifying the victim
Task Queue: linked list of tasks to be performed
Plug-ins
Communication Module: DLL for communication with the C & C server
Autorun: method for ensuring persistence
Local Transport Settings: IP addresses of computers on the same network
Last Connection: time of the last connection to the C & C server (SYSTEMTIME)
RSA Private Key: generated in the process, used to decrypt data Gazer
Result Queue: linked list of task execution results
Inject Settings: list of processes which are used to implement the communication module
C & C-servers
Using alternative data streams
If access to the registry is not available, these configuration items are saved using alternative data streams.
A function is called
The same GUIDs as above are used to hide data in ADS for a file (hardcoded in binary format): For example, here is the full path to access the object ID:
Gazer Resources Gazer-
related files are stored in the resources of the orchestra.
File Format
A total of 11 resources (101 to 111) are structured as follows:
DATATYPE | SIZE | DATA | PADDING
DATATYPE:
SIZE: data volume (blank)
Encryption
With the exception of resources 101 and 102, which are RSA keys, each resource is packed using Bzip and encrypted with 3DES.
[RSAEncryptedBlob] [SignatureBlob] [3DESBlob]
Each resource is decrypted dynamically. The signature is verified against decrypted data to verify integrity. Next, the resource will be encrypted with a new RSA key, randomly generated in the orchestrator code. The private key and encrypted resource are stored in the registry under a specific GUID subkey.
Resource List:
Task execution The task received from the C&C server is executed by an infected machine or another computer on the network through the P2P mechanism (as in Carbon and Snake).
Possible tasks:
The result is stored in the queue and will be sent to the module, which will contact the C&C server when the Internet is available.
Class hierarchy The
malware is written in C ++ and RTTI , which contains information about the objects used in the code and is not overwritten.
There are five abstract classes:
The communication module is used to extract tasks from the C&C server and transfer them to the orchestra.
The library is embedded in a process that can legitimately access the Internet. The library is the same as in the bootloader, which is used to enter the orchestra's
Initialization of communication
If a proxy server exists, it is retrieved and used by Gazer to perform HTTP requests. There are two methods to get this value:
query this registry key
Next, the system user agent is configured:
Before attempting to access the C&C server, the Internet connection is checked. The following servers are requested one after another:
Communication with a C & C server A
malicious program interacts with a C & C server to retrieve tasks (via HTTP GET requests) and send execution results (via HTTP POST requests).
Before sending a request to the server, a command is transmitted to the orchestra
Before sending a request to C&C, the CMC_GIVE_SETTINGS command is sent to the orchestra via their communication channel (named channel, more on this in the next section). The CMC_GIVE_SETTINGS message contained in the packet, in this case, is one byte set by the orchestra for the status of the result of the command.
The orchestrator answers in the same channel with the settings obtained from the working directory with the object identifier, a list of C & C servers and the date of the last connection.
To get the task from the C&C server, a GET request is executed.
GET request parameters are selected from a hard-coded list of keywords that does not look suspicious. The values are generated randomly in the encoding [a-z0-9] with a random size for each parameter:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Here are some examples of such requests: For each request (send, receive, connection ) a ten minute timeout is set with . After sending the request, the response is processed only if the returned HTTP status identifier is 404. The content of the response is encrypted and can be decrypted using the RSA private key generated by the orchestra. It contains blob and MD5 data hash. If the response size is 20 bytes (4-byte blob + hash), there are no tasks to retrieve. Command
Communications between components A
global named pipe is used to communicate between different components. Data sent through it is formatted as follows:
Figure 4.
DATATYPE message format: the same constants are used for resources (File Format section in the Resources chapter)
ID_CMD: command name (see below)
MSG: data to be sent
List of messages:
The task received from the C&C server is sent to the orchestra, which saves it in the task queue.
Delete the Gazer bootloader file, configure the bootloader copy and store it permanently in accordance with one of the resources
After receiving a message, the orchestrator will extract the result of the task from the result queue, pack it and encrypt it using the public RSA key (resource 102) and send the blob to the communication module, which will send it to the server (POST request).
The communication module sends this message to the orchestra to request information necessary for contact with the server (list of C&C servers, last connection time, victim identifier).
When the communication module sends the result of the task to the server, a message is sent to the orchestrator instructing to remove the result from the queue.
If the operation is unsuccessful (for example, if the communication module cannot correctly interpret the data received from the orchestra), a message with the last error code is sent to the orchestra. Code can be added to the log file.
Used to delete files from disk.
No operations
The command is sent to the orchestra when the communication module cannot communicate with any server. In this case, if the results of the task are in the queue, they will be encrypted and stored in the Gazer system.
The command is sent from the communication module to the orchestra every time the attackers establish communication with the controller server. Contains a SystemTime structure (with the current system time). When messages are received by the orchestra, the time of the last connection will be packed and encrypted in the Gazer repository (in the registry or in ADS).
Not implemented
Four versions of malware detected.
In the first version, the function used to record logs has the real name of the function as a parameter. There are various methods for implementing code.
In the second version, function names used as parameters are replaced by an identifier. Only one method is used for code injection.
Some samples from the first versions are signed with a valid Comodo certificate issued by Solid Loop Ltd. The compilation is dated 2002, but can be faked, since the certificate was released in 2015. Below are the certificates used to sign Gazer versions:
The latest versions are signed by another certificate - Ultimate Computer Support Ltd. Some efforts have been made to obfuscate strings that can be used as indicators of compromise. The mutex name and named pipe are no longer displayed in clear text, now it is encoded with the XOR key.
In previous versions, log file names were hard-coded in a binary file. Now, the GetTempFileNameA function is used to generate a random file name.
The latest versions collected in 2017 have different journal messages (although they have the same meaning). For example,
Finally, the fake compilation timestamp is no longer used.
A complete list of compromise indicators is available on our GitHub account . For any questions related to Turla / Gazer, write to threatintel@eset.com.
File Names: Registry Keys: C&C: Mutexes:
Recently, the press remembered Turla hackers, which has not happened for a long time. Journalists of The Interceptrecalled the presentation of the Communication Security Establishment Office of Canada (CSE), which lists Turla operator errors. The authors of the presentation call the cybergroup MAKERSMARK, a brief summary on the slide below:
Gazer, like other Turla tools, uses advanced methods for espionage and ensuring stability in target systems. We talk about attacks using Gazer and present a technical analysis of the backdoor functionality.
Summary
According to ESET telemetry, Gazer infected computers in several countries around the world, but mainly in Europe. Technique, tactics and procedures ( TTPs ) correspond to the indicators that we usually observe in Turla: a backdoor of the first stage (such as Skipper ), probably delivered by targeted phishing; the appearance of a second stage backdoor in the infected system, in this case Gazer. According to our research, the main goals of Gazer are in Southeast Europe and the former Soviet republics.
We currently do not have comprehensive evidence of Gazer belonging to the Turla group, but this is indicated by a few tips. Firstly, the target objects are in the sphere of interests of Turla - the Ministry of Foreign Affairs and the Embassy. Secondly, Turla is indicated by methods - targeted phishing, installing a backdoor of the first stage, a hidden backdoor of the second stage. In most cases, along with Gazer, a Skipper first stage backdoor is found, also associated with Turla. Thirdly, there are a number of similarities between Gazer and other second-stage backdoors used by Turla, such as Carbon and Kazuar .
As usual, Turla strives to avoid tool discovery by safely deleting files, changing lines, and randomizing. In the last studied version, Gazer authors modified most of the lines by adding video game related sentences to the code. An example in the figure below:
Similarities to other Turla tools
Gazer is written in C ++ and has similarities with other Turla tools. Backdoors Gazer, Carbon and Kazuar receive encrypted tasks from a remote C&C server, which can be performed both on the infected system and on another machine in the network. All of them use encrypted storage for the components and configuration of the malicious program, and also record operations in a file.
The list of C&C servers is encrypted and embedded in the resources of PE Gazer. These are legitimate compromised sites (mainly on Wordpress) that act as first-level proxies. Tactics characteristic of the Turla group.
Another interesting connection is that one of the C&C servers built into the Gazer sample was used by a backdoor on JScript KopiLuwak , disassembled by Kaspersky Lab.
Last but not least. Three families of malware (Gazer, Carbon, and Kazuar) have a similar list of processes that can be used as a target for introducing a module for communication with a C & C server. The resource containing this list may vary from one sample to another. It is most likely adapted to what is installed on the system (for example, the safari.exe process appears in some samples in the list).
Custom encryption
Gazer authors are actively using encryption. It seems that instead of the Windows Crypto API and other public libraries, they use their own library for 3DES and RSA.
The RSA keys embedded in the resources contain the attackers' public key, which is used to encrypt the data sent to the C&C server, and the private key for decrypting the resources in a binary file. Each sample has its own unique keys.
These resources are structured in the same way as RSA from OpenSSL , but their values (p, q, etc.) are calculated in the custom implementation of Gazer authors.
Global architecture
В разделе мы опишем в деталях компоненты Gazer — его архитектура представлена на рисунке ниже:
Загрузчик
Загрузчик – первый компонент вредоносной программы, который выполняется в системе. Два ресурса сохраняются незашифрованными в двоичном файле:
101: имя процесса, в который внедряется оркестратор
102: оркестратор
Следующий мьютекс обеспечивает выполнение только одного экземпляра вредоносной программы:
{531511FA-190D-5D85-8A4A-279F2F592CC7}
Создание именованного канала
Чтобы установить канал связи между компонентами Gazer, запущен именованный канал. Он создается из этой строки:
\\\\.\\pipe\\Winsock2\\CatalogChangeListener-FFFF-F
Шаблон FFFF-F заменяется значениями, вычисленными из идентификатора безопасности (SID) текущего пользователя и метки времени.
Рассмотрим, например, текущую дату 2017/04/24 и SID:
S-1-5-21-84813077-3085987743-2510664113-1000
To create a template at the end of a named channel, the following calculations are performed: Named channel in this case: If the SID of the current user cannot be restored, the following named channel is used by default: Injecting code through a stream intercept To use the orchestrator in a remote process, the not very common method is used . An executable thread from a remote process is intercepted to run a shellcode that will execute the entry point of the communication module. 1. The module and shell code are copied to the remote process; 2. The function is used to extract the total number of threads in the target process; 3. The following operations are performed in each thread:
time = SystemTime.wDay * Systemtime.wMonth * SystemTime.wYear = 24 * 04 * 2017 = 0x2f460
xsid = (1 * 21 * 84813077 * 3085987743 * 2510664113 * 1000) & 0xFFFFFFFF = 0xefa252d8
((time >> 20) + (time & 0xFFF) + ((time >> 12) & 0xFFF)) % 0xFF = 0x93
((xsid >> 20) + (xsid & 0xFFF) + ((xsid >> 12) & 0xFFF)) % 0xFF = 0x13
((time * xsid >> 24) + (uint8_t)(time * xsid) + ((uint16_t)(time * xsid) >> 8) + (uint8_t)(time * xsid >> 16)) % 0xf) = 0xa
\\\\.\\pipe\\Winsock2\\CatalogChangeListener-9313-a
\\\\.\\pipe\\\Winsock2\\CatalogChangeListener-FFFE-D
ZwQuerySystemInformation
- thread suspended by function
OpenThread/SuspendThread
; - thread context is retrieved using
GetThreadContext
; - the flow instruction pointer is stored and modified to point to the shell code (via
SetThreadContext
); - stream resumes using
ResumeThread
.
4. If one of the previous operations is not performed, the thread resumes and the same operations are performed in another thread. The shell code is the loader that will execute the module entry point in the new thread. Saving data The loader sends binary data through a named pipe to the orchestra. Blob contains:
launcher:
push rax
sub rsp, 38h
movabs rax, 5D20092 ; @ end of payload
mov qword ptr ss:[rsp+28], rax ; lpThreadId
mov qword ptr ss:[rsp+20], 0 ; dwCreationFlags
xor r9d, r9d ; lpParameter
movabs r8, 5D20046 ; lpStartAddress => @payload
xor edx, edx ; dwStackSize = 0
xor ecx, ecx ; lpThreadAttributes = NULL
call qword ptr ds:[CreateThread]
movabs rax, 90A7FACE90A7FACE ; replaced by the saved instruction pointer from thread context ;)
add rsp, 38h
xchg qword ptr ss:[rsp], rax
ret
payload:
sub rsp, 28
movabs r8, 5D20096
mov edx, 1
movabs rcx, 4000000000000000
call qword ptr ds: [DllEntryPoint]
xor ecx, ecx
call ExitThread
int 3
xxxx; @DllEntryPoint
xxxx ; @CreateThread
xxxx; @ExitThread
xxxx
xxxx
xxxx
xxxx ; TID
- team id:
CMC_TAKE_LOADER_BODY
- bootloader file path
- PE bootloader
When a message is received by the orchestra, the bootloader is safely deleted by overwriting the contents of the file and using the function
DeleteFile
. Persistence information is retrieved from resource 105 and stored in Gazer. Among this data, there is a value
dword
that is used to select the data storage mode. Resource 105 is structured as follows:
- value
dword
indicates data storage mode - value
dword
shows the amount of data - data retention information
There are six different data storage modes.
0: ShellAutorun
Persistence is achieved through the Windows registry by adding a Shell parameter with a value
explorer.exe, %malware_pathfile%
for the following key: HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
1: HiddenTaskAutorun
Very similar to the TaskScheduler Autorun (4) method described below. The main difference is that the task is hidden from the user with the help of the attribute
TASK_FLAG_HIDDEN
(set via the method SetFlags
from the interface Itask
). 2: ScreenSaverAutorun
In this mode, Gazer provides persistence by installing an executable file used as a screensaver in the Windows registry.
Most parameters are created in the registry branch
HKCU\Control Panel\Desktop
:SCRNSAVE.exe
path to malicious executable- value
ScreenSaveActive
- 1: enable screensaver - value
ScreenSaverIsSecure
- 0: screensaver is not password protected ScreenSaveTimeout
set the value specified in the resource. Indicates how long the system remains in standby mode before starting the screensaver (in this case, malware).
3: StartupAutorun
If resource 105 starts with a value of
dword
3, an LNK file will be created in the Start menu. The resource also provides a shortcut file description, path and file name for LNK. The interface is
IshellLink
used to create a shell reference. 4: TaskSchedulerAutorun
The method is used to achieve persistence by creating a scheduled task.
A task is created and configured through the COM interfaces associated with tasks (
ITaskService, ITaskSettings, …
). Some information, in particular, the name of the task and its description, is extracted from the resource. For example, in one of the sample resources, the data storage mode is set to 04 (
TaskSchedulerAutorun
) with data:
In this example, a scheduled task is created and configured as follows:%APPDATA%\Adobe\adobeup.exe Adobe Acrobat Reader Updater. This task was generated by Adobe Systems, Inc to keep your Adobe Software up-to-data. \Adobe\AcrobatReader.Adobe
1. Task name:
"Adobe Acrobat Reader Updater"
2. Executable file: The
"%APPDATA%\Adobe\adobeup.exe"
orchestra will copy the bootloader received on the named pipe in this location
3. Task description:
"Задача создана Adobe Systems, Inc для обновлений вашего программного обеспечения Adobe"
4. Task folder: Finally, the task is configured to start the task scheduler at any time after the scheduled time has passed. The task will be launched when the current user logs in. 5: LinkAutorun Method modifies existing LNK files to execute malware through cmd.exe. For each LNK file in the folder specified in the resource, the icon and arguments are deleted. The path to cmd.exe is specified with the argument: In most of the samples we studied, the configuration file indicates that the TaskSchedulerAutorun method should be used. Magazines
\Adobe\AcrobatReader.Adobe
/q /c start "%s" && start "%s"
All three Gazer components write actions to log files. They are encrypted using the same algorithm - 3DES.
In some versions of Gazer, it is easy to get these files, since their names are hard-coded in binary files:
%TEMP%\CVRG72B5.tmp.cvr
: bootloader logs%TEMP%\CVRG1A6B.tmp.cvr
: orchestra magazines%TEMP%\CVRG38D9.tmp.cvr
: communication module logs
Each log file is structured as follows:
[LOGSIZE] [DECRYPTION_KEY] [ENCRYPTED_LOG]
- logsize: when this value (2 bytes) is subtracted from the magic number 0xf18b, we get the size of the encrypted log.
- decryption_key: when this 12-byte blob is encrypted using ХОР with another hard-coded key of 12 bytes, we get a 3DES key that can be used to decrypt the log
- encrypted_log: the log is encrypted using the 3DES algorithm in CBC mode
After decryption, each log entry is formatted as follows:
| Hour: Min: Sec: Ms | [log ID] [log]
The following is an example of a decrypted orchestrator log file: Note that in older versions of Gazer, "log ID" is replaced with the name of the current function.
|10:29:56:197| [1556]
|10:29:56:197| [1557] ******************************************************************************************
|10:29:56:197| [1558] DATE: 25.05.2017
|10:29:56:197| [1559] PID=900 TID=2324 Heaps=32 C:\Windows\Explorer.EXE
|10:29:56:197| [1565] DLL_PROCESS_ATTACH
|10:29:56:197| [1574] 4164
|10:29:58:197| [0137] ==========================================================================
|10:29:58:197| [0138] Current thread = 2080
|10:29:58:197| [0183] Heap aff0000 [34]
|10:29:58:197| [0189] ### PE STORAGE ###
|10:29:58:197| [0215] ### PE CRYPTO ###
|10:29:58:197| [0246] ### EXTERNAL STORAGE ###
|10:29:58:197| [1688] Ok
|10:29:58:197| [0279] Path = \HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ScreenSaver
|10:29:58:197| [0190] \HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ScreenSaver
|10:29:58:197| [0338] ---FAILED
|10:29:58:197| [0346] Initializing standart reg storage...
|10:29:58:197| [0190] Software\Microsoft\Windows\CurrentVersion\Explorer\ScreenSaver
|10:29:58:197| [2605] Storage is empty!
|10:29:58:197| [0392] ### EXTERNAL CRYPTO ###
|10:29:59:666| [1688] Ok
|10:29:59:713| [1473] Ok
|10:29:59:760| [1688] Ok
|10:29:59:775| [1473] Ok
|10:29:59:775| [1688] Ok
|10:29:59:775| [1473] Ok
|10:29:59:791| [1688] Ok
|10:29:59:791| [1473] Ok
|10:29:59:806| [1688] Ok
|10:29:59:806| [1473] Ok
|10:29:59:806| [0270] 08-00-27-90-05-2A
|10:29:59:806| [0286] _GETSID_METHOD_1_
|10:29:59:806| [0425] 28 7 8 122
|10:29:59:806| [0463] S-1-5-21-84813077-3085987743-2510664113-1000
|10:29:59:806| [0471]
|10:29:59:806| [0787] Ok
|10:29:59:806| [1473] Ok
|10:29:59:822| [0514] ### QUEUES ###
|10:29:59:822| [0370] T Empty
|10:29:59:822| [0482] R Empty
|10:29:59:822| [1754] Ok
|10:29:59:822| [1688] Ok
|10:29:59:822| [1473] Ok
|10:29:59:838| [0505] R #4294967295 PR_100 TR_00000000 SZ_172 SC_0(50) --+- EX_0
|10:29:59:838| [0625] ### TRANSPORT ###
|10:29:59:838| [0286] _GETSID_METHOD_1_
|10:29:59:838| [0425] 28 7 25 122
|10:29:59:838| [0463] S-1-5-21-84813077-3085987743-2510664113-1000
|10:29:59:838| [0471]
|10:29:59:838| [0165] \\.\pipe\Winsock2\CatalogChangeListener-2313-4
|10:29:59:838| [0131] PipeName = \\.\pipe\Winsock2\CatalogChangeListener-2313-4
|10:29:59:838| [0041] true
[...]
Working directory
Using the Windows registry
All files related to Gazer (except logs) are stored in encrypted form in the registry.
The resource of the orchestrator 109 contains the root path of the vault (called in the report
%RootStoragePath%
). In each sample we examined, this resource pointed to the same storage path: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ScreenSaver
If this resource is empty, the registry key is used by default. With the exception of RSA keys, all data in the storage is encrypted.
Several subdirectories are created (their names are hardcoded in binary format):
%RootStoragePath%{119D263D-68FC-1942-3CA3-46B23FA652A0}
Object ID: unique ID for identifying the victim
%RootStoragePath%{1DC12691-2B24-2265-435D-735D3B118A70}
Task Queue: linked list of tasks to be performed
%RootStoragePath%{28E74BDA-4327-31B0-17B9-56A66A818C1D}
Plug-ins
%RootStoragePath%{31AC34A1-2DE2-36AC-1F6E-86F43772841F}
Communication Module: DLL for communication with the C & C server
%RootStoragePath%{3CDC155D-398A-646E-1021-23047D9B4366}
Autorun: method for ensuring persistence
%RootStoragePath%{4A3130BD-2608-730F-31A7-86D16CE66100}
Local Transport Settings: IP addresses of computers on the same network
%RootStoragePath%{56594FEA-5774-746D-4496-6361266C40D0}
Last Connection: time of the last connection to the C & C server (SYSTEMTIME)
%RootStoragePath%{629336E3-58D6-633B-5182-576588CF702A}
RSA Private Key: generated in the process, used to decrypt data Gazer
%RootStoragePath%{6CEE6FE1-10A2-4C33-7E7F-855A51733C77}
Result Queue: linked list of task execution results
%RootStoragePath%{81A03BF8-60AA-4A56-253C-449121D61CAF}
Inject Settings: list of processes which are used to implement the communication module
%RootStoragePath%{8E9810C5-3014-4678-27EE-3B7A7AC346AF}
C & C-servers
Using alternative data streams
If access to the registry is not available, these configuration items are saved using alternative data streams.
A function is called
GetVolumeInformation()
to ensure that the C: \\ drive supports named streams for using ADS.The same GUIDs as above are used to hide data in ADS for a file (hardcoded in binary format): For example, here is the full path to access the object ID:
"%TEMP%\\KB943729.log"
%TEMP%\KB943729.log:{1DC12691-2B24-2265-435D-735D3B118A70}
Orchestrator
Gazer Resources Gazer-
related files are stored in the resources of the orchestra.
File Format
A total of 11 resources (101 to 111) are structured as follows:
DATATYPE | SIZE | DATA | PADDING
DATATYPE:
dword
defines the data type of the resource:- 0: primary data
- 0xFFFFFFFF: empty
- 0x4: not defined
- 0x1030001: array of strings
- 0x1: binary format
SIZE: data volume (blank)
Encryption
With the exception of resources 101 and 102, which are RSA keys, each resource is packed using Bzip and encrypted with 3DES.
[RSAEncryptedBlob] [SignatureBlob] [3DESBlob]
- RSAEncryptedBlob: The first 1024 bits of data is a blob that contains the 3DES key. Blob is encrypted using RSA and can be decrypted using resource 101.
- SignatureBlob: the second piece of data is a 1024-bit blob containing the signature of the last piece of data that has been decrypted.
- 3DESBlob: the last part is the actual data that is encrypted with the 3DES key from the first blob.
Each resource is decrypted dynamically. The signature is verified against decrypted data to verify integrity. Next, the resource will be encrypted with a new RSA key, randomly generated in the orchestrator code. The private key and encrypted resource are stored in the registry under a specific GUID subkey.
Resource List:
- 101: the resource contains a private RSA key. It is used to decrypt other resources.
- 102: RSA public key.
- 103: empty
- 104: not defined
- 105: data storage information
- 106: list of processes that are used to implement a communication module
- 107: DLL for communicating with C&C servers
- 108: list of C & C servers
- 109: path to the Gazer working directory
- 110: plugin list
- 111: local data transfer information
Task execution The task received from the C&C server is executed by an infected machine or another computer on the network through the P2P mechanism (as in Carbon and Snake).
Possible tasks:
- send file
- upload file
- update configuration
- execute command
The result is stored in the queue and will be sent to the module, which will contact the C&C server when the Internet is available.
Class hierarchy The
malware is written in C ++ and RTTI , which contains information about the objects used in the code and is not overwritten.
There are five abstract classes:
Communication module
The communication module is used to extract tasks from the C&C server and transfer them to the orchestra.
The library is embedded in a process that can legitimately access the Internet. The library is the same as in the bootloader, which is used to enter the orchestra's
explorer.exe
. Initialization of communication
If a proxy server exists, it is retrieved and used by Gazer to perform HTTP requests. There are two methods to get this value:
query this registry key
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings
or use a function InternetQueryOption
with a sign INTERNET_OPTION_PROXY
if the proxy server cannot be obtained through the registry. Next, the system user agent is configured:
- retrieves the value of the User Agent data key for the key
HKCU\Software\Microsoft\Windows\Current Version\Internet Settings
; - The key values in the section are listed
HKLM\Software\Microsoft\Windows\Current Version\Internet Settings\5.0\User Agent\Post Platform
; those that have IEAK data are connected to a user agent; - if no user agent is found in the registry, hardcoded UA is used
Mozilla/4.0 (compatible; MSIE 6.0)
Before attempting to access the C&C server, the Internet connection is checked. The following servers are requested one after another:
update.microsoft.com
microsoft.com
windowsupdate.microsoft.com
yahoo.com
google.com
Communication with a C & C server A
malicious program interacts with a C & C server to retrieve tasks (via HTTP GET requests) and send execution results (via HTTP POST requests).
Before sending a request to the server, a command is transmitted to the orchestra
CMC_GIVE_SETTINGS
through a communication channel (named channel, more in the next section). The message ( MSG
) contained in the packet, in this case, is one byte set by the orchestra for status Before sending a request to C&C, the CMC_GIVE_SETTINGS command is sent to the orchestra via their communication channel (named channel, more on this in the next section). The CMC_GIVE_SETTINGS message contained in the packet, in this case, is one byte set by the orchestra for the status of the result of the command.
The orchestrator answers in the same channel with the settings obtained from the working directory with the object identifier, a list of C & C servers and the date of the last connection.
To get the task from the C&C server, a GET request is executed.
GET request parameters are selected from a hard-coded list of keywords that does not look suspicious. The values are generated randomly in the encoding [a-z0-9] with a random size for each parameter:
•
id
[6-12] •
hash
[10-15] •
session
[10-15] •
photo
[6-10] •
video
[6-10] •
album
[6-10] •
client
[5-10] •
key
[5-10] •
account
[6-12] •
member
[6-12] •
partners
[5-10] •
adm
[6-12] •
author
[6-12] •
contact
[6-12] •
content
[6-12] •
user
[6-12] Here are some examples of such requests: For each request (send, receive, connection ) a ten minute timeout is set with . After sending the request, the response is processed only if the returned HTTP status identifier is 404. The content of the response is encrypted and can be decrypted using the RSA private key generated by the orchestra. It contains blob and MD5 data hash. If the response size is 20 bytes (4-byte blob + hash), there are no tasks to retrieve. Command
xxx.php?album=2ildzq&key=hdr2a&partners=d2lic33f&session=nurvxd2x0z8bztz&video=sg508tujm&photo=4d4idgk
xxx.php?photo=he29zms5fc&user=hvbc2a&author=xvfj5r0q9c&client=7mvvc&partners=t4mgmuy&adm=lo3r6v4
xxx.php?member=ectwzo820&contact=2qwi15&album=f1qzoxuef4&session=x0z8bztz8hrs65f&id=t3x0ftu9
xxx.php?partners=ha9hz9sn12&hash=5740kptk3acmu&album=uef4nm5d&session=dpeb67ip65f&member=arj6x3ljj
xxx.php?video=nfqsz570&client=28c7lu2&partners=818eguh70&contact=ibj3xch&content=1udm9t799ixr&session=5fjjt61qred9uo
InternetSetOption
CMC_TAKE_TASK
It is sent to the orchestrator with an encrypted task received from the C&C server and its size. The orchestra will be responsible for completing the task and will send the results to the communication module. The result of the execution (encrypted by the orchestra) will be transmitted to the C & C server using the POST request in the same way as for the GET request (using parameters with random values). Communications between components A
global named pipe is used to communicate between different components. Data sent through it is formatted as follows:
Figure 4.
DATATYPE message format: the same constants are used for resources (File Format section in the Resources chapter)
ID_CMD: command name (see below)
MSG: data to be sent
List of messages:
CMC_TAKE_TASK (ID_CMD: 1)
The task received from the C&C server is sent to the orchestra, which saves it in the task queue.
CMC_TAKE_LOADER_BODY (ID_CMD: 2)
Delete the Gazer bootloader file, configure the bootloader copy and store it permanently in accordance with one of the resources
CMC_GIVE_RESULT (ID_CMD: 4)
After receiving a message, the orchestrator will extract the result of the task from the result queue, pack it and encrypt it using the public RSA key (resource 102) and send the blob to the communication module, which will send it to the server (POST request).
CMC_GIVE_SETTINGS (ID_CMD: 5)
The communication module sends this message to the orchestra to request information necessary for contact with the server (list of C&C servers, last connection time, victim identifier).
CMC_TAKE_CONFIRM_RESULT (ID_CMD: 6)
When the communication module sends the result of the task to the server, a message is sent to the orchestrator instructing to remove the result from the queue.
CMC_TAKE_CAN_NOT_WORK (ID_CMD: 7)
If the operation is unsuccessful (for example, if the communication module cannot correctly interpret the data received from the orchestra), a message with the last error code is sent to the orchestra. Code can be added to the log file.
CMC_TAKE_UNINSTALL (ID_CMD: 8)
Used to delete files from disk.
CMC_TAKE_NOP (ID_CMD: 9)
No operations
CMC_NO_CONNECT_TO_GAZER (ID_CMD: 0xA)
The command is sent to the orchestra when the communication module cannot communicate with any server. In this case, if the results of the task are in the queue, they will be encrypted and stored in the Gazer system.
CMC_TAKE_LAST_CONNECTION (ID_CMD: 0xB)
The command is sent from the communication module to the orchestra every time the attackers establish communication with the controller server. Contains a SystemTime structure (with the current system time). When messages are received by the orchestra, the time of the last connection will be packed and encrypted in the Gazer repository (in the registry or in ADS).
CMC_GIVE_CACHE / CMC_TAKE_CACHE (ID_CMD: 0xC / 0xD)
Not implemented
Gazer Versions
Four versions of malware detected.
In the first version, the function used to record logs has the real name of the function as a parameter. There are various methods for implementing code.
In the second version, function names used as parameters are replaced by an identifier. Only one method is used for code injection.
Some samples from the first versions are signed with a valid Comodo certificate issued by Solid Loop Ltd. The compilation is dated 2002, but can be faked, since the certificate was released in 2015. Below are the certificates used to sign Gazer versions:
The latest versions are signed by another certificate - Ultimate Computer Support Ltd. Some efforts have been made to obfuscate strings that can be used as indicators of compromise. The mutex name and named pipe are no longer displayed in clear text, now it is encoded with the XOR key.
In previous versions, log file names were hard-coded in a binary file. Now, the GetTempFileNameA function is used to generate a random file name.
The latest versions collected in 2017 have different journal messages (although they have the same meaning). For example,
PE STORAGE
replaced by EXE SHELTER
, PE CRYPTO
on EXE CIPHER
, etc. Finally, the fake compilation timestamp is no longer used.
A complete list of compromise indicators is available on our GitHub account . For any questions related to Turla / Gazer, write to threatintel@eset.com.
IoCs
File Names: Registry Keys: C&C: Mutexes:
%TEMP%\KB943729.log
%TEMP%\CVRG72B5.tmp.cvr
%TEMP%\CVRG1A6B.tmp.cvr
%TEMP%\CVRG38D9.tmp.cvr
%TEMP%\~DF1E06.tmp
%HOMEPATH%\ntuser.dat.LOG3
%HOMEPATH%\AppData\Local\Adobe\AdobeUpdater.exe
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ScreenSaver
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Explorer\ScreenSaver
daybreakhealthcare.co.uk/wp-includes/themees.php
simplecreative.design/wp-content/plugins/calculated-fields-form/single.php
169.255.137.203/rss_0.php
outletpiumini.springwaterfeatures.com/wp-includes/pomo/settings.php
zerogov.com/wp-content/plugins.deactivate/paypal-donations/src/PaypalDonations/SimpleSubsribe.
php
ales.ball-mill.es/ckfinder/core/connector/php/php4/CommandHandler/CommandHandler.php
dyskurs.com.ua/wp-admin/includes/map-menu.php
warrixmalaysia.com.my/wp-content/plugins/jetpack/modules/contact-form/grunion-table-form.php
217.171.86.137/config.php
217.171.86.137/rss_0.php
shinestars-lifestyle.com/old_shinstar/includes/old/front_footer.old.php
www.aviasiya.com/murad.by/life/wp-content/plugins/wp-accounting/inc/pages/page-search.php
baby.greenweb.co.il/wp-content/themes/san-kloud/admin.php
soligro.com/wp-includes/pomo/db.php
giadinhvabe.net/wp-content/themes/viettemp/out/css/class.php
tekfordummies.com/wp-content/plugins/social-auto-poster/includes/libraries/delicious/Delicious.php
kennynguyen.esy.es/wp-content/plugins/wp-statistics/vendor/maxmind-db/reader/tests/MaxMind/Db/
test/Reader/BuildTest.php
sonneteck.com/wp-content/plugins/yith-woocommerce-wishlist/plugin-fw/licence/templates/panel/
activation/activation.php
chagiocaxuanson.esy.es/wp-content/plugins/nextgen-gallery/products/photocrati_nextgen/modules/
ngglegacy/admin/templates/manage_gallery/gallery_preview_page_field.old.php
hotnews.16mb.com/wp-content/themes/twentysixteen/template-parts/content-header.php
zszinhyosz.pe.hu/wp-content/themes/twentyfourteen/page-templates/full-hight.php
weandcats.com/wp-content/plugins/broken-link-checker/modules/checkers/http-module.php
{531511FA-190D-5D85-8A4A-279F2F592CC7}