Travle aka PYLOT backdoor hits Russian-speaking targets

At the end of September, Palo Alto released a report on Unit42 activity where they – among other things – talked about PYLOT malware. We have been detecting attacks that have employed the use of this backdoor since at least 2015 and refer to it as Travle. Coincidentally, KL was recently involved in an investigation of a successful attack where Travle was detected, during which we conducted a deep analysis of this malware. So, with this intelligence ready we are sharing our findings in this blog to supplement Palo Alto’s research with additional details.

Technical Details

The Travle sample found during our investigation was a DLL with a single exported function (MSOProtect). The malware name Travle was chosen given a string found in early samples of this family: “Travle Path Failed!”. This typo was replaced with correct word “Travel” in newer releases. We believe that Travle could be a successor to the NetTraveler family.

First of all, we detected numerous malicious documents being used in spear-phishing attacks with file names suggesting Russian-speaking targets with executables maintained in encrypted form:

This encryption method has been well known for a long time – it was first used in exploit documents to conceal Enfal, then we discovered this backdoor – Travle. Later documents with such encryption started maintaining another one APT family – Microcin. Travle C2 domains often overlap with those of Enfal. In regard to NetTraveler, at some point Enfal samples started using the same encryption method for maintaining the C2 URL as was used in NetTraveler:

Enfal sample with NetTraveler-like C2 string encryption

So, clearly these backdoors – Enfal, NetTraveler, Travle and Microcin – are all related to each other and are believed to have Chinese-speaking origins. And after finding the string “Travel path failed!” we believe that the Travle backdoor could be intended as a successor to the NetTraveler malware.

The malware starts by initializing the following variables:

%TEMP%\KB287640\ – local malware drop-zone
%TEMP%\KB887209\ – plugins storage
<malware install path>\~KB178495.DAT – configuration file path

Surprisingly, these paths remain the same in all samples of this family. If no configuration file is found, Travle reads the default settings from its resource “RAW_DATA“. Settings are maintained in an encrypted form. Here is the code for decryption:

The storage format for the configuration block is as follows:

The described sample maintains the following configuration data:

The Travle backdoor starts its communication with the C2 by sending gathered information about the target operating system in an HTTP POST request to a URL built using the C2 domain and the path specified in the settings. The information sent includes the following data:

• UserID – based on the computer name and IP-address
• Computer name
• Keyboard layout
• OS version
• IP-addresses
• MAC-address

Once the C2 receives the first packet, it responds with a block of data containing the following information:

• URL path for receiving commands
• URL path for reporting on command execution results
• URL path for downloading files from C2
• URL path for uploading files to C2
• C2 second RC4 key
• C2 first RC4 key
• C2 ID

After this packet has been received, Travle waits for additional commands from the server.

Communication encryption

The ciphering algorithm depends on the type of transmitted object. There are three possible variants:

1. Data
   • Data is ciphered with Base64
   • The resulting string is appended to the header with a size of 0x58 bytes
   • The resulting buffer is ciphered by RC4 with the C2 first RC4 key
   • The resulting buffer is ciphered with Base64
2. List of strings
• Each line is ciphered by RC4 with the C2 second RC4 key
• The resulting buffer is ciphered with Base64
• All the previously Base64-ciphered strings are merged in one delimited with \r\n”
• The resulting string is appended to the header with a size of 0x54 bytes
• The resulting buffer is ciphered by RC4 with the C2 first RC4 key
• The resulting buffer is ciphered with Base64
3. File
• Compressed with LZO
• The resulting archive is ciphered with the C2 second RC4 key

Messages format

The header for the transmitted data is as follows:

The file is transferred to the C2 in a POST request as a multipart content type with boundary “kdncia987231875123nnm“. All samples of Travle we have discovered use this value.

Message types – from bot to C2

The command ID is specified at offset 0x18 in the header.

Technical messages are as follows:

Operational messages are as follows:

Message types – from C2 to bot

In case of bot sending POST request C2 responses with data of following format:

Bot also may send GET request for retrieving a specific file from the server. In this case, C2 responses with the requested file.

General communication between bot and C2

Interaction with C2 includes two stages:

1^st (automatic – carried out with no operator actions). It consists of:

• Sending information about the OS
• Receiving information about C2
• Sending a request for the first command
• Receiving the command with ordinal 1 and first argument “*”
• Sending the request for the next command

2^nd (carried out by operators). It consists of:

• Sending commands to the bot
• Sending files to the bot
• Sending results of the executed commands to the C2

Commands – general bot functionality

Plugins

Unfortunately, we have been unable to receive plugins from any C2 found in examined Travle samples, but after analyzing the code of Travle we can briefly describe how they are handled.

Plugins are handled with the use of commands 32-35. From all the analyzed Travle samples, we found out that not every Travle sample is able to work with plugins.

Each plugin DLL is saved in a file and loaded with the use of the LoadLibrary API function. The DLL should export three functions: GetPluginInfo, Starting and FreeMemory. These functions are invoked one-by-one at the plugin DLL loading stage. When Travle has to unload the plugin DLL it calls the FreeLibrary API function.

In all analyzed Travle samples, plugins are saved in the same location: %TEMP%\KB887209\.

Conclusion

The actor or actors responsible for the Travle attack has been active during the last few years, apparently not worried about being tracked by AV companies. Usually, modifications and new additions to their arsenal are discovered and detected quite quickly. Still, the fact that they didn?t really need to change their TTPs during all these years seems to suggest that they don?t need to increase their sophistication level in order to fulfill their goals. What’s worse, according to subjects of decoy documents these backdoors are used primarily in the CIS region against government organizations, military entities and companies engaged in high-tech research, which indicates that even high-profile targets still have a long way to go to implement IT-sec best practices which efficiently resist targeted attacks.

We detect Travle samples with the following verdicts:

Trojan.Win32.Tpyn.*
Trojan.Win32.TravNet.*
Trojan-Spy.Win32.TravNet.*
HEUR:Trojan.Win32.Generic
HEUR:Trojan.Win32.TravNet.gen
HEUR:Backdoor.Win32.NetTraveler.gen

More information about the Travle APT is available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com