At the beginning of April, Carbon Black Threat Research began analyzing a malware variant commonly referred to as Red Leaves, which appears to have code reuse from the PlugX family. During the last month, this malware family has been referenced in several security blogs and government alerts.

Carbon Black is publicly providing this technical write up to assist customers, other organizations, and researchers continuing to investigate incidents related to this malware family. Along with this report, Carbon Black is providing product specific queries, rules and scripts aimed at assisting in the detection and analysis of this malware family in the Carbon Black User Exchange. The overall process of how the malware’s components are created on an infected system and the different points where the suite of Carbon Black products could detect the different stages of the malware are outlined in that User Exchange post.

This malware family has been observed in the wild since at least June 2016. The malware uses a technique called DLL side loading, which is common with the PlugX family. DLL sideloading works by using a legitimate or benign executable file to load a modified DLL. This DLL is responsible for loading and executing an encoded or encrypted malicious data file. The ultimate payload for this sample is a shellcode loader, which injects the Red Leaves implant, via process hollowing, into a hard coded process.

The metadata for the initial dropper file that was analyzed is listed in the information below.

File Name : tea_leaves_First-Stage
 File Size : 3,804,160 bytes
 MD5 : b3139b26a2dabb9b6e728884d8fa8b33
 SHA1 : de5672c7940e4fad3c8145ce9e8a5fcb1da0fcee
 SHA256 : 5262cb9791df50fafcb2fbd5f93226050b51efe400c2924eecba97b7ce437481
 Fuzzy : 98304:drzo0aM7e5O92nAv/tyE6peB1IY8CEueiSH0h292bNcx:pzo0S4yRY8tueiSUh1bCx
 Compiled Time : Wed Feb 22 02:41:17 2017 UTC
 PE Sections (5) : Name Size MD5
  .text 1,264,128 181494d7465a4b5f1c6624b89826d147
  .rdata 291,328 b80b1b78172e51912b085932c3a0e106
  .data 2,032,128 059174f08ccd413e22acc50c91374730
  .rsrc 40,448 cae79604deb6e0793c6a3282a1b63104
  .reloc 175,104 9e12d15095cb458e072e0eae5c4c5095
 Magic : PE32 executable for MS Windows (GUI) Intel 80386 32-bit

Technical Details

The initial stage of the sample analyzed has little functionality outside of dropping or creating the malicious second stage files on the infected system. PlugX has in the past been documented as being delivered via a self extracting (SFX) Rar executable, which acts as the first stage dropper.

Once the files have been created on disk, the dropper will execute the Obedience.exe file, starting the overall process. A brief overview of the entire process is outlined in the below two figures and the accompanying table.

The main dropper/installer creates the three component files on the infected system. The dropper creates the entrenchment mechanism (a link file in a startup folder, which is detailed further later in the report) and executes Obedience.exe. Obedience imports the GetVersion function from Starburn.dll The GetVersion function from StarBurn.dll loads the the handkerchief.dat file and decodes the file into shared memory space. Starburn.dll calls CreateProcess and hands control over to the decoded handkerchief.dat file, which is shellcode with an embedded payload. The shellcode will load several standard libraries and create an iexplore.exe process in suspended state. The shellcode then writes the embedded payload into the memory space for the Iexplore.exe process. The suspended Iexplore.exe process is then resumed and the Red Leaves implant begins its process.

First Stage – Dropper

The first stage dropper will push several hard-coded values to a function, which is responsible for decoding the three embedded files. These files comprise the second stage of the overall malware setup. The image below displays these values being pushed (highlighted in red) as well as being labeled for clarity.

The pushed values in the above image (file offsets and sizes), are passed to a function responsible for decoding and writing the files to disk, along with the hard coded file names. The embedded files are decoded by the function displayed in the image below. The function will decode the first half of the file with one set of XOR keys (these instructions are highlighted in red), and the second half of the function with a different set of XOR keys (these instructions are highlighted in yellow). The XOR key sets are derived from a 16 byte ASCII string immediately preceding the encoded data, in which every other byte is used to XOR each byte of encoded data. The first eight bytes are used for the first half of the file and the last 8 bytes for the second half of the file.

