Executive Summary

    On or about April 3rd, 2025 a critical deserialization vulnerability in Gladinet’s CentreStack and Triofox platforms was publicly released as CVE-2025-30406. The vulnerability arises from the use of hardcoded machineKey values in both their underlying Internet Information Services (IIS) configuration files.

    An attacker who can obtain a prior copy of CentreStack software can trivially extract hardcoded machineKey values from the default web.config files in the installer. Once obtained, an attacker could use the machineKey values to forge ViewState payloads that pass-through server-side integrity checks, potentially leading to unauthenticated remote code execution on the webserver.

    Exploitation of this vulnerability has been reported in the wild, leading to the vulnerability being added to CISA’s known exploited vulnerabilities (KEV) catalog. If exploited, this vulnerability could provide attackers the ability to deploy backdoor access to the compromised server leading up to subsequent attacks such as ransomware deployment.

    Patches have been released for both products from Gladinet. Beazley Security Labs strongly urges users of these products to install patches or follow recommended mitigation steps below to secure their installations.

    Affected Systems or Products

    Gladinet CentreStack and Gladinet Triofox software suites are susceptible to this vulnerability, due to static machineKey values being used in both software installers.

    Software

    Affected Versions

    Fixed Versions

    Gladinet CentreStack

    16.1.10296.56315 and earlier

    16.4.10315.56368 or later

    Gladinet Triofox

    All prior to 16.4.10317.56372

    16.4.10317.56372 or later

    Mitigations / Workarounds

    For users not able to install the patch immediately, the machineKey values can be manually rotated. This involves generating a new machineKey value through the underlying IIS manager and updating the web.config values accordingly. Instructions to perform the key rotation and other hardening steps have been provided by CentreStack support here.

    Gladinet has released a patched version of CentreStack (build 16.4.10315.56368) that automatically generates a unique machineKey value for each installation, also mitigating the vulnerability. The installer for this build can be downloaded from Gladinet’s support site.

    Given the active exploitation and severity of this vulnerability, affected organizations should verify the integrity of their data. See the Indicators of Compromise section for guidance on artifacts to look for when reviewing systems for exploitation attempts.

    Additional advisory and mitigation content has been provided directly from Gladinet at the links below:

    Patches

    CentreStack has provided an update that fixes this vulnerability by automatically generating a unique machineKey value for underlying IIS configurations and deployments.

    The Installation GUI Tool made available on CentreStack’s website will detect existing installations of the software and automatically upgrade it to the latest release.

    Indicators of Compromise

    At the time of this writing, it is believed the vulnerability has been actively exploited since March 2025.

    Per observations made by Huntress, successful exploitation could be monitored by watching for unexpected PowerShell invocations to sideload a DLL, triggering ViewState errors within Windows application event logs with event ID 1316:

    EventData:
Data:
- '4009'
- 'Viewstate verification failed. Reason: Viewstate was invalid.'
- 4/11/2025 4:59:43 PM
- 92d34ed2e5ee445db69fb1a426daec8c
- '2008'
- '1'
- '50204'
- /LM/W3SVC/1/ROOT/portal-1-REDACTED
- Full
- /portal
- C:\Program Files (x86)\Gladinet Cloud Enterprise\portal\
- [REDACTED]
- ''
- '8660'
- w3wp.exe
- IIS APPPOOL\portal
- https://<hostIP>:443/portal/loginpage.aspx
- /portal/loginpage.aspx
- REDACTED
- ''
- 'False'
- ''
- IIS APPPOOL\portal
- Invalid viewstate.
- REDACTED
- '53572'
- python-requests/2.32.3
- /[==REDACTEDBASE64PAYLOADREDACTEDBASE64PAYLOADREDACTEDBASE64PAYLOAD==]
- ''
- /portal/loginpage.aspx
Binary: null

    Other post-exploitation indicators include the presence of the following:

    Files

    • d3d11.dll | 48b006cb17e75ecdb707dc40dd654f449b94abe49f97a808b35cabca1c5fabbf

    • Centre.exe | 30981d4082b58704d12a376c3cbb12fecb8a36c2bce64666315e26aef21e75c2

    IPs

    • 165.227.7[.]206

    • 104.21.16[.]1

    • 104.21.48[.]1

    • 2.58.56[.]16

    • 45.84.107[.]76

    Technical Details

    The vulnerability stems from the application’s reliance on hardcoded decryption and validation key values within IIS’s running web.config files. These machineKey values are critical to maintain ViewState integrity in ASP.NET applications.

    In events where an attacker can obtain decryption and validation keys, they can create and submit forged ViewState payloads that bypass integrity checks, potentially leading to deserialization attacks within underlying ASP.NET routines on the server.

    An attacker would need to know the machineKey values and have ability to send a POST request to a vulnerable endpoint on the CentreStack software, such as the login portal often exposed to the internet and located at https://<host>/portal/loginpage.aspx.

    If successful, the attacks can lead up to unauthenticated remote code execution (RCE), allowing an attacker to execute arbitrary code on the server with the privileges of the underlying IIS application pool.

    Security researchers have detailed the flaw’s similarity to older ViewState exploitation techniques, with the difference being the exposure of static machineKey values across installations that simplify exploitation. Huntress has released a blog defining abuse of the ASPX ViewState mechanism as a “very standard and well-researched attack technique with ViewState deserialization.”

    How Beazley Security is responding

    Beazley Security is monitoring client perimeter devices through our Karma product to identify impacted devices and support organizations to remediate any issues found.

    We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.

    Sources