Security1 distinct publisher2 min readPublished
Acronis says the operator borrowed a security vendor's own uninstall driver to shut down Defender on Cambodian machines, and the loader keeps three further ways to blind an agent if the kernel route fails.
The Watch · Security desk
Compiled by The WatchSomething wrong?How this is made
Count the suppression steps and the design intent is legible. The DLL loader looks for Huorong Internet Security's HipsTray.exe and, if it is running, tries to weaken that product's privileges [9]. The payload patches AMSI and ETW functionality [13]. The installed driver terminates the named endpoint processes from the kernel [5]. A third PNG-embedded payload does the same job in user mode against a hard-coded process list [14]. That is four mechanisms aimed at one objective, and only one of them has to work [2].
The driver is a legitimate OPSWAT AppRemover component [4], so detecting the file means detecting a vendor's own uninstall tooling, and the operator gets a signed kernel primitive at no development cost. The event worth policing is the load itself, keyed to the vulnerable build. Deny it and the rest of the chain still runs, without the kernel option. Permit it and the endpoint stack goes quiet before Spark RAT is injected into ctfmon.exe and starts calling out [15].
The earlier stages are built to survive analysis rather than defeat it. The loader runs a timing check on sleep delays and quits if the elapsed time falls outside the expected range, which is aimed at sandboxes that accelerate sleeps [8]. The second stager branches on privilege: already SYSTEM, it goes straight to injection; otherwise it establishes persistence first, checking for Qihoo 360 processes before registering a Windows service [10][12]. Inject mode puts shellcode into vssvc.exe and then watches that process, re-injecting if it exits or comes back with a new PID [11]. Killing the injected thread does not end the session.
Acronis stops short of naming an actor. The BYOVD routine references TrueSight and Zemana Anti-Malware SDK drivers, both used by Silver Fox before dropping Winos 4.0, and the Huorong targeting matches repeated past Silver Fox activity, as do the targeting overlaps and the sideloading through a signed application [16][17]. Read that as toolkit lineage rather than identity. Spark RAT is open source and Go-based [2], the driver set is public, and every component here is copyable by the next crew.
The dating gives about six weeks of artifacts [1], which is a short observation window and not evidence of a short campaign. For anyone with Cambodian operations or staff, the checkable item is whether the vulnerable ardrv.sys build can load on the fleet at all.
Ranked by verification strength, evidence, and original report placement.
The BYOVD routine references other drivers including those part of TrueSight and Zemana Anti-Malware SDK, both of which were used by the Silver Fox threat actor prior to dropping Winos 4.0, also known as ValleyRAT.
Targeting of Huorong security processes has been repeatedly observed in past Silver Fox-related attacks, and other Silver Fox-style indicators include targeting overlaps and the use of DLL sideloading through a signed application.
Acronis Threat Research Unit researchers Darrel Virtusio and Subhajeet Singha published an analysis on Wednesday describing a new campaign targeting individuals and organizations in Cambodia with the open-source remote access trojan Spark RAT.
Spark RAT is an open-source, Go-based, cross-platform RAT that enables remote control of compromised devices.
Attack chains likely use targeted phishing emails carrying compressed archives that contain an Inno Setup executable, with lures including Cambodian government notices, public health announcements, dental examination records, real estate documents and promotional offers.
The multi-stage attack uses the bring your own vulnerable driver technique to load a legitimate-but-vulnerable driver associated with OPSWAT AppRemover, ardrv.sys, to escalate privileges and neutralize security software.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed single-vendor analysis, no independent corroboration
The technical substance is unusually specific for a single report - named driver and CVE, named processes, two execution modes, four PNG-staged payloads - which raises confidence that the analyst had samples in hand. But the entire cluster rests on one vendor report relayed by one publisher, with no second research team, no CERT advisory, no IOC set and no vendor patch confirmation, so nothing here is independently verifiable from the supplied material.
Confirmed in-the-wild samples, victim footprint unquantified
There is real-world deployment: multiple malicious artifacts with diverse lure themes across roughly a six-week window, plus operational BYOVD abuse of a shipping commercial driver. What is missing is scale - no victim counts, no named affected organizations, no sector or infrastructure breakdown, and an explicit statement that Acronis cannot say whether the campaign is still active.
Framing tracks the vendor evidence, with modest headline sharpening
The reporting stays close to what Acronis documented and reproduces the vendor's own limits - insufficient evidence for Silver Fox attribution, low-confidence tracking as an unattributed cluster, unclear campaign status. The mild overstatement is presentational: 'EDR killer' framing and the accumulation of technique detail read as larger than a six-week, unquantified campaign disclosed by one vendor with no measured victim impact.
Security-vendor research with visibility incentive, partly self-limited
The primary evidence originates with Acronis, a commercial security vendor whose threat-research publishing supports product credibility and brand visibility, and it names competing endpoint products as the ones being disabled. Those incentives are partly offset by the vendor's own restraint on attribution and its acknowledgement of low confidence and unknown campaign status. The relaying publisher adds no disclosed commercial stake in the vendors involved.
Technique detail credible, scale and attribution unresolved
Confidence is moderate: the mechanics are described with enough specificity to act on, and the vendor's caveats are transparent. It is held below high by full dependence on one publisher relaying one vendor, no corroborating advisory or IOC set, no patch or blocklist status for the abused driver, and no quantified victim base.
security
Defender's own signed driver becomes the bypass: BTR.sys and the week's trusted-component defects1 distinct publisher
security
Same Backdoors, Two Outcomes: APT36 Lands in Kabul, Stalls in Delhi1 distinct publisher
build
PyInstaller exits zero, then the real work starts: notarization traps that report success1 distinct publisher
security
PavinLoader: the lures keep changing, the MSBuild stage does not1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 27, 2026