{ "id": "7fd82b88-91c1-40a0-8e20-018301d60e3f", "created_at": "2026-04-06T00:11:23.473378Z", "updated_at": "2026-04-10T03:20:56.47768Z", "deleted_at": null, "sha1_hash": "13e5e8887b45109e620b6d55eba7a88843a09eca", "title": "TokyoX: DLL side-loading an unknown artifact (Part 2)", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 415069, "plain_text": "TokyoX: DLL side-loading an unknown artifact (Part 2)\r\nPublished: 2022-01-12 · Archived: 2026-04-05 13:35:22 UTC\r\nAs we mentioned in the previous post, we have performed an analysis of the threat which, lacking further\r\ninformation, we have not been able to identify it as a known threat. Thus, for the moment, we will keep referring\r\nto it as TokyoX.\r\nThis threat can only be found in memory, since it is encrypted on disk and its loading is performed as described in\r\nthe previous post.\r\nAfter the whole loading process, the first thing the threat does is to check for the existence of a mutex in the\r\nsystem with the name “aftdoslm” and if it finds it, it terminates its execution in order to avoid multiple instances\r\nof the threat running in parallel.\r\nIt then generates a 32-character string similar to a md5 hash from the computer’s file system and Volume\r\ninformation, which is used as the victim ID and placed at the beginning of every packet it sends to the command\r\nand control server:\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact-part-2/\r\nPage 1 of 6\n\nIt then obtains the user name, computer name, local IP and operating system version, with which it builds a string\r\nand generates a first packet for the C2:\r\nAt the time of the analysis the command and control server was not available. For that reason, some fields of the\r\npackets a priori not used by the threat, could not be identified. However, from the analysis of the threat assembly,\r\nit has been possible to observe that the response of the C2 is very similar to those sent by the threat, since it most\r\nlikely contains the first 44 bytes of the threat request or a very similar content: the victim ID (in red) , the first\r\nthree dwords (in green). After that part, it will have a fourth dword (in blue) that consists of a command code\r\nsupported by the threat, after which, depending on the command, it may contain one information or another (in\r\nyellow).\r\nThe command code in question goes in LittleEndian, so for the command 7010, the field should contain “10 70 00\r\n00”. Inside the threat code, a switch can be found that identifies 6 different commands:\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact-part-2/\r\nPage 2 of 6\n\nThe first one is “6010”, which can be seen in the screenshot along with the contents of the network packet. This\r\ncommand is not among the options accepted by the threat, but it is the one that the threat itself uses when it sends\r\nthe first packet to the command and control server, and we assume that it is the one used as a beacon when it does\r\nnot intend to do anything, since a command that is not supported by the switch statement will simply cause a 5-\r\nminute sleep and a new request to C2 after this time.\r\nSecond comes the “6011” command which is relatively interesting since it first calls a function that will delete all\r\nthe infection files and terminate the execution of the threat. The fact that makes it interesting to us is that after this\r\ncall, inside the switch that controls each command, it appears again as a command to perform no action (in this\r\ncase it should be the 6010 probably) and make another request to C2, although this code will never be executed\r\nbecause the initial function will close the process.\r\nThe next command is “7010” which scans the disks installed in the computer using the\r\n“GetLogicalDriveStringsW” API and sends the results to the command and control server.\r\nThe command “7011” imitates the “Dir” command as it receives after the code a folder path, and allows it to list\r\nthe content of a folder, showing hidden and system files too.\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact-part-2/\r\nPage 3 of 6\n\nThe next command “7017” expects, after the command code, a structure with three dwords followed by a path\r\nwith a filename, and allows to upload a file from the attacking computer to the victim machine. In order to do so,\r\nit first creates an empty file and then generates a new thread that will make a second request to the command and\r\ncontrol server. Within the response from the C2, this request expects the contents of the file to be uploaded, which\r\nthe requesting thread will store in the file generated by the main thread.\r\nSimilarly, the command “7018” also expects after the command code a structure with three dwords, identical to\r\nthe “7017” command, followed by a path with a filename. In this case, it generates a new thread that tries to read\r\nthat file within the victim computer and makes a second request to the C2 containing the raw content, allowing the\r\nattacker to exfiltrate files from the infected computer.\r\nWith respect to the three dwords received before the file path, it has only been possible to identify the third one for\r\nthe moment, which consists of the total size of the file to be sent or received and is used before obtaining the file\r\nto reserve a buffer of that size, plus one in the Heap of the application in order to recover the content there before\r\ndumping it to disk or reading it from disk.\r\nFinally, there is the “8001” command with a command string to be run in a cmd.exe shell, since it calls\r\nCreateProcessW for “cmd.exe” with the input and output redirected by anonymous pipes to the executable itself.\r\nThen, it executes the command received in the request and replies to the C2 with the output of that command, thus\r\nforming a remote Shell of the victim machine.\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact-part-2/\r\nPage 4 of 6\n\nAlthough we do not have enough evidence to make any kind of attribution, there are some characteristic TTPs\r\nin the infection chain: the attacker using a Dll-sideload with a legitimate binary and a library, the fact that the\r\nlibrary is responsible for decrypting and executing a third encrypted file in memory, and the fact of removing the\r\nMZ characters from the beginning of the binary and replacing them with another string. This last characteristic is\r\nvery common in APT groups that use PlugX as the main threat, where instead of using “tokyo” to replace MZ,\r\nthey usually add “plug” at the beginning, which has motivated the name of the threat.\r\nAll of this explains the attribution of this hash to PlugX by some antivirus engines, although as it has been\r\nobserved in the post, it is a somewhat smaller threat, which is not developed in Delphi as plugx and that keeps a\r\ngreater resemblance to HttpBrowser in terms of capabilities. However, HttpBrowser does not share code or style\r\nof command codes with this sample, so it is most likely a different tool for the first infection stage.\r\naftdoslma Mutex\r\nC:\\Users\\Public\\Z46F4501-F44G-4DLS-AV8E-4E4DFDY918FG-DL5F102TVSFG7\r\nPath\r\n382b3d3bb1be4f14dbc1e82a34946a52795288867ed86c6c43e4f981729be4fc Dll\r\n3493331e8f6151a37a48d11243e0fa32e756e8ca78a454912630865b48a43693\r\nTokyoX\r\nciphered\r\n6370aa86e4bd2079913553bf34a5fe983b54d4907d168b278d6fe3caaf278d13 Zip File\r\n31.192.107[.]187:443 C2\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\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact-part-2/\r\nPage 5 of 6\n\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-part-2/\r\nhttps://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact-part-2/\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://lab52.io/blog/tokyox-dll-side-loading-an-unknown-artifact-part-2/" ], "report_names": [ "tokyox-dll-side-loading-an-unknown-artifact-part-2" ], "threat_actors": [], "ts_created_at": 1775434283, "ts_updated_at": 1775791256, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/13e5e8887b45109e620b6d55eba7a88843a09eca.pdf", "text": "https://archive.orkl.eu/13e5e8887b45109e620b6d55eba7a88843a09eca.txt", "img": "https://archive.orkl.eu/13e5e8887b45109e620b6d55eba7a88843a09eca.jpg" } }