Affected Platforms: Windows Endpoints
Impact Parties: QuickFox Users
Impact: Supply chain attack resulting in the installation of an implant for persistent access.
Severity Level: Medium

FortiGuard Labs is tracking a campaign associated with a long-standing supply chain attack on the QuickFox application. QuickFox is a VPN proxy and game accelerator typically employed by Chinese users to speed up access to Chinese-based resources, often to improve video game user experience.

Active since at least August 2025, the supply chain attack involves a trojanized version of the QuickFox application. The attack is delivered via a modified Electron renderer HTML file used to download and execute a JavaScript-based loader. Upon execution, the JavaScript loader fingerprints the victim endpoint to determine if it’s a valid target before downloading and installing an FDMTP implant. Analysis of infrastructure related to this campaign indicates active development, and infrastructure continues to be active at the time of publishing.

Fortinet has contacted QuickFox as part of our responsible disclosure process. QuickFox has removed the described malicious components from their Windows installer from v3.59.6, and the malicious components that were later transferred to MacOS components do not result in the progression of the infection.

Infection Process

The infection chain associated with this supply chain attack is outlined in Figure 1 below. Note that two different ‘generations’ of the .NET loader employed at different stages of the intrusion were observed, with the deviations of each noted in Figure 1.

Infection Chain Technical Analysis

The installer executable was trojanized by adding two lines of JavaScript to a single HTML file. This HTML file is executed by the Electron renderer, which is part of the main QuickFox application during initialization. The modified HTML file can be found nested within the archive embedded within the executable file at path ‘<executable path>\<version>.7z\resources\app.asar\candy\core\service\index.html’. The two lines of JavaScript added to the file are shown in the screenshot in Figure 3, below, and a comparison of the original and the modified version is shown in Figure 2.

Table 1: Comparison of domain details for the legitimate QuickFox infrastructure and the malicious masquerading domain.

Table 2: Details of the affected version of the QuickFox installer. Note. QuickFox does not maintain a publicly accessible version release timeline or historic installers for their Windows applications, so these represent the versions publicly available at the time of this reporting and should not be considered an exhaustive list.

Analysis of the files served by the two URLs identified that ‘firebase-analytics-compat.js’ contains legitimate Google Firebase code. The ‘firebase-app-compat.js’ file is a heavily obfuscated JavaScript file masquerading as the legitimate Firebase SDK code. Obfuscation of JavaScript and HTML components within an Electron application like QuickFox is not anomalous, so the presence of obfuscated JavaScript is not itself anomalous. However, in this case, the downloaded JavaScript leverages a custom algorithm outlined below:

1. Wrapper function ‘r1muVuL’ designed to bypass static analysis
2. Ten parallel layers of base91 decryption with a distinct 91 char alphabet
3. Layers of encoded strings resolved through a cached string table
4. Flow obfuscation with nested switch statements

A screenshot of some of the obfuscation is shown below in Figure 4.

Figure 4: Obfuscated JavaScript within the fake ‘firebase-app-compat.js’ file served by masquerading QuickFox URL.

Table 3: Process names and likely associated application and application function.

The next stage of the JavaScript involves downloading the zip file ‘update.zip’ from the previous C2 via a web request to ‘hxxp://cdns3[.]51quickfox[.]cn/2025090411/update.zip’ and saving it to ‘%TEMP%\quickfox\update.zip’. FortiGuard Labs has identified at least two generations of the next stage of the intrusion, both of which execute an FDMTP payload:

1. Generation 1 – Available from at least September 2025 – involves an ‘update.zip’ file that contains two components:
   • ‘csmonitor.exe’, a legitimate Microsoft binary ‘Windows Azure Compute and Storage Emulator’ used to sideload ‘Microsoft.ServiceHosting.Tools.dll’
   • ‘Microsoft.ServiceHosting.Tools.dll’, a trojanized version of Microsoft Azure SDK that contains an FDMTP payload embedded within the file itself.
2. Generation 2 – Available from May 2026 – involves an ‘update.zip’ file that contains three components:
   • ‘csmonitor.exe’, a legitimate Microsoft binary ‘Windows Azure Compute and Storage Emulator’ used to sideload ‘Microsoft.ServiceHosting.Tools.dll’
   • ‘Microsoft.ServiceHosting.Tools.dll’, a custom loader that decrypts and executes the FDMTP payload contained within ‘update.bin’
   • ‘update.bin’, an AES128-ECB encrypted payload file containing the FDMTP payload.

