{
	"id": "05270d89-bd64-4827-b190-e5a66f32cb2a",
	"created_at": "2026-04-06T00:21:08.481855Z",
	"updated_at": "2026-04-10T03:33:20.07422Z",
	"deleted_at": null,
	"sha1_hash": "ce5d2096b4d274477ef7da69a6ebf55018dd7249",
	"title": "The Approach of TA413 for Tibetan Targets",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 928601,
	"plain_text": "The Approach of TA413 for Tibetan Targets\r\nBy Gameel Ali\r\nPublished: 2023-02-07 · Archived: 2026-04-05 19:20:22 UTC\r\nSummaryPermalink\r\nThis attack chain begins with the victim receiving a malicious RTF file through a phishing attack. When the\r\nvictim opens the RTF file, it contains a hidden encoded file which is then decoded and executed using a shellcode.\r\nThe executed file then performs process hollowing, injecting itself into the rundll32.dll process and establishing a\r\nconnection with the attacker’s command and control (C2) server.\r\nOnce connected to the C2 server, the infected machine begins sending data about itself to the attacker, who can\r\nthen use this information to send further modules and commands to the infected machine.\r\nTechnical analysisPermalink\r\nDuring our analysis, we collected some important information about the document file in question. By utilizing\r\nVirusTotal to scan the file’s hash, we were able to detect that the file is a RTF document that has been flagged by\r\n34 different security solutions. Further analysis revealed that the RTF document exploits several known\r\nvulnerabilities, including CVE-2017-11882, CVE-2017-8759, CVE-2018-0802, and CVE-2018-0798.\r\nhttps://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nPage 1 of 16\n\nUsing the tool rtfobj, we were able to extract multiple objects from the RTF document. Upon examining these\r\nobjects, we identified an exploit code. exploit code equation drop encode payload on temp folder\r\nTemp\\ghb4nrwmp.wmf . After deconding dropped file, it executed to reliver second stage.\r\nFurther investigation revealed that the RTF document is related to the Royal Road.\r\nRoyal Road: It is known for its use of weaponized Microsoft Office documents to deliver payloads, including\r\nransomware and other malicious software. The documents often exploit vulnerabilities in software such as Adobe\r\nReader or Microsoft Office to execute the payload without the user’s knowledge.\r\nRoyalRoad has been used in various campaigns targeting individuals and organizations around the world. It has\r\nbeen observed being delivered through spam emails, exploit kits, and other methods. Once the payload is\r\nhttps://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nPage 2 of 16\n\ndelivered and executed, it may perform various malicious actions such as encrypting files, stealing sensitive\r\ninformation, and installing other malware.\r\nDuring our analysis, we utilized the rr_decoder tool to decode the second stage payload of the RoyalRoad\r\nmalware, which was named “ghb4nrwmp.wmf”. The results of the decoding are shown in the figure below.\r\n$python3 rr_decode.py sample_ghb4nrwmp.wmf second_stage.exe\r\n[!] Type [b2a66dff] is Detected!\r\n[+] Decoding…\r\n[!] Complete!\r\nsecond stagePermalink\r\nUpon decoding the second stage payload of the RoyalRoad malware, second stage is packed. so we identified that\r\nit utilized the VirtualAlloc function multiple times to allocate a region of memory in which to copy shellcode.\r\nUpon transferring execution to the shellcode, we observed the use of obfuscation techniques such as stack strings\r\nto obscure the names of APIs. Further analysis revealed that the shellcode used the “LoadLibraryA” and\r\n“GetProcAddress” functions to resolve and locate APIs necessary for injecting the third stage of the malware into\r\nthe “rundll.dll” process.\r\nIn order to understand the injection process used by the RoyalRoad, we analyzed the behavior of the payload and\r\nidentified the following steps:\r\nThe malware utilizes the VirtualAlloc function to copy shellcode into a region of memory.\r\nThe shellcode uses stack strings to obscure the commandline.\r\nThe CreateProcA function is used to create a process in a suspended state (0x4) rundll32.dll .\r\nA handle to the target process is obtained to allocate a region of memory on it using VirtualAllocEx .\r\nThe third stage of the malware is copied into the target process using WriteProcessMemory `.\r\nThe third stage is executed using the ResumeThread function.\r\nFrom the previous steps, we can identif that second stage used process hollowing to inject third stage into\r\nrundll.dll and excute it using this commandline\r\nC:\\Windows\\system32\\rundll32.exe\"shell32.dll,Control_RunDLL\r\nthrid stagePermalink\r\nThe third stage of the malware is developed in C and functions as a backdoor to collect information about the\r\ninfected system and send it to the attacker. If the attacker determines that the infected system is of interest, they\r\nmay choose to drop the next stage of the malware.\r\nmutexPermalink\r\nUpon analysis of the malware, it was observed that the malware creates a mutex with the identifier “552FFA80-\r\n3393-423d-8671-7BA046BB5906.” This mutex is also used as the malware’s campaign name, as shown in the\r\nhttps://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nPage 3 of 16\n\nfollowing figure.\r\nobfuscationPermalink\r\nThe malware is equipped with a capability to encrypt strings using a simple XOR algorithm. This function was\r\nused by the malware to decrypt APIs into runtime in order to evade detection by static analysis tools. The malware\r\nalso loaded 4 libraries into runtime using this technique. It is worth noting that different keys were used to decrypt\r\nthe APIs and the libraries.\r\nThe keys used for decryption are as follows:\r\nhttps://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nPage 4 of 16\n\nKey for decrypting APIs : cffb9895f0dcddca9e8befc4aee9b1bf (in hex)\r\nKey for decrypting libraries: bf8a87e415cebb95aaf991b08ec486a4 (in hex)\r\nAfter decrypting the APIs, the malware was able to utilize the GetProcAddress function to resolve the APIs and\r\nload the libraries using LoadLibraryA. This allowed the malware to execute its desired functions at runtime and\r\nwe can include laoded libraries.\r\nws2_32.dll\r\nntdll.dll!\r\nadvapi32.dll\r\nwe can see our script to decrypted encrypted strings.\r\ndef unhex(hex_string):\r\n import binascii\r\n if type(hex_string) == str:\r\n return binascii.unhexlify(hex_string.encode('utf-8'))\r\n else:\r\n return binascii.unhexlify(hex_string)\r\ndef tohex(data):\r\n import binascii\r\n if type(data) == str:\r\n return binascii.hexlify(data.encode('utf-8'))\r\n else:\r\n return binascii.hexlify(data)\r\nout = []\r\ndata = unhex(\"c8f8b7b822f993f6ce9c9b\")\r\nkey = unhex(\"bf8a87e415cebb95aaf991b08ec486a4\")\r\nfor i in range(0, len(data)):\r\n \r\n out.append(i ^ data[i] ^ key[i \u0026 15])\r\nprint(bytes(out))\r\ncollecting sensitive informationPermalink\r\nfunction appears to be designed to gather and encode various system information. It does this by first decrypting\r\nseveral strings using the mw_decrypt_strings function. These strings are likely API names or other relevant\r\ninformation that is used later in the function.\r\nThe function then calls one of the decrypted functions (either GetNativeSystemInfo or GetSystemInfo) to retrieve\r\nsystem information and stores it in an array called system_info. This information may include details such as the\r\nsystem’s processor, memory, and operating system.\r\nhttps://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nPage 5 of 16\n\nThe function then encodes this information, as well as the hostname and username, using the mw_base64_encode\r\nfunction. The encoded strings are then concatenated into a single string.\r\ncollected information:\r\nUsername\r\nProcess name and Process ID\r\nIP Address\r\nHostname\r\nEvade DetectionPermalink\r\nAfter gathering and encoding data, the malware appears to use the LZF compression algorithm to compress the\r\ndata further. It then applies an XOR operation with the value 0x2b to encrypt each element of the compressed data\r\nbefore encoding it again using the base64 encoding method. This process may be used to reduce the size of the\r\ndata for easier transmission.\r\nEstablish a connectionPermalink\r\nMalware establish a connection with the server over a socket, so malware call htons to ensure that the data is\r\ncorrectly interpreted by the receiving system then call\r\nhttps://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nPage 6 of 16\n\nmw_create_listen: to create a socket that can listen for incoming connections.\r\nmw_send_socket_connection: to be used to send a socket connection request to a server.\r\nmw_establishing_connection_server: to be used to establish a connection with a server.\r\nimplemention of a simple HTTPPermalink\r\nThe malware appears to have implemented a simple HTTP client that can send HTTP requests to a server and\r\nreceive responses. The process begins by extracting the hostname and port number for the connection. A socket is\r\nthen created and a connection is established with the server.\r\nThe malware then constructs an HTTP request using the following format: “CONNECT %s:%d\r\nHTTP/1.1\\r\\nProxy-Connection: Keep-Alive\\r\\nContent-Length: 0\\r\\nHost: %s\\r\\nUser-Agent: %s\\r\\n”. The\r\nrequest is then sent to the server and a response is received. It is not clear how the response is processed or what\r\nthe purpose of the request is.\r\nhttps://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nPage 7 of 16\n\nEncryption data with AESPermalink\r\nAfter establishing a connection with the server, the malware appears to be utilizing the AES algorithm to encrypt\r\ndata before sending it to the server. It uses a ransom key as the initial key for the encryption process and then\r\nreceives a key from the server to encrypt the data again\r\nhttps://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nPage 8 of 16\n\nc2 responsePermalink\r\nmalware appears to use a specific method for receiving encrypted data from the server and decrypting it. This data\r\nis likely to be modules or commands that are used for specific tasks. The decryption process is reversing method\r\nthat was used to encrypt the data, which includes:\r\nLZF compression\r\nXORing with 0x2b\r\nBase64 encoding\r\nAES encryption with a randomly generated key\r\nAES encryption with a key derived from the XOR of the Client, Server Random Bytes Key\r\ncommandsPermalink\r\nmalware checkes the header of response with “PK” and receive also one commands or more and we can see the\r\ncommands in the next figure.\r\nCommand 2000 : which used to decode using base64, decrypt, with 0x2b key and decompress uing LZF.\r\nhttps://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nPage 9 of 16\n\nWe can see a table of commands\r\nNo. command info\r\n1 2000 which used to decode using base64, decrypt, with 0x2b key and decompress uing LZF\r\n2 2001 clear the command of data\r\n3 2002 set communication delay time\r\n4 2003 exit command loop\r\n5 2004 break connection\r\n6 2005 load module from attaker into memory\r\n7 2006 run module\r\n8 default listen for proxy connection\r\nAnalysis InfrastructurePermalink\r\nIt appears that the hostname “45.77.19.75.vultrusercontent.com” is associated with the domain\r\n“VULTRUSERCONTENT.COM” and is hosted by the cloud provider Vultr. The host is located in Japan,\r\nspecifically in the city of Ōi. The organization responsible for the host is Vultr Holdings, LLC, and the ISP\r\nhttps://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nPage 10 of 16\n\nis The Constant Company, LLC. The ASN associated with the host is AS20473. It is important to note that\r\nthe presence of a host or domain on a cloud provider does not necessarily indicate malicious activity.\r\nThe network and AS are likely used by the malware for communication with its command and control\r\n(C2).\r\nClassification and attributionPermalink\r\nAttribution refers to the process of identifying the source of a cyber attack or threat. It is often difficult to\r\naccurately attribute cyber attacks to a specific country, as attackers often use various tactics to hide their identity\r\nand location. There are a number of factors that can be used to help attribute a cyber attack to a specific country,\r\nincluding:\r\nVictimology: This refers to the characteristics of the victims of the attack, such as the type of organization or\r\nindustry they belong to. If a group of attacks all target organizations in a specific country, it can be a strong\r\nindication that the attacks are coming from that country.\r\nInfrastructure: If a group of attacks all use the same infrastructure, such as a specific set of servers or domain\r\nnames, this can be used to help attribute the attacks to a specific country or group.\r\nTactics, Techniques, and Procedures (TTPs): The specific tactics and techniques used in an attack can often be\r\nused to identify the group or country behind the attack.\r\nMalware used: The type of malware used in an attack can often be used to attribute the attack to a specific group\r\nor country.\r\nA spreadsheet targeting a Tibetan organization was used and a domain, tibet[.]bet, was attributed to the TA413\r\ngroup for the attack. ansd we can see that in the next figure.\r\nhttps://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nPage 11 of 16\n\nIn this particular case, TA413 are known to have impersonated the “Department of Religion \u0026 Culture.” This type\r\nof social engineering tactic is often used to trick individuals into revealing sensitive information or downloading\r\nmalware.\r\nhttps://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nPage 12 of 16\n\nideas how to track activity of this tool:Permalink\r\nSet up a YARA rule to identify the RTF version of the Royal Road tool or any associated indicators of\r\ncompromise (IOCs). This can be done by analyzing the characteristics of the RTF file, such as specific\r\nstrings of code or patterns of behavior, and creating a rule that matches these characteristics.\r\nUse YARA to scan your network for any instances of the RTF version of the Royal Road tool or associated\r\nIOCs. This can be done by running YARA on a schedule, such as daily or weekly, or in real-time as part of\r\na threat hunting process.\r\nWhen YARA detects a match, conduct further investigation to determine the scope and impact of the RTF\r\nversion of the Royal Road tool on your network. This may involve analyzing network traffic, examining\r\nsystem logs, and performing forensic analysis on affected systems.\r\nTake appropriate remediation steps to remove the RTF version of the Royal Road tool from your network\r\nand secure any affected systems. This may involve isolating infected systems, patching vulnerabilities, and\r\nimplementing additional security measures to prevent future attacks.\r\nUse threat intelligence sources to stay informed about the latest tactics and techniques used by APT groups,\r\nincluding those that use the RTF version of the Royal Road tool. This can help you stay ahead of potential\r\nthreats and better defend your network.\r\nhttps://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nPage 13 of 16\n\nTTPsPermalink\r\nYara RulePermalink\r\nrule lowzero_malware: lowzero\r\n{\r\n meta:\r\ndescription = \"Detect_lowzero_malware\"\r\n author = \"@malgamy12\"\r\ndate = \"2022/12/26\"\r\nlicense = \"DRL 1.1\"\r\n hash = \"de44e5f6cfac9cd3e61194efd5c2b20ba44c437a520fe7018ed7f623e66f8131\"\r\n \r\n strings:\r\n \r\n $pdb = \"Proxy-Authorization: NTLM \" ascii\r\n \r\n $op = {8B C1 8D 14 39 83 E0 ?? 8A 44 05 ?? 32 04 16 32 C1 41 88 02 3B CB}\r\n \r\n condition:\r\n uint16(0) == 0x5A4D and all of them\r\n}\r\nhttps://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nPage 14 of 16\n\nIOCsPermalink\r\nFrist stagePermalink\r\n9681ef910820d553e4cd54286f8893850a3a57a29df7114c6a6b0d89362ff326\r\nsecond stagePermalink\r\n028e07fa88736f405d24f0d465bc789c3bcbbc9278effb3b1b73653847e86cf8\r\nthird stagePermalink\r\nde44e5f6cfac9cd3e61194efd5c2b20ba44c437a520fe7018ed7f623e66f8131\r\nIPPermalink\r\n45.77.19.75\r\ndomainPermalink\r\nchorig-org.web.app\r\ndesktoppreview.com\r\nodc.officeapps.live.com\r\nip addressesPermalink\r\n131.107.255.255\r\n45.77.19.75\r\n199.36.158.100Permalink\r\nurlsPermalink\r\nhttps://chorig-org.web.app/Application-form-Sixmonth-workshop-2022V1.doc\r\nhttp://chorig-org.web.app/Application-form-Sixmonth-workshop-2022V1.doc\r\nhttp://desktoppreview.com/salvoed.dotx\r\nhttps://desktoppreview.com/salvoed.dotx\r\nFilesPermalink\r\n0b30433bb80abd4b1978fa84d953c13f4d7b726cd533e3c50cef36b4e79f2d2e\r\ncfc72b48732286a2beab5d0fc60aabc8d529faf4d0fb262b99a092096a187dc0\r\n1351dca77922b22ab5dae0689550cb55807900348a42b5dc71b01a5a78602b0f\r\n9681ef910820d553e4cd54286f8893850a3a57a29df7114c6a6b0d89362ff326\r\nba2c89192643f05e64f49b5cb3513a6a5bbfa719225af3b72c83587b8b774e8d\r\nhttps://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nPage 15 of 16\n\nd987e80a23f334c5eb50c9883a6b5b1b2090230f950fa5eb7cec0a2d74f5271b\r\n3a69c1453b8062620837ab32be68ed871df383e24e68161839508a98bf7033b8\r\nc0fc6a2ba864650af25b9da8e70396cdb40e8a196f7f0ce6024ff67a080346dc\r\nc44be5ed5c4bec2be72ce9737bde5a2d48fe5fb0ea235ddc61ba447b26642949\r\nc8934c7b3187e48b1ee44fc2c8e1c3ab19850efc1e45383442cfe4b9b4a06d01\r\n9b79fbbc895ca98b951aecd664cdd7ce69f63901996c7341a560d7c207a143ea\r\n65bddf8148ed60f5625b3495baba0824d2fcd13a710494817c7a84e0062ce227\r\n1120275dc25bc9a7b3e078138c7240fbf26c91890d829e51d9fa837fe90237ed\r\n4f941e1203bf7c1cb3ec93d42792f7f971f8ec923d11017902481ccf42efaf75\r\n67458476cc289f7d0f0bda8938f959b8a1a515e23f37c9d16452b2e1d8adf5a4\r\n7d9e22ae60cb85c4dbdceac46d33fc080b89df23607ab4904b3795d9a9765b82\r\nc83c28add56ec8cad23a14155d5d3d082a1166c64ea5b7432e0acaa728231165\r\nb7bebe92a5802aa922e5719c948e35716f908e67701cfffaeebfcadc7a6e650a\r\n0eb7ba6457367f8f5f917f37ebbf1e7ccf0e971557dbe5d7547e49d129ac0e98\r\nReferences:\r\nhttps://www.recordedfuture.com/chinese-state-sponsored-group-ta413-adopts-new-capabilities-in-pursuit-of-tibetan-targets\r\nhttps://nao-sec.org/2020/01/an-overhead-view-of-the-royal-road.html\r\nhttps://github.com/nao-sec/rr_decoder\r\nSource: https://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nhttps://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage\r\nPage 16 of 16\n\nmalware checkes commands in the the header of next figure. response with “PK” and receive also one commands or more and we can see the\nCommand 2000 : which used to decode using base64, decrypt, with 0x2b key and decompress uing LZF.\n   Page 9 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://malgamy.github.io/malware-analysis/The-Approach-of-TA413-for-Tibetan-Targets/#third-stage"
	],
	"report_names": [
		"#third-stage"
	],
	"threat_actors": [
		{
			"id": "b740943a-da51-4133-855b-df29822531ea",
			"created_at": "2022-10-25T15:50:23.604126Z",
			"updated_at": "2026-04-10T02:00:05.259593Z",
			"deleted_at": null,
			"main_name": "Equation",
			"aliases": [
				"Equation"
			],
			"source_name": "MITRE:Equation",
			"tools": null,
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "3b1367ff-99dc-41f0-986f-4a1dcb41bbbf",
			"created_at": "2022-10-25T16:07:24.273478Z",
			"updated_at": "2026-04-10T02:00:04.918037Z",
			"deleted_at": null,
			"main_name": "TA413",
			"aliases": [
				"White Dev 9"
			],
			"source_name": "ETDA:TA413",
			"tools": [
				"Exile RAT",
				"ExileRAT",
				"Sepulcher"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "9792e41f-4165-474b-99fa-e74ec332bd87",
			"created_at": "2023-01-06T13:46:38.986789Z",
			"updated_at": "2026-04-10T02:00:03.172308Z",
			"deleted_at": null,
			"main_name": "Lucky Cat",
			"aliases": [
				"TA413",
				"White Dev 9"
			],
			"source_name": "MISPGALAXY:Lucky Cat",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "86182dd7-646c-49c5-91a6-4b62fd2119a7",
			"created_at": "2025-08-07T02:03:24.617638Z",
			"updated_at": "2026-04-10T02:00:03.738499Z",
			"deleted_at": null,
			"main_name": "BRONZE HOBART",
			"aliases": [
				"APT23",
				"Earth Centaur ",
				"KeyBoy ",
				"Pirate Panda ",
				"Red Orthrus ",
				"TA413 ",
				"Tropic Trooper "
			],
			"source_name": "Secureworks:BRONZE HOBART",
			"tools": [
				"Crowdoor",
				"DSNGInstaller",
				"KeyBoy",
				"LOWZERO",
				"Mofu",
				"Pfine",
				"Sepulcher",
				"Xiangoop Loader",
				"Yahaoyah"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434868,
	"ts_updated_at": 1775792000,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ce5d2096b4d274477ef7da69a6ebf55018dd7249.pdf",
		"text": "https://archive.orkl.eu/ce5d2096b4d274477ef7da69a6ebf55018dd7249.txt",
		"img": "https://archive.orkl.eu/ce5d2096b4d274477ef7da69a6ebf55018dd7249.jpg"
	}
}