To clarify this process, the data in the table below represents one of the encoded embedded files. The first 16 bytes (which are in bold) are the ASCII string, from which the key sets are derived. The first half of the file is decoded by XORing each byte of encoded data with each byte which is designated in red below. The second half is of the file is then decoded in the same manner using the each byte, in blue, from the second half of the overall string. The same result can be obtained by XORing each byte of the 4 byte key and then using the result to XOR each byte of encoded data, which in this specific scenario is 0x1B and clearly visible from the null areas of an executable file.

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
 
 0017C330 4F 31 36 22 44 45 26 38 32 49 37 31 38 37 38 36 O16"DE&82I718786
 0017C340 56 41 4B 1B 19 1B 1B 1B 1F 1B 14 1B E4 E4 1B 1B VAK ää 
 0017C350 A3 1B 1B 1B 1B 1B 1B 1B 5B 1B 01 1B 1B 1B 1B 1B £ [ 
 0017C360 1B 1B 1B 1B 1B 1B 1B 1B 1B 1B 1B 1B 1B 1B 1B 1B 
 0017C370 1B 1B 1B 1B 1B 1B 1B 1B 1B 1B 1B 1B 1B 1A 1B 1B 
 0017C380 A1 0B 1B 15 04 AF 12 D6 3A A3 1A 57 D6 3A 8B 8B ¡ ¯ Ö:£ WÖ:‹‹
 0017C390 4F 73 72 68 3B 6B 69 74 7C 69 7A 76 3B 76 6E 68 Osrh;kit|izv;vnh
 0017C3A0 6F 3B 79 7E 3B 69 6E 75 3B 6E 75 7F 7E 69 3B 4C o;y~;inu;nu ~i;L
 0017C3B0 72 75 28 29 16 11 3F 2C 1B 1B 1B 1B 1B 1B 1B 1B ru() ?,

The file labeled as embed_1 is a legitimate and validly signed executable (typically used in conjunction with different CD software applications), and in this sample will be created as the hard coded name obedience.exe (it should be noted that the file name could easily be changed in other variants).

The file labeled as embed_2 is a slightly modified file that will be named StarBurn.dll. The final file labeled as embed_3 is an encoded file that when decoded and executed will inject the Red Leaves implant into the memory of a target process. All of these files will be be created in the current user’s Temp folder (ex. C:Users[account]AppDataLocalTemp). The first stage dropper is also responsible for installing the persistence mechanism for the malware, as a shortcut named persuasion.lnk in the current user’s startup folder. The shortcut or link file will point to the target file obedience.exe and will execute that file when the user logs into the system.

File Name : tea_leaves.exe_embed_1
 File Size : 1,616,040
 MD5 : 6a1c14d5f16a07bef55943134fe618c0
 SHA1 : 1a46e961bffc6bcc1adac9708393462024f0f6ad
 SHA256 : aba4df64717462c61801d737c9fa20a7fada61539eaef50954331d31f7306d27
 
 File Name : tea_leaves.exe_embed_2
 File Size : 134,144
 MD5 : 45cb2f0440f3cc2d86ec7a313aeab5d6
 SHA1 : ae3f724a2d253af16a2689001b64d96b0f36cb4c
 SHA256 : 63d5aa72d8e0b55f59a1e28e53d2cc6f7f94ec978ec4690862fdadbde00a7ac0
 
 
 File Name : tea_leaves.exe_embed_3
 File Size : 254,593
 MD5 : fb0c714cd2ebdcc6f33817abe7813c36
 SHA1 : fc4f3698e768f690425523cdfd548b81d891c3b0
 SHA256 : 773b176b3a68c3d21fae907af8fba7908b55726bd591c5335c8c0bc9de179b76

Second Stage

Obedience.exe

Once the benign file obedience.exe has been executed it loads several libraries, one of which is StarBurn.dll. The below image displays the Import table from Obedience showing where the malicious GetVersion function is imported. The StarBurn.dll is side loaded, which is a fairly common tactic often associated with the PlugX family.

StarBurn.dll

Once the GetVersion function from StarBurn.dll is imported it will execute and look for the hard coded filename handkerchief.dat in the directory where StarBurn.dll is located. The image below highlights these actions.

The handkerchief.dat file’s data is then read into memory. The pseudo-code in the image below highlights the the next steps in the process (variables were renamed for clarity). The StarBurn.dll function will make the address space where the handkerchief.dat data was read into memory read, write and executable (which is highlighted in the first red box).

The function will then decode the data in the same manner in which the previous embedded files were decoded, where a 16 byte ASCII string is used to derive 2 XOR key sets, which are then used to decode the first and second half of the files. The StarBurn.dll function will then create a thread with the starting address of the decoded data, is highlighted in the second red box.

The decoded data is shellcode with an additional embedded payload. The table below is a small excerpt of the decoded shellcode, which will load the Red Leaves implant into memory.

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
 
 00000000 EB 05 5F 8B C7 EB 05 E8 F6 FF FF FF 55 8B EC 81 ë _‹Çë èöÿÿÿU‹ì 
 00000010 EC DC 05 00 00 53 56 57 E9 B0 06 00 00 8F 45 E0 ìÜ SVWé° Eà
 00000020 60 33 C9 64 8B 35 30 00 00 00 8B 76 0C 8B 76 1C `3Éd‹50 ‹v ‹v 
 00000030 81 7E 1C 18 00 1A 00 74 07 8B 36 83 FE 00 75 F0 ~ t ‹6ƒþ uð
 00000040 8B 5E 08 8B FB 89 7D EC 8B 47 3C 8B 54 07 78 03 ‹^ ‹û‰}ì‹G<‹T x 
 00000050 D7 8B 4A 18 8B 5A 20 03 DF 49 8B 34 8B 03 F7 B8 ׋J ‹Z ßI‹4‹ ÷¸
 00000060 47 65 74 50 39 06 75 F1 B8 72 6F 63 41 39 46 04 GetP9 uñ¸rocA9F 
 00000070 75 E7 8B 5A 24 03 DF 66 8B 0C 4B 8B 5A 1C 03 DF uç‹Z$ ßf‹ K‹Z ß
 00000080 8B 04 8B 03 C7 89 45 E8 6A 00 68 61 72 79 41 68 ‹ ‹ ljEèj haryAh
 00000090 4C 69 62 72 68 4C 6F 61 64 54 57 FF D0 89 45 D8 LibrhLoadTWÿЉEØ
 000000A0 83 C4 10 61 8B 45 E0 66 8B 08 66 89 4D F0 8B 55 ƒÄ a‹Eàf‹ f‰Mð‹U
 000000B0 E0 83 C2 02 89 55 E0 8B 45 EC 89 45 DC 8B 4D E0 àƒ ‰Uà‹Eì‰EÜ‹Mà
 000000C0 89 4D FC C7 45 D4 00 00 00 00 8B 55 E0 89 55 D0 ‰MüÇEÔ ‹Uà‰UÐ

Shellcode Loader

The shellcode will load several common libraries which will be used to inject the Red Leaves payload into memory. The shellcode decodes (using a single byte XOR of 0x53) a portion of the implant’s configuration block, where the processname is stored that will be injected into via process hollowing. The image below shows the code responsible for configuration decoding, highlighted in red.

The shellcode loader will then create a process in suspended state, in this case the target process was Iexplore.exe. The image below, which has been commented for clarity, displays where the shellcode creates the suspended thread. The Red Leaves payload will then be written to that process’ memory location and the thread is then resumed allowing the Red Leaves implant to impersonate Internet Explorer and communicate with the pre-configure C2s.

As other research reports have pointed the embedded Red Leaves implant has the MZ and PE ASCII characters from the DOS and PE headers overwritten with the values 0xFF, which are highlighted in red in the table below.

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
 
 00001470 00 04 00 00 00 FF FF 00 00 B8 00 00 00 00 00 00 ÿÿ ¸ 
 00001480 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 @ 
 00001490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 000014A0 00 00 00 00 00 F0 00 00 00 0E 1F BA 0E 00 B4 09 ð º ´ 
 000014B0 CD 21 B8 01 4C CD 21 54 68 69 73 20 70 72 6F 67 Í!¸ LÍ!This prog
 000014C0 72 61 6D 20 63 61 6E 6E 6F 74 20 62 65 20 72 75 ram cannot be ru
 000014D0 6E 20 69 6E 20 44 4F 53 20 6D 6F 64 65 2E 0D 0D n in DOS mode. 
 000014E0 0A 24 00 00 00 00 00 00 00 DD DD DD DD DD DD DD $ ÝÝÝÝÝÝÝ
 000014F0 DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD ÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝ
 00001500 DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD ÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝ
 00001510 DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD ÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝ
 00001520 DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD ÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝ
 00001530 DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD ÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝ
 00001540 DD DD DD DD DD DD DD DD DD 00 00 00 00 00 00 00 ÝÝÝÝÝÝÝÝÝ 
 00001550 00 00 00 00 00 00 00 00 00 FF FF 00 00 4C 01 05 ÿÿ L 
 00001560 00 4C A8 7D 58 00 00 00 00 00 00 00 00 E0 00 02 L¨}X à 
 00001570 21 0B 01 0A 00 00 FA 02 00 00 D0 00 00 00 00 00 ! ú Ð 
 00001580 00 EE BE 01 00 00 10 00 00 00 10 03 00 00 00 00 î¾ 
 00001590 10 00 10 00 00 00 02 00 00 05 00 01 00 00 00 00 

Third Stage – Red Leaves Implant

Once the Red Leaves malware is running the program will initially decode its configuration block, which is encoded using a single byte XOR (in this example the 0x53). This functionality is highlighted in the image below. The configuration block is 0x940 bytes in length and contains several different options related to how the malware will install itself as well as where and how it will communicate with the hard coded C2s. The configuration block itself is a list of null terminated strings and binary values, which correspond to hard coded values.

The configuration block is detailed in the table below. The Value section are the values present in the sample that was analyzed.

Offset	Size	Value	Description
0x0	0x8	0x53 or “S”	The first byte of this 8 byte section is the XOR key that is used to decode the configuration block
0x8	0x40	67.205.132.17	This area contains the first hard coded C2 Server Value
0x48	0x40	67.205.132.17	This area contains the second hard coded C2 Server Value
0x88	0x40	144.168.45.116	This area contains the third hard coded C2 Server Value
0xC8	0x4	0xBB 01	This area supplies the port that will be used when connecting to the C2s. This value is little Endian hex encoded and translated to decimal is 443
0x1D4	0x4	0x05	This is a sleep interval value. The value is this area will be multiplied by 1000 milliseconds for a sleep interval when beaconing to the C2s. If no value is provided the malware will use the default value of 5000 milliseconds
0x1D8	0x4	0x04	This is a variable that is used to determine the connection Mode. The 4 value is used for TCP and HTTP. If this value is used it will iterate through the hard coded ports 443, 53, 80, and 995 for each C2 it can properly resolve.
0x1EC	0x10+	2017-2-22-ALL	This area is the Campaign ID, and could be as long as 0x31B characters.
0x508	0x20+	vv11287GD	This area contains the Unicode string to be used as the Mutex for malware while running.
0x72E	0x100	%ProgramFiles%Internet Exploreriexplore.exe	This area contains the target process that will be spawned by the original shellcode and the read leaves malware will be injected into via process hollowing
0x832	0xA	Lucky123	This area contains a null terminated string that is the key used in the RC4 algorithm that the malware employs to encrypt communications with the C2

After the configuration data has been decoded the malware will go into the main communication thread creation function, which is responsible for initiating the communications to the embedded C2s. The connection mode value is evaluated and the malware will used the appropriate functions to either use a custom protocol or standard APIs to communicate with the C2s. The value in this sample is 4 which will then attempt to resolve the different C2s iterating through the ports 443, 53, 80, and 995 (in that specific order).

Once a connection has been established the malware will communicate with the C2 utilizing the RC4 algorithm with the key “Lucky123”. The malware uses a series of command Identifiers, which are parsed, and then the program will pass control to the appropriate functions to carry out commands and return the responses or data back to the C2. The jump table responsible for evaluating commands is displayed in the image below.

The communication protocol has been well documented in other research papers, which can be reviewed for further information. The malware itself has the following capabilities, which allow the malware to be used as an efficient Remote Access Tool (RAT).

• Update C2 Configuration

• Search for Files

• Get Disk Information

• Get Host Information

• Create Pipe to cmd.exe

• Interactive Reverse Shell

• Enumerate Users

• Upload/Download FIles

• Delete Files

• Run Command/Program

• Download File from URL

• Proxy Tunneling

• Create ScreenShots

• Bind to Sockets

• Impersonate Users