ESET: Turla Mosquito backdoor used in Eastern Europe

    Turla is one of the most famous espionage cybergroups. In its arsenal is an extensive set of tools , the most advanced of which are used to set priority for attacking machines. The espionage platform is primarily Windows-oriented, but can be used for macOS and Linux using various backdoors and rootkits.

    Not so long ago, we discovered a new method of compromising workstations that Turla uses. This technique is used in attacks aimed at employees of embassies and consulates of the post-Soviet countries.


    1. Overview


    For several years, Turla used fake Adobe Flash Player installers to compromise victims. Such a vector does not require complex exploits; success depends on the degree of credulity of the user who is convinced to install the fake.

    In recent months, we have observed unusual new behavior that leads to infection with one of the Turla backdoors. Not only is it packaged in a package with a true Flash installer, it also looks like it is downloaded from adobe.com. From an end-user perspective, the remote IP address is owned by Akamai, the official content distribution network (CDN) used by Adobe to distribute its legitimate Flash Player installers. After examining the process, we found that the fake Flash installers (including the Snake backdoor installer for macOS) made a GET request to get.adobe.com URLs to exfiltrate data about new compromised machines. According to our telemetry data, the IP address was the legitimate IP address used by Adobe.

    In this report, we describe methods that could lead to similar malicious behavior. According to our data, the malware did not use legitimate updates to Adobe Flash Player and is not associated with known vulnerabilities in Adobe products. We can safely say that Adobe has not been compromised. Attackers only used the brand to deceive users.

    We also found that the Turla group used a web application hosted on Google Apps Script as a team server (C&C) for JavaScript malvari, which was downloaded by some versions of the fake Flash installer. It is obvious that attackers tend to work as quietly as possible, masking their activity in the network traffic of target organizations.

    According to telemetry, there is evidence that Turla programs have been transmitting information to get.adobe.com URLs since at least July 2016. Victims are on the territory of the former USSR. Regarding Gazer , another malware developed by Turla, its objectives are consulates and embassies of Eastern Europe. We have seen several infections in private companies, but they do not seem to be the main targets of the attack. Finally, some victims are infected with other malware that Turla owns, including ComRAT or Gazer.

    2. Why do we associate this campaign with the Turla group?


    Before analyzing unusual network connections, we will explain why we attribute this campaign to Turla.

    First, part of the fake installers of Adobe Flash Player downloads the Mosquito backdoor, which some IB companies associate with Turla.

    Secondly, some C&C servers associated with hosted backdoors use or have previously used SATCOM IP addresses related to Turla .

    Thirdly, the malware has common features with other Turla tools. The similarities include identical string obfuscation (pushing lines onto the stack and applying XOR with 0x55) and the same API resolution.

    The listed elements allow you to confidently determine the relationship of the campaign with Turla.

    3. Legitimate use of Adobe Flash and Flash-related domains


    Using fake Flash installers is not a new tactic for Turla. So, experts documented this behavior in 2014. However, in our opinion, the malware is first downloaded via HTTP from Adobe's legitimate URLs and IP. This could be confusing even for experienced users.

    3.1. Imitation distribution through adobe.com


    Since the beginning of August 2016, we have found several attempts to download the Turla installer from admdownload.adobe.com.

    At first glance, it seemed that we would see a typical trick consisting in setting the Host header of the HTTP request, while the TCP socket is installed on the IP address of the C&C server. But after deep analysis, we realized that the IP address is legitimate and belongs to Akamai, the large content delivery network (CDN) used by Adobe to distribute the legitimate Flash installer.

    Even if the executable file is downloaded from a legitimate URL (for example, http://admdownload.adobe.com/bin/live/flashplayer27_xa_install.exe), the referrer field looks changed. We saw that this field changed to http://get.adobe.com/flashplayer/download/?installer=Flash_Player, which is not like the URL pattern used by Adobe, which caused a 404 error in the request.

    It is important to note that all download attempts found in the collected data were made over HTTP, not HTTPS. This allows you to perform a wide range of attacks on the way from the user's machine to Akamai servers.

    The following section discusses potential compromise scenarios. The question of what really happened remains open. Feedback will be appreciated if you have additional information.

    3.2. Compromise hypotheses


    Figure 1 presents hypotheses that could explain how to force a user, possibly visiting a legitimate Adobe website via HTTP, to download the Turla malware.


    Figure 1. Possible interception points on the path between the potential victim's machine and the Adobe servers

    We quickly eliminated the hypothesis of an unauthorized DNS server, since the IP address corresponds to the servers used by Adobe to distribute Flash. After discussion with Adobe and based on their investigations, scenario 5 seems unlikely, since the attackers did not compromise the Flash Player download site . Thus, the following options remain:

    1) a man-in-the-middle attack (MitM) using a compromised machine on a local network,
    2) a compromised network gateway or organization proxy,
    3) an MitM attack at the Internet service provider (ISP) level,
    4) an attack on BGP routers ( Border Gateway Protocol hijacking ) to redirect traffic to Turla-controlled servers.

    3.2.1. MitM Local Attack


    Turla operators could use an already compromised machine on the victim organization network to carry out a local MitM attack. Using ARP spoofing, they could redirect traffic on the fly from the target machine to a compromised one. And although we are not aware of the availability of such tools in Turla's arsenal, they are not difficult to develop, given the technical capabilities of this group.

    However, we found many victims in different organizations. This means that Turla would have to compromise at least one computer in each of these organizations, more precisely, a computer in the subnet of its preferred target.

    3.2.2. Compromised Gateway


    This attack is similar to the previous one, but it is much more interesting for attackers - they can intercept the traffic of the entire organization without ARP spoofing, since gateways and proxies usually see all incoming and outgoing traffic between the intranet and the Internet. We do not know about the presence or absence of a tool for solving a similar problem with Turla, but their rootkit Uroburos has the ability to analyze packages. It can be installed on servers and used as a proxy to distribute tasks for infected machines that do not have a public IP address . Turla has sufficient expertise and resources to modify the Uroburos code to intercept traffic on the fly and introduce malicious components, or otherwise change unencrypted content.

    3.2.3. Provider MitM Attack


    If traffic is not intercepted before leaving the organization’s internal network, it changes later, on the way to the Adobe servers. The main access point in this segment are Internet providers. ESET previously announced the distribution of FinFisher spyware through the introduction of packages at the ISP level.

    All the victims we know are in the countries of the former USSR. They use the services of at least four Internet providers. Thus, this scenario assumes that Turla has the ability to monitor traffic in different countries or data transmission channels.

    3.2.4. Attack on BGP Routers


    If the traffic is not changed by the service provider and does not reach the Adobe servers, this means that it is redirected to another server controlled by Turla operators. This can be done by attacking BGP routers in one of the following ways.

    On the one hand, Turla operators could use the Autonomous System (AS) to advertise a prefix owned by adobe.com. In this way, traffic sent to adobe.com from locations close to those controlled by Turla AS will be sent to their server. An example of similar malicious activity was analyzed.Ripe. However, this would be quickly noticed in Adobe or in a service that performs BGP monitoring. In addition, we checked the RIPEstat statistics and did not notice any suspicious route advertisements for the Adobe IP addresses used in this campaign.

    Turla operators, on the other hand, could use their ASs to declare a shorter path than any other AS to the Adobe servers. Thus, traffic would also go through their routers and could be intercepted and changed in real time. However, most of the traffic to the Adobe servers would be redirected to an unauthorized router - such tactics are difficult to disguise and there is a chance that after the launch in August 2016, the campaign would soon be detected.

    3.2.5. Total


    Of the five scenarios presented in Figure 1, we examined only four, as we are sure that Adobe was not compromised. The attack on BGP routers and the MitM attack at the service provider level are more complex than the others. We assume that the Turla group uses a special tool installed on the local gateways of the target organizations, which allows you to intercept and modify traffic before it leaves the intranet.

    3.3. Retrieving information from get.adobe.com URLs


    After the user has downloaded and launched the fake Flash installer, the process of compromise starts. It begins with the introduction of the Turla backdoor. This may be Mosquito, a malware for 32-bit Windows, described in section 4; a malicious JavaScript file that communicates with a Google Apps Script web application described in section 5; or an unknown file downloaded from the fake address of the Adobe URL:
    http://get.adobe.com/flashplayer/download/update/[x32|x64]

    In the latter case, since there is no such URL on the Adobe server, to transfer content through it to the Turla group, you need something like MitM on the path between the compromised machines and the Adobe servers.

    Next, a query is displayed that displays information about the new compromised machine. This is a GET request athttp://get.adobe.com/stats/AbfFcBebD/q=. According to our records, Adobe uses a legitimate IP address, but the URL pattern is not similar to that used by Adobe, which causes a 404 error when requesting. Since the request is over HTTP, it is most likely that the MitM attack scripts mentioned earlier in section 3.2 are used.


    Figure 2. Code executing a request to a fake URL get.adobe.com

    base64- encoded data contains confidential information about the victim’s machine. It would be strange if she actually went to the Adobe server. Figure 3 shows an example of a decrypted report. The data includes a unique ID (the last 8 bytes of the fake installer for the Flash installer, as shown in Figure 4), a username, a list of installed security products, and an ARP table.


    Figure 3. Installation report sent to the fake URL URL get.adobe.com


    Figure 4. Unique ID at the end of the installer

    Interestingly, the Snake installer for macOS (the Turla-related backdoor) uses the same URL as in Figure 5. The information transmitted is slightly different, since it contains only the username and device name, although it is still encoded in base64. However, this behavior was not documented by Fox-IT when publishing the analysis.


    Figure 5. Code executing a request at the substitute URL get.adobe.com in the Snake installer for macOS

    Finally, the fake installer injects or downloads and then launches the legitimate Flash Player application. A legitimate installer is either built into the fake installer, or is downloaded using the following path to the Google Drive URL:https://drive.google[.]com/uc?authuser=0&id=0B_LlMiKUOIstM0RRekVEbnFfaXc&export=download

    4. Win32 backdoor analysis


    In this section, we describe samples discovered in-the-wild, mainly in 2017. We found evidence that the campaign has been going on for several years, and the 2017 samples are the result of the backdoor evolving into a file InstructionerDLL.dll. Earlier samples were less obfuscated; they contained only a backdoor DLL without a loader, which appeared in later versions. Some of the older samples have a compilation time stamp of 2009, but most likely they have been tweaked.

    4.1. Installer


    It comes as a fake Flash installer and comes with two additional components that are later flushed to disk. As explained above, we found several users who downloaded the fake Flash installer from the URL and IP used by Adobe to distribute the legitimate installer.

    4.1.1. Encryption


    In newer versions, the installer is always obfuscated, as it seems to us, using encryption. Figure 6 shows an example of a function obfuscated with this tool.


    Figure 6. Obfuscated Function

    Firstly, this encryptor widely uses fuzzy predicates along with arithmetic operations. For example, an obfuscated function calculates a number from hard-coded values ​​and then compares it in magnitude with another hard-coded value. Thus, during each execution, the flow of the process will be the same, but emulation is required to determine the right path. Therefore, the code becomes too complicated for analysis for both analysts and automated security software algorithms. This can slow down the emulation to such an extent that the object will not be scanned due to time limitations, and as a result, the indicated (if it is not obfuscated) malware will not be detected.

    Secondly, after the first stage of deobfuscation, a call to the Win32 API occursSetupDiGetClassDevs(0,0,0,0xFFFFFFFF), and the encryptor checks if the received value matches 0xE000021A. The function is usually used to obtain information about devices in the system. Although a certain value is Flags (0xFFFFFFFF)not documented, according to our tests, the resulting value always corresponds 0xE000021Ato machines on Windows 7 and Windows 10. We believe that such API requests and subsequent verification are performed to bypass sandbox mode and emulation, which perform them incorrectly.

    Thirdly, this code is divided into several fragments, which are decrypted using a special function and ordered at runtime to create PE in memory. Then it is performed using the bootloader function of the PE encoder. This PE loader contains several debugging lines, as shown in Figure 7.


    Figure 7. Debug lines in the PE loader function

    4.1.2. Installation


    After decryption, the installer searches for a subfolder %APPDATA%and drops two files into a folder with the longest path to it. When searching for such a folder, it bypasses any containing the word AVASTin the name. He then uses the name of one of the unhidden files in this folder with the cropped extension as the base name for the dumped files. If all the files in the directory are hidden, or if the directory is empty, it uses the DLL name from %WINDIR%\System32. The resettable bootloader has an extension .tlb, and the main backdoor has .pdb. Interestingly, it does not use WriteFileto reset two DLLs. Instead, it creates a file, marks it in memory, and calls it memmoveto copy the data. Perhaps this was done to circumvent hooks to WriteFilesecurity products and sandboxes.

    We also saw earlier installer options that downloaded only one file with the extension .tlb. In this case, the same file contains the bootloader and backdoor functions. DllMainselects which code to execute.

    He writes a simple unencrypted log file in %APPDATA%\kb6867.bin. The complete file is created in the same directory as these two DLLs, and has the extension .tnl.


    Figure 8. Files created in the random child directory% APPDATA%

    Then it provides persistence using the Run registry key, or intercepting COM . If the display name of the antivirus received by Windows Management Instrumentation (WMI) matches Total Security, then it adds the entry rundll32.exe[path to backdoor] StartRoutineto the branch HKCU\Software\Microsoft\Windows\CurrentVersion\Run\auto_update.

    Otherwise, it replaces the registry entry in HKCR\CLSID\{D9144DCD-E998-4ECA-AB6A-DCD83CCBA16D}\InprocServer32or HKCR\CLSID\{08244EE6-92F0-47F2-9FC9-929BAA2E7235}\InprocServer32with the path to the bootloader. These CLSID - EhStorShell.dlland ntshrui.dllaccordingly. These DLLs are legitimately launched by many processes, including explorer.exethe Windows GUI. Thus, the bootloader will be called every time it starts explorer.exe. Finally, he adds a registry entry to store the path to the original intercepted DLL and the main backdoor, as shown in Figure 9.


    Figure 9. Registry modification to ensure stability.

    The remaining CLSIDs are hard-coded in the binary, but we have not seen them used. A complete list is available in the section with indicators of compromise.

    As explained in the previous section, the installer sends some information, such as a unique sample ID, username, or ARP table, to the Adobe domain URL get.adobe.com. It also launches the real Adobe Flash installer, which can either be downloaded from Google Drive or built into the fake installer.

    Before starting the main backdoor, the installer creates an administrator account HelpAssistant(or HelpAsistantin some samples) with a password sysQ!123. LocalAccountTokenFilterPolicychanges to 1, allowing remote management actions. We believe that this account name is necessary to go unnoticed, as this name is used during a legitimate remote assistance session .

    4.2. DebugParser (launcher)


    A launcher called DebugParser.dllis called during the loading of an intercepted COM object. He is responsible for launching the main backdoor and loading the intercepted COM object. A simplified component pseudo-code is shown in Figure 10.


    Figure 10. Launch pseudo-code

    However, it uses some tricks to load the intercepted library and return to the correct address. The process is described below:

    1. Get the original return address after a legitimate call LoadLibrary. At the beginning, DllMainthe value of the ESP registry is stored. Then it checks FF 15(call operation code CALL) in ESP - 6. If present, the registry leaves the original return address.


    Figure 11. Searching for an address after calling LoadLibrary

    2. Allocate RWX memory containing the following values:


    Figure 12. Allocation of memory

    3. Go to the interception function by modifying the response address DllMain.

    4. In the interception function:
    a. calling the function that is responsible for loading ntshrui.dll(or any other intercepted library)
    b. call FreeLibraryto DebugParser.dll(backdoor loader)
    c. Navigation to the original response address before interception.

    Since the original DLL is loaded, the user will most likely not notice that the backdoor is running.

    In early versions, in which the bootloader and backdoor functions are combined in one file, it DllMainselects which code to execute, as shown in Figure 13.


    Figure 13. Loader and backdoor in the same library

    4.3. Main backdoor


    The main backdoor of this campaign CommanderDLL.dll, so named by the authors, is launched either by the bootloader described above, or directly at startup, if the selected persistence mechanism is the Run key in the registry. In both cases, the library export is called StartRoutine, as shown in Figure 14, but this export is not in the DLL export table.


    Figure 14. The DLL does not have an EXPORT Address Table in the .reloc section. An export table is created

    in the function DllMainfor its output:
    1. It creates a structure IMAGE_EXPORT_DIRECTORYwith StartRoutineas the name of a single export
    2. Copies this structure after moving the section located at the end of the PE image in memory
    3. Changes the header field of the PE containing the Relative Virtual Address (RVA) of the export table to the address of the newly created export table.

    With these changes in the library in memory, there is an export named StartRoutineas shown in Figures 15 and 16. Figure 17 is a screenshot from the Hex-Rays decompiler showing the code for the entire process of adding this export.


    Figure 15. Newly created export table.


    Figure 16. Name of the new export.


    Figure 17. The process of patching the export table.

    4.3.1. Customization


    Firstly, the module CommanderDLLdeletes the dropper file (fake Flash installer). The path is passed from the dropper through a named pipe called \\.\pipe\namedpipe. Then, in a new process, he creates a second named pipe \\.\pipe\ms32loc, and waits until another process connects to this pipe, after which the program terminates.

    Secondly, CommanderDLL configures some internal structures and stores configuration values ​​in the registry. Table 1 describes the various registry values ​​that are stored in HKCU\Software\Microsoft\[dllname].

    Table 1. Backdoor values ​​in the registry


    All registry values, except for the layout entry, are encrypted using a special algorithm, which is described in section 4.3.2.

    Thirdly, an additional C&C server address is loaded from a document stored in Google Docs(https://docs.google [.] com / uc? authuser = 0 & id = 0B_wY-Tu90pbjTDllRENWNkNma0k & export = download) . It is encrypted using the algorithm described in 4.3.2.

    4.3.1. Encryption


    The backdoor uses a special encryption algorithm. Each byte of plain text is added modulo 2 in the stream generated by a function similar to the Blum Blum Shub algorithm . For encryption or decryption, the key and the module are transferred to the encryption function.

    Different samples use different keys and modules. Some are hardcoded, some are generated during execution. Table 2 describes the various keys and modules used by malware.

    Table 2. Encryption Keys and Modules


    4.3.3. Log


    The program maintains a log file called [dllname].tnl. Interestingly, it contains a time stamp of each record, which allows you to track the chain of events occurring on a compromised machine. This may be useful for cybercriminalists. It is encrypted using the algorithm described above. The key is located after the indentation at 0x20 in the header of the log file, the module is always 0x5DEE0B89. Figure 18 describes the structure of this file.


    Figure 18. Log file structure


    Figure 19. Start of the log file

    4.3.4. C & C server data exchange and backdoor commands


    The main backdoor loop is responsible for managing the exchange of data with the C & C server and executing the commands transmitted to it. At the beginning of each of them, he is inactive for a random time period, but usually about 12 minutes.

    Request to server always uses the URL on the same scheme: https://[C&C server domain]/scripts/m/query.php?id=[base64(encrypted data)]. The user agent is hard-coded in the samples and cannot be changed:
    Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36

    This default value is used by Google Chrome 41. The structure of the parameter idis described in Figure 20.


    Figure 20. Structure of the request to the C&C server –GET request with data in the id parameter The

    previous sample is the one case when the idGET request parameter contains a structureData. However, the data may also be contained inside a cookie (with a full name) or a POST request. Figure 21 describes the various possibilities.

    In all of these cases, the encryption key is the first DWORD of the idURL structure . The key in combination with the 0x7DFDC101 module can decrypt the structure id, POST data and cookie value. Then the payload from the data structure is decrypted.


    Figure 21. Selecting the request

    The original request contains general information on the compromised machine, such as the result of commands ipconfig, set, whoamiand tasklist.

    The C&C server then issues one of the instruction sets as an answer. The structure of this answer is shown in Figure 21. The packet is fully encrypted (except for the first four bytes) with the same algorithm borrowed from the Blum Blum Shub described in section 4.3.2, which uses the first DWORD as the key and 0x7DFDC101 for the module. Each instruction set is encrypted separately with 0x3EB13 for the key and 0x7DFDC101 for the module.


    Figure 22. C&C response packet structure The

    backdoor can perform some predefined actions that are hard-coded in a binary file. Table 3 provides a brief description of the available commands.

    Table 3. Description of the available backdoor commands


    In some analyzed samples, the backdoor can also run PowerShell scripts.

    5. JavaScript backdoor analysis


    Some fake Flash installers deliver two JavaScript backdoors instead of Mosquito. These files are flushed to disk in a folder %APPDATA%\Microsoft\. They are called google_update_checker.js и local_update_checker.js.

    The first interacts with a web application hosted on the Google Apps Script service at: (https://script.google[.]com/macros/s/AKfycbwF_VS5wHqlHmi4EQoljEtIsjmglLBO69n_2n_k2KtBqWXLk3w/exec)and expects a response encoded in base64. Then it executes the decoded content using eval. We do not know the exact purpose of the additional backdoor, but it can be used to download additional malvari, or to execute malicious JavaScript code directly. To ensure persistence, it adds a value Shellto HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon.

    The second JavaScript file reads %ProgramData%\1.txtand executes the content using the function eval. To ensure persistence, it adds valuelocal_update_checkc HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.

    6. Conclusion


    The campaign shows that the Turla cybergroup has many tools to mask malicious traffic as legitimate. The methods used can be confusing even for experienced users. The use of HTTPs could reduce the effectiveness of such attacks - in this protocol it is more difficult to intercept and replace encrypted traffic on the way from the machine to the remote server. File signature verification should be suspicious because the files used by Turla are not signed, unlike Adobe installers.

    In addition, the new campaign indicates Turla's interest in consulates and embassies located in Eastern Europe. The group makes a lot of efforts to provide access to these sources of information.

    For questions regarding the campaign, contact threatintel@eset.com.

    7. Indicators of compromise


    7.1. Command server addresses (by years)


    2017: smallcloud.ga
    2017: fleetwood.tk
    2017: docs.google.com/uc?authuser=0&id=0B_wY-Tu90pbjTDllRENW
    NkNma0k&export=download (adstore.twilightparadox.com)
    2017: bigpen.ga
    2017: https://script.google.com/macros/s/AKfycbxxPPyGP3Z5wgwbs
    mXDgaNcQ6DCDf63vih-Te_jKf9SMj8TkTie/exec
    2017: https://script.google.com/macros/s/AKfycbwF_VS5wHqlH
    mi4EQoljEtIsjmglLBO69n_2n_k2KtBqWXLk3w/exec
    2017-2015: ebay-global.publicvm.com
    2017-2014: psychology-blog.ezua.com
    2016: agony.compress.to
    2016: gallop.mefound.com
    2016: auberdine.etowns.net
    2016: skyrim.3d-game.com
    2016: officebuild.4irc.com
    2016: sendmessage.mooo.com
    2016, 2014: robot.wikaba.com
    2015: tellmemore.4irc.com


    7.2. Adobe fake addresses


    http://get.adobe[.]com/stats/AbfFcBebD/?q=
    http://get.adobe[.]com/flashplayer/download/update/x32
    http://get.adobe[.]com/flashplayer/download/update/x64


    7.3. Unofficial addresses for legitimate Flash installers


    https://drive.google[.]com/uc?authuser=0&id=0B_LlMiKUOIsteEtraEJYM0QxQVE&export=download
    https://drive.google[.]com/uc?authuser=0&id=0B_LlMiKUOIstM0RRekVEbnFfaXc&export=download


    7.4. Hashes





    7.5. Windows artifacts


    7.5.1. Intercepted CLSID


    {D9144DCD-E998-4ECA-AB6A-DCD83CCBA16D}
    {08244EE6-92F0-47F2-9FC9-929BAA2E7235}
    {4E14FBA2-2E22-11D1-9964-00C04FBBB345}
    {B5F8350B-0548-48B1-A6EE-88BD00B4A5E7}
    {603D3801-BD81-11D0-A3A5-00C04FD706EC}
    {F82B4EF1-93A9-4DDE-8015-F7950A1A6E31}
    {9207D8C7-E7C8-412E-87F8-2E61171BD291}
    {A3B3C46C-05D8-429B-BF66-87068B4CE563}
    {0997898B-0713-11D2-A4AA-00C04F8EEB3E}
    {603D3801-BD81-11D0-A3A5-00C04FD706EC}
    {1299CF18-C4F5-4B6A-BB0F-2299F0398E27}


    7.5.2. Files


    Three files with the same name but with different extensions (.tlb, .pdb and .tnl) in the folder %APPDATA%
    %APPDATA%\kb6867.bin(simplified log file)

    7.6. ESET Detection


    7.6.1. Recent Samples


    Win32/Turla.CQ
    Win32/Turla.CP
    Win32/Turla.CR
    Win32/Turla.CS
    Win32/Turla.CT
    Win32/Turla.CU
    Win32/Turla.CV
    Win32/Turla.CW
    Win32/Turla.CX


    7.6.2. Old options


    Win32/TrojanDownloader.CAM
    Win32/TrojanDownloader.DMU


    7.6.3. JavaScript backdoor


    JS/Agent.NWB
    JS/TrojanDownloader.Agent.REG

    Also popular now: