How Hardcoded Cryptographic Keys in Gladinet CentreStack Led to Widespread RCE Attacks

How Hardcoded Cryptographic Keys in Gladinet CentreStack Led to Widespread RCE Attacks

Alex Cipher's Profile Pictire Alex Cipher 7 min read

A single cryptographic oversight in Gladinet CentreStack and Triofox products recently gave attackers the keys to the kingdom—literally. By embedding hardcoded cryptographic keys and initialization vectors directly into the product’s binary, Gladinet inadvertently created a universal backdoor for anyone savvy enough to reverse-engineer their code. Researchers from Huntress, using indicators of compromise provided by Gladinet, demonstrated how these static keys—derived from two 100-byte strings of Chinese and Japanese text—could be extracted and used to decrypt or forge authentication tokens, bypassing all access controls. This flaw enabled attackers to escalate from ticket forgery to full-blown remote code execution (RCE), impacting organizations across healthcare and technology sectors. The incident underscores how even a single misstep in cryptographic implementation can cascade into a major security crisis, as detailed in BleepingComputer’s coverage.

Inside the Exploit: How Hardcoded Keys Opened the Door to Remote Code Execution

Discovery of the Cryptographic Flaw in CentreStack

The vulnerability at the heart of the CentreStack incident was rooted in a flawed cryptographic implementation within Gladinet’s CentreStack and Triofox products. Unlike standard cryptographic practices, which mandate the use of unique and securely generated keys per installation, Gladinet’s developers embedded hardcoded cryptographic keys and initialization vectors (IVs) directly into the product’s binary, specifically within the GladCtrl64.dll file (BleepingComputer). This approach meant every deployment of CentreStack and Triofox worldwide used the exact same cryptographic secrets, dramatically lowering the barrier for attackers.

Researchers from Huntress, leveraging indicators of compromise (IoCs) provided by Gladinet, reverse-engineered the cryptographic routines and confirmed that the static keys could be extracted from memory or the binary itself. The keys were derived from two 100-byte strings of Chinese and Japanese text, which were identical across all installations. This uniformity allowed any actor with access to the keys to decrypt or forge authentication tokens, bypassing authentication and authorization controls.

The vulnerability was not assigned a CVE at the time of public disclosure, but Gladinet issued customer notifications and released patches on November 29, 2025, urging users to upgrade and rotate their cryptographic keys (BleepingComputer).

Technical Mechanics: Exploiting the Hardcoded Keys

The exploit chain began with the attacker targeting the filesvr.dn handler, which managed encrypted access tickets. These tickets, referred to as the ‘t’ parameter (Access Ticket), were designed to securely encapsulate file paths, usernames, passwords, and timestamps. However, due to the hardcoded AES keys, attackers could decrypt any ticket or, more critically, generate their own valid tickets (BleepingComputer).

Attackers extracted the static keys from the product’s DLL and used them to:

  • Decrypt legitimate access tickets, revealing sensitive data such as file paths and user credentials.
  • Forge new tickets with arbitrary parameters, including setting the timestamp to the year 9999, effectively creating tickets that never expired.
  • Impersonate any user and instruct the server to return any file on the disk, including sensitive configuration files.

The next step in the attack involved requesting the server’s web.config file. This file contained the machineKey, a critical secret used by the .NET framework for cryptographic operations, including ViewState validation. With access to the machineKey, attackers could exploit a ViewState deserialization vulnerability, enabling remote code execution (RCE) on the server (BleepingComputer).

Attack Progression: From Ticket Forgery to Full Compromise

Once the attackers had forged a valid access ticket using the hardcoded keys, they could retrieve the web.config file by instructing the server to serve it as if it were a legitimate user request. The presence of the machineKey in this file was pivotal. By obtaining it, attackers could craft malicious ViewState payloads that the server would accept as authentic, leading to arbitrary code execution.

The attack sequence unfolded as follows:

  1. Extraction of Hardcoded Keys: Attackers reverse-engineered the DLL to obtain the static AES key and IV.
  2. Forging of Access Tickets: Using the extracted keys, attackers generated access tickets with custom parameters, including non-expiring timestamps.
  3. Retrieval of Sensitive Files: The forged tickets were used to access the web.config file, bypassing access controls.
  4. ViewState Exploitation: With the machineKey in hand, attackers crafted malicious ViewState payloads, exploiting a deserialization flaw to achieve RCE.

This chain of events illustrates how a single cryptographic misstep—using hardcoded, universally shared keys—can cascade into a full system compromise, especially when combined with additional vulnerabilities such as insecure deserialization.

Indicators of Compromise and Detection Strategies

Gladinet and Huntress identified several indicators of compromise (IoCs) that organizations could use to detect exploitation attempts. The most reliable IoC was the presence of the string vghpI7EToZUDIZDdprSubL3mTZ2 in server logs, which is associated with the encrypted file path parameter used in the attack (BleepingComputer).

Other detection strategies included:

  • Log Analysis: Scanning for anomalous access patterns, particularly requests for sensitive files such as web.config originating from unexpected IP addresses.
  • Ticket Validation: Monitoring for access tickets with suspiciously long expiration times (e.g., year 9999), which are indicative of forged tickets.
  • Machine Key Rotation: Ensuring that the machineKey is regularly rotated and not left at default or static values, reducing the window of opportunity for attackers.

Huntress confirmed that at least nine organizations across healthcare and technology sectors had been targeted as of December 10, 2025, with exploitation activity traced to the IP address 147.124.216[.]205. The breadth of targeting and the speed of exploitation underscored the criticality of rapid detection and response.

Broader Security Implications and Lessons Learned

The CentreStack incident highlights several broader lessons for secure software development and operational security:

  • Never Hardcode Cryptographic Keys: Embedding static keys in software binaries creates a single point of failure. Once discovered, all deployments become vulnerable. Best practices dictate the use of unique, securely generated keys per installation, ideally managed by a hardware security module (HSM) or a dedicated key management service.
  • Defense in Depth: The attack succeeded not just because of the cryptographic flaw, but also due to the presence of additional vulnerabilities, such as insecure ViewState deserialization and improper access controls on sensitive configuration files. Layered defenses, including strict file access policies and secure deserialization routines, are essential.
  • Rapid Patch Deployment: Gladinet’s response—issuing patches and notifying customers—was critical in limiting the window of exposure. However, the incident demonstrates the importance of automated patch management and vulnerability scanning to ensure timely remediation.
  • Comprehensive Logging and Monitoring: Effective detection relied on the availability of detailed logs and the ability to correlate anomalous activity. Organizations should ensure that logging is enabled for all sensitive operations and that logs are regularly reviewed for signs of compromise.
  • User Awareness and Communication: Gladinet’s communication to customers, including IoCs and mitigation steps, was essential in enabling defenders to respond. Transparent and timely disclosure of vulnerabilities is a key component of coordinated incident response.

By understanding the technical mechanics of how hardcoded keys facilitated remote code execution, organizations can better appreciate the importance of robust cryptographic practices and the need for holistic security architectures that anticipate and mitigate such risks. For further technical details and ongoing updates, refer to the BleepingComputer coverage.

Final Thoughts

The Gladinet CentreStack incident is a textbook example of how hardcoded cryptographic keys can unravel an entire security architecture. Attackers didn’t just exploit a single bug—they chained together cryptographic flaws, insecure deserialization, and weak access controls to achieve remote code execution. This breach highlights the importance of never embedding static secrets in software, enforcing defense in depth, and maintaining robust detection and response capabilities. For organizations, the lesson is clear: cryptographic hygiene isn’t optional, and rapid, transparent communication—like Gladinet’s customer notifications and patch releases—can make all the difference in limiting damage. For a deeper dive into the technical details and ongoing updates, check out BleepingComputer’s report.

References

Related Articles