{
	"id": "33990cf6-6ff0-4a40-bb9d-d94b064ad21e",
	"created_at": "2026-04-06T00:13:17.840042Z",
	"updated_at": "2026-04-10T03:20:16.646452Z",
	"deleted_at": null,
	"sha1_hash": "e8e5dc6cc8e10e374d501aa139c03c995212dd21",
	"title": "TokyoX: DLL side-loading an unknown artifact",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 6658115,
	"plain_text": "TokyoX: DLL side-loading an unknown artifact\r\nPublished: 2022-01-10 · Archived: 2026-04-05 23:04:25 UTC\r\nDuring Christmas holidays, Lab52 has been analyzing a sample which loads an artifact that we have decided to\r\nrefer to as “TokyoX” since no similarities have been found as to any known malware, which we usually detect in\r\nopen sources. However, we cannot confirm so far that it is indeed a new family of malware.\r\nThe first thing we identified was a DLL\r\n(382b3d3bb1be4f14dbc1e82a34946a52795288867ed86c6c43e4f981729be4fc) which had the following\r\ntimestamps in VirusTotal at the time of the current analysis, and was uploaded from Russia via web site:\r\nCreation Time 2021-12-09 02:46:43\r\nFirst Submission 2021-12-09 08:48:20\r\nLast Submission 2021-12-09 08:48:20\r\nLast Analysis 2021-12-23 23:38:08\r\nSome antivirus engines tagged the sample as PlugX, but it seems that the attribution might be due to the final\r\npayload’s loading mechanism: DLL sideloading with an encrypted payload in the same directory. After analyzing\r\nthe final payload we could not find any similarities with other known samples from PlugX other than the loading\r\nTTPs.\r\nThis DLL had a related .zip file with the name планирование.zip (translated to as planning.zip). When unzipping,\r\nthe following files are observed:\r\nThe legitimate file Creative.exe, an encrypted Data file and the version.dll DLL, which implements the loader\r\nfunction for the Data file, and therefore responsible of mapping the “TokyoX”.\r\nIf we execute it from a path which is not final or the expected by the malware, it replicates to another path and\r\nexecutes from there, which is something it does have in common with some PlugX dll loaders:\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nPage 1 of 16\n\nOnce executed, we observe how the netsh.exe process tries to establish connections with port 443 of the IP\r\naddress 31.192.107[.]187.\r\nIn this analysis we will focus on different aspects about the process; from double-clicking the binary 123.exe\r\nprocess (which is a copy of Creative.exe but in another path) to the execution of “TokyoX” already decrypted in\r\nmemory.\r\nThe first thing we observe within the process is how the version.dll library prepares the decryption and the final\r\npayload’s loading in the remote process:\r\nIn fact, we can see how the content of the Data file is read in the code section of version.dll:\r\nIf we edit the Data file with a hexadecimal editor we will see their values, which will help us to identify it in\r\nmemory later (beginning with E3 84):\r\nAfter reading the file from disk, a child process netsh.exe is created. This just-created child process is where\r\nseveral new memory segments will be located (a total of 5, including the final decrypted payload) to decrypt the\r\nfinal “TokyoX” payload. The APIs which were observed for the creation and writing of the remote process are the\r\nnative APIs NtAllocateVirtualmemory and NtwriteVirtualmemory.\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nPage 2 of 16\n\nFirst, it creates two segments: 100Kb where the encrypted payload is located and which comes from the disc, and\r\nanother one of 4Kb. In the 4Kb segment we observe how the following string is set (which will be the string used\r\nfor the decrypting process):\r\nThe other memory segment of 100Kb contains the following (encrypted content, as we see how it matches the\r\ncontent from Data file on Disk):\r\nAfter the creation of these two segments, a third segment is allocated, where it is loaded the absolute memory\r\naddresses from several win32 APIs (VirtualAlloc, LoadLibrary, GetProcAddress, the home address of the coded\r\npayload, etc.) for its later use by the loader:\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nPage 3 of 16\n\nWe can notice how the segment will have the memory addresses (starting from 123.exe they are located in\r\nnetsh.exe segment through the version.dll code):\r\nThen, another segment of 4Kb is created where it loads the code that will decrypt and load the final payload.\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nPage 4 of 16\n\nFinally, the “TokyoX” loader runs from the DLL (version.dll) in netsh.exe through the API NtcreateThreadEx and\r\nwe see the start of the last page created in the stack:\r\nAfter the execution of NtCreateThreadEx, as indicated, the loader is initiated in netsh.exe in the segment:\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nPage 5 of 16\n\nOnce the execution is moved to the netsh.exe process, it takes the string located in the initial 4Kb segment, copies\r\nit into the stack and replicates it (0x100, 256 bytes) to match the specific block size of 256bytes. In the following\r\nscreenshots we can observe how the block ends with the string “!Up?” when it reaches the value 0x100 in\r\nhexadecimal.\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nPage 6 of 16\n\nAfter the block is created with the replicated string, the values from 00 to FF are found and used for the\r\ndecrypting process.\r\nAt this point, the loader transforms the 00-FF block with a series of additions combining the replicated string’s\r\nblock with the 00-FF block, as we can see:\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nPage 7 of 16\n\nThe combination of the blue block (in following image) and the 00-FF block (pointed in red in previous image)\r\nresults in the following block in memory, marked in red in the image:\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nPage 8 of 16\n\nOn the next step, the loader reads the initial argument, arg0, whose value is 0x900000 and points at the 4Kb block,\r\nwhich stores the absolute addresses to different API from Win32:\r\nAfter this, the decrypting process for the final payload begins. The decrypting process gets two values from the\r\nsecond block, exchanges and adds them, and the result serves as a final index to recover the element from the\r\nsecond block with which the xor will be achieved through the coded block.\r\nThis description of the decryption algorythm has been identified as the RC4 algorythm.\r\nAfter the decryption process, we find a PE binary, as seen in the following image. In this case, the payload does\r\nnot start with the traditional MZ header but the string “tokyo”:\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nPage 9 of 16\n\nThen, we see how it loads the VirtualAlloc absolute address (0x77211856) from the segment previously created:\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nPage 10 of 16\n\nThis creates another memory segment in the process netsh.exe with RWX licenses (that of 116Kb) which will be\r\nused to load the PE:\r\nIn this new segment, it maps the binary using the virtual addresses as the regular Windows PE loader would do.\r\nThen, it calls the API LoadLibraryA (it has the address since the DLL saved it in the memory segment) of the\r\nstrings located in the mapped block:\r\nThen it calls GetProcAddress() to get the addresses of certain functions:\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nPage 11 of 16\n\nNext, the libraries and functions block may be appreciated:\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nPage 12 of 16\n\nAfter the correct mapping and having loaded the necessary libraries for its proper functioning, it calls EAX to run\r\nthe decrypted and mapped payload:\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nPage 13 of 16\n\nTo summarize, this article goes through the process followed in memory after executing the Creative Cloud\r\napplication until deploying TokyoX in memory. This DLL sideloading style is often linked to APT groups whose\r\nattribution is also linked to China, however being a known technique as it is, we are not able to consider any\r\nfeasible attribution at the moment.\r\nAs reviewed at the beginning of the article, what we have named as “TokyoX” has not been identified as a known\r\nmalware so far (at least, with the sources that we have).\r\nAdditionally, at some point of the analysis we identified a tool used by this group for the creation of version.dll,\r\nwhich pretends to be a Windows DLL located in SysWOW/System32. The string “AheadLib” found among the\r\ncode of the malicious version.dll drew our attention, and we quickly found two chinese (casually or not) GitHub\r\nrepositories with the source code of some tool called AheadLib.\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nPage 14 of 16\n\nBasically, this tool will allow you to create a C++ source code file, implementing a DLL with the same exported\r\nfunctions as a given DLL. For the purpose of the current analysis we generated a source code file using this tool\r\nand giving the legitimate version.dll as input.\r\nIn the shown screenshot we can see on the left side the pseudocode generated by IDA Pro while analyzing the\r\nmalicious version.dll sample. On the right side, we can observe the source code automatically generated by\r\nAheadLib using the legitimate version.dll as input. Even though the exported functions are not shown in the\r\nprevious image, we can appreciate how there is a perfect match between both snippets.\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nPage 15 of 16\n\nRead the second part of the analysis of the final “TokyoX” RAT and its capacities here.\r\nIOCs\r\n382b3d3bb1be4f14dbc1e82a34946a52795288867ed86c6c43e4f981729be4fc\r\n31.192.107[.]187:443\r\nCustomers with Lab52’s APT intelligence private feed service already have more tools and means of detection for\r\nthis campaign.\r\nIn case of having threat hunting service or being client of S2Grupo CERT, this intelligence has already been\r\napplied.\r\nIf you need more information about Lab52’s private APT intelligence feed service, you can contact us through the\r\nfollowing link\r\nSource: https://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact/"
	],
	"report_names": [
		"tokyox-dll-side-loading-an-unknown-artifact"
	],
	"threat_actors": [],
	"ts_created_at": 1775434397,
	"ts_updated_at": 1775791216,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e8e5dc6cc8e10e374d501aa139c03c995212dd21.pdf",
		"text": "https://archive.orkl.eu/e8e5dc6cc8e10e374d501aa139c03c995212dd21.txt",
		"img": "https://archive.orkl.eu/e8e5dc6cc8e10e374d501aa139c03c995212dd21.jpg"
	}
}