Gladinet Hard-Coded Keys 2025: How Static AES Keys Let Attackers Forge Access Tickets and Steal Machine Keys

In December 2025, Huntress reported that attackers were exploiting hard-coded cryptographic keys in Gladinet CentreStack and Triofox, file sharing and remote access servers widely used by managed service providers. The flaw, later assigned CVE-2025-14611, meant every installation encrypted its "access tickets" with the same AES key and IV. Attackers forged a ticket that never expires, used it to download the server's web.config file, took the ASP.NET machine keys inside it and then ran code on the server through ViewState deserialization. As of 10 December 2025, Huntress had seen nine organisations affected, in healthcare and technology, and CISA added the flaw to its Known Exploited Vulnerabilities catalogue on 15 December. It was the third time in 2025 that attackers reached the same machine keys on Gladinet servers, after CVE-2025-30406 in the spring and CVE-2025-11371 in the autumn. At its core this is a story about secrets that were shared by every customer and never rotated.

At a glance

What happened

CentreStack and Triofox are Gladinet products that give organisations cloud-style file sharing, backup and remote access on their own Windows servers. Help Net Security describes CentreStack as a platform that lets managed service providers deliver these services to their customers. The servers run on Microsoft IIS and ASP.NET, and many are exposed to the internet by design.

The first hard-coded key problem surfaced in the spring. CVE-2025-30406, published on 3 April 2025, describes a "deserialization vulnerability due to the CentreStack portal's hardcoded machineKey use, as exploited in the wild in March 2025." ASP.NET uses the machineKey to sign and encrypt ViewState, the data a page sends back to the server. Gladinet explained the risk plainly: "If an attacker obtains or predicts the machineKey, they can forge ViewState payloads that pass integrity checks." Because the key was the same default on every install, anyone who knew it could get code running on any exposed server. Gladinet fixed it in CentreStack 16.4.10315.56368 and Triofox 16.4.10317.56372, and CISA added the flaw to the KEV catalogue on 8 April 2025. Huntress saw exploitation from 11 April and, by 14 April, counted seven compromised organisations, with attackers installing the MeshCentral remote access tool and moving laterally.

The fix generated unique keys, but the keys still sat in a file on the server. In October 2025, Huntress reported CVE-2025-11371, an unauthenticated local file inclusion flaw in the /storage/t.dn handler, first exploited on 26 September 2025. Attackers used it to download web.config, read the machine key and then reuse the CVE-2025-30406 ViewState technique. Three Huntress customers were affected at the time, and Gladinet released a fix in version 16.10.10408.56683 on 14 October.

The December activity reached the same file by a different route. Huntress researcher Bryan Masters wrote on 10 December 2025 that "The AES implementation of Gladinet's CentreStack and Triofox products contains hardcoded cryptographic keys." The GenerateSecKey function in GladCtrl64.dll produces a 32-byte key and a 16-byte IV from two static 100-byte text strings, one in Chinese and one in Japanese, according to Huntress. The function appears to take the current time as input but returns the same strings every time. In Huntress's words, "Because these keys never change, we could extract them from memory once and use them to decrypt any ticket generated by the server."

Those keys protect the "access tickets" that the /storage/filesvr.dn handler accepts. A decrypted ticket contains a file path, a Windows username and password, and a timestamp. The attacker's tickets asked for the web.config file, left the username and password blank and set the timestamp to the year 9999, which creates "a ticket that never expires," Huntress says. With blank credentials, the impersonation logic appears to fail and the request is served anyway. The encrypted string vghpI7EToZUDIZDdprSubL3mTZ2, which appears in IIS logs, corresponds to the request for the web.config path.

Once the attacker had the machine keys, Huntress says, "they performed a viewstate deserialization attack and then attempted to retrieve the output of the execution which failed." In two further incidents on 15 December, Huntress saw the IIS worker process, w3wp.exe, run PowerShell that downloaded a file called conqueror.exe, followed by host enumeration.

Timeline

How it happened: the identity attack path

1. A secret shipped in the product. The AES key and IV that protect access tickets were derived from fixed strings in GladCtrl64.dll, so every CentreStack and Triofox server shared them. Anyone who extracted them once held the key for all customers.
2. A forged bearer credential. Access tickets work like bearer tokens: whoever presents a valid one gets the file it names. The attacker encrypted their own ticket, pointing at web.config, with blank credentials and a year 9999 expiry.
3. No login required. The /storage/filesvr.dn handler accepted the forged ticket without authentication and returned the configuration file.
4. A second, more powerful key. web.config holds the ASP.NET machine keys, the secrets the server uses to trust ViewState. Stealing them turns a file read into the ability to sign data the server will deserialise.
5. Code runs as the application pool identity. A forged ViewState payload ran commands through the IIS worker process, which in later incidents launched PowerShell to download conqueror.exe.
6. Keys outlive the patch. Upgrading removes the static AES key, but machine keys already read from web.config remain valid until they are rotated, which is why Huntress and FINRA both tell customers to rotate them.

Impact

Huntress reported nine affected organisations as of 10 December 2025, across healthcare and technology, and two more incidents on 15 December. It has not published a total for the campaign, and victims have not been named. In the first incidents the attackers achieved deserialization but failed to retrieve the output; in the later ones they downloaded and ran a payload.

