“SilentSetup”: a signed installer that waits for its start date, then drops the PackClient RAT

About this post. Thanks to MalwareHunterTeam for flagging this sample. This analysis and write-up were produced by Claude (Opus 5.5), working as an agent in Claude Code on a REMnux analysis VM. Tools used: Malcat, ILSpy, capa, capstone, unicorn, tshark, Recorded Future Triage and ANY.RUN.

TL;DR

SilentSetup.exe looks like a generic Chinese "应用程序" ("application") installer and carries a valid EV code-signing signature. It does nothing at all until a hard-coded start time: 11 October 2026, 20:00. After that it quietly downloads a zip and hides it in a random folder at the root of the system drive (usually C:\). A harmless old printing program in the zip is tricked into loading a malicious DLL. That DLL decrypts and starts a remote-access trojan known to network defenders as PackClient RAT. The attacker’s server then pushes a plugin that tries to install a second signed file: a kernel driver built to kill antivirus and shield the trojan.

• What it is: a multi-stage chain ending in a full remote-access trojan (RAT) with screen viewing, keylogging, remote control, file and shell access, and a clipboard hijacker.
• Who it targets: Chinese-speaking Windows users. The kill list is mostly Qihoo 360 and Huorong security products, plus Microsoft Defender.
• Two certificates: the installer is signed by "Zaozhuang ZhongStore District HaoYouhao Department" and the driver by "Xidao E-commerce Studio, Yishui County". Both are Certum EV certificates issued to small Shandong businesses.
• Live infrastructure: the control server 91[.]204[.]224[.]87 on port 8790 was answering on 20 October 2026. We recovered the trojan’s main module and plugin byte-for-byte from sandbox traffic.
• Limits: in all three sandbox runs of this sample, the driver failed to load, so its antivirus-killing step most likely never ran. A sibling dropper’s driver appears to have loaded in a VirusTotal sandbox, so this isn’t a dud.

But it’s signed!

Code signing is a digital seal that says "this file came from this publisher and hasn’t been changed". Windows and many users trust signed files more, which is exactly why criminals buy or abuse certificates. A brand-new certificate in the name of a small local shop, signing a program that claims a different company in its own details, is a pattern we see again and again with signed malware.

That’s the case here. The certificate belongs to "Zaozhuang ZhongStore District HaoYouhao Department" (serial 581f78ae1e23067baff8f1a57a73b718), valid from 4 September 2026. The program’s own version information names a different company, "金华玖玖信息技术有限公司". The file was signed on 11 October 2026 at 13:03 UTC, the same day as its built-in start time (20:00 on the victim PC’s local clock).

As usual, the certificate has been reported to the CA and added to the CertGraveyard. The driver’s certificate (Xidao) was already in the CertGraveyard from one of our earlier reports, and VirusTotal now shows it as revoked.

A timer, then a silent download

The installer is built with MicaSetup, an open-source framework for good-looking Windows installers. The attackers renamed its internals "Nexify" and switched it to a "drop only" mode. The installer pages are skipped and there is nothing to click.

The first thing the code does is check the clock. Before 11 October 2026, 20:00 (local time) it simply exits. A delayed start like this helps a sample look harmless to anyone who tests it too early.

After that date it:

