In my work I had the opportunity to analyze a China-Nexus Threat Actor, called Earth Alux, and this research, which only covers the fundamental points of the Kill Chain and the analysis of some components of its Toolkit, was the starting point of a long process of studies on how the Chinese state invested in its Cyber Warfare capabilities 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 fruits of my process of studying China’s capabilities in employing Cyber Warfare that is aligned with state interests.

Chinese State Turns to Cyber Warfare

First, it is extremely important to understand that the China-Nexus Threat Actors do not have the same banal motivations as the eCrime Threat Actors. For decades, the Chinese state has incorporated the cyber warfare project into civil society, and it is a civic duty of citizens and private companies to collaborate with the objectives aligned with the Chinese state. It may not seem that impressive, but China has worked for decades to become one of the world’s technological powers today, and has incorporated policies that use cyber warfare to its advantage, through the PLA (People’s Liberation Army) and MSS (Ministry of State Security) units, which are used to conduct cyber campaigns against private companies, governments, and critical structures, with the aim of meeting the needs of the state. Literally, cybersecurity at the service of the state.

This makes me think that the China-Nexus Threat Actors have the most sophisticated motivations of all. It’s not as simple as a threat actor wanting to make an impact to generate revenue for themselves; the China-Nexus are cyber threats driven by state interests. They can compromise organizations only to silently persist in their infrastructure for years, just to gather intelligence in the long term, and become a few steps ahead of the Chinese state’s competitors.

The cybersecurity market, especially those that invest heavily in marketing, talk a lot about Cyber Warfare when referring to Ransomware groups, or Malware-as-a-Service operated by e-Crime, but the real Cyber Warfare is that which is waged by states and not by cyber criminals with financial purposes. Cyber Warfare causes diplomatic and financial market disputes, causes theft of intellectual property, or causes mass espionage through infiltration of telecommunications companies. And this is exactly the case that I will discuss in this post.

China Targets Country’s Own Telecommunications

In this post, I will analyze a campaign that was named DragonClone by the Seqrite Labs APT-Team, whose research can be found here.

This 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 encrypting the main servers of the victim’s Domain. In this campaign, the Threat Actors infected the company China Mobile Tietong Co., Ltd, which is a subsidiary of China Mobile, one of the largest companies in the telecommunications industry in China. In other words, by compromising a Telecommunications company, the adversaries have access to the entire backbone responsible for this company, consequently, the adversaries have access to all the traffic that passes through this backbone. Mass Espionage.

This allows us to observe how strategic the China-Nexus Threat Actors are, allowing the Chinese state to remain well positioned to identify, respond to any future state threat. Now let’s analyze the technical aspect of the campaign.

Technical Analysis of the DragonClone Campaign

Below, we can see the general flow of the infection that we are going to unravel, and as we can see, the initial access is made through the Spearphishing technique (T1566.001), delivering to users a ZIP file that contains binaries related to an internal training program for employees of China Mobile Tietong Co., Ltd. Wondershare software, specifically Recoverit. But when executed, the benign software will execute a malicious DLL placed by the Threat Actor, with the aim of loading a 2nd stage into memory.

The component that was Sideloaded is a DLL that Wondershare contains a dependency on, which the Threat Actor replaced with a loader customized by the adversary identified as VELETRIX.

The ZIP file we will use in this analysis contains the SHA256 below.

SHA256:"fef69f8747c368979a9e4c62f4648ea233314b5f41981d9c01c1cdd96fb07365"

Within the ZIP file it is possible to observe several binaries, however, the main one that is targeted by Spearphishing is the one identified as “2025年中国移动有限公司内部培训计划即将启动，请尽快报名.exe“, in which is translated to “China Mobile Limited’s internal training program for 2025 is about to start, please sign up as soon as possible“. As we can see, the filename has a social engineering component that as we said before, targeting the China Mobile Tietong Co. employees.

Below, we can see the point exploited with DLL Side-Loading, where the main Wondershare software has a DLL dependency with drstat.dll, as we can see below.

It is at this point in the kill chain that the Threat Actor will abuse this dependency, executing a malicious chain through the legitimate software. So, let’s analyze the drstat.dll DLL placed in the ZIP file by the Threat Actors.

drstat.dll Reverse Engineering

When we load the binary in Binary Ninja, we can see the exports of this DLL in the Triage Summary view.

None of the exports listed above do something, except the exported function dr_data_stop. This is the only function that has a routine, and, it is the main function of the VELETRIX.

When this function is called by the legitimate binary, the first routine to be executed is the Anti-Sandbox routine, executing the GetTickCount in the beginning and in the end of the Anti-Sandbox loop. The loop is compound by a 10 seconds sleep (with Sleep API) and checking the sound in the system with Beep call.

After the Anti-Sandbox routine is completed, VELETRIX’s main function is to start the dynamic API loading routine with LoadLibraryA and GetProcAddress, as we can see in the Disassembly code snippet below, where the adversary tries to evade detection and hinder the analysis through the Stack Strings technique.

All of the Windows APIs that is loaded in this routine you can see below.

