Inside TDrop2: Technical Analysis of new Dark Seoul Malware

Palo Alto Networks recently identified a new campaign targeting the transportation sector in Europe with ties to the Dark Seoul and Operation Troy campaigns that took place in 2013. This new campaign used updated instances of the Tdrop malware family discovered in the Operation Troy campaign. For more information on the new campaign discovered by Unit 42, please refer to our recent blog post.

In this attack, attackers embedded the TDrop2 malware inside a legitimate video software package hosted on the software distributor’s website. By doing this, they were able to target organizations that relied on the distributor’s security camera solution and infect their systems with malware. They created a true Trojan horse, which sneaks into a network as a gift, but when opened, the attacker’s army leaps out.

Trojanized Video Player (Stage 1)

The malware used for the attempted infection purported to be a legitimate video player, providing viewing software for security camera solutions. The following two unique file names were involved in the attack.

• [redacted]Player_full.exe
• [redacted]Player_light.exe

The difference between the files involves the specific video player that was dropped and executed during runtime. Each file would drop and execute the full or light version of the legitimate video player respective to the file name.

Both the legitimate copy of the video player, as well as a malicious executable were bundled into a single executable. These files were added to the end of the Trojan executable, as seen below.

 

When initially run, the malware checks to see if its parent process is either explorer.exe or cmd.exe. In the event the malware is not running in the context of either of these processes, it will exit. This check exists in a number of the subsequent processes/executables used by the TDrop2 malware variant.

 

Subsequently, the malware proceeds to extract both the video player and the embedded malware using a series of calls to CreateFile, CreateFileMapping, GetFileSize, andMapViewOfFile. Once extracted, the file writes it to a new file on disk prior to executing it. The video player is written to one of the following locations, based on the original filename:

• %TEMP%\[redacted]Player_full.exe
• %TEMP%\[redacted]Player_light.exe

The malware itself is written to the %TEMP% directory as well. The filename is derived by randomly choosing an executable name from the system32 directory. The randomly chosen executable must not contain any of the following strings:

• setup
• install
• update

Dropped Malware (Stage 2)

This dropped malware begins by performing the same parent process check witnessed in the original sample. In the event the malware is not running within the parent process of cmd.exe or explorer.exe, it will exit immediately. This malware sample will also dynamically load a number of functions and libraries. After the kernel32.dll and ntdll.dll libraries are loaded via calls toGetModuleHandle, the following process takes place:

1. Create a char array containing the desired function name and store this array to a variable
2. Load this library via a call to GetProcAddress
3. Store this function offset in a global variable
4. Free the memory containing the char array

 

In total, the following 14 functions are loaded during runtime:

CreateFileA GetFileSize CloseHandle VirtualAlloc GetModuleFileNameA CreateProcessA NtUnmapViewOfSection

VirtualAllocEx WriteProcessMemory GetThreadContext SetThreadContext ResumeThread TerminateProcess TerminateThread

After these functions are loaded, the malware will randomly select an executable from the system32 using the same routine witnessed in the earlier sample. The malware proceeds to spawn a new process of the selected executable and performs a technique called process hollowing to hide itself inside a legitimate executable. This leads us to the next stage of our malware

Injected Malware (Stage 3)

This particular stage of malware acts as a downloader. The parent process check is not used in this particular sample. The malware initially attempts to download a file from the following location:

• http://www.combra[.]eu/includes/images/logo.jpg

While the link above shows a file extension of an image, the transferred file is in fact a modified executable file.

 

The downloaded file has the first two bytes of the PE file format replaced with the characters ‘DW’, instead of the usual ‘MZ’. After the download occurs, the malware immediately corrects the first two bytes with the ‘MZ’ characters prior to writing the file to disk.

 

The downloaded file is dropped to the system32 folder. The malware selects a randomly chosen DLL from this directory. The base name of this DLL is used to write the downloaded file. As an example, in the event apcups.dll was selected, the malware would write the downloaded file to apcups.exe in the same folder. The downloader then proceeds to execute this downloaded file in a new process.

 JPG Executable (Stage 4)

