Gazer: backdoor of the second stage of the ART group Turla
ESET analyzed the new, previously undocumented backdoor, which is most likely used by the ART group Turla. 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 methods of Turla hackers are watering hole attacks and targeted phishing. The new backdoor has been actively used since at least 2016. Based on the lines found in the studied samples, we called it Gazer.
Recently, the press remembered the hackers Turla, which has not happened for a long time. The Intercept reporters recalled the presentation of the Office of Communications Protection Canada (CSE - Communication Security Establishment), which lists the errors of Turla operators. The presentation authors call the MAKERSMARK cyber group, a summary on the slide below:
')
Gazer, like other Turla tools, uses advanced methods of espionage and sustainability in target systems. We talk about attacks using Gazer and present a technical analysis of the functionality of the backdoor.
According to ESET telemetry, Gazer infected computers in several countries around the world, but mainly in Europe. The techniques, tactics and procedures ( TTPs ) correspond to the indicators that we usually see in Turla: the first stage backdoor (such as the Skipper ), probably delivered by targeted phishing; the appearance of the second stage backdoor in the infected system, in this case Gazer. According to our research, the main goals of Gazer are in South-Eastern Europe and the former Soviet republics.
Currently, we do not have exhaustive evidence of Gazer’s belonging to the Turla group, but several clues indicate this. First, the targets correspond to the area of ​​interest of Turla - the ministry of foreign affairs and the embassy. Secondly, Turla is indicated by methods - targeted phishing, installation of the backdoor of the first stage, hidden backdoor of the second stage. In most cases, along with Gazer, the backdoor of the first stage Skipper, also associated with Turla, is found. Thirdly, there are a number of common features of Gazer and other second-stage backdoors used by Turla, such as Carbon and Kazuar .
As usual, the Turla team seeks to avoid detecting tools by safely deleting files, changing strings, and randomizing. In the last version studied, the authors of Gazer modified most of the lines by adding sentences related to video games to the code. The example in the figure below:
Gazer is written in C ++ and has common features with other Turla tools. Gazer, Carbon and Kazuar backdoors receive encrypted tasks from a remote C & C server that can be performed on the infected system or on another machine on the network. All of them use encrypted storage for malware components and configuration, and also record operations in a file.
The list of C & C servers is encrypted and built into the resources of PE Gazer. These are legitimate compromised sites (mostly on Wordpress), which act as a first-level proxy. Tactics are typical for the Turla group.
Another interesting connection is that one of the C & C servers built into the Gazer sample was used by the backdoor in JScript KopiLuwak , which was disassembled by Kaspersky Lab.
Last but not least. The three families of malicious programs (Gazer, Carbon and Kazuar) have a similar list of processes that can be used as a target for implementing a module for communicating with a C & C server. A 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, in some samples the safari.exe process appears 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 attacker's public key, which is used to encrypt data sent to the C & C server and the private key to decrypt 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 a custom implementation of the authors Gazer.
In the section we describe in detail the components of Gazer - its architecture is shown in the figure below:
Loader
The loader is the first component of the malware that runs on the system. Two resources are stored unencrypted in a binary file:
101: name of the process in which the orchestrator is embedded
102: orchestrator
The following mutex ensures that only one instance of the malware is executed:
Creating a named pipe
To establish a communication channel between Gazer components, a named pipe has been launched. It is created from this line:
The FFFF-F pattern is replaced by the values ​​calculated from the security identifier (SID) of the current user and the timestamp.
Consider, for example, the current date 2017/04/24 and SID:
To create a pattern at the end of a named pipe, the following calculations are performed:
Named channel in this case:
If the current user’s SID cannot be recovered, the default named pipe is used by default:
Code injection through stream capture
To introduce the orchestrator into the remote process, a not too common method is used.
The executing thread from the remote process is intercepted to launch the shellcode, which will execute the entry point of the communication module.
1. The module and shellcode are copied to the remote process;
2. The
3. The following operations are performed in each stream:
4. If one of the previous operations is not performed, the flow is resumed and the same operations are performed in another flow.
The shellcode is the loader that will execute the entry point of the module in the new stream.
Saving data
The loader sends binary data through the named pipe to the orchestrator. Blob contains:
When the message is received by the orchestrator, the loader is safely removed by overwriting the contents of the file and using the
Information on persistence is extracted from resource 105 and stored in Gazer. Among these data is the value of
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 the value of
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
2: ScreenSaverAutorun
In this mode, Gazer provides persistence by installing in the Windows system registry an executable file used as a screensaver.
Most of the parameters are created in the registry branch
3: StartupAutorun
If resource 105 starts with
The
4: TaskSchedulerAutorun
The method is used to achieve persistence by creating a scheduled task.
A task is created and configured via COM-related task interfaces (
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 saving mode is set to 04 (
In this example, a scheduled task is created and configured as follows:
1. Task name:
2. Executable file:
The orchestrator will copy the bootloader obtained via the named pipe in this location.
3. Task description:
4. Task folder:
Finally, the task is configured to run by the task scheduler at any time after the scheduled one. The task will be started when the current user is logged in.
5: LinkAutorun
The 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 set with an argument:
In most of the samples we studied, the configuration file indicates that the TaskSchedulerAutorun method should be used.
Magazines
All three Gazer components record actions in log files. They are encrypted using the same algorithm - 3DES.
In some versions of Gazer, these files are easy to get, because 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]
Below is an example with the decrypted log file of the orchestrator:
Note that in older versions of Gazer, the “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 an encrypted form in the registry.
The resource of the orchestrator 109 contains the root path of the repository (in the report it is called
If this resource is empty, the registry key is used by default. With the exception of RSA keys, all data in the vault is encrypted.
Several subdirectories are created (their names are hardcoded in binary format):
Object ID: a unique ID to identify the victim
Task Queue: a linked list of running tasks
Plugins
Communication Module: DLL to communicate with the C & C server
Autorun: persistence method
Local Transport Settings: IP addresses of computers on the same network
Last Connection: time of the last connection with the C & C server (SYSTEMTIME)
RSA Private Key: generated in process, used to decrypt Gazer data
Result Queue: a linked list of task results
Inject Settings: a list of processes that are used to implement the communication module
C & C Servers
Using alternative data streams
If registry access is not available, these configuration items are retained using alternative data streams.
The
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
Files associated with Gazer are stored in the resources of the orchestrator.
File format
A total of 11 resources (from 101 to 111) are structured as follows:
DATATYPE | SIZE | DATA | Padding
DATATYPE:
SIZE: the amount of data (without filling)
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 checked against the decrypted data to verify integrity. Further, the resource will be encrypted with the new RSA key, which was randomly created in the orchestrator code. The private key and the encrypted resource are stored in the registry under a certain subkey GUID.
Resource List:
Task performance
The task received from the C & C server is performed by the 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 malicious program is written in C ++ and RTTI , which contains information about the objects used in the code, is not overwritten.
There are five abstract classes:
The communication module is used to retrieve tasks from the C & C server and transfer them to the orchestrator.
The library is being introduced into a process that can legitimately access the Internet. The library is the same as in the bootloader, which is used to enter the orchestrator in
Communication initialization
If a proxy server exists, it is retrieved and used by Gazer to execute HTTP requests. There are two methods for obtaining this value:
query this registry
Next, the system user agent is configured:
Before attempting to access the C & C server, the Internet connection is checked. One by one, the following servers are requested:
Communication with the C & C server
The malicious program interacts with the 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, the
Before sending a request for C & C, the CMC_GIVE_SETTINGS team is sent to the orchestra through their communication channel (named pipe, 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 responds in the same channel with the settings obtained from the working directory with the object identifier, the list of C & C servers and the date of the last connection.
To receive the task from the C & C server, a GET request is made.
GET request parameters are selected from a hard-coded list of keywords that does not look suspicious. Values ​​are generated randomly in [a-z0-9] encoding with a random size for each parameter:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Here are some examples of such queries:
For each request (send, receive, connect) a ten minute timeout is set using
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 a private RSA key generated by the orchestrator. It contains blob and md5 data hash.
If the response size is 20 bytes (4-byte blob + hash), there are no tasks to retrieve.
The
Messages between components
The global named pipe is used for communication between various components. Data sent through it is formatted as follows:
Figure 4. Message Format
DATATYPE: the same constants are used for resources (the File Format section in the “Resources” chapter)
ID_CMD: command name (see below)
MSG: data to send
List of messages:
The task received from the C & C server is sent to the orchestrator, which stores it in the task queue.
Delete the Gazer loader file, set up a copy of the loader and permanently store it in accordance with one of the resources
After receiving the message, the orchestrator will extract the result of the task from the results queue, package and encrypt it with the RSA public key (resource 102) and send a blob to the communication module, which will send it to the server (POST request).
The communication module sends this message to the orchestrator to request the information needed to contact the server (list of C & C servers, last connection time, victim ID).
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 fails (for example, if the communication module cannot correctly interpret the data received from the orchestrator), a message with the last error code is sent to the orchestrator. Code can be added to the log file.
Used to delete files from disk.
No operations
A team 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 saved to the Gazer system.
The team is sent from the communication module to the orchestrator each time the attackers contact the controller server. Contains a SystemTime structure (with current system time). When messages are received by the orchestrator, the time of the last connection will be packed and encrypted in the Gazer storage (in the registry or in ADS).
Not implemented
Four versions of the malware have been detected.
In the first version, the function used to write logs has the real name of the function as a parameter. There are various methods of code injection.
In the second version, the 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 may be forged since the certificate was issued in 2015. Below are the certificates used to sign Gazer versions:
Latest versions are signed with another certificate - Ultimate Computer Support Ltd. Some efforts have been made to obfuscate strings, which can be used as indicators of compromise. The name of the mutex and the named pipe are no longer displayed in clear text, it is now encoded with the XOR key.
In previous versions, the log file names were hardcoded in a binary file. Now to generate a random file name, the function GetTempFileNameA is used.
The latest versions compiled in 2017 differ in journal messages (although they have the same meaning). For example,
Finally, the fake compile time stamp is no longer used.
A complete list of compromise indicators is available in our account on GitHub. For any questions regarding Turla / Gazer, email threatintel@eset.com.
File Names:
Registry keys:
C & C:
Mutexes:
Recently, the press remembered the hackers Turla, which has not happened for a long time. The Intercept reporters recalled the presentation of the Office of Communications Protection Canada (CSE - Communication Security Establishment), which lists the errors of Turla operators. The presentation authors call the MAKERSMARK cyber group, a summary on the slide below:
')
Gazer, like other Turla tools, uses advanced methods of espionage and sustainability in target systems. We talk about attacks using Gazer and present a technical analysis of the functionality of the backdoor.
Summary
According to ESET telemetry, Gazer infected computers in several countries around the world, but mainly in Europe. The techniques, tactics and procedures ( TTPs ) correspond to the indicators that we usually see in Turla: the first stage backdoor (such as the Skipper ), probably delivered by targeted phishing; the appearance of the second stage backdoor in the infected system, in this case Gazer. According to our research, the main goals of Gazer are in South-Eastern Europe and the former Soviet republics.
Currently, we do not have exhaustive evidence of Gazer’s belonging to the Turla group, but several clues indicate this. First, the targets correspond to the area of ​​interest of Turla - the ministry of foreign affairs and the embassy. Secondly, Turla is indicated by methods - targeted phishing, installation of the backdoor of the first stage, hidden backdoor of the second stage. In most cases, along with Gazer, the backdoor of the first stage Skipper, also associated with Turla, is found. Thirdly, there are a number of common features of Gazer and other second-stage backdoors used by Turla, such as Carbon and Kazuar .
As usual, the Turla team seeks to avoid detecting tools by safely deleting files, changing strings, and randomizing. In the last version studied, the authors of Gazer modified most of the lines by adding sentences related to video games to the code. The example in the figure below:
Similarities with other Turla tools
Gazer is written in C ++ and has common features with other Turla tools. Gazer, Carbon and Kazuar backdoors receive encrypted tasks from a remote C & C server that can be performed on the infected system or on another machine on the network. All of them use encrypted storage for malware components and configuration, and also record operations in a file.
The list of C & C servers is encrypted and built into the resources of PE Gazer. These are legitimate compromised sites (mostly on Wordpress), which act as a first-level proxy. Tactics are typical for the Turla group.
Another interesting connection is that one of the C & C servers built into the Gazer sample was used by the backdoor in JScript KopiLuwak , which was disassembled by Kaspersky Lab.
Last but not least. The three families of malicious programs (Gazer, Carbon and Kazuar) have a similar list of processes that can be used as a target for implementing a module for communicating with a C & C server. A 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, in some samples the safari.exe process appears 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 attacker's public key, which is used to encrypt data sent to the C & C server and the private key to decrypt 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 a custom implementation of the authors Gazer.
Global architecture
In the section we describe in detail the components of Gazer - its architecture is shown in the figure below:
Loader
The loader is the first component of the malware that runs on the system. Two resources are stored unencrypted in a binary file:
101: name of the process in which the orchestrator is embedded
102: orchestrator
The following mutex ensures that only one instance of the malware is executed:
{531511FA-190D-5D85-8A4A-279F2F592CC7}
Creating a named pipe
To establish a communication channel between Gazer components, a named pipe has been launched. It is created from this line:
\\\\.\\pipe\\Winsock2\\CatalogChangeListener-FFFF-F
The FFFF-F pattern is replaced by the values ​​calculated from the security identifier (SID) of the current user and the timestamp.
Consider, for example, the current date 2017/04/24 and SID:
S-1-5-21-84813077-3085987743-2510664113-1000
To create a pattern at the end of a named pipe, the following calculations are performed:
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
Named channel in this case:
\\\\.\\pipe\\Winsock2\\CatalogChangeListener-9313-a
If the current user’s SID cannot be recovered, the default named pipe is used by default:
\\\\.\\pipe\\\Winsock2\\CatalogChangeListener-FFFE-D
Code injection through stream capture
To introduce the orchestrator into the remote process, a not too common method is used.
The executing thread from the remote process is intercepted to launch the shellcode, which will execute the entry point of the communication module.
1. The module and shellcode are copied to the remote process;
2. The
ZwQuerySystemInformation function ZwQuerySystemInformation used to retrieve the total number of threads executed in the target process;
3. The following operations are performed in each stream:
- thread suspended by the
OpenThread/SuspendThread; - the thread context is retrieved using
GetThreadContext; - The stream command pointer is saved and modified to point to the shellcode (via
SetThreadContext); - the thread is resumed using
ResumeThread.
4. If one of the previous operations is not performed, the flow is resumed and the same operations are performed in another flow.
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
The shellcode is the loader that will execute the entry point of the module in the new stream.
Saving data
The loader sends binary data through the named pipe to the orchestrator. Blob contains:
- team ID:
CMC_TAKE_LOADER_BODY - bootloader file path
- PE loader
When the message is received by the orchestrator, the loader is safely removed by overwriting the contents of the file and using the
DeleteFile function.
Information on persistence is extracted from resource 105 and stored in Gazer. Among these data is the value of
dword , which is used to select the mode of saving data.
Resource 105 is structured as follows:
dwordvalue indicates data saving modedwordvalue indicates the amount of data- data storage information
There are six different data storage modes.
0: ShellAutorun
Persistence is achieved through the Windows registry by adding a Shell parameter with the value of
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
TASK_FLAG_HIDDEN attribute (set via the SetFlags method from the Itask interface).
2: ScreenSaverAutorun
In this mode, Gazer provides persistence by installing in the Windows system registry an executable file used as a screensaver.
Most of the parameters are created in the registry branch
HKCU\Control Panel\Desktop :
SCRNSAVE.exepath to the malicious executable fileScreenSaveActivevalue - 1: enable screensaverScreenSaverIsSecurevalue - 0: the screensaver is not password protectedScreenSaveTimeoutset to the value specified in the resource. Indicates how long the system remains in standby mode before launching the screensaver (in this case, malware).
3: StartupAutorun
If resource 105 starts with
dword 3, an LNK file will be created in the Start menu. The resource also provides the label file description, path and file name for LNK.
The
IshellLink interface 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 via COM-related task interfaces (
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 saving mode is set to 04 (
TaskSchedulerAutorun ) with data:
%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
In this example, a scheduled task is created and configured as follows:
1. Task name:
"Adobe Acrobat Reader Updater"
2. Executable file:
"%APPDATA%\Adobe\adobeup.exe"
The orchestrator will copy the bootloader obtained via the named pipe in this location.
3. Task description:
" Adobe Systems, Inc Adobe"
4. Task folder:
\Adobe\AcrobatReader.Adobe
\Adobe\AcrobatReader.Adobe
Finally, the task is configured to run by the task scheduler at any time after the scheduled one. The task will be started when the current user is logged in.
5: LinkAutorun
The 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 set with an argument:
/q /c start "%s" && start "%s"
In most of the samples we studied, the configuration file indicates that the TaskSchedulerAutorun method should be used.
Magazines
All three Gazer components record actions in log files. They are encrypted using the same algorithm - 3DES.
In some versions of Gazer, these files are easy to get, because their names are hard-coded in binary files:
%TEMP%\CVRG72B5.tmp.cvr: bootloader logs%TEMP%\CVRG1A6B.tmp.cvr: Orchestrator Journals%TEMP%\CVRG38D9.tmp.cvr: Communications 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 HOR with another 12-byte hard-coded key, we get the 3DES key, which 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]
Below is an example with the decrypted log file of the orchestrator:
|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
[...]
Note that in older versions of Gazer, the “log ID” is replaced with the name of the current function.
Working directory
Using the Windows Registry
All files related to Gazer (except logs) are stored in an encrypted form in the registry.
The resource of the orchestrator 109 contains the root path of the repository (in the report it is called
%RootStoragePath% ). In each sample we studied, this resource indicated 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 vault is encrypted.
Several subdirectories are created (their names are hardcoded in binary format):
%RootStoragePath%{119D263D-68FC-1942-3CA3-46B23FA652A0}
Object ID: a unique ID to identify the victim
%RootStoragePath%{1DC12691-2B24-2265-435D-735D3B118A70}
Task Queue: a linked list of running tasks
%RootStoragePath%{28E74BDA-4327-31B0-17B9-56A66A818C1D}
Plugins
%RootStoragePath%{31AC34A1-2DE2-36AC-1F6E-86F43772841F}
Communication Module: DLL to communicate with the C & C server
%RootStoragePath%{3CDC155D-398A-646E-1021-23047D9B4366}
Autorun: persistence method
%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 with the C & C server (SYSTEMTIME)
%RootStoragePath%{629336E3-58D6-633B-5182-576588CF702A}
RSA Private Key: generated in process, used to decrypt Gazer data
%RootStoragePath%{6CEE6FE1-10A2-4C33-7E7F-855A51733C77}
Result Queue: a linked list of task results
%RootStoragePath%{81A03BF8-60AA-4A56-253C-449121D61CAF}
Inject Settings: a list of processes that are used to implement the communication module
%RootStoragePath%{8E9810C5-3014-4678-27EE-3B7A7AC346AF}
C & C Servers
Using alternative data streams
If registry access is not available, these configuration items are retained using alternative data streams.
The
GetVolumeInformation() function is GetVolumeInformation() to ensure that the C: \\ drive supports named streams for ADS use.
The same GUIDs as above are used to hide data in ADS for a file (hardcoded in binary format):
"%TEMP%\\KB943729.log"
For example, here is the full path to access the object ID:
%TEMP%\KB943729.log:{1DC12691-2B24-2265-435D-735D3B118A70}
Orchestrator
Gazer Resources
Files associated with Gazer are stored in the resources of the orchestrator.
File format
A total of 11 resources (from 101 to 111) are structured as follows:
DATATYPE | SIZE | DATA | Padding
DATATYPE:
dword specifies the data type of the resource:
- 0: primary data
- 0xFFFFFFFF: empty
- 0x4: not defined
- 0x1030001: array of strings
- 0x1: binary format
SIZE: the amount of data (without filling)
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 represent a blob that contains the 3DES key. Blob is encrypted using RSA and can be decrypted using resource 101.
- SignatureBlob: the second part of the data is a 1024-bit blob containing the signature of the last part of the data that was 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 checked against the decrypted data to verify integrity. Further, the resource will be encrypted with the new RSA key, which was randomly created in the orchestrator code. The private key and the encrypted resource are stored in the registry under a certain subkey GUID.
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 determined
- 105: data saving information
- 106: List of processes used to implement a communication module.
- 107: DLL for communicating with C & C servers
- 108: list of C & C servers
- 109: Gazer Work Directory Path
- 110: list of plugins
- 111: local data transfer information
Task performance
The task received from the C & C server is performed by the 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 the 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 malicious program is written in C ++ and RTTI , which contains information about the objects used in the code, is not overwritten.
There are five abstract classes:
Communication module
The communication module is used to retrieve tasks from the C & C server and transfer them to the orchestrator.
The library is being introduced into a process that can legitimately access the Internet. The library is the same as in the bootloader, which is used to enter the orchestrator in
explorer.exe .
Communication initialization
If a proxy server exists, it is retrieved and used by Gazer to execute HTTP requests. There are two methods for obtaining this value:
query this registry
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings or use the InternetQueryOption function with the INTERNET_OPTION_PROXY flag 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
HKCU\Software\Microsoft\Windows\Current Version\Internet Settingskey; - lists the key values ​​in the
HKLM\Software\Microsoft\Windows\Current Version\Internet Settings\5.0\User Agent\Post Platformsection; those that have IEAK as data are connected to a user agent; - if a user agent is not found in the registry, then
Mozilla/4.0 (compatible; MSIE 6.0)hard-coded UA is used
Before attempting to access the C & C server, the Internet connection is checked. One by one, the following servers are requested:
update.microsoft.commicrosoft.comwindowsupdate.microsoft.comyahoo.comgoogle.com
Communication with the C & C server
The malicious program interacts with the 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, the
CMC_GIVE_SETTINGS command is transmitted to the CMC_GIVE_SETTINGS via the communication channel (named pipe, more details in the next section). The message ( MSG ) contained in the packet, in this case, is the one byte set by the orchestrator for the status
Before sending a request for C & C, the CMC_GIVE_SETTINGS team is sent to the orchestra through their communication channel (named pipe, 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 responds in the same channel with the settings obtained from the working directory with the object identifier, the list of C & C servers and the date of the last connection.
To receive the task from the C & C server, a GET request is made.
GET request parameters are selected from a hard-coded list of keywords that does not look suspicious. Values ​​are generated randomly in [a-z0-9] encoding 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 queries:
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
For each request (send, receive, connect) a ten minute timeout is set using
InternetSetOption .
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 a private RSA key generated by the orchestrator. It contains blob and md5 data hash.
If the response size is 20 bytes (4-byte blob + hash), there are no tasks to retrieve.
The
CMC_TAKE_TASK team CMC_TAKE_TASK sent to the orchestra with an encrypted task received from the C & C server and its size. The orchestrator will be responsible for the task and will send the results to the communication module. The resulting execution result (encrypted by the orchestrator) 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).
Messages between components
The global named pipe is used for communication between various components. Data sent through it is formatted as follows:
Figure 4. Message Format
DATATYPE: the same constants are used for resources (the File Format section in the “Resources” chapter)
ID_CMD: command name (see below)
MSG: data to send
List of messages:
CMC_TAKE_TASK (ID_CMD: 1)
The task received from the C & C server is sent to the orchestrator, which stores it in the task queue.
CMC_TAKE_LOADER_BODY (ID_CMD: 2)
Delete the Gazer loader file, set up a copy of the loader and permanently store it in accordance with one of the resources
CMC_GIVE_RESULT (ID_CMD: 4)
After receiving the message, the orchestrator will extract the result of the task from the results queue, package and encrypt it with the RSA public key (resource 102) and send a 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 orchestrator to request the information needed to contact the server (list of C & C servers, last connection time, victim ID).
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 fails (for example, if the communication module cannot correctly interpret the data received from the orchestrator), a message with the last error code is sent to the orchestrator. 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)
A team 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 saved to the Gazer system.
CMC_TAKE_LAST_CONNECTION (ID_CMD: 0xB)
The team is sent from the communication module to the orchestrator each time the attackers contact the controller server. Contains a SystemTime structure (with current system time). When messages are received by the orchestrator, the time of the last connection will be packed and encrypted in the Gazer storage (in the registry or in ADS).
CMC_GIVE_CACHE / CMC_TAKE_CACHE (ID_CMD: 0xC / 0xD)
Not implemented
Versions of Gazer
Four versions of the malware have been detected.
In the first version, the function used to write logs has the real name of the function as a parameter. There are various methods of code injection.
In the second version, the 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 may be forged since the certificate was issued in 2015. Below are the certificates used to sign Gazer versions:
Latest versions are signed with another certificate - Ultimate Computer Support Ltd. Some efforts have been made to obfuscate strings, which can be used as indicators of compromise. The name of the mutex and the named pipe are no longer displayed in clear text, it is now encoded with the XOR key.
In previous versions, the log file names were hardcoded in a binary file. Now to generate a random file name, the function GetTempFileNameA is used.
The latest versions compiled in 2017 differ in journal messages (although they have the same meaning). For example,
PE STORAGE replaced by EXE SHELTER , PE CRYPTO to EXE CIPHER and others.
Finally, the fake compile time stamp is no longer used.
A complete list of compromise indicators is available in our account on GitHub. For any questions regarding Turla / Gazer, email threatintel@eset.com.
Iocs
File Names:
%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
Registry keys:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ScreenSaver
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Explorer\ScreenSaver
C & C:
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
Mutexes:
{531511FA-190D-5D85-8A4A-279F2F592CC7}Source: https://habr.com/ru/post/336804/
All Articles