The wider exposure comes from the product's role. CentreStack servers often hold customer files for managed service providers, so a compromised server can reach many downstream organisations. In April 2025 Huntress counted several hundred internet-exposed servers using Shodan. On 18 December 2025 Huntress noted reports from other intelligence firms that the cl0p ransomware group was targeting internet-facing CentreStack servers, and in January 2026 FINRA told member firms that Clop had been confirmed exploiting the three Gladinet flaws. We have not found a public list of organisations harmed by that activity.

What this means for NHI governance

Gladinet's 2025 was a year of the same lesson, three times. Every exploited path ended with the ASP.NET machine keys, and two of the three flaws were hard-coded keys shipped by the vendor. Cryptographic keys are non-human credentials. They authenticate data, not people, and a server that holds the right key will trust whatever that key has signed. When the key is identical on every installation, the product has one password for all of its customers.

The December flaw also shows how one secret leads to another. A weak key protecting access tickets exposed a configuration file, and that file held a stronger key protecting the application itself. This is the same chain seen in attacks on publicly disclosed ASP.NET machine keys and in ToolShell against SharePoint, where attackers stole machine keys so they could return after patching. Secrets in configuration files are only as safe as every path that can read those files.

Finally, patching and rotation are separate tasks. A software update can remove a vulnerable code path, but it cannot un-steal a key. Organisations need to know which keys each server holds, who or what can read them, and how to replace them quickly.

Recommendations

• Upgrade CentreStack and Triofox to 16.12.10420.56791 or later, and confirm earlier fixes for CVE-2025-30406 and CVE-2025-11371 are in place.
• Rotate the ASP.NET machine keys on every server that was exposed before patching, following Gladinet's hardening guidance. Treat any key that could have been read as compromised. Our Challenges of Rotating NHIs explains why this needs planning.
• Hunt for past exploitation. Search IIS logs for vghpI7EToZUDIZDdprSubL3mTZ2 and requests to /storage/filesvr.dn and /storage/t.dn, block the published attacker IP addresses and look for w3wp.exe spawning PowerShell.
• Keep secrets out of configuration files where possible. Store keys in a protected store with access logging, and inventory every key embedded in third-party software, as set out in the Secrets Management Guide.
• Ask vendors how keys are generated. Require unique per-installation keys, documented rotation and a way to rotate without downtime. The Machine Identity and PKI Certificate Lifecycle Guide covers key ownership and lifecycle.
• Limit the application pool identity. Run IIS application pools with least privilege, as FINRA recommends, so that code execution does not become domain-wide access.
• Reduce internet exposure. Put file sharing servers behind a VPN or access proxy where the business allows it.

Frequently asked questions

What is the Gladinet hard-coded key vulnerability?

CVE-2025-14611 is a flaw in Gladinet CentreStack and Triofox before 16.12.10420.56791 where the AES key and IV used to encrypt access tickets were hard-coded and the same on every server. Attackers forged tickets to read web.config without logging in, then used the machine keys inside it for remote code execution.

How is CVE-2025-14611 different from CVE-2025-30406?

CVE-2025-30406, exploited from March 2025, was a hard-coded ASP.NET machineKey that allowed ViewState deserialization directly. CVE-2025-14611, exploited in December 2025, was a hard-coded AES key for access tickets. It let attackers steal the server's machine keys, which they then used with the CVE-2025-30406 technique.

Is patching enough to fix the Gladinet vulnerability?

No. Upgrading closes the flaw, but machine keys taken from web.config before the upgrade still work. Huntress and FINRA advise rotating the machine keys and checking logs for signs of earlier exploitation.

Related NHI Mgmt Group resources

ASP.NET machine keys and RCE attacks · ToolShell SharePoint exploitation 2025 · Hard-coded credentials in SAP SQL Anywhere Monitor · Oracle E-Business Suite Cl0p zero-day 2025 · The secret sprawl challenge

How NHI Mgmt Group can help

Hard-coded keys, machine keys and application pool identities are non-human identities that rarely appear in any inventory until an attacker uses them. Our NHI Foundation Level Training Course shows teams how to find, own and rotate these secrets across their own and third-party software.

References

• Huntress: Active Exploitation, Gladinet CentreStack/Triofox Insecure Cryptography Vulnerability (10 December 2025, updated 18 December 2025)
• NIST NVD: CVE-2025-14611 (12 December 2025)
• Huntress: CVE-2025-30406, Critical Gladinet CentreStack and Triofox Vulnerability Exploited in the Wild (14 April 2025)
• Help Net Security: RCE flaw in MSP-friendly file sharing platform exploited by attackers (CVE-2025-30406) (9 April 2025)
• Tenable: CVE-2025-30406 (3 April 2025, updated 5 November 2025)
• Huntress: Active Exploitation of Gladinet CentreStack and Triofox Local File Inclusion Flaw (9 October 2025, updated 15 October 2025)
• The Hacker News: Active Attacks Exploit Gladinet's Hard-Coded Keys for Unauthorized Access and Code Execution (11 December 2025)
• FINRA: Cybersecurity Alert, Threat Actors Exploiting Gladinet CentreStack and TrioFox Vulnerabilities (29 January 2026)