{
	"id": "56eba25f-da30-4315-88ed-76224ed8bc07",
	"created_at": "2026-04-06T01:32:17.087107Z",
	"updated_at": "2026-04-10T13:12:44.986827Z",
	"deleted_at": null,
	"sha1_hash": "baf22f7cb2090d828711063754f6a29ac386028a",
	"title": "VELETRIX Loader Dissection: Kill Chain Analysis of China-Nexus Telecommunications Infrastructure Targeting - 0x0d4y Malware Research",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4051018,
	"plain_text": "VELETRIX Loader Dissection: Kill Chain Analysis of China-Nexus Telecommunications Infrastructure Targeting - 0x0d4y\r\nMalware Research\r\nBy 0x0d4y\r\nPublished: 2025-07-02 · Archived: 2026-04-06 00:21:08 UTC\r\nIn my work I had the opportunity to analyze a China-Nexus Threat Actor, called Earth Alux, and this research,\r\nwhich only covers the fundamental points of the Kill Chain and the analysis of some components of its Toolkit,\r\nwas the starting point of a long process of studies on how the Chinese state invested in its Cyber Warfare\r\ncapabilities in the long term. This long process of studies, which is still ongoing, led me to analyze several China-Nexus Threat Actors and their most recent campaigns, especially the most recent ones. This post is one of the\r\nfruits of my process of studying China’s capabilities in employing Cyber Warfare that is aligned with state\r\ninterests.\r\nChinese State Turns to Cyber Warfare\r\nFirst, it is extremely important to understand that the China-Nexus Threat Actors do not have the same banal\r\nmotivations as the eCrime Threat Actors. For decades, the Chinese state has incorporated the cyber warfare project\r\ninto civil society, and it is a civic duty of citizens and private companies to collaborate with the objectives aligned\r\nwith the Chinese state. It may not seem that impressive, but China has worked for decades to become one of the\r\nworld’s technological powers today, and has incorporated policies that use cyber warfare to its advantage, through\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 1 of 31\n\nthe PLA (People’s Liberation Army) and MSS (Ministry of State Security) units, which are used to conduct cyber\r\ncampaigns against private companies, governments, and critical structures, with the aim of meeting the needs of\r\nthe state. Literally, cybersecurity at the service of the state.\r\nThis makes me think that the China-Nexus Threat Actors have the most sophisticated motivations of all. It’s not as\r\nsimple as a threat actor wanting to make an impact to generate revenue for themselves; the China-Nexus are cyber\r\nthreats driven by state interests. They can compromise organizations only to silently persist in their infrastructure\r\nfor years, just to gather intelligence in the long term, and become a few steps ahead of the Chinese state’s\r\ncompetitors.\r\nThe cybersecurity market, especially those that invest heavily in marketing, talk a lot about Cyber Warfare when\r\nreferring to Ransomware groups, or Malware-as-a-Service operated by e-Crime, but the real Cyber Warfare is that\r\nwhich is waged by states and not by cyber criminals with financial purposes. Cyber Warfare causes diplomatic and\r\nfinancial market disputes, causes theft of intellectual property, or causes mass espionage through infiltration of\r\ntelecommunications companies. And this is exactly the case that I will discuss in this post.\r\nChina Targets Country’s Own Telecommunications\r\nIn this post, I will analyze a campaign that was named DragonClone by the Seqrite Labs APT-Team, whose\r\nresearch can be found here.\r\nThis is an example where it is possible to observe a sophistication in the motivation of the Threat Actor China-Nexus. Here, the objective is not necessarily the theft of intellectual property of a certain product, or the impact of\r\nencrypting the main servers of the victim’s Domain. In this campaign, the Threat Actors infected the company\r\nChina Mobile Tietong Co., Ltd, which is a subsidiary of China Mobile, one of the largest companies in the\r\ntelecommunications industry in China. In other words, by compromising a Telecommunications company, the\r\nadversaries have access to the entire backbone responsible for this company, consequently, the adversaries have\r\naccess to all the traffic that passes through this backbone. Mass Espionage.\r\nThis allows us to observe how strategic the China-Nexus Threat Actors are, allowing the Chinese state to remain\r\nwell positioned to identify, respond to any future state threat. Now let’s analyze the technical aspect of the\r\ncampaign.\r\nTechnical Analysis of the DragonClone Campaign\r\nBelow, we can see the general flow of the infection that we are going to unravel, and as we can see, the initial\r\naccess is made through the Spearphishing technique (T1566.001), delivering to users a ZIP file that contains\r\nbinaries related to an internal training program for employees of China Mobile Tietong Co., Ltd. Wondershare\r\nsoftware, specifically Recoverit. But when executed, the benign software will execute a malicious DLL placed by\r\nthe Threat Actor, with the aim of loading a 2nd stage into memory.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 2 of 31\n\nThe component that was Sideloaded is a DLL that Wondershare contains a dependency on, which the Threat Actor\r\nreplaced with a loader customized by the adversary identified as VELETRIX.\r\nThe ZIP file we will use in this analysis contains the SHA256 below.\r\nSHA256:\"fef69f8747c368979a9e4c62f4648ea233314b5f41981d9c01c1cdd96fb07365\"\r\nWithin the ZIP file it is possible to observe several binaries, however, the main one that is targeted by\r\nSpearphishing is the one identified as “2025年中国移动有限公司内部培训计划即将启动，请尽快报名.exe“,\r\nin which is translated to “China Mobile Limited’s internal training program for 2025 is about to start, please\r\nsign up as soon as possible“. As we can see, the filename has a social engineering component that as we said\r\nbefore, targeting the China Mobile Tietong Co. employees.\r\nBelow, we can see the point exploited with DLL Side-Loading, where the main Wondershare software has a DLL\r\ndependency with  drstat.dll , as we can see below.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 3 of 31\n\nIt is at this point in the kill chain that the Threat Actor will abuse this dependency, executing a malicious chain\r\nthrough the legitimate software. So, let’s analyze the drstat.dll DLL placed in the ZIP file by the Threat Actors.\r\ndrstat.dll Reverse Engineering\r\nWhen we load the binary in Binary Ninja, we can see the exports of this DLL in the Triage Summary view.\r\nNone of the exports listed above do something, except the exported function  dr_data_stop . This is the only\r\nfunction that has a routine, and, it is the main function of the  VELETRIX .\r\nWhen this function is called by the legitimate binary, the first routine to be executed is the  Anti-Sandbox  routine,\r\nexecuting the GetTickCount in the beginning and in the end of the  Anti-Sandbox  loop. The loop is compound by\r\na 10 seconds sleep (with Sleep API) and checking the sound in the system with Beep call.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 4 of 31\n\nAfter the Anti-Sandbox routine is completed, VELETRIX’s main function is to start the dynamic API loading\r\nroutine with LoadLibraryA and GetProcAddress, as we can see in the Disassembly code snippet below, where the\r\nadversary tries to evade detection and hinder the analysis through the Stack Strings technique.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 5 of 31\n\nAll of the Windows APIs that is loaded in this routine you can see below.\r\nVirtualAllocExNuma;\r\nVirtualProtect;\r\nEnumCalendarInfoA;\r\nSystemFunction036 (RtlGenRandom);\r\nHeapAlloc;\r\nHeapFree;\r\nRtlIpv4StringToAddressA.\r\nAnd here’s the interesting thing, if you look at the strings in the VELETRIX binary, you’ll see a large number of\r\nIPv4 addresses. These addresses together are the encrypted shellcode that VELETRIX loads upon execution.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 6 of 31\n\nThis is not a new method of obfuscation, but it is quite unusual. It works because each byte (in hexadecimal) of\r\nthe shellcode can be represented by an octet of an IPv4 address. The work that the adversary had to do was to\r\naggregate four octets (4 bytes) and transform them visually into IPv4 addresses. To convert IPv4 addresses into\r\nbytes, it is necessary to use the RtlIpv4StringToAddressA API, which is exactly the routine that VELETRIX\r\nexecutes.\r\nAfter deobfuscating the Shellcode, VELETRIX subjects each byte to an XOR operation with the key 0x6f, with\r\nthe aim of decrypting the previously obfuscated Shellcode.\r\nI implemented a script in Python in uploaded in my Github (the link is in the Reference section), which aims to\r\nexecute the same algorithm flow, that is, receive the list of IPv4 addresses, transform the octets into their\r\ncorresponding bytes and finally submitting the byte to a single-key XOR operation  0x6f . At the end of this\r\ndecryption flow we will have the decrypted Shellcode.\r\nVELETRIX implements an unconventional method of Shellcode injection, opting to use\r\nthe  EnumCalendarInfoA  API. Basically, VELETRIX allocate a memory space and change the protection\r\nthrough  VirtualProtect  to  PAGE_EXECUTE_READWRITE  permissions, in this space it will be placed the Shellcode\r\naddress as the first argument of the  EnumCalendarInfoA  API call, since it expects to receive the application-defined callback function. Thus, the API will execute the code present in the address given in the first\r\nargument  lpCalInfoEnumProc . With this unconventional implementation, the Shellcode will be executed and may\r\nescape detections that conventional methods monitor. Below, we can see this implementation.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 7 of 31\n\nShellcode Reverse Engineering\r\nThe first action to be performed is to collect the kernel32.dll DLL by accessing the memory structures through the\r\nPEB.\r\nBy collecting the address of kernel32.dll, Shellcode de-hashes the LoadLibraryA API, which will be used to load\r\nthe other DLLs. The DLL names were placed in Stack Strings, with the aim of evading detection.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 8 of 31\n\nBelow, you can more easily observe the DLL loading flow followed by the API Hashing process.\r\nThe Hashing algorithm is simple, being based on the ROR13 algorithm, as we can see below.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 9 of 31\n\nFrom this point on, the Shellcode will use the WinSocket library to communicate with its Command and Control\r\nserver. Below we can see the network communication setup\r\nWSAStartup – Initialize Winsock\r\nWSASocketA – Create socket\r\nconnect – Establish connection\r\nsend – Send data\r\nrecv – Receive data\r\nclosesocket – Clean up socket\r\ngethostbyname / inet_addr – DNS resolution\r\nBelow we can see the use of WSAStartup to start the socket initialization process.\r\nBelow you can see the socket setup, where you can see that Shellcode will use the TCP protocol to establish the\r\nconnection.\r\nThe IP address of the Command and Control server is hardcoded via Stack String, as can be seen in the image\r\nbelow, being  62.234.24.38 .\r\nAnd to validate that this is in fact the Command and Control IPv4 address, we just need to look at the score of this\r\nIP address on VirusTotal, and the country of origin being China.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 10 of 31\n\nBelow we can see the Shellcode finally calling the  connect  API, with the aim of connecting to the Command\r\nand Control address identified previously.\r\nBelow we can see the loop implemented in Shellcode, which allows a certain persistence of communication.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 11 of 31\n\nAnd here’s the interesting part! Shellcode has the ability to receive encrypted data from the Command and Control\r\nserver, decrypt it through a simple  XOR  algorithm with the key  0x99 , then execute it at a previously allocated\r\naddress with  PAGE_EXECUTE_READWRITE  permissions. Below, we can see the flow of what was briefly described.\r\nThis is interesting because what we know through public intelligence is that  VELETRIX  carries\r\na  VShell  shellcode which is an  Offensive Security Tool , like  Meterpreter ,  Cobalt Strike  among others,\r\nwhich means that, when executed, it will communicate with the Command and Control server, where some data\r\nwill be sent (possibly for agent authentication), and then the Command and Control server will send encrypted\r\ndata that will be subjected to an XOR operation, and executed in memory.\r\nA Deep Dive into the C\u0026C Communication \u0026 2nd Stage Extraction\r\nSo far, we have only analyzed the Loader component of the Kill Chain, but as we have seen in our analysis, the\r\nVELETRIX Shellcode appears to download and execute some type of data. To identify this, in my isolated\r\nlaboratory I executed the Wondshare software and consequently the VELETRIX loader. During its execution, I\r\ncaptured all the loader traffic, which we can see in the image below, the validation of communication with the\r\nIPv4 address 62.234.24.38 on TCP port 9999.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 12 of 31\n\nBelow, we can see that the Command and Control server sent a large amount of data to the infected host, reaching\r\n5MB.\r\nThis amount of packets is not in vain, basically VELETRIX sends two pieces of information to the Command and\r\nControl server as a Beacon:\r\nThe version of the 2nd Loader: w64\r\nThe IP address of the Command and Control server: 62.234.24.38\r\nAfter sending this beacon, the Command and Control server sent almost 5MB of encrypted data.\r\nSince we have the logic of the decryption algorithm through an XOR operation with the key 0x99, I developed a\r\nPython script that decrypts the entire HEX data block and checks whether the first 16 bytes of the binary refer to\r\nthe MZ and PE header. The complete code you can find on my Github.\r\nThis way, we extract, decrypt and obtain offline the 2nd stage loaded by VELETRIX.\r\nWhen uploading to Unpac.me, we can see in the image below that the decrypted binary is Packed, and that\r\nUnpac.me performed Unpack of this binary, the final format being a Golang DLL with the Hash\r\nc9dc947b793d13c3b66c34de9e3a791d96e34639c5de1e968fb95ea46bd52c23.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 13 of 31\n\nWhen we open this binary in PEStudio, we can see that the original name of the binary references a possible\r\nReverse Shell TCP for amd64 processors, as we can see below.\r\nMaybe in the future I’ll do an in-depth analysis of this sample, but for now I’ll stop here, as this post is already a\r\nbit long 🙂\r\nAnyway, I’ve uploaded this sample to MalwareBazaar so you can download it and run your own analysis. At the\r\nend of this post you can get all the links.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 14 of 31\n\nWith the pattern identified in this lab run, I also developed a Python script that automates the automatic download\r\nand decryption routine:\r\nThe script will connect to the C\u0026C server;\r\nIt will send the Beacon for authentication purposes;\r\nIt will download the encrypted 2nd Stage;\r\nIt will decrypt the 2nd Stage, and finally save it to a file for future analysis.\r\nYou can use this script to securely download the data from your research host. Below we can see the execution of\r\nthis script.\r\nHunting and Analyze other Samples with the same Pattern\r\nUsing the patterns identified during this research, I created two Yara rules, one for Loader and one for Shellcode.\r\nWhen performing the Hunt with the Shellcode Yara rule, it was possible to identify two different samples, one\r\nidentified on June 17, 2025, and the other on April 18, 2025.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 15 of 31\n\nThe sample with the hash a15f30f20e3df05032445697c906c3a2accf576ecef5da7fad3730ca5f9c141c is the pure\r\nshellcode, in which we can observe that it has several primary similarities, identified in the analyzed Shellcode of\r\nthe DragonClone campaign.\r\nThe same Hashes and their corresponding APIs are resolved;\r\nThe same routine for attempting to obfuscate the IP address through the Stack String ( 121.37.80.227 );\r\nThe same routine for storing a Buffer that will contain the 2nd Stage that will be sent by the Command and\r\nControl server, decrypting it and executing it in memory.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 16 of 31\n\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 17 of 31\n\nNow when we analyze the other sample that also matched my Yara rule, the one with Hash\r\n27c04c7d2d6dbbb80247adae62e76dfa43c39c447f51205e276b064555a6eb84 , we can see that it is actually a Loader\r\nthat loads and executes the decrypted Shellcode in memory.\r\nThis Loader loads the decrypted Shellcode into the only Resource present in the binary, identified by ID 101 .\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 18 of 31\n\nThe Loader code is very straightforward, without any kind of API obfuscation. Below, you can see the use of\r\nstandard APIs to load resources.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 19 of 31\n\nAfter extracting the Shellcode from the binary’s Resource, the Loader will implement three routines:\r\nLoading of Undocumented APIs required for injection into the Thread;\r\nAllocation of Memory with Execution permissions to allocate the Shellcode;\r\nExecution of the Shellcode through a Thread.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 20 of 31\n\nAnd finally, we come to the analysis of the Shellcode that will be injected and executed in a Thread. The patterns\r\nare literally the same, with only the IPv4 address of the Command and Control server ( 156.238.236.130 ) being\r\nchanged.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 21 of 31\n\nThe same pattern is also observed in the 2nd Stage receiving, decryption and execution routine, as we can see\r\nbelow.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 22 of 31\n\nAll these analysis of samples that matched my Yara rule lead me to believe that this Shellcode is indeed part of\r\nsome OST (Offensive Security Tool), like the VShell pointed out in the Seqrite report. But, most importantly, they\r\nare probably samples from the same Threat Actor. So, let’s analyze the infrastructure identified so far.\r\nAnalysis of C\u0026C Infraestrutucture\r\nWell, by now you may be wondering, how certain can we be of attributing this campaign? Well, in fact, just the\r\nfact that one of the largest telecommunications companies in China is the target of this campaign may not be\r\nenough. However, when we analyze the IPv4 addressess of the C\u0026C servers we can be a little more certain of the\r\norigin of this campaign. Below, we can see that the IPv4 address 62.234.24.38 identified on that sample of\r\nDragonClone campaign belongs to China itself, in addition to having a series of open TCP ports for network\r\nservices.\r\nIn addition, the image below also provides some extra information such as:\r\nServices are hosted on this IPv4 address;\r\nThe operating system of this server is Ubuntu;\r\nThis IP address belongs to Tencent Cloud Computing (Beijing), a China Cloud Computing provider.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 23 of 31\n\nBelow we can see that the server is still active, and still contains a login page, probably a Threat Actors campaign\r\ncontrol page, on TCP port 8082.\r\nAnd when we look deeper into the location via Shodan, we can see that the IP address is located in Beijing.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 24 of 31\n\nWhen we search on Google Maps, we can see that the location indicated on the Shodan map is the location of\r\nTiananmen, where we have the historic square where one of the peaks of the communist regime’s repression\r\nagainst civilian protests took place. The origin of the connection is probably within the ‘Forbidden City‘\r\ncomplex.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 25 of 31\n\nWhen we analyze the others, the IP address 156.238.236.130 on VirusTotal appears to be from the United\r\nStates.\r\nWhen we analyze the Relations tab in VirusTotal, we are able to observe 4 samples, two of which have names that\r\nwe already know from our analysis. This strengthens our hypothesis that this Shellcode is in fact VShell.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 26 of 31\n\nOn Shodan, we noticed that this same IPv4 address also has other services, including a web server.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 27 of 31\n\nWhen we enter the web server through an isolated environment, we can see that although VirusTotal tells us that\r\nthe origin was the United States, it hosts a Chinese-language web server.\r\nWhen we analyze the IPv4 address 121.37.80.227 , VirusTotal immediately tells us that its origin is also in\r\nChina.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 28 of 31\n\nAlso in the Relations tab, despite not having samples with the exact name identified previously, we are presented\r\nwith a sample identified in a similar way to the previous ones, as ‘ windows_amd64.exe ‘. The novelty here is that\r\nthere are two other ELF samples for Linux systems.\r\nWhen analyzing one of the ELF samples correlated with the Command and Control server 121.37.80.227 , it is\r\npossible to observe that one of the signatures indicates that this sample is a VShell.\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 29 of 31\n\nConclusion\r\nWe have reached the end of the analysis of this campaign and other examples that share the same code patterns\r\nand infrastructure. VShell is probably the OST most used by China-Nexus Threat Actors, so identifying them in\r\nyour infrastructure is a suspicious indicator and deserves your due attention. I hope you enjoyed reading this post\r\nand learned something new from it. See you next time.\r\nReferences \u0026 Links\r\nBelow are the references used during the research, and the links to Yaras scripts and rules produced through this\r\nresearch.\r\nOperation DRAGONCLONE: Chinese Telecommunication industry targeted via VELETRIX \u0026 VShell\r\nmalware – Seqrite\r\nPython Script to Decrypt the VELETRIX Shellcode\r\nPython Script to Decrypt the VELETRIX 2nd Stage\r\nPython Script to Download and Decrypt VELETRIX 2nd Stage\r\nVELETRIX Network Packet Capture Infection\r\nVELETRIX Loader Yara Rule\r\nVELETRIX Shellcode Yara Rule\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 30 of 31\n\nSource: https://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure\r\n-positioning/\r\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/\r\nPage 31 of 31\n\nhttps://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/      \nBelow, you can more easily observe the DLL loading flow followed by the API Hashing process.\nThe Hashing algorithm is simple, being based on the ROR13 algorithm, as we can see below.\n   Page 9 of 31  \n\nlaboratory I captured all executed the Wondshare the loader traffic, software which we can and consequently see in the image the VELETRIX below, the validation loader. During of communication its execution, I with the\nIPv4 address 62.234.24.38 on TCP port 9999.  \n   Page 12 of 31\n\nUsing the patterns When performing identified the Hunt during this research, with the Shellcode I created Yara rule, two Yara rules, it was possible one for Loader to identify two and one for different samples, Shellcode. one\nidentified on June 17, 2025, and the other on April 18, 2025.\n   Page 15 of 31\n\n https://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/      \nAnd finally, we come to the analysis of the Shellcode that will be injected and executed in a Thread. The patterns\nare literally the same, with only the IPv4 address of the Command and Control server ( 156.238.236.130 ) being\nchanged.       \n    Page 21 of 31",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://0x0d4y.blog/telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning/"
	],
	"report_names": [
		"telecommunications-supply-chain-china-nexus-threat-technical-analysis-of-veletrix-loaders-strategic-infrastructure-positioning"
	],
	"threat_actors": [
		{
			"id": "2f964894-0020-457e-b4e7-65a8c8fe740c",
			"created_at": "2025-05-29T02:00:03.202897Z",
			"updated_at": "2026-04-10T02:00:03.858601Z",
			"deleted_at": null,
			"main_name": "Earth Alux",
			"aliases": [],
			"source_name": "MISPGALAXY:Earth Alux",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "fdcb30ba-5fef-4ae2-97bd-f8200f4bd2e5",
			"created_at": "2025-04-22T02:01:52.35523Z",
			"updated_at": "2026-04-10T02:00:04.658231Z",
			"deleted_at": null,
			"main_name": "Earth Alux",
			"aliases": [],
			"source_name": "ETDA:Earth Alux",
			"tools": [
				"Agentemis",
				"Cobalt Strike",
				"CobaltStrike",
				"Godzilla",
				"Godzilla Loader",
				"MASQLOADER",
				"RAILLOAD",
				"RAILSETTER",
				"RSBINJECT",
				"VARGEIT",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775439137,
	"ts_updated_at": 1775826764,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/baf22f7cb2090d828711063754f6a29ac386028a.pdf",
		"text": "https://archive.orkl.eu/baf22f7cb2090d828711063754f6a29ac386028a.txt",
		"img": "https://archive.orkl.eu/baf22f7cb2090d828711063754f6a29ac386028a.jpg"
	}
}