Active Exploitation of Gladinet CentreStack/Triofox Insecure Cryptography Vulnerability

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

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):

Filepath: The absolute path to the file on the server's disk.
Username: The Windows account to impersonate.
Password: The credentials for that account.
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 1: Excerpt from IIS logs highlight recent attack

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

Figure 3: 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.