In both generations, the prior JavaScript extracts the contents of the downloaded ‘update.zip’ to the ‘%APPDATA%\Local\Temp\quickfox\updated\’ directory. Following extraction, the script creates a 1-byte file ‘data.dat’ in the updated directory. This file serves as a file-based mutex, and the script will exit if the file already exists to prevent re-infection. The script then executes ‘csmonitor.exe’, which sideloads the malicious ‘Microsoft.ServiceHosting.Tools.dll’ DLL.

Unpacking the FDMTP Implant

Initial loader execution

The behavior of this ‘Microsoft.ServiceHosting.Tools.dll’ loader changes between generations, indicating ongoing development to improve the campaign’s survivability.

Analysis of the generation 1 version of the ‘Microsoft.ServiceHosting.Tools.dll’ file (SHA256:2B6CDAFDFE427A3DE1A94A8A2CA1F09FC4C8F90E4F59089FD9B35B73185ED01C) identifies it as a .NET loader containing an embedded .NET module payload ‘Client.dll’ stored as a byte array. When executed through the csmonitor.exe application, the .NET loader instantiates an instance of the ‘DevStore’ class, which loads and executes the embedded ‘Client.dll’ as a new thread within the context of the csmonitor.exe process. A code snippet of key components of the DevStore class from the ‘Microsoft.ServiceHosting.Tools.dll’ file is shown below, in Figure 7.

