Following the Turla’s Skipper over the ocean of cyber operations

In the middle of May 2019 new malware variants identified to be part of Turla suite comes into light.

Turla, also known as Snake or Uroburos is one of the most advanced threat actor in the cyber operations landscape. The full malicious set retrieved can be referred to a campaign started in the second half of 2018 and likely aimed at compromise government entities and high-level diplomatic institutions.

The average number of variants found in conjunction sometime with low detection rates as well as the nature of targeted entities confirm the “APT” nature of the actor and its ability to remain in the shadows for a long time.

It has been also noted that the suite under analysis has been updated and maintained over the time in relation to the first variants found that we can date back to 2015. The main features being updated over the time are those dedicated to maintain a low level of detection as well as those dedicated to the interaction between processes and the modularity of the entire malicious solution.

Our analysis focuses on one representative Skipper implanter and its main
orchestrator. Although we are not yet sure about the initial infection vector of this specific malicios components, it is possible to hypothesize that they were delivered by spear-phishing e-mail messages.

Insights

The Turla “Skipper” suite has been designed to work through different modules in order to execute a first system recognition and a threat persistence phase on the basis of the following semplified scheme:

Generally speaking, it can be categorized as a first-stage backdoor capable of performing various actions within the victim system. Its main purpose, therefore, is to facilitate the intrusion of further malicious components.

In this case our analysis started with an SFX armed archive designed to launch the main malware module. This is a publicly available and referenced malware.

Quite interesting to note the comment inside this in addition to the execution instructions

In the “comment” area of the archive it’s possibile to find the string “Расположенный ниже комментарий содержит команды SFX-сценария” that translated from russian means “The comment below contains SFX script commands“.

Once opened, this starts wds.exe under %appdata%\Microsoft\winword\addons\.

wds.exe is main malware module designed to work primarly through 4 main functions according to the following image

The first performed actions are aimed at ensuring a persistent execution of the code within the victim system through scheduling tasks and modifing RegKeys.

The backdoor works by calling CreateProcess function in order to execute the command

schtasks /create /SC DAILY /TN update /F /TR %APPDATA%\Roaming\Microsoft\WinWord\Addons\wds.exe, null

Internally some strings decryption routines (supported by RC4 cryptographic cycles) help to evade local security solutions.

As mentioned, the module can also work with registry keys to ensure that the backdoor is reloaded on reboot. It modifies

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

and

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows

writing respectively the values MSCTF and Load filling them with the wds.exe working path.

A set of instructions aimed at system reconnaissance and at the collection of local information regarding the current host configuration is then performed.

The malware calls CreateProcess function to start cmd.exe and executing the /c Systeminfo command relying on pipes for inter-process communications. The amount of information it can find is quite substantial if compared to other similar counterparts.

These information vary from the collection of system variables to the user name details, the system default language ID, the input locale identifiers, the volume information, the computer name etc. etc.

After performing these kind of operations the third main function is called.
It is has been designed to perform an enumeration of the running processes looking for its same name among the list returning from the function CreateToolhelp32Snapshot

This can be used like a sort of anti-analysis trick as well since some malware sandboxing services rename the malware before executing them.
In this regard the module presents some anti-static-analysis implementations by filling variables making use of loops and mem allocation functions.

The fourth main function can be considered the core of the malware. It has a quite complex structure and in here it goes to load further malicious features by including in its address space others malware components.

Following there is a graph relation between code snippets as observed during the analysis showing the complexity of the structure:

Downloader without Injecting

In the past the Turla “Skipper” suite made use of code injection techniques in external processes in order to execute its payload. Retrieving the PDB file name of one of its included libraries however seems that lately something has changed.

Indeed, the file name cvrt.dll (that we called, without fantasy, “communication module“) presented itself to us having its program database included (PDB).

According to Wikipedia, a Program database (PDB) is “a proprietary file format (developed by Microsoft) for storing debugging information about a program (or, commonly, program modules such as a DLL or EXE) [….] A PDB file is typically created from source files during compilation. It stores a list of all symbols in a module with their addresses and possibly the name of the file and the line on which the symbol was declared.“

The PDB file we retrieved is reported following:

PDB File Name : C:\Users\George\Desktop\for B1 30.07.2018\Downloader without injecting\Downloader without injecting\Release\dll_tranport.pdb

This could suggest us some things:

1. We have to say “Hello” to “George” for the entry into this game.
2. The dev project could be started on 30.07.2018. According to the compilation timestamp of the library [29-08-2018] this could be plausible.
3. The development of the malware variant took a month of work.
4. The original name of the project is dll_tranport.pdb [we would have expected “dll_transport”]
5. “B1” could identify a malware suite under maintenance and / or development. Based on this logic we could expect other names like “B2”, “B3” etc. etc.
6. On the basis of its dev path, the module should have the ability to communicate to the outside [“Downloader without injecting“]
7. On the basis of its dev path, the module should not be injected

In reference to this last point, indeed, we observed that this specific library is included as external resource into the primary orchestrator.

The included module can export different functions; all of them are mainly designed to support the malware suite adding the ability to communicate to the outside world. The following is the exaustive list of exported functions:

Fuction “CI” seems to be designed to validate and test the connectivity of the victim host adding a “/1” to the contacted server using “GET” method

Function “SHR” is able to handle communications with the CnC and POST data to the remote server when the backdoor is instructed to execute the “upload” command. The CnC domain name is retrieved by “CS” function.

The “CS” function is able to retrieve and validate the remote CnC. It calls further module function in order to perform the system identification to the command and control center

“SHRforCS” function is able to compose the identification requests for external communication using the HttpAddRequestHeadersA and InternetSetCookieA functions

The resulting outgoing request has at this point a rather clear characteristic; It’s composed therefore by additional headers like the “MyCookie:” and “Cookie:” ones. The “MyCookie:” header rapresents an ID of the victim system and it’s composed by the MachineGUID [retrieved by querying HKLM\Software\Microsoft\Cryptography\MachineGuid RegKey] and by the volume serial number.

After the identification is done we can observe the typical features of a reconnaissance backdoor. It can launch arbitrary commands over the victim host and download and upload files.

Commands are given by the CnC and interpreted and executed by the module itself.

The following is the User-Agent used while composing HTTP requests.

Finally, the backdoor leverages on compromised websites for CnC communications.

Conclusion

Turla is a very advanced group. It still continues to operate with advanced and custom tools relying on compromised and hijacked resources to support their operations. The group is able to rely on a wide set of malicious components; each of them is part of different malware cluster that is continuously updated and maintained.

System and network indicators of compromise, the full malware set and YARA / Snort / Sigma rules to fight infections by Turla, are available by subscribing a Telsy CTI service

For more related articles, check our blog.