{"id":1168,"date":"2022-01-10T18:07:26","date_gmt":"2022-01-10T17:07:26","guid":{"rendered":"https:\/\/lab52.io\/blog\/?p=1168"},"modified":"2022-01-25T11:39:14","modified_gmt":"2022-01-25T10:39:14","slug":"tokyox-dll-side-loading-an-unknown-artifact","status":"publish","type":"post","link":"https:\/\/lab52.io\/blog\/tokyox-dll-side-loading-an-unknown-artifact\/","title":{"rendered":"TokyoX: DLL side-loading an unknown artifact"},"content":{"rendered":"\n

During Christmas holidays, Lab52 has been analyzing a sample which loads an artifact that we have decided to refer to as \u201cTokyoX\u201d since no similarities have been found as to any known malware, which we usually detect in open sources. However, we cannot confirm so far that it is indeed a new family of malware.<\/p>\n\n\n\n

The first thing we identified was a DLL
(382b3d3bb1be4f14dbc1e82a34946a52795288867ed86c6c43e4f981729be4fc) which had the following timestamps in VirusTotal at the time of the current analysis, and was uploaded from Russia via web site:<\/p>\n\n\n\n

Creation Time 2021-12-09 02:46:43
First Submission 2021-12-09 08:48:20
Last Submission 2021-12-09 08:48:20
Last Analysis 2021-12-23 23:38:08<\/p>\n\n\n\n

Some antivirus engines tagged the sample as PlugX, but it seems that the attribution might be due to the final payload\u2019s loading mechanism: DLL sideloading with an encrypted payload in the same directory. After analyzing the final payload we could not find any similarities with other known samples from PlugX other than the loading TTPs.<\/p>\n\n\n\n

This DLL had a related .zip file with the name \u043f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435.zip (translated to as planning.zip). When unzipping, the following files are observed:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

The legitimate file Creative.exe, an encrypted Data file and the version.dll DLL, which implements the loader function for the Data file, and therefore responsible of mapping the \u201cTokyoX\u201d.<\/p>\n\n\n\n

If we execute it from a path which is not final or the expected by the malware, it replicates to another path and executes from there, which is something it does have in common with some PlugX dll loaders:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

Once executed, we observe how the netsh.exe process tries to establish connections with port 443 of the IP address 31.192.107[.]187.<\/p>\n\n\n\n

In this analysis we will focus on different aspects about the process; from double-clicking the binary 123.exe process (which is a copy of Creative.exe but in another path) to the execution of \u201cTokyoX\u201d already decrypted in memory.<\/p>\n\n\n\n

The first thing we observe within the process is how the version.dll library prepares the decryption and the final payload\u2019s loading in the remote process:<\/p>\n\n\n\n

In fact, we can see how the content of the Data file is read in the code section of version.dll:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

If we edit the Data file with a hexadecimal editor we will see their values, which will help us to identify it in memory later (beginning with E3 84):<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

After reading the file from disk, a child process netsh.exe is created. This just-created child process is where several new memory segments will be located (a total of 5, including the final decrypted payload) to decrypt the final \u201cTokyoX\u201d payload. The APIs which were observed for the creation and writing of the remote process are the native APIs NtAllocateVirtualmemory and NtwriteVirtualmemory.<\/p>\n\n\n\n

First, it creates two segments: 100Kb where the encrypted payload is located and which comes from the disc, and another one of 4Kb. In the 4Kb segment we observe how the following string is set (which will be the string used for the decrypting process):<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

The other memory segment of 100Kb contains the following (encrypted content, as we see how it matches the content from Data file on Disk):<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

After the creation of these two segments, a third segment is allocated, where it is loaded the absolute memory addresses from several win32 APIs (VirtualAlloc, LoadLibrary, GetProcAddress, the home address of the coded payload, etc.) for its later use by the loader:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

We can notice how the segment will have the memory addresses (starting from 123.exe they are located in netsh.exe segment through the version.dll code):<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

Then, another segment of 4Kb is created where it loads the code that will decrypt and load the final payload.<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

Finally, the \u201cTokyoX\u201d loader runs from the DLL (version.dll) in netsh.exe through the API NtcreateThreadEx and we see the start of the last page created in the stack:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

After the execution of NtCreateThreadEx, as indicated, the loader is initiated in netsh.exe in the segment:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

Once the execution is moved to the netsh.exe process, it takes the string located in the initial 4Kb segment, copies it into the stack and replicates it (0x100, 256 bytes) to match the specific block size of 256bytes. In the following screenshots we can observe how the block ends with the string \u201c!Up?\u201d when it reaches the value 0x100 in hexadecimal.<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n

After the block is created with the replicated string, the values from 00 to FF are found and used for the decrypting process.<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

At this point, the loader transforms the 00-FF block with a series of additions combining the replicated string\u2019s block with the 00-FF block, as we can see:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

The combination of the blue block (in following image) and the 00-FF block (pointed in red in previous image) results in the following block in memory, marked in red in the image:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

On the next step, the loader reads the initial argument, arg0, whose value is 0x900000 and points at the 4Kb block, which stores the absolute addresses to different API from Win32:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

After this, the decrypting process for the final payload begins. The decrypting process gets two values from the second block, exchanges and adds them, and the result serves as a final index to recover the element from the second block with which the xor will be achieved through the coded block.<\/p>\n\n\n\n

This description of the decryption algorythm has been identified as the RC4 algorythm<\/strong>.<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

After the decryption process, we find a PE binary, as seen in the following image. In this case, the payload does not start with the traditional MZ header but the string \u201ctokyo\u201d:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

Then, we see how it loads the VirtualAlloc absolute address (0x77211856) from the segment previously created:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

This creates another memory segment in the process netsh.exe with RWX licenses (that of 116Kb) which will be used to load the PE:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

In this new segment, it maps the binary using the virtual addresses as the regular Windows PE loader would do.<\/p>\n\n\n\n

Then, it calls the API LoadLibraryA (it has the address since the DLL saved it in the memory segment) of the strings located in the mapped block:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

Then it calls GetProcAddress() to get the addresses of certain functions:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n

Next, the libraries and functions block may be appreciated:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

After the correct mapping and having loaded the necessary libraries for its proper functioning, it calls EAX to run the decrypted and mapped payload:<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n

To summarize, this article goes through the process followed in memory after executing the Creative Cloud application until deploying TokyoX in memory. This DLL sideloading style is often linked to APT groups whose attribution is also linked to China, however being a known technique as it is, we are not able to consider any feasible attribution at the moment.<\/p>\n\n\n\n

As reviewed at the beginning of the article, what we have named as \u201cTokyoX\u201d has not been identified as a known malware so far (at least, with the sources that we have).<\/p>\n\n\n\n

Additionally, at some point of the analysis we identified a tool used by this group for the creation of version.dll, which pretends to be a Windows DLL located in SysWOW\/System32. The string \u201cAheadLib\u201d found among the code of the malicious version.dll drew our attention, and we quickly found two chinese (casually or not) GitHub repositories with the source code of some tool called AheadLib.<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n

Basically, this tool will allow you to create a C++ source code file, implementing a DLL with the same exported functions as a given DLL. For the purpose of the current analysis we generated a source code file using this tool and giving the legitimate version.dll as input.<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

In the shown screenshot we can see on the left side the pseudocode generated by IDA Pro while analyzing the malicious version.dll sample. On the right side, we can observe the source code automatically generated by AheadLib using the legitimate version.dll as input. Even though the exported functions are not shown in the previous image, we can appreciate how there is a perfect match between both snippets.<\/p>\n\n\n\n

Read the second part of the analysis of the final \u201cTokyoX\u201d RAT and its capacities here<\/a>.<\/p>\n\n\n\n

IOCs<\/strong><\/h2>\n\n\n\n