As we’ve seen in previous samples, this executable file begins by checking the parent process for the presence of ‘cmd.exe’ or ‘explorer.exe’. It proceeds to randomly select an executable file in the system32 folder, and performs process hollowing against it. The injected executable contains the last stage of the TDrop2 malware variant.

Final Payload (Stage 5)

Upon execution, we once again see the parent process check to determine if the malware is running within the ‘cmd.exe’ or ‘explorer.exe’ parent process. It continues to dynamically load a number of libraries and functions for later use. A feature that has yet to be seen is that of string encryption. Strings are encrypted using the following function, represented in Python:

After dynamically loading functions and libraries, the malware iterates through the running processes and attempts to determine if the ‘V3lite.exe’ process is running. This process name is associated with the South Korean-based AhnLab security software provider. In the event this process is running, the malware will attempt to kill the process’ class window.

The final payload proceeds to generate the following mutex to ensure only one copy of the malware is running concurrently:

Global\SPPLMUTEX

The payload then spawns two threads—one to maintain persistence and another to gather victim information and perform command and control operations. Persistence is achieved by setting the following registry key:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

The name of the registry key in the above instances is derived from the basename of the supplied argument. In the event the supplied argument was C:\malware.exe, the registry key would be named ‘malware’, and the path for this key would be ‘C:\malware.exe’.

The persistence thread runs in a loop where the registry keys are set every 60 seconds, ensuring persistence even in the event an administrator manually deletes the registry keys.

The other thread begins by collecting information about the victim, such as the following:

• Computer Name
• IP Address
• Registered Owner
• Registered Organization
• Installation Date

These data points are used to generate a unique victim ID, which is stored in the following registry key:

HKCU\SOFTWARE\Microsoft\HY08A\Build

The malware will continue to decrypt and store embedded C2 URLs. The following URLs have been identified:

• http://mcm-yachtmanagement[.]com/installx/install_ok.php
• http://www.junfac[.]com/tires/skin/tires.php

The final payload proceeds to enter its command and control loop. It initially performs a DNS check against microsoft.com to ensure it has Internet connectivity. After this check is performed, it enters an infinite loop, with a sleep interval set at a default of 30 minutes. The malware will periodically poll the C2 server and determine if any commands are received. The initial POST request contains a unique victim identifier that was previously generated.

 

The optional response by the C2 server is both encoded and encrypted.

 

The data is first encrypted using an unidentified algorithm. The two keys used for this encryption are generated using another unidentified algorithm. The following Python script can be used to generate the keys. A default salt of ‘FFFFFFFF’ is used.

Additionally, the following Python script can be used for encryption/decryption

After the data is encrypted, it is then base64-encoded using a custom alphabet. The following alphabet is used:

3bcd1fghijklmABCDEFGH-J+LMnopq4stuvwxyzNOPQ7STUVWXYZ0e2ar56R89K/

When the previously mentioned C2 response is both decoded and decrypted, we are presented with the following data:

The command structure of the C2 response always begins with the string ‘tick’. The number following this string is most likely a unique command identifier. The malware will store these command identifiers in the following files:

• %TEMP%\MSI2001.LOG
• %TEMP%\MSI2002.LOG

In the event the number after the tick was previously witnessed, the command from the C2 will be ignored. The remaining lines are then parsed. The following commands are supported:

Command	Description
1001	Modify C2 URLs
1003	Download
1013	Download/execute malware in other process
1018	Modify wait interval time
1025	Download/execute and return response
Default	Execute command and return results

Once again, using the previous example, the malware will first ensure that the command was not previously parsed/executed. In the event it is new, it will proceed to execute the various reconnaissance commands found on line #2. The results of these commands are uploaded to the C2 server.

 

As we can see in the above network traffic, the malware attempts to disguise the data as a .gif image. Finally, the malware will parse the third line, which instructs the malware to modify the wait interval to a value of ‘60’. This interval value is set in the following registry key:

HKCU\Software\Microsoft\HY08A\Policy

Additionally, in the event the C2 response instructs the malware to update C2 URLs, it will be in the following format:

1001; [unique_identifier] [url]

The malware will encrypt the URL string with a 4-byte XOR key of “\x01\x02\x03\x04” and store this data in the following registry key:

HKCU\Software\Microsoft\HY08A\[unique_identifier]

Conclusion

The TDrop2 malware family that was witnessed in a recent attack against a European transportation company provided a minimal set of commands to the attackers. It was most likely used to establish a foothold, perform reconnaissance and deploy further malware into the victim’s network. While the malware lacked a large set of capabilities, it had a wealth of interesting and advanced features, such as the custom encryption/encoding witnessed in the network traffic, the use of process hollowing against a randomly selected Microsoft Windows binary, and the downloading component that attempted to bypass network security measures by modifying the executable header.

We created the AutoFocus tag TDrop2 to identify samples of this new variant and added known C2 domains and hash values to the Threat Prevention product set. At this time, WildFire is able to correctly identify the samples associated with this campaign as malicious.

Sample Identifiers

Stage 1

MD5	56C9BB7A7F3AF5F55F4E4FA94E8C6ACC
SHA1	1B86A66A0A0D6A619D8F2CD1E2904EF7395B3F81
SHA256	43EB1B6BF1707E55A39E87985EDA455FB322AFAE3D2A57339C5E29054FB52042
Timestamp	2015-05-20 14:27:55 UTC

 

MD5	23637A57EA2F984AFAF991D4E90E3F4A
SHA1	6270129B7EE49AEF969E8C18FAD584E7CB2E512E
SHA256	A02E1CB1EFBE8F3551CC3A4B452C2B7F93565860CDE44D26496AABD0D3296444
Timestamp	2015-05-20 14:27:55 UTC

 

Stage 2

MD5	285352CAD75DC32BAAE10ABF68005397
SHA1	01635C842F4CEE4E5A97FBA2341207B1372A4559
SHA256	EE878A8ADEE367371242D624F79531FCB81850A25AF0A46B1F82CFB5975F1C89
Timestamp	2005-09-13 08:15:56 UTC

 

MD5	F6F3D7264F7478B472894B90A66EA2A2
SHA1	8BB8E4193ED7A115B97046AFAA6CF371F237885F
SHA256	3E9BFA7F4EFD3B5687872FEAE62138FAB14E4AF48E2A018C8113325C3D79D6CB
Timestamp	2015-07-30 23:45:41 UTC

 

Stage 3

MD5	29289C19C414CF79E61E095C1500938A
SHA1	25D283BEA4136F07C13FF3902821A207A9F67A7F
SHA256	2356DB510C8C2D5F72945D3D0B9B826DA55AD93C4CD2461961888468EC2F1591
Timestamp	2015-08-24 18:29:52 UTC

 

MD5	C89A97B99063A74EEEA8B7288196CB96
SHA1	6C53A43ACFB8F3A1C7B37EB614CBD89DD7E70DFE
SHA256	E64443E3F3D86D0AB86DAEB0B9E51D2ADA44B23CEBEE68AF9889C8AC72D2ED97
Timestamp	2015-08-24 18:29:52 UTC

 

Stage 4

MD5	C89A97B99063A74EEEA8B7288196CB96
SHA1	7315E7FD14518B8A27750D5F717A9FA6BBA71880
SHA256	A10CF8B278AF1BBC93E03E29908202197365792FCB0ADD8D02A1E0BDBF94121E
Timestamp	2015-05-24 09:33:48 UTC

 

Stage 5

MD5	B67638C91EAE7DB255E41F7CC0CCE46B
SHA1	0EF3EC648B63BADADB6BA947E4F90F12C2C8B7E8
SHA256	49A665D51E0F17C6554F11BE7ABCDCC98B94A68F6041FD02A74291540FC05A79
Timestamp	2015-09-14 17:53:14 UTC

Josh Grunzweig

[Palo Alto Networks Blog]