The generation 2 sample of ‘Microsoft.ServiceHosting.Tools.dll’ (SHA256:795594AD5E6F2868CC4D8ED12DABF4F3999A1477C6B250527C5EDE9A98528FB9) functions differently from the generation 1 sample. The generation 2 sample is obfuscated using the JieJie .NET Protector tool¹ and functions as a loader to decrypt and load the contents of ‘update.bin’. The ‘update.bin’ file is encrypted using AES-128-ECB encryption with a common, hardcoded key ‘POt_L[Bsh0=+@0a.’ Note that this is the same decryption key observed in the previous FDMTP campaign reported by Darktrace. The decrypted contents of this file are a copy of the final FDMTP payload ‘Client.dll’ and functionally match those loaded in generation 1.

Operation of the FDMTP implant

The Client.dll payload contains 15 compressed modules within its resources section, as shown in Figure 8 below.

On execution, it registers a ‘ResolveEventHandler’ object that points to the ‘Costura.AssemblyLoader.ResolveAssembly()’ method as shown above in Figure 8. This method is called when the .NET Framework can’t find a module that the client module is trying to load (i.e., when an ‘Assembly Resolve’ event is triggered). When called, this method decompresses and loads the corresponding module from the module resource section. This functionality obfuscates code within the compressed modules, reducing the effectiveness of static analysis methods.

Each of these 15 modules contains specific functionality used during the operation of the FDMTP payload, but the main module that orchestrates the payload execution is ‘Client.FDMTPFrame.dll’.

FDMTP implant operation

Following the registration of this handler, the FDMTP implant attempts to obtain a C2 connection via the ‘Client.Program.InitConnect() method, as shown in Figure 9 below.

This method defines two RPC servers (CommonService and PluginService) and three plugins (FileTransferPlugin, SystemEventsPlugin, and ActiveWindowPlugin) for retrieving information from a hardcoded staging C2 via an API request ‘GET /GetCluster?protocol=DotNet-TcpFDMTP&tag=<campaign>’ to a staging domain, which in the analyzed sample here was ‘www[.]icloud-cdn[.]net’. This request registers the affected endpoint with the C2 using a country code (<campaign>) and retrieves an array of nodes (IP addresses and ports) used for subsequent DTMP C2 communications.

The staging domain used to provide the IP and ports of FDMTP clusters is hardcoded within each sample. The FortiGuard Labs team identified several domains being used as staging domains associated with the QuickFox supply chain compromise, with at least three still active when QuickFox was notified of the compromise. The infrastructure related to this campaign continues to evolve the contents of ‘update.zip’, changing along with subsequent malware file names. Internal names within tooling appear consistent. The API function names also appear to be changing over time, with ‘GetSlaver’, ‘GetGateways’, ‘GetEndpoints’ ‘GetServers’, ‘GetHosts’, and ‘GetNodes’ all observed performing similar functions. These C2 staging domains, along with some of their associated URLs, are shown in Table 4.

Table 4: Domains and associated URLs used as staging domains for the FDMTP implants associated with this QuickFox campaign infrastructure.

Table 5: FDMTP cluster nodes associated with identified staging C2 domains.

It contains:

• The window title of the topmost active program
• Installed AV software
• Client Type
• .NET Framework runtime version
• Network information, including the IP address, gateway IP address, and MAC address
• Windows OS information and the installation date and time for the current endpoint
• Current username.
• Implant information including file full path, version, process ID, and hosting process name

The malware compresses the data list above and sends it to the C2 server over a ‘00 15’ flag packet, as illustrated at the bottom of Figure 11. The C2 server then sends an ‘EnumProcessByJson’ RPC request to collect all running process information from the compromised endpoint, including the PIDs and process names. This is likely to perform additional server-side filtering of compromised endpoints and to support adversary targeting.

The implant continued to periodically connect to FDMTP infrastructure. The implant appears to operate largely through plugins (DLLs) that are pushed from the FDMTP server to the implant during check-ins. When the adversary needs to execute a remote plugin on the compromised device, the C2 server sends ‘IsRegistryPlugin’, ‘RegistryPlugin’ and ‘RunPlugin’ RCP requests within packets marked with the ‘00 14’ flag.

IsRegistryPlugin

The C2 server sends a plugin’s hash code to the operating implant as the parameter to the IsRegistryPlugin() method, which invokes the corresponding ‘Client.FDMTPFrame.Connection.PluginService.IsRegistryPlugin()’ with the DLL file hash code as its parameter. The operating implant then checks whether the corresponding plugin has already been stored in the compromised device’s registry.

It then reports the result (‘00’ indicates not found; ‘01’ indicates found) back to the C2 server within a ‘00 15’ flag packet, as shown in Figure 13.

RegistryPlugin

If the C2 server receives a ‘00’ response to the ‘IsRegistryPlugin’ request, it sends a ‘RegistryPlugin’ RPC request to the FDMTP server. The corresponding RPC request response contains a compressed executable file embedded within the packet, as shown below in Figure 14.

On receipt of this response, the ‘Client.FDMTPFrame.Connection.PluginService.RunPlugin()’ method is invoked to save the compressed executable file into the system registry under the specific sub-key ‘HKCU\SOFTWARE\Microsoft\IME\{Common.HostInfo.HWID}’.

If the server receives a ‘01’ in response to the ‘IsRegistryPlugin’ request, or once the response to the ‘RegistryPlugin’ request has been saved to the registry, the C2 server proceeds directly with a ‘RunPlugin’ RPC request.

RunPlugin

When the implant receives a ‘RunPlugin’ RPC request, the ‘Client.FDMTPFrame.Connection.PluginService.RunPlugin()’ method is invoked. The corresponding packet contains a hash of the target plugin’s compressed file code corresponding to the target plugin that is passed to the ‘Client.FDMTPFrame.Connection.PluginService.RunPlugin()’ method. Within the method, the implant first retrieves the plugin file from the system registry using its hash, then decompresses and loads it. Finally, the plugin’s ‘Plugin.Room.run()’ method is invoked. In the sample analyzed during testing, the loaded plugin file is named ‘Assist.dll’. When its ‘Plugin.Room.run()’ method is invoked, it calls the ‘Handle()’ method to process the decompressed parameter stored in the ‘pluginMethod’ variable, as shown in Figure 15.

In the case of the plugin sample analyzed during our investigation, the ‘Assist.dll’ plugin downloads two files and saves them to the ‘%LocalAppData%\Microsoft\WindowsApps’ folder. Once downloaded, the C2 server can issue a ‘StartProcess’ RPC request to execute the downloaded files. It should be noted that these URLs used to retrieve subsequent executable components are embedded within the server-provided plugin and are configurable between campaigns, allowing some additional survivability for running implants.

FortiGuard Labs did not observe significant post-exploitation behavior from the FDMTP implant on affected victims following initial installation beyond basic enumeration performed through the previously described plugin functionality. The FortiGuard Labs team did not observe any additional plugins beyond those reported by Darktrace in previous FDMTP reporting.

Vendor Engagement and Response

FortiGuard Incident Response has engaged with the affected vendor, per our responsible disclosure program. QuickFox responded quickly to identify the trojanized components of their software, has since removed the reported components, and begun an internal investigation into the associated supply chain attack. Currently identified affected versions apply to the Windows applications only at this stage, and versions >v3.0.35 (the earliest known non-compromised version) and <v3.55.6, the most recent version in which QuickFox has removed malicious components.

Attribution

FortiGuard Labs does not confidently attribute this campaign to a particular actor. However, there is significant technical crossover with open-source reporting that is externally attributed to Twill Typhoon. Details of this technical crossover are outlined below.

Twill Typhoon

Reporting by Darktrace highlights the recent use of an FDMTP implant matching the final payload deployed in the campaign related to the QuickFox supply chain compromise. Matches were based on side-loading techniques (T1574.001 – Hijack Execution Flow: DLL), code structure, and key loader components. In this previously reported campaign, the adversary leveraged the legitimate ‘biz_render.exe’ binary, a legitimate component of Sogou Pinyin IME, as the sideloading target, with their loader replacing ‘browser_host.dll’, whereas in our case, the adversary leveraged the ‘csmonitor.exe’ application as a target for sideloading.

In addition to this technique implementation crossover, there is shared infrastructure between the two campaigns, as C2 ‘cluster’ IPs provided by staging domains observed in this previously reported campaign were also registered as C2 ‘cluster’ IPs linked to staging domains observed in the campaign we highlighted above. Linkages here are entirely related to technical factors, indicating with high confidence that the same infrastructure and tooling were employed across the two reported campaigns.

An additional consideration regarding attribution is the inclusion of partial victim filtering at the client level. The JavaScript executed through the trojanized HTML code responsible for the initial C2 connection includes execution guardrails that kill the infection if an executable named ‘steam.exe’ is running. FortiGuard Labs assesses that this is likely intended to avoid deployment on endpoints used for personal use, increasing the likelihood of the second-stage payload only being deployed in corporate environments. Additionally, the initial JavaScript installs the payload only if one of a list of processes (see Table 3) is present. The list includes several processes associated with administrator tooling, translator applications focused on Chinese-native translators, developer tools, and crypto-related applications. This collection of applications does not provide definitive validation of targeting, as a broad range of motivations can be supported by targeting the processes in the targeted list. However, the list does contain a large percentage of Chinese translation applications

QuickFox’s user base is primarily Chinese international students and expats who use the application to more efficiently interact with Chinese-based services. Given this user base, a hypothesis around targeting is that primary targeting was generically for Chinese citizens operating outside China. A competing hypothesis is that this campaign aimed to target professionals required to interact with Chinese native speakers, potentially for trade or diplomatic engagement purposes. Neither hypothesis can be confirmed without understanding the victim context for second-stage intrusions, which would identify true targets of the campaign.

Conclusion

This campaign highlights the need for organizations to adequately prepare against supply chain attacks, especially those targeting specific user bases that may not sit within an organization’s typical threat profile. Additionally, the TTP and indicator crossover related to this campaign and the campaign reported by Darktrace earlier in 2026 highlight how the application of timely, high-confidence open-source threat intelligence can, in some cases, provide detection opportunities across adversary campaigns.

The lack of confidence in attribution beyond technical clustering is largely due to limited visibility into second-stage post-exploitation activity. Despite identifying several victims of this initial infection, this initial part of the campaign (up to and including FDMTP implant installation) appears opportunistic, with the information gathered centralized, likely for second-stage target validation.

FortiGuard Labs is continuing to investigate infrastructure associated with this larger campaign to fill some of these intelligence gaps and identify other potentially related supply chain attacks. If you believe this or any other cybersecurity threat has impacted your organization, please contact our Global FortiGuard Incident Response Team²

Fortinet Protections

FortiGuard Antivirus signatures associated with indicators related to this investigation are provided in the IOC section below. FortiGate, FortiMail, FortiClient, and FortiEDR support ingestion of signatures from the FortiGuard AntiVirus service. As a result, customers who have these products with up-to-date protections are protected.

The URLs are rated as “Malicious Websites” and “Malicious Activities Found” by the FortiGuard Web Filtering service.

FortiGuard IP Reputation and Anti-Botnet Security Service proactively block these intrusions by aggregating malicious source IP data from the Fortinet distributed network of threat sensors, CERTs, MITRE, cooperative competitors, and other global sources that collaborate to provide up-to-date threat intelligence about hostile sources.

MITRE ATT&CK Mapping

TA0001: Initial Access 

TA0002: Execution 

TA0003: Persistence 

TA0005: Stealth

TA0007: Discovery 

TA0011: Command & Control  

Indicators of Compromise

The following lists of indicators are associated with the campaign outline in this article.

Network Indicators

Host Based Indicators

¹ https://github.com/dcsoft-yyf/JIEJIE.NET
² https://www.fortinet.com/corporate/about-us/contact-us/experienced-a-breach