And here’s the interesting thing, if you look at the strings in the VELETRIX binary, you’ll see a large number of IPv4 addresses. These addresses together are the encrypted shellcode that VELETRIX loads upon execution.

This is not a new method of obfuscation, but it is quite unusual. It works because each byte (in hexadecimal) of the shellcode can be represented by an octet of an IPv4 address. The work that the adversary had to do was to aggregate four octets (4 bytes) and transform them visually into IPv4 addresses. To convert IPv4 addresses into bytes, it is necessary to use the RtlIpv4StringToAddressA API, which is exactly the routine that VELETRIX executes.

After deobfuscating the Shellcode, VELETRIX subjects each byte to an XOR operation with the key 0x6f, with the aim of decrypting the previously obfuscated Shellcode.

I implemented a script in Python in uploaded in my Github (the link is in the Reference section), which aims to execute the same algorithm flow, that is, receive the list of IPv4 addresses, transform the octets into their corresponding bytes and finally submitting the byte to a single-key XOR operation 0x6f. At the end of this decryption flow we will have the decrypted Shellcode.

VELETRIX implements an unconventional method of Shellcode injection, opting to use the EnumCalendarInfoA API. Basically, VELETRIX allocate a memory space and change the protection through VirtualProtect to PAGE_EXECUTE_READWRITE permissions, in this space it will be placed the Shellcode address 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 argument lpCalInfoEnumProc. With this unconventional implementation, the Shellcode will be executed and may escape detections that conventional methods monitor. Below, we can see this implementation.

Shellcode Reverse Engineering

The first action to be performed is to collect the kernel32.dll DLL by accessing the memory structures through the PEB.

By collecting the address of kernel32.dll, Shellcode de-hashes the LoadLibraryA API, which will be used to load the other DLLs. The DLL names were placed in Stack Strings, with the aim of evading detection.

Below, you can more easily observe the DLL loading flow followed by the API Hashing process.

The Hashing algorithm is simple, being based on the ROR13 algorithm, as we can see below.

From this point on, the Shellcode will use the WinSocket library to communicate with its Command and Control server. Below we can see the network communication setup

WSAStartup – Initialize Winsock
WSASocketA – Create socket
connect – Establish connection
send – Send data
recv – Receive data
closesocket – Clean up socket
gethostbyname / inet_addr – DNS resolution

Below we can see the use of WSAStartup to start the socket initialization process.

Below you can see the socket setup, where you can see that Shellcode will use the TCP protocol to establish the connection.

The IP address of the Command and Control server is hardcoded via Stack String, as can be seen in the image below, being 62.234.24.38.

And to validate that this is in fact the Command and Control IPv4 address, we just need to look at the score of this IP address on VirusTotal, and the country of origin being China.

Below we can see the Shellcode finally calling the connect API, with the aim of connecting to the Command and Control address identified previously.

Below we can see the loop implemented in Shellcode, which allows a certain persistence of communication.

And here’s the interesting part! Shellcode has the ability to receive encrypted data from the Command and Control server, decrypt it through a simple XOR algorithm with the key 0x99, then execute it at a previously allocated address with PAGE_EXECUTE_READWRITE permissions. Below, we can see the flow of what was briefly described.

This is interesting because what we know through public intelligence is that VELETRIX carries a VShell shellcode which is an Offensive Security Tool, like Meterpreter, Cobalt Strike among others, which means that, when executed, it will communicate with the Command and Control server, where some data will be sent (possibly for agent authentication), and then the Command and Control server will send encrypted data that will be subjected to an XOR operation, and executed in memory.

A Deep Dive into the C&C Communication & 2nd Stage Extraction

So far, we have only analyzed the Loader component of the Kill Chain, but as we have seen in our analysis, the VELETRIX Shellcode appears to download and execute some type of data. To identify this, in my isolated laboratory I executed the Wondshare software and consequently the VELETRIX loader. During its execution, I captured all the loader traffic, which we can see in the image below, the validation of communication with the IPv4 address 62.234.24.38 on TCP port 9999.

Below, we can see that the Command and Control server sent a large amount of data to the infected host, reaching 5MB.

This amount of packets is not in vain, basically VELETRIX sends two pieces of information to the Command and Control server as a Beacon:

The version of the 2nd Loader: w64
The IP address of the Command and Control server: 62.234.24.38

After sending this beacon, the Command and Control server sent almost 5MB of encrypted data.

Since we have the logic of the decryption algorithm through an XOR operation with the key 0x99, I developed a Python script that decrypts the entire HEX data block and checks whether the first 16 bytes of the binary refer to the MZ and PE header. The complete code you can find on my Github.

This way, we extract, decrypt and obtain offline the 2nd stage loaded by VELETRIX.

When uploading to Unpac.me, we can see in the image below that the decrypted binary is Packed, and that Unpac.me performed Unpack of this binary, the final format being a Golang DLL with the Hash c9dc947b793d13c3b66c34de9e3a791d96e34639c5de1e968fb95ea46bd52c23.

When we open this binary in PEStudio, we can see that the original name of the binary references a possible Reverse Shell TCP for amd64 processors, as we can see below.