1. decodes a web address hidden with a simple XOR scramble (XOR mixes each byte with a key; reversing it is trivial once you have the key): hxxp[://]108[.]187[.]43[.]139:8080/china4[.]zip
2. downloads the zip and unpacks it into a new folder with six random letters as its name, directly under C:\, and marks that folder hidden and "system"
3. starts the first program it finds there, then closes itself.

The code passes a password to the unzip routine, but the zip isn’t actually encrypted. It’s a leftover that does nothing.

A printer program with a bad neighbour

The zip contains seven files. Most of them are real: an old 2018 printing tool called NimoPrinter (renamed here to EventLog.exe to sound like part of Windows), its picture-processing and PDF libraries, and genuine Microsoft runtime files.

Two files are new. cximagecrtu.dll has the same name as one of the printer program’s own libraries, and update.xml isn’t XML at all. This trick is called DLL sideloading. When a program starts, Windows looks for the DLLs it needs in the program’s own folder first. Put a malicious DLL with the right name next to a legitimate program, and the legitimate program loads it for you. It’s like a burglar hiding inside a delivery box that the house already expects.

The fake DLL contains a whole compression library as padding, and its build path leaks a project folder: D:\Projects\pay\tools\wework_loader_go\. Its real job is small:

• find the Windows functions it needs by walking memory and comparing name hashes, so they don’t show up in an easy-to-read import list
• open update.xml, check for its own magic marker EPK1, and decrypt it with ChaCha20-Poly1305 (a modern encryption scheme that also detects tampering)
• find the program hidden inside, load it straight into memory and start it. It never touches the disk as a normal file.

We didn’t rebuild the decryption by hand. We ran the DLL’s own decryption function in an emulator (a software CPU that runs only the code you point it at) and fed it the real update.xml. The built-in tamper check passed, which proves the output is exactly what the attackers packed. The key starts from the string EPK1-SEED-DEMO-01, which looks like a builder default and will likely appear in other builds.

Meet PackClient

The program inside update.xml is PackClientLauncher. The whole toolkit calls itself "PackMonitorClient", and the operator side is PackMonitorServer.exe. Emerging Threats already ships network rules for this family under the name "PackClient RAT", and ANY.RUN’s sandbox fired a whole set of them on this sample’s traffic. Proofpoint described PackClient in 2026: a RAT sold on Telegram and used by a group it tracks as TA4922 against China and India with tax-themed lures. Our sample matches that report’s build path, configuration markers, registry values and network protocol. It differs in delivery (a signed installer and a sideloaded DLL instead of a rundll32 downloader), in its port, and in one big extra: the driver plugin below, which Proofpoint doesn’t mention. Because the RAT is sold to whoever pays, the name alone doesn’t tell us who ran this campaign.

The launcher’s settings are in plain view: server 91[.]204[.]224[.]87, port 8790, group "Default". It does three things:

• Pulls the real trojan. It downloads PackClientCore.dll from the server, unpacks it and loads it in memory. It also keeps an encrypted copy on disk (Windows DPAPI, tied to the user account) in a pluginsdata folder.
• Sets up a bodyguard. It writes a hidden PowerShell script, pack_proc_guard.ps1, next to itself and starts it in a hidden window. The script watches the trojan and restarts it up to 20 times a minute if it’s killed.
• Prefers the logged-in user’s session. It can jump from a background SYSTEM process into the active user’s desktop.

What the operator can do

PackClientCore is a full remote-access trojan. From its command set and from the live sessions:

• watch the screen. Small thumbnails were actually sent back to the server during the sandbox runs.
• log keystrokes and the clipboard
• control the mouse and keyboard remotely
• run commands and programs, move files, and act as a proxy (send the attacker’s traffic through the victim’s PC)
• hijack the clipboard. The operator can push a pattern and a replacement. When you copy something matching the pattern, such as a cryptocurrency address, it’s silently swapped for theirs.
• read AnyDesk’s configuration and ID, a common way to take over an existing remote-desktop setup
• update itself and load plugins

The core also lists plugins it can host, among them TgTool, WaMonitor, MnemonicScan, ChatClone, BrowserMgr and ShellcodeLoader. Those names strongly suggest Telegram and WhatsApp spying, crypto-wallet seed-phrase hunting and browser theft. None of them was sent in the sessions we have, so we can’t confirm what they do.

The plugin that brings a driver

Within a minute of the trojan connecting, the server automatically pushed one plugin, PackExtraPlugin.Ksl888.dll (its internal name is "Ksl666"). It does two jobs.

Persistence, meaning it makes sure the trojan comes back after a reboot. With admin rights it creates a scheduled task called MicroEvent2026 or MicroEvent2026Maint, authored as "Microsoft Corporation" and described as "Windows Diagnostics Host Maintenance". Without admin rights it adds a MicroEvent2026Maint entry to the user’s Run key.

A kernel driver. A driver runs inside the Windows kernel, the most privileged part of the system, where it can do things no normal program can. The plugin carries a driver called YGProtect, signed by "Xidao E-commerce Studio, Yishui County" (serial 7836fc681aae72e82815b7a3654dbf01). The plugin is built to use it to:

• forcibly close security products: 360 Total Security and its many components, Huorong, and Microsoft Defender / Windows Security
• block anyone from opening or changing the trojan’s process, files, scheduled task and Run key.

The plugin also carries a genuine 2011 Microsoft driver (KSLDriver.sys) that can access physical memory, for an older "kill" mode. The current workflow doesn’t use it.

A few bytes of log tell the real story

Here’s the good news. In all three sandbox runs of this sample, the driver failed to load.

The plugin writes small progress numbers to text files as it works, and the sandboxes saved those files. In one sandbox (ANY.RUN) the plugin also printed its whole debug log, in plain text. Together they show:

• Without admin rights it can’t work. In the ANY.RUN run, which wasn’t elevated, Windows refused to let it write to the drivers folder or create the driver’s service, and the plugin logged "load FAILED all dirs — kill/protect unavailable". It then fell back to a simple Run-key autostart.
• With admin rights it got further but still failed. In both Triage runs the driver file landed in System32\drivers, then the plugin recorded its "YGProtect not ready" code and retried from C:\Windows\Temp. Its "loaded and working" code never appears. Its logs stop before the final Windows error code, so we don’t know exactly why the load failed.

The kill step only runs if the driver is loaded, so the antivirus products most likely survived in these runs.

But don’t count on that. A sibling dropper signed with the same certificate (more below) ran in VirusTotal’s sandboxes, and among its dropped files is the plugin’s "loaded and working" code, which suggests the driver loaded there. Modern Windows normally refuses new kernel drivers that Microsoft hasn’t signed. However, machines with Secure Boot off or test-signing on are more lenient, and some setups clearly let this driver through.

The same certificates sign more

Searching VirusTotal for files signed with the two certificates turned up a lot more:

• A sibling dropper. NexifySetup.exe, signed on 8 October with the same installer certificate, also circulated as 稅務清單文件.pdf … .exe ("tax list document", in Traditional Chinese). "Nexify" is the same name our installer uses internally. It drops the very same driver file and the same set of helper DLLs, and talks to a different PackClient server, 161[.]248[.]14[.]20:8790. It’s clearly the same toolkit; whether it’s the same operator we can’t say.
• More drivers. Between them, the two certificates sign seven other kernel drivers.
• Tax lures. The driver certificate also signs files such as TaxVerify.exe ("Tax Document Verification") and T.No.20260923600745255.exe, which was run from a mounted disk image. That looks a lot like the tax-themed disk-image lures in Proofpoint’s report, but we haven’t checked what those files deliver, so treat this as a lead, not a link.
• Used together. One identical SDL2.dll build was signed with both certificates about an hour and a half apart, and an Electron app called "TotalClaw 企业助手" switched from one certificate to the other. So at least one customer had access to both. The driver certificate also signs unrelated hacking tools, VPN and parental-control software, so this could just as well be a signing service rented out to many buyers.

What we couldn’t reach

• The other plugins. We only saw the server push one plugin. The Telegram, WhatsApp, seed-phrase and browser plugins are known by name only.
• The driver’s insides. We identified the driver’s features from its own messages but didn’t fully reverse it.
• A second server. A sibling zip with the same DLL, seen two days earlier, talks to 156[.]251[.]16[.]214:8790 and uses a slightly different build of the main module, which we couldn’t recover.

Advice

For regular users

• A valid signature isn’t a guarantee. Be wary of installers from unofficial download sites, especially ones that show no window and "finish" instantly.
• If you find a hidden folder with a random six-letter name directly under C:\, containing EventLog.exe and update.xml, treat the PC as compromised.
• Don’t work day-to-day as an administrator, and keep Secure Boot on (search "System Information" → "Secure Boot State"). The driver failed without admin rights, and Secure Boot makes unsigned-by-Microsoft drivers much harder to load.
• If you copy cryptocurrency addresses, always double-check the pasted address before sending.

For defenders

• Hunt for scheduled tasks named MicroEvent2026*, the service YgProtect, and ygp.dat in System32\drivers or Windows\Temp.
• Look for %LOCALAPPDATA%\PackMonitorClient\ and the registry key HKCU\Software\PackMonitorClient\.
• Alert on hidden PowerShell started with -File …\pack_proc_guard.ps1 -WatchPid.
• Hunt for HKCU\Software\PackClientConsole\. The trojan’s code contains this key name and Proofpoint documents it, although our sandboxes didn’t record it being written.
• Block the IPs below. Emerging Threats rules for "PackClient RAT" already detect the protocol on the wire.

Indicators of compromise

Wrapping up

This one has all the classic layers: a signed wrapper, a timer, a sideloaded DLL next to an innocent program, a payload that only ever lives in memory, and a signed driver meant to clear the road. The most ambitious part was also the most fragile. In our sandboxes the driver never loaded, but a sibling shows it can. Basic hygiene (no everyday admin accounts, Secure Boot on) is what stands in its way.

If you’ve seen other EPK1-packed update.xml files or PackClient servers, we’d love to hear about them. Stay safe, and check those signatures and who they really belong to.