Silver Fox fake software installers impersonate Razer and Edge to disable Windows Defender and deploy malware. See how the campaign works.
Related Posts:
PHP Web Server Rootkit Targets F5 BIG-IP Devices
StreamRat Banking Trojan Targets Spanish Android Users
The Gentlemen Ransomware Deploys in Under 24 Hours
The post Silver Fox Fake Software Installers Disable Windows Defender appeared first on Daily CyberSecurity.
ValleyRAT hides behind legitimate adware, using DLL sideloading to evade detection, steal data and give Silver Fox control of infected systems.
ValleyRAT doesn’t always need to disguise itself as a cracked game or a fake browser update. It can also hide behind something much more ordinary: an application that looks like adware and appears to serve a legitimate purpose.
Kaspersky’s latest analysis shows how this works. Researchers found a malicious installer that uses a modified version of
ValleyRAT hides behind legitimate adware, using DLL sideloading to evade detection, steal data and give Silver Fox control of infected systems.
ValleyRAT doesn’t always need to disguise itself as a cracked game or a fake browser update. It can also hide behind something much more ordinary: an application that looks like adware and appears to serve a legitimate purpose.
Kaspersky’s latest analysis shows how this works. Researchers found a malicious installer that uses a modified version of QN Wallpaper, a legitimate Chinese desktop wallpaper application, to deliver the ValleyRAT backdoor while making the infection look like a normal software installation.
Researchers found a malicious installer that uses a modified version of QN Wallpaper, a legitimate Chinese desktop wallpaper application, to deliver the ValleyRAT backdoor while making the infection look like a normal software installation.
The interesting part is how the attackers make the first stages look harmless. The installer can present itself as software associated with DingTalk, Google Chrome or Tencent Meeting, depending on the filename, while quietly deploying the modified wallpaper application in the background.
That gives the victim something familiar to look at while the real work happens elsewhere. It’s a simple trick, but it removes one of the most obvious warning signs of a malware infection: the feeling that something unusual has just been installed.
Kaspersky originally received one of the samples because a customer wanted it classified as adware. An initial look at the file suggested exactly that, but suspicious network activity changed the picture and led researchers to examine the sample more closely. They found that the advertising component didn’t actually perform its supposed job. Instead, it started an infection chain that eventually loaded ValleyRAT.
“The original version of QN Wallpaper is genuine adware: on installation, it delivers bundled partner apps to the device and then displays ad banners to the user.” reads Kaspersky’s report. “In this case, however, the attackers use it to carry out DLL sideloading, a technique that allows malicious code to run under the guise of a signed process by way of a malicious DLL.”
That distinction matters because the attackers aren’t inventing a fake application from scratch. They’re abusing software that already looks legitimate and using its normal execution flow to load malicious code.
The technique is DLL sideloading. In simple terms, the attacker places a malicious DLL where a legitimate program expects to find a library, allowing the trusted application to load the attacker’s code.
Here, the relevant library is libcef.dll. QN Wallpaper and its companion process load that library when they start, giving the attackers a convenient place to execute their own code under the name of a legitimate application.
The installer also creates persistence and disables Windows Defender through the DisableAntiSpyware registry key before launching QnWallpaper.exe. That combination makes the infection considerably more serious than ordinary adware.
Once the malicious library runs, it checks whether the current user has administrator privileges. If necessary, it attempts to relaunch the process with elevated privileges before continuing with the next stage.
The actual ValleyRAT payload sits encrypted inside the infection chain. Depending on which legitimate process loads the malicious library, the backdoor comes from either a separate PeLoader file or resources embedded in libcef.dll.
The payloads use AES encryption and contain ValleyRAT as an encrypted DLL. Their configurations differ mainly in the command-and-control addresses they use, giving the operators more than one way to manage infected systems.
ValleyRAT then starts behaving like the backdoor it actually is. It reads its configuration, connects to its command-and-control infrastructure and prepares a range of functions that give an attacker control over the compromised machine.
The malware can collect keystrokes and clipboard contents, monitor the active window and gather detailed information about the infected system. That includes the hostname, IP addresses, Windows version, CPU information, available disk space, graphics adapter, language settings and other system details.
“The backdoor also has spyware functionality. While running, it tracks keystrokes and the currently focused window by using functions from the DirectInput8 library. It also captures clipboard contents.” continues the report. “All collected data is saved to a file on disk.”
The operator can also order the backdoor to take screenshots, reboot or shut down the machine, wipe logs, change its command-and-control addresses and download additional modules. ValleyRAT can retrieve those modules from either its own C2 infrastructure or a third-party address.
That last capability gives the attackers room to change what the malware does after the initial infection. They don’t need to put every capability into the first payload if they can download new components later.
The malware also takes steps to make itself harder to remove. Depending on its configuration, it can inject code into svchost.exe so that the backdoor restarts if someone stops it. It can also mark its own process as critical, meaning that terminating it can trigger a system crash.
That’s not subtle, but it’s effective. The malware is essentially telling the defender that killing the process isn’t supposed to be a clean operation.
Kaspersky says ValleyRAT can detect security and traffic-analysis tools, while the campaign has been detected over 100,000 times in 2026, affecting more than 1,500 users, mainly in China and India. The activity is linked to Silver Fox, focused on both espionage and financial gain.
In July 2026, Cato CTRL documented a SilverFox campaign targeting a Japanese industrial manufacturer. The attack chain adds two previously undocumented DLL-sideloading hosts, two kernel drivers not previously associated with SilverFox, and a dual-layer recovery architecture that keeps ValleyRAT running even if defenders terminate individual components.
That broader activity puts the Kaspersky finding into perspective. The adware campaign isn’t an isolated curiosity. It fits a larger pattern in which Silver Fox uses legitimate software, familiar brands and trusted execution paths to get malicious code onto Windows systems and keep it there.
For defenders, blocking a known ValleyRAT file is not enough because the real risk is how the malware gets executed. A legitimate-looking application, signed component or familiar installer can become part of a malicious chain. Antivirus exclusions can make the problem worse by creating blind spots.
“This case is a clear example of how adware and affiliate networks can turn out to be far more dangerous than they appear. ValleyRAT is a sophisticated backdoor capable of collecting sensitive data such as keystrokes and clipboard contents, taking screenshots, and delivering additional malicious modules.” concludes the report. “The attackers exploited a well-known adware application to run the backdoor under the guise of a signed process, which complicates detection.”
Kaspersky recommends clear rules for third-party software, security awareness and avoiding suspicious applications or exclusions simply because a program asks for them. The malware does not need to look dangerous; it only needs to look legitimate enough that nobody questions why an ordinary application suddenly behaves like a backdoor.
Kaspersky uncovered a ValleyRAT backdoor adware campaign using signed wallpaper apps to drop malware. Learn how to protect your systems.
Related Posts:
UAT-10147 Deploys SPECTRE Cross-Platform Implant
Kimsuky Spear Phishing Abuses Remote Control Tools
Fire Ant Threat Actor Targets Trusted Infrastructure
The post ValleyRAT Backdoor Spread via Signed Chinese Adware appeared first on Daily CyberSecurity.
Attackers typically try to pass off malware as legitimate applications or as potentially unwanted programs that users deliberately search for and download, such as cheats or cracks. They often rely on ad and affiliate networks to deliver their creations to victims’ devices. This post examines a less conventional case: a well-known backdoor distributed under the guise of adware. The attackers may have chosen this distribution method because the adware was signed by the developer. On top of that,
Attackers typically try to pass off malware as legitimate applications or as potentially unwanted programs that users deliberately search for and download, such as cheats or cracks. They often rely on ad and affiliate networks to deliver their creations to victims’ devices. This post examines a less conventional case: a well-known backdoor distributed under the guise of adware. The attackers may have chosen this distribution method because the adware was signed by the developer. On top of that, users often manually add these apps to exclusions, so their useful features don’t get blocked.
Some time ago, a client asked us to analyze a file with the MD5 hash c24e99f9437feacaa63766a3cde3fe3d and add it to our detection database. We initially classified it as adware, but a cursory analysis turned up suspicious network activity, which prompted us to dig deeper. It turned out the sample did far more than serve ads. In fact, its advertising functionality doesn’t even work; instead, it triggers an infection chain that delivers the ValleyRAT backdoor.
Malicious installer
The file the client shared with us turned out to be an installer that performed different actions depending on the two-letter suffix used in the file name, positioned just before the numeric string.
Installer name
What it does
FS_SETUP_DD_173.exe
Installs DingTalk, a workplace collaboration platform
FS_SETUP_GG_173.exe
Installs Google Chrome
FS_SETUP_HY_173.exe
Opens hxxps://meeting[.]tencent[.]com/download/
These actions are most likely designed to divert the user’s attention away from the sample’s malicious functionality. Regardless of the file name, the installer deploys a modified Chinese desktop wallpaper management tool called QN Wallpaper (hxxps://qnwallpaper[.]keansoft[.]cn/) and adds it to the registry’s autorun entries.
The original version of QN Wallpaper is genuine adware: on installation, it delivers bundled partner apps to the device and then displays ad banners to the user. In this case, however, the attackers use it to carry out DLL sideloading, a technique that allows malicious code to run under the guise of a signed process by way of a malicious DLL.
The QN Wallpaper modules, along with the malicious components, are unpacked to C:\Program Files\QNWallpaper\5.4.0.1662\<random string of letters and digits>. The following files are saved in that directory:
File name
MD5
Purpose
1.zip
7ad1e3ef4e6d9d636c9e7e967733850e
Archive containing the adware files QnWallpeper.exe and QnwPlayer.exe, along with the modules needed to run them
7z.dll
96b4c1d0683dce22bd3223e1e40689c1
7z archiver library
7z.exe
9b86d3ab6cef15c633933fbbeab39c0a
Archiver
chrome_elf.dll
edfdc30cbd85879776b8f735ea7de1f1
Library used to launch Electron-based applications
libcef.dll
07ddbbe2c71c45577a7a4fbcdba0df91
Malicious library
PeLoader
48826d5ca845979d2e6ebd66dc1aae90
File containing the encrypted backdoor
QnWallpaper.exe
6c158c0f8e029342192d4f0d72e102b7
Adware module
QnwPlayer.exe
9a71d6a41cd258b9e89cdc5fc224de73
Adware module
<random string of letters and digits>Nedca.exe
c24e99f9437feacaa63766a3cde3fe3d
Malicious installer copy
After unpacking, the installer uses the DisableAntiSpyware registry key to disable Windows Defender and then launches QnWallpaper.exe.
Disabling Windows Defender
DLL Sideloading via libcef.dll
QnWallpaper.exe has dependencies in libcef.dll, so this library gets loaded when the process starts. QnWallpaper.exe also launches QnwPlayer.exe, which likewise calls libcef.dll.
QnWallpaper and QnwPlayer won’t actually function correctly, because the functions exported from libcef.dll are put into an infinite sleep. However, in case that sleep is ever interrupted, the attackers have implemented a function that loads all the necessary functions from the original library into memory, provided it can locate that library on the system.
Example of an exported function
Loading functions from the original libcef.dll
The malicious functionality in libcef.dll is invoked by a call to DllMain, which runs automatically when the library is loaded. That said, alongside the original exports, the library also contains a function named RunDLL, which likewise initiates execution of the malicious code. QnWallpaper never calls this function. We suspect the attackers intended to invoke it manually via rundll32 or planned to use a separate executable for this purpose, one that wasn’t included in the package downloaded by the sample.
The RunDLL function
Running the malicious code
When the library is loaded, code runs that ensures QnWallpaper.exe persists at startup: it adds a file extension association and drops a file with the corresponding extension in C:\Documents and Settings\<username>\Start Menu\Programs\Startup\.
This is followed by a chain of wrapper functions whose main job is to call the next one. Execution eventually reaches the function that contains the actual malicious code. For convenience, we’ll refer to it as mw_entry.
Inside mw_entry, the malware checks two things:
Whether the current user belongs to the Administrators group
Which process the DLL is running inside
Checking for administrator privileges
If the user isn’t a member of the Administrators group, the program attempts to obtain administrator privileges by using the runas utility.
Relaunching the process to obtain administrator privileges
Once it has administrator privileges, the malicious code determines which process the DLL has been loaded into, and selects the payload accordingly:
If the library is running inside QnWallpaper.exe, the payload is loaded from the PeLoader file.
Encrypted payload
If the library is running inside QnwPlayer.exe, the payload is loaded from libcef.dll resources.
Retrieving the payload from a resource
Both payloads are AES-encrypted DLLs that contain the ValleyRAT backdoor. The only difference between them is their configuration, specifically, the C2 server addresses. After decryption, libcef.dll checks the magic signatures in the resulting PE file’s headers to confirm the sample is valid. If this check fails, the library releases its resources and takes no further action.
Validating the PE file headers after decryption
If the headers check out, libcef.dll loads the payload into the process’s memory space and hands control over to the backdoor by calling DllMain.
Calling DllMain
ValleyRAT
ValleyRAT begins its operation by parsing its configuration, which consists of key:value pairs concatenated into a single string. To obfuscate this configuration, the attackers wrote the string in reverse.
Obfuscated configuration
During parsing, the backdoor restores the correct character order and reads the key values one by one. The set of keys is the same regardless of which process the backdoor is running in.
Parsing the configuration
Some of the configuration fields are listed below:
Key
Description
p?
C2 server IP address
o?
C2 server port
t?
Protocol (1: TCP, 0: UDP)
dd
Sleep duration before executing the main code
cl
Sleep duration after receiving the corresponding command from the server
bz
Configuration creation date
bh
Whether to mark the current process as critical (so that terminating it triggers a blue screen of death) Possible values: 1: yes, 0: no
ll
Whether to check for running security/traffic-analysis tools/processes (1: check, 0: do not check)
sh
Whether to inject code into svchost that will restart the malicious process (1: inject, 0: do not inject)
The backdoor uses several techniques to protect its process. Some are configuration-dependent, while others are always applied:
Injecting code into svchost to restart the process: a configurable option. The backdoor allocates memory inside the svchost process, injects code into it, and sets PAGE_NOACCESS permissions on the memory page containing the injected data. It then creates a suspended thread, waits 60 seconds, grants read, write, and execute permissions on the page, and resumes the thread.
Injecting code into svchost
The function injected into the process has a single job: restart the backdoor if its execution is interrupted for any reason.
Injected function
Marking its own process as critical (so that terminating it triggers a blue screen of death): a configurable option.
Setting its own process as critical
Restarting on an unhandled exception. This protection mechanism is always active, regardless of the backdoor’s configuration.
Restarting on exceptions
The backdoor also has spyware functionality. While running, it tracks keystrokes and the currently focused window by using functions from the DirectInput8 library. It also captures clipboard contents. All collected data is saved to a file on disk.
Capturing clipboard data
If the ll key in the configuration is set to 1, ValleyRAT periodically checks for active windows belonging to applications that could be used to analyze processes or traffic. Window enumeration is done via the EnumWindows function, using the following callback:
Window name checks
After completing these checks, the backdoor collects system information, including:
Host name
Host IP addresses
User idle time
Detailed Windows version information (ProductName, EditionId, DisplayVersion)
Number of CPU cores
Free disk space
Graphics adapter
Currently focused window and its title
System bitness
Language settings
Path to the system directory
On command, the backdoor can perform the actions typical of this malware category:
Rebooting the computer
Shutting down the computer
Taking a screenshot
Wiping logs
Updating its C2 addresses
Downloading additional modules
Sending keylogger logs along with clipboard contents
Snippet of the command handler
Let’s take a closer look at the module-loading functionality. Upon receiving the corresponding command with a link from its operator, the backdoor downloads the file at that link and executes it. The download can come from either the C2 server or a third-party address.
The DownloadPeFile function is responsible for downloading a PE file
The DownloadAndExecute function calls DownloadPeFile, then launches the downloaded module
Additional modules can take the form of purpose-built dynamic libraries or shellcode. If the payload is shellcode, the backdoor uses process hollowing with svchost to launch the module.
Implementation of the process hollowing technique
If the module is a dynamic library, the backdoor loads the PE file into its own process, calls DllMain, and searches for a Main function among the exported functions. Once Main has been called, the library is unloaded from memory.
Calling DllMain after the backdoor loads the PE file
Targets and attribution
Over the course of 2026, we detected the ValleyRAT backdoor and its associated malware more than 100,000 times, with more than 1500 unique users affected, primarily in China and India.
This attack geography, combined with the use of the ValleyRAT backdoor, points to Silver Fox, a known operator of this malware family, as the likely group behind the campaign.
Conclusion
This case is a clear example of how adware and affiliate networks can turn out to be far more dangerous than they appear. ValleyRAT is a sophisticated backdoor capable of collecting sensitive data such as keystrokes and clipboard contents, taking screenshots, and delivering additional malicious modules. The attackers exploited a well-known adware application to run the backdoor under the guise of a signed process, which complicates detection.
Motivated by both cyberespionage and financial gain, Silver Fox targets organizations across multiple countries. To stay protected, organizations should keep employee cybersecurity awareness up to date and enforce clear policies on the use of third-party software on work devices.
For individual users, we recommend avoiding the installation of software with a questionable reputation, and, even more importantly, never adding such software to your security solutions’ exclusion lists.
SilverFox targeted a Japanese manufacturer with new DLL sideloading techniques, kernel drivers, and resilient ValleyRAT persistence mechanisms.
Cato CTRL documented a new SilverFox campaign targeting a Japanese industrial manufacturer. The attack chain adds two previously undocumented DLL-sideloading hosts, two kernel drivers not previously associated with SilverFox, and a dual-layer recovery architecture that keeps ValleyRAT running even if defenders terminate individual components.
The
SilverFox targeted a Japanese manufacturer with new DLL sideloading techniques, kernel drivers, and resilient ValleyRAT persistence mechanisms.
Cato CTRL documented a new SilverFox campaign targeting a Japanese industrial manufacturer. The attack chain adds two previously undocumented DLL-sideloading hosts, two kernel drivers not previously associated with SilverFox, and a dual-layer recovery architecture that keeps ValleyRAT running even if defenders terminate individual components.
The attack chain starts with an invoice-themed phishing email. The last stage was remote access via ValleyRAT. Everything in between is the interesting part.
“The attack begins with an invoice-themed phishing lure and uses attacker-controlled content hosted through legitimate QQ and Tencent Cloud services. The attackers then abuse ConvertToPDF.exe and PDFDirect.exe to sideload a malicious PDFCORE8.dll.” reads the report published by Cato. “Based on the public research we reviewed, neither application had previously been documented as a DLL-sideloading host.”
Both applications are legitimate products from Zeon Corporation, digitally signed and unmodified. The attack works because Windows resolves DLL dependencies from the local working directory first, so placing a malicious PDFCORE8.dll in the same folder as the trusted executable is enough.
In some samples, the executable was also renamed MicrosoftEdgeUpdate.exe to reduce suspicion further, which at least shows a sense of humor about impersonation targets.
Once loaded, PDFCORE8.dll operates as a self-contained execution framework with all its most dangerous components stored inside as encrypted resources.
“The malicious PDFCORE8.dll embeds BootRepair.sys, EnPortv.sys, and wsftprm.sys and manages them through shared resource-decryption, driver-deployment, service-creation, and device-communication routines.” continues the report. “One of the most significant findings in this campaign is SilverFox’s modular BYOVD framework. Rather than depending on a single signed but vulnerable driver, the malware supports three options: BootRepair.sys, EnPortv.sys, and wsftprm.sys.“
Across variants, the malware mainly changes the driver image, device name, and IOCTL value while reusing the same core framework.
The practical implication of this modular design is that blocking one driver doesn’t stop the attack, the framework simply tries another. BootRepair.sys and EnPortv.sys are both new associations for SilverFox; wsftprm.sys appeared in prior reporting on the group.
All three drivers ultimately serve the same purpose: getting a process identifier into kernel space and calling ZwTerminateProcess() on security products that user-mode processes can’t touch. The user-mode component enumerates running processes, matches them against a hardcoded list of endpoint security tools, and passes the PIDs to whichever driver is loaded. The driver handles the actual kill from kernel mode. The malware also unhooks NTDLL by replacing its in-memory .text section with a clean copy from disk, removing inline monitoring hooks before calling native Windows APIs.
After terminating security processes and cleaning up API hooks, the malware contacts its C2 at 43.128.26[.]132, downloads shellcode, injects it into a suspended svchost.exe process via thread-context hijacking, and stores both the shellcode and its configuration in the registry, under HKCU\Console\0 and HKLM\SOFTWARE\IpDates_sun respectively.
“Before executing the registry-resident shellcode, the malware searches it for the marker: FaCai2024 The marker does not represent executable instructions. Instead, it identifies a reserved region inside the payload where the malware inserts its runtime configuration.” continues the report. “The framework retrieves the configuration from: HKLM\SOFTWARE\IpDates_sunIt then replaces the FaCai2024 placeholder with the recovered C2 information, producing a fully configured payload immediately before execution. This separation gives the attacker operational flexibility. The same stored payload can be reused with updated server addresses or ports without changing the payload body itself.”
“Fa Cai” means “become prosperous” in Mandarin. Tencent Security previously documented the same marker and registry location in earlier FaCai phishing group activity.
The recovery architecture is what makes this campaign notably harder to disrupt than typical malware deployments. An internal monitoring routine checks every cycle whether the injected svchost.exe process is still active, and recreates the payload if it isn’t. An external watchdog, a batch script embedded in the DLL’s resources and executed via cmd.exe, checks every 30 seconds whether the loader itself is still running, and relaunches it if not. Defenders who terminate only the injected payload leave the loader running to recreate it.
Defenders who terminate only the loader leave the watchdog running to restart it. Both components need to go simultaneously, and then the scheduled task that relaunches the loader on logon needs to go too.
Detection should focus on behavior sequences rather than individual indicators. ConvertToPDF.exe or PDFDirect.exe executing from %TEMP%, kernel-driver services for any of the three embedded drivers appearing, binary data written to HKCU\Console\0, and tasklist.exe or find.exe running repeatedly from cmd.exe are each individually explainable — together they describe this specific attack chain. Cato’s NGAM blocked the malicious PDFCORE8.dll before the driver deployment stage was reached in the observed incident, which cut the chain at its most central point since the DLL contains every subsequent capability the attack depends on.
“This campaign shows how SilverFox is expanding its defense-evasion and remote-access toolkit. The most significant additions are the previously undocumented SilverFox use of BootRepair.sys and EnPortv.sys, along with the abuse of ConvertToPDF.exe and PDFDirect.exe as DLL-sideloading hosts.” concluders the report. “The malicious PDFCORE8.dll brings these capabilities together in one modular stage that combines vulnerable-driver deployment, security-process termination, NTDLL unhooking, thread-context hijacking, registry-based payload storage, and dual recovery mechanisms. This design improves resilience by allowing the malware to restore execution if either the payload or loader is interrupted.”
Proofpoint says TA4922, a suspected China aligned cybercrime group, is targeting UK and European organisations with tax, payroll and benefits themed malware campaigns.
Proofpoint says TA4922, a suspected China aligned cybercrime group, is targeting UK and European organisations with tax, payroll and benefits themed malware campaigns.
In December 2025, we detected a wave of malicious emails designed to look like official correspondence from the Indian tax service. A few weeks later, in January 2026, a similar campaign began targeting Russian organizations. We have attributed this activity to the Silver Fox threat group.
Both waves followed a nearly identical structure: phishing emails were styled as official notices regarding tax audits or prompted users to download an archive containing a “list of tax violations”. Inside the
In December 2025, we detected a wave of malicious emails designed to look like official correspondence from the Indian tax service. A few weeks later, in January 2026, a similar campaign began targeting Russian organizations. We have attributed this activity to the Silver Fox threat group.
Both waves followed a nearly identical structure: phishing emails were styled as official notices regarding tax audits or prompted users to download an archive containing a “list of tax violations”. Inside the archive was a modified Rust-based loader pulled from a public repository. This loader would download and execute the well-known ValleyRAT backdoor. The campaign impacted organizations across the industrial, consulting, retail, and transportation sectors, with over 1600 malicious emails recorded between early January and early February.
During our investigation, we also discovered that the attackers were delivering a new ValleyRAT plugin to victim devices, which functioned as a loader for a previously undocumented Python-based backdoor. We have named this backdoor ABCDoor. Retrospective analysis reveals that ABCDoor has been part of the Silver Fox arsenal since at least late 2024 and has been utilized in real-world attacks from the first quarter of 2025 to the present day.
Email campaign
In the January campaign, victims received an email purportedly from the tax service with an attached PDF file.
Phishing email sent to victims in Russia
The PDF contained two clickable links to download an archive, both leading to a malicious website: abc.haijing88[.]com/uploads/фнс/фнс.zip.
Contents of the PDF file from the January phishing wave
Contents of the фнс.zip archive
In the December campaign, the malicious code was embedded directly within the files attached to the email.
Phishing email sent to victims in India
The email shown in the screenshot above was sent via the SendGrid cloud platform and contained an archive named ITD.-.rar. Inside was a single executable file, Click File.exe, with an Adobe PDF icon (the RustSL loader).
Contents of ITD.-.rar
Additionally, in late December, emails were distributed with an attachment titled GST.pdf containing two links leading to hxxps://abc.haijing88[.]com/uploads/印度邮箱/CBDT.rar. (印度邮箱 translates from Chinese as “Indian mailbox”).
PDF file from the phishing email
Both versions of the campaign attempt to exploit the perceived importance of tax authority correspondence to convince the victim to download the document and initiate the attack chain. The method of using download links within a PDF is specifically designed to bypass email security gateways; since the attached document only contains a link that requires further analysis, it has a higher probability of reaching the recipient compared to an attachment containing malicious code.
RustSL loader
The attackers utilized a modified version of a Rust-based loader called RustSL, whose source code is publicly available on GitHub with a description in Chinese:
Screenshot of the description from the RustSL loader GitHub project
The description also refers to RustSL as an antivirus bypass framework, as it features a builder with extensive customization options:
Eight payload encryption methods
Thirteen memory allocation methods
Twelve sandbox and virtual machine detection techniques
Thirteen payload execution methods
Five payload encoding methods
Furthermore, the original version of RustSL encrypts all strings by default and inserts junk instructions to complicate analysis.
The Silver Fox APT group first began using a modified version of RustSL in late December 2025.
Silver Fox RustSL
This section examines the key changes the Silver Fox group introduced to RustSL. We will refer to this customized version as Silver Fox RustSL to distinguish it from the original.
The steganography.rs module
The attackers added a module named steganography.rs to RustSL. Despite the name, it has little to do with actual steganography; instead, it implements the unpacking logic for the malicious payload.
The usage of the new module within the Silver Fox RustSL code
The threat actors also modified the RustSL builder to support the new format and payload packing.
The attackers employed several methods to deliver the encrypted malicious payload. In December, we observed files being downloaded from remote hosts followed by delivery within the loader itself. Later, the attackers shifted almost entirely to placing the malicious payload inside the same archive as the loader, disguised as a standalone file with extensions like PNG, HTM, MD, LOG, XLSX, ICO, CFG, MAP, XML, or OLD.
Encrypted malicious payload format
The encrypted payload file delivered by the Silver Fox RustSL loader followed this structure:
<RSL_START>rsl_encrypted_payload<RSL_END>
If additional payload encoding was selected in the builder, the loader would decode the data before proceeding with decryption.
The rsl_encrypted_payload followed this specific format:
Below is a description of the data blocks contained within it:
sha256_hash: the hash of the decrypted payload. After decryption, the loader calculates the SHA256 hash and compares it against this value; if they do not match, the process terminates.
enc_payload_len: the size of the encrypted payload
sgn_iterations and sgn_key: parameters used for decryption
sgn_decoder_size and decoder: unused fields
enc_payload: the primary payload
Notably, the new proprietary steganography.rs module was implemented using the same logic as the public RustSL modules (such as ipv4.rs, ipv6.rs, mac.rs, rc4.rs, and uuid.rs in the decrypt directory). It utilized a similar payload structure where the first 32 bytes consist of a SHA-256 hash and the payload size.
To decrypt the malicious payload, steganography.rs employed a custom XOR-based algorithm. Below is an equivalent implementation in Python:
def decrypt(data: bytes, sgn_key: int, sgn_iterations: int) -> bytes:
buf = bytearray(data)
xor_key = sgn_key & 0xFF
for _ in range(sgn_iterations):
k = xor_key
for i in range(len(buf)):
dec = buf[i] ^ k
if k & 1:
k = (dec ^ ((k >> 1) ^ 0xB8)) & 0xFF
else:
k = (dec ^ (k >> 1)) & 0xFF
buf[i] = dec
return bytes(buf)
The unpacking process consists of the following stages:
Extraction of rsl_encrypted_payload.The loader extracts the encrypted payload body located between the <RSL_START> and <RSL_END> markers.
Original file containing the encrypted malicious payload
XOR decryption with a hardcoded key.Most loaders used the hardcoded key RSL_STEG_2025_KEY.
Payload decoding occurs if the corresponding setting was enabled in the builder.The GitHub version of the builder offers several encoding options: Base64, Base32, Hex, and urlsafe_base64. Silver Fox utilized each option at least once. Base64 was the most frequent choice, followed by Hex and Base32, with urlsafe_base64 appearing in a few samples.
Encrypted malicious payload prior to the final decryption stage
Decryption of the final payload using a multi-pass XOR algorithm that modifies the key after each iteration (as demonstrated in the Python algorithm provided above).
The guard.rs module
Another module added to Silver Fox RustSL is guard.rs. It implements various environment checks and country-based geofencing.
In the earliest loader samples from late December 2025, the Silver Fox group utilized every available method for detecting virtual machines and sandboxes, while also verifying if the device was located in a target country. In later versions, the group retained only the geolocation check; however, they expanded both the list of countries allowed for execution and the services used for verification.
The GitHub version of the loader only includes China in its country list. In customized Silver Fox loaders built prior to January 19, 2026, this list included India, Indonesia, South Africa, Russia, and Cambodia. Starting with a sample dated January 19, 2026 (MD5: e6362a81991323e198a463a8ce255533), Japan was added to the list.
To determine the host country, Silver Fox RustSL sends requests to five public services:
ip-api.com (the GitHub version relies solely on this service)
ipwho.is
ipinfo.io
ipapi.co
www.geoplugin.net
Phantom Persistence
We discovered that a loader compiled on January 7, 2026 (MD5: 2c5a1dd4cb53287fe0ed14e0b7b7b1b7), began to use the recently documented Phantom Persistence technique to establish persistence. This method abuses functionality designed to allow applications requiring a reboot for updates to complete the installation process properly. The attackers intercept the system shutdown signal, halt the normal shutdown sequence, and trigger a reboot under the guise of an update for the malware. Consequently, the loader forces the system to execute it upon OS startup. This specific sample was compiled in debug mode and logged its activity to rsl_debug.log, where we identified strings corresponding to the implementation of the Phantom Persistence technique:
[unix_timestamp] God-Tier Telemetry Blinding: Deployed via HalosGate Indirect Syscalls.
[unix_timestamp] RSL started in debug mode.
[unix_timestamp] ==========================================
[unix_timestamp] Phantom Persistence Module (Hijack Mode)
[unix_timestamp] ==========================================
[unix_timestamp] [*] Calling RegisterApplicationRestart...
[unix_timestamp] [+] RegisterApplicationRestart succeeded.
[unix_timestamp] [*] Note: This API mainly works for application crashes, not for user-initiated shutdowns.
[unix_timestamp] [*] For full persistence, you need to trigger the shutdown hijack logic.
[unix_timestamp] [*] Starting message thread to monitor shutdown events...
[unix_timestamp] [+] SetProcessShutdownParameters (0x4FF) succeeded.
[unix_timestamp] [+] Window created successfully, message loop started.
[unix_timestamp] [+] Phantom persistence enabled successfully.
[unix_timestamp] [*] Hijack logic: Shutdown signal -> Abort shutdown -> Restart with EWX_RESTARTAPPS.
[unix_timestamp] Phantom persistence enabled.
[unix_timestamp] Mouse movement check passed.
[unix_timestamp] IP address check passed.
[unix_timestamp] Pass Sandbox/VM detection.
Attack chain and payloads
During this phishing campaign, Silver Fox utilized two primary methods for delivering malicious archives:
As an email attachment
Via a link to an external attacker-controlled website contained within a PDF attachment
We also observed three different ways the payload was positioned relative to the loader:
Embedded within the loader body
Hosted on an external website as a PNG image
Placed within the same archive as the loader
The diagram below illustrates the attack chain using the example of an email containing a PDF file and the subsequent delivery of a malicious payload from an external attacker-controlled website.
Attack chain of the campaign utilizing the RustSL loader
The infection chain begins when the user runs an executable file (the Silver Fox modification of the RustSL loader) disguised with a PDF or Excel icon. RustSL then loads an encrypted payload, which functions as shellcode. This shellcode then downloads an encrypted ValleyRAT (also known as Winos 4.0) backdoor module named 上线模块.dll from the attackers’ server. The filename translates from Chinese as “online-module.dll”, so for the sake of clarity, we’ll refer to it as the Online module.
Beginning of the decrypted payload: shellcode for loading the ValleyRAT (Winos 4.0) Online module
The Online module proceeds to load the core component of ValleyRAT: the Login module (the original filename 登录模块.dll_bin translates from Chinese as “login-module.dll_bin”). This module manages C2 server communication, command execution, and the downloading and launching of additional modules.
The initial shellcode, as well as the Online and Login modules, utilize a configuration located at the end of the shellcode:
End of the decrypted payload: ValleyRAT (Winos 4.0) configuration
The values between the “|” delimiters are written in reverse order. By restoring the correct character sequence, we obtain the following string:
The key configuration parameters in this string are:
p#, o#: IP addresses and ports of the ValleyRAT C2 servers in descending order of priority
bz: the creation date of the configuration
The Silver Fox group has long employed the infection chain described above – from the encrypted shellcode through the loading of the Login module – to deploy ValleyRAT. This procedure and its configuration parameters are documented in detail in industry reports: (1, 2, and 3).
Once the Login module is running, ValleyRAT enters command-processing mode, awaiting instructions from the C2. These commands include the retrieval and execution of various additional modules.
ValleyRAT utilizes the registry to store its configurations and modules:
Registry key
Description
HKCU:\Console\0
For x86-based modules
HKCU:\Console\1
For x64-based modules
HKCU:\Console\IpDate
Hardcoded registry location checked upon Login module startup
HKCU:\Software\IpDates_info
Final configuration
The ValleyRAT builder leaked in March 2025 contained 20 primary and over 20 auxiliary modules. During this specific phishing campaign, we discovered that after the main module executed, it loaded two previously unseen modules with similar functionality. These modules were responsible for downloading and launching a previously undocumented Python-based backdoor we have dubbed ABCDoor.
Custom ValleyRAT modules
The discovered modules are named 保86.dll and 保86.dll_bin. Their parameters are detailed in the table below.
HKCU:\Console\0 registry key value
Module name
Library MD5 hash
Compiled date and time (UTC)
fc546acf1735127db05fb5bc354093e0
保86.dll
4a5195a38a458cdd2c1b5ab13af3b393
2025-12-04 04:34:31
fc546acf1735127db05fb5bc354093e0
保86.dll
e66bae6e8621db2a835fa6721c3e5bbe
2025-12-04 04:39:32
2375193669e243e830ef5794226352e7
保86.dll_bin
e66bae6e8621db2a835fa6721c3e5bbe
2025-12-04 04:39:32
Of particular note is the PDB path found in all identified modules: C:\Users\Administrator\Desktop\bat\Release\winos4.0测试插件.pdb. In Chinese, 测试插件 translates to “test plugin”, which may suggest that these modules are still in development.
Upon execution, the 保86.dll module determines the host country by querying the same five services used by the guard.rs module in Silver Fox RustSL: ipinfo.io, ip-api.com, ipapi.co, ipwho.is, and geoplugin.net. For the module to continue running, the infected device must be located in one of the following countries:
Countries where the 保86.dll module functions
If the geolocation check passes, the module attempts to download a 52.5 MB archive from a hardcoded address using several methods. The sample with MD5 4a5195a38a458cdd2c1b5ab13af3b393 queried hxxp://154.82.81[.]205/YD20251001143052.zip, while the sample with MD5 e66bae6e8621db2a835fa6721c3e5bbe queried
hxxp://154.82.81[.]205/YN20250923193706.zip.
Interestingly, Silver Fox updated the YD20251001143052.zip archive multiple times but continued to host it on the same C2 (154.82.81[.]205) without changing the filename.
The module implements the following download methods:
Using the InternetReadFile function with the User-Agent PythonDownloader
The archive was saved to the path %LOCALAPPDATA%\appclient\111.zip.
Contents of the 111.zip archive
The archive is quite large because the python directory contains a Python environment with the packages required to run the previously unknown ABCDoor backdoor (which we will describe in the next section), while the ffmpeg directory includes ffmpeg.exe, a statically linked, legitimate audio/video tool that the backdoor uses for screen capturing.
Once downloaded, the DLL module extracts the archive using COM methods and runs the following command to execute update.bat:
The update.bat script copies the extracted files to C:\ProgramData\Tailscale. This path was chosen intentionally: it corresponds to the legitimate utility Tailscale (a mesh VPN service based on the WireGuard protocol that connects devices into a single private network). By mimicking a VPN service, the attackers likely aim to mask their presence and complicate the analysis of the compromised system.
@echo off
set "script_dir=%~dp0"
set SRC_DIR=%script_dir%
set DES_DIR=C:\ProgramData\Tailscale
rmdir /s /q "%DES_DIR%"
mkdir "%DES_DIR%"
call :recursiveCopy "%SRC_DIR%" "%DES_DIR%"
start "" /B "%DES_DIR%\python\pythonw.exe" -m appclient
exit /b
:recursiveCopy
set "src=%~1"
set "dest=%~2"
if not exist "%dest%" mkdir "%dest%"
for %%F in ("%src%\*") do (
copy "%%F" "%dest%" >nul
)
for /d %%D in ("%src%\*") do (
call :recursiveCopy "%%D" "%dest%\%%~nxD"
)
exit /b
Contents of update.bat
After copying the files, the script launches the appclient Python module using the legitimate pythonw tool:
The primary entry point for the appclient module, the __main__.py file, contains only a few lines of code. These lines are responsible for utilizing the setproctitle library and executing the run function, to which the C2 address is passed as a parameter.
Code for main.py: the module entry point
The setproctitle library is primarily used on Linux or macOS systems to change a displayed process name. However, its functionality is significantly limited on Windows; rather than changing the process name itself, it creates a named object in the format python(<pid>): <proctitle>. For example, for the appclient module, this object would appear as follows:
We believe the use of setproctitle may indicate the existence of backdoor versions for non-Windows systems, or at least plans to deploy it in such environments.
The appclient.core module has a PYD extension and is a DLL file compiled with Cython 3.0.7. This is the core module of the backdoor, which we have named ABCDoor because nearly all identified C2 addresses featured the third-level domain abc.
Upon execution, the backdoor establishes persistence in the following locations:
Windows registry: It adds "<path_to_pythonw.exe>" -m appclient to the value HKCU:\Software\Microsoft\Windows\CurrentVersion\Run:AppClient, e.g:
The command creates a task named “AppClient” that runs every minute.
The backdoor is built on the asyncio and Socket.IO Python libraries. It communicates with its C2 via HTTPS and uses event handlers to processes messages asynchronously. The backdoor follows object-oriented programming principles and includes several distinct classes:
MainManager: handles C2 connection and authorization (sending system metadata)
MessageManager: registers and executes message handlers
AutoStartManager: manages backdoor persistence
ClientManager: handles backdoor updates and removal
SystemInfoManager: collects data from the victim’s system, including screenshots
RemoteControlManager: enables remote mouse and keyboard control via the pynput library and manages screen recording (using the ScreenRecorder child class)
FileManager: performs file system operations
KeyboardManager: emulates keyboard input
ProcessManager: manages system processes
ClipboardManager: exfiltrates clipboard contents to the C2
CryptoManager: provides functions for encrypting and decrypting files and directories (currently limited to DPAPI; asymmetric encryption functions lack implementation)
First, the get_machine_guid_via_file_func function attempts to read an identifier from the file %LOCALAPPDATA%\applogs\device.log. If the file does not exist, it is created and initialized with a random UUID4 value. However, immediately after this, the get_machine_guid_via_reg function overwrites the identifier obtained by the first function with the value from HKLM:\SOFTWARE\Microsoft\Cryptography:MachineGuid. This likely indicates a bug in the code.
The primary characteristic of this backdoor is the absence of typical remote control features, such as creating a remote shell or executing arbitrary commands. Instead, it implements two alternative methods for manipulating the infected device:
Emulating a double click while broadcasting the victim’s screen
A "file_open" message within the FileManager class, which calls the os.startfile function. This executes a specified file using the ShellExecute function and the default handler for that file extension
For screen broadcasting, the backdoor utilizes a standalone ffmpeg.exe file included in the ABCDoor archive. While early versions could only stream from a single monitor, recent iterations have introduced support for streaming up to four monitors simultaneously using the Desktop Duplication API (DDA). The broadcasting process relies on the screen capture functions RemoteControl::ScreenRecorder::start_single_monitor_ddagrab, RemoteControl::ScreenRecorder::start_multi_monitor_ddagrab, and RemoteControl::ScreenRecorder::test_ddagrab_support. These functions generate a lengthy string of launch arguments for ffmpeg; these arguments account for monitor orientation (vertical or horizontal) and quantity, stitching the data into a single, cohesive stream.
Because ABCDoor runs within a legitimate pythonw.exe process, it can remain hidden on a victim’s system for extended periods. However, its operation involves various interactions with the registry and file system that can be used for detection. Specifically, ABCDoor:
Writes its initial installation timestamp to the registry value HKCU:\Software\CarEmu:FirstInstallTime
Creates the directory and file %LOCALAPPDATA%\applogs\device.log to store the victim’s ID
Logs any exceptions to %LOCALAPPDATA%\applogs\exception_logs.zip. Interestingly, Silver Fox even implemented a Utility::upload_exception_logs function to send this archive to a specified URI, likely to help debug and refine the malware’s performance
Additionally, ABCDoor features self-update and self-deletion capabilities that generate detectable artifacts. Updates are downloaded from a specific URI to %TEMP%\tmpXXXXXXXX\update.zip (where XXXXXXXX represents random alphanumeric characters), extracted to %TEMP%\tmpXXXXXXXX\update, and executed via a PowerShell command:
The existing ABCDoor process is then forcibly terminated.
ABCDoor versions
Through retrospective analysis, we discovered that the earliest version of ABCDoor (MD5: 5b998a5bc5ad1c550564294034d4a62c) surfaced in late 2024. The backdoor evolved rapidly throughout 2025. The table below outlines the primary stages of its evolution:
Version
Compiled date (UTC)
Key updates
ABCDoor .pyd MD5 hash
121
2024.12.19 18:27:11
– Minimal functionality (file downloads, remote control using the Graphics Device Interface (GDI) in ffmpeg)
– No OOP used
– Registry persistence
– DPAPI encryption functions
– Chunked file uploading to C2
de8f0008b15f2404f721f76fac34456a
154
2025.05.09 13:36:24
– Implementation of installation channels
– Key combination emulation
9bf9f635019494c4b70fb0a7c0fb53e4
156
2025.08.11 13:36:10
– Retrieval and logging of initial installation time to the registry
a543b96b0938de798dd4f683dd92a94a
157
2025.08.28 14:23:57
– Use of DDA source in ffmpeg for monitor screen broadcasting
fa08b243f12e31940b8b4b82d3498804
157
2025.09.23 11:38:17
– Compiled with Cython 3.0.7 (previous version used Cython 3.0.12)
13669b8f2bd0af53a3fe9ac0490499e5
Evolution of ABCDoor distribution methods
Although the first version of the backdoor appeared in late 2024, the threat actor likely began using it in attacks around February or March 2025. At that time, the backdoor was distributed using stagers written in C++ and Go:
C++ stagerThe file GST Suvidha.exe (MD5: 04194f8ddd0518fd8005f0e87ae96335) downloaded a loader (MD5: f15a67899cfe4decff76d4cd1677c254) from hxxps://mcagov[.]cc/download.php?type=exe. This loader then downloaded the ABCDoor archive from hxxps://abc.fetish-friends[.]com/uploads/appclient.zip, extracted it, and executed it.
Go stagerThe file GSTSuvidha.exe (MD5: 11705121f64fa36f1e9d7e59867b0724) executed a remote PowerShell script:
Thanks to these “channel” names, we identified overlaps between ABCDoor and other malicious files likely belonging to Silver Fox. These are NSIS installers featuring the branding of the Ministry of Corporate Affairs of India (responsible for regulating industrial companies and the services sector). These installers establish a connection to the attackers’ server at hxxps://vnc.kcii2[.]com, providing them with remote access to the victim’s device. Below is the list of files we identified:
The file MCA-Ministry.exe (MD5: 32407207e9e9a0948d167dca96c41d1a) was also hosted on one of the servers used by the ABCDoor stagers and was downloaded via TinyURL:
Starting in November 2025, the attackers began using a JavaScript loader to deliver ABCDoor. This was distributed via self-extracting (SFX) archives, which were further packaged inside ZIP archives:
November Statement.zip (MD5: b500e0a8c87dffe6f20c6e067b51afbf) (BillReceipt.exe)
December Statement.zip (MD5: 814032eec3bc31643f8faa4234d0e049) (statement.exe)
December Statement.zip (MD5: 90257aa1e7c9118055c09d4a978d4bee) (statement verify .exe)
Statement of Account.zip (MD5: f8371097121549feb21e3bcc2eeea522) (Review the file.exe)
The ZIP archives were likely distributed through phishing emails. They contained one of two SFX files: BillReceipt.exe (MD5: 2b92e125184469a0c3740abcaa10350c) or Review the file.exe (MD5: 043e457726f1bbb6046cb0c9869dbd7d), which differed only in their icons.
Icons of the SFX archives
When executed, the SFX archive ran the following script:
SFX archive script
This script launched run_direct.ps1, a PowerShell script contained within the archive.
The run_direct.ps1 script
The run_direct.ps1 script checked for the presence of NodeJS in the standard directory on the victim’s computer (%USERPROFILE%\.node\node.exe). If it was not found, the script downloaded the official NodeJS version 22.19.0, extracted it to that same folder, and deleted the archive. It then executed run.deobfuscated.obf.js – also located in the SFX archive – using the identified (or newly installed) NodeJS, passing two parameters to it: an encrypted configuration string and a XOR key for decryption:
Decrypted configuration for the JS loader
The JS code being executed is heavily obfuscated (likely using obfuscate.io). Upon execution, it writes the channel parameter value from the configuration to the registry at HKCU:\Software\CarEmu:InstallChannel as a REG_SZ type. It then downloads an archive from the link specified in the zipUrl parameter and saves it to %TEMP%\appclient_YYYYMMDDHHMMSS.zip (or /tmp on Linux). The script extracts this archive to the %USERPROFILE%\AppData\Local\appclient directory (%HOME%/AppData/Local/appclient on Linux) and launches it by running cmd /c start /min python/pythonw.exe -m appclient in background mode with a hidden window. After extraction, the script deletes the ZIP archive.
Additionally, the code calls a console logging function after nearly every action, describing the operations in Chinese:
Log fragments gathered from throughout the JS code
Victims
As previously mentioned, Silver Fox RustSL loaders are configured to operate in specific countries: Russia, India, Indonesia, South Africa, and Cambodia. The most recent versions of RustSL have also added Japan to this list. According to our telemetry, users in all of these countries – with the exception of Cambodia – have encountered RustSL. We observed the highest number of attacks in India, Russia, and Indonesia.
Distribution of RustSL loader attacks by country, as a percentage of the total number of detections (download)
The majority of loader samples we discovered were contained within archives with tax-related filenames. Consequently, we can attribute these attacks to a single campaign with a high degree of confidence. That Silver Fox has been sending emails on behalf of the tax authorities in Japan has also been reported by our industry peers.
Conclusion
In the campaign described in this post, attackers exploited user trust in official tax authority communications by disguising malicious files as documents on tax violations. This serves as another reminder of the critical need for vigilance and the thorough verification of all emails, even those purportedly from authoritative sources. We recommend that organizations improve employee security awareness through regular training and educational courses.
During these attacks, we observed the use of both established Silver Fox tools, such as ValleyRAT, and new additions – including a customized version of the RustSL loader and the previously undocumented ABCDoor backdoor. The attackers are also expanding their geographic focus: Russian organizations became a primary target in this campaign, and Japan was added to the supported country list in the malware’s configuration. Theoretically, the group could add other countries to this list in the future.
The Silver Fox group employs a multi-stage approach to payload delivery and utilizes a segmented infrastructure, using different addresses and domains for various stages of the attack. These techniques are designed to minimize the risk of detection and prevent the blocking of the entire attack chain. To identify such activity in a timely manner, organizations should adopt a comprehensive approach to securing their infrastructure.
Detection by Kaspersky solutions
Kaspersky security solutions successfully detect malicious activity associated with the attacks described in this post. Let’s look at several detection methods using Kaspersky Endpoint Detection and Response Expert.
The activity of the malware described in this article can be detected when the command interpreter, while executing commands from a suspicious process, initiates a covert request to external resources to download and install the Node.js interpreter. KEDR Expert detects this activity using the nodejs_dist_url_amsi rule.
Silver Fox activity can also be detected by monitoring requests to external services to determine the host’s network parameters. The attacker performs these actions to obtain the external IP address and analyze the environment. The KEDR Expert solution detects this activity using the access_to_ip_detection_services_from_nonbrowsers rule.
After running the command cmd /c start /min python/pythonw.exe -m appclient, the Silver Fox payload establishes persistence on the system by modifying the value of the UserInitMprLogonScript parameter in the HKCU\Environment registry key. This allows attackers to ensure that malicious scripts run when the user logs in. Such registry manipulations can be detected. The KEDR Expert solution does this using the persistence_via_environment rule.
Entrar