Maybe 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 bit long 🙂

Anyway, I’ve uploaded this sample to MalwareBazaar so you can download it and run your own analysis. At the end of this post you can get all the links.

With the pattern identified in this lab run, I also developed a Python script that automates the automatic download and decryption routine:

The script will connect to the C&C server;
It will send the Beacon for authentication purposes;
It will download the encrypted 2nd Stage;
It will decrypt the 2nd Stage, and finally save it to a file for future analysis.

You can use this script to securely download the data from your research host. Below we can see the execution of this script.

Hunting and Analyze other Samples with the same Pattern

Using the patterns identified during this research, I created two Yara rules, one for Loader and one for Shellcode. When performing the Hunt with the Shellcode Yara rule, it was possible to identify two different samples, one identified on June 17, 2025, and the other on April 18, 2025.

The sample with the hash a15f30f20e3df05032445697c906c3a2accf576ecef5da7fad3730ca5f9c141c is the pure shellcode, in which we can observe that it has several primary similarities, identified in the analyzed Shellcode of the DragonClone campaign.

The same Hashes and their corresponding APIs are resolved;
The same routine for attempting to obfuscate the IP address through the Stack String (121.37.80.227);
The same routine for storing a Buffer that will contain the 2nd Stage that will be sent by the Command and Control server, decrypting it and executing it in memory.

Now when we analyze the other sample that also matched my Yara rule, the one with Hash 27c04c7d2d6dbbb80247adae62e76dfa43c39c447f51205e276b064555a6eb84, we can see that it is actually a Loader that loads and executes the decrypted Shellcode in memory.

This Loader loads the decrypted Shellcode into the only Resource present in the binary, identified by ID 101.

The Loader code is very straightforward, without any kind of API obfuscation. Below, you can see the use of standard APIs to load resources.

After extracting the Shellcode from the binary’s Resource, the Loader will implement three routines:

Loading of Undocumented APIs required for injection into the Thread;
Allocation of Memory with Execution permissions to allocate the Shellcode;
Execution of the Shellcode through a Thread.

And finally, we come to the analysis of the Shellcode that will be injected and executed in a Thread. The patterns are literally the same, with only the IPv4 address of the Command and Control server (156.238.236.130) being changed.

The same pattern is also observed in the 2nd Stage receiving, decryption and execution routine, as we can see below.

All these analysis of samples that matched my Yara rule lead me to believe that this Shellcode is indeed part of some OST (Offensive Security Tool), like the VShell pointed out in the Seqrite report. But, most importantly, they are probably samples from the same Threat Actor. So, let’s analyze the infrastructure identified so far.

Analysis of C&C Infraestrutucture

Well, by now you may be wondering, how certain can we be of attributing this campaign? Well, in fact, just the fact that one of the largest telecommunications companies in China is the target of this campaign may not be enough. However, when we analyze the IPv4 addressess of the C&C servers we can be a little more certain of the origin of this campaign. Below, we can see that the IPv4 address 62.234.24.38 identified on that sample of DragonClone campaign belongs to China itself, in addition to having a series of open TCP ports for network services.

In addition, the image below also provides some extra information such as:

Services are hosted on this IPv4 address;
The operating system of this server is Ubuntu;
This IP address belongs to Tencent Cloud Computing (Beijing), a China Cloud Computing provider.

Below we can see that the server is still active, and still contains a login page, probably a Threat Actors campaign control page, on TCP port 8082.

And when we look deeper into the location via Shodan, we can see that the IP address is located in Beijing.

When we search on Google Maps, we can see that the location indicated on the Shodan map is the location of Tiananmen, where we have the historic square where one of the peaks of the communist regime’s repression against civilian protests took place. The origin of the connection is probably within the ‘Forbidden City‘ complex.

When we analyze the others, the IP address 156.238.236.130 on VirusTotal appears to be from the United States.

When we analyze the Relations tab in VirusTotal, we are able to observe 4 samples, two of which have names that we already know from our analysis. This strengthens our hypothesis that this Shellcode is in fact VShell.

On Shodan, we noticed that this same IPv4 address also has other services, including a web server.

When we enter the web server through an isolated environment, we can see that although VirusTotal tells us that the origin was the United States, it hosts a Chinese-language web server.

When we analyze the IPv4 address 121.37.80.227, VirusTotal immediately tells us that its origin is also in China.

Also in the Relations tab, despite not having samples with the exact name identified previously, we are presented with a sample identified in a similar way to the previous ones, as ‘windows_amd64.exe‘. The novelty here is that there are two other ELF samples for Linux systems.

When analyzing one of the ELF samples correlated with the Command and Control server 121.37.80.227, it is possible to observe that one of the signatures indicates that this sample is a VShell.

Conclusion

We have reached the end of the analysis of this campaign and other examples that share the same code patterns and infrastructure. VShell is probably the OST most used by China-Nexus Threat Actors, so identifying them in your infrastructure is a suspicious indicator and deserves your due attention. I hope you enjoyed reading this post and learned something new from it. See you next time.