AI Detection Lessons From the Gladinet KEV Exploit

Hard-coded cryptographic keys are the kind of bug that makes defenders groan—because once an attacker knows the secret, it isn’t a “vulnerability” anymore. It’s a reusable capability.

That’s why the Gladinet CentreStack and TrioFox incident matters. This flaw (now tracked as CVE-2025-14611, CVSS 7.1) has been exploited in the wild, landed in CISA’s Known Exploited Vulnerabilities (KEV) catalog, and comes with a clear federal deadline: January 5, 2026. For security teams heading into year-end change freezes and holiday staffing gaps, that timing is brutal.

This post is part of our AI in Cybersecurity series, and I’ll take a stance: patching is necessary, but it’s not a strategy by itself. The Gladinet case is a clean example of where AI-based anomaly detection and behavioral monitoring can catch exploitation while it’s happening—even if your patch cycle is imperfect.

What happened with Gladinet (and why it’s so exploitable)

Answer first: The Gladinet issue is exploitable because the application relies on hard-coded cryptographic keys, enabling attackers to forge or decrypt access tickets and pull sensitive files like web.config, which can enable remote code execution (RCE).

CentreStack and TrioFox use access “tickets” that carry authorization data. A function called GenerateSecKey() inside GladCtrl64.dll returns the same 100-byte strings across installations. Those strings are used to derive encryption keys. Translation: the keys never change, so attackers can create “valid” encrypted tokens without ever authenticating.

From there, the path gets ugly fast:

• Attackers craft requests to a file server endpoint (observed path: /storage/filesvr.dn).
• They request sensitive files (notably web.config).
• If they obtain the machine key, they can attempt ViewState deserialization, a classic route to code execution on IIS/ASP.NET applications.

Huntress observed exploitation affecting nine organizations across sectors including healthcare and technology, with activity tied to a specific IP and (importantly) chaining across multiple Gladinet vulnerabilities.

If you’re thinking “this sounds like a playbook,” you’re right. And playbooks are exactly what AI-assisted detection is good at recognizing.

The attacker workflow: why traditional controls miss it

Answer first: Traditional security fails here because exploitation looks like “normal app traffic” until you correlate token structure, endpoint behavior, file targets, and reuse patterns.

A lot of environments still lean on three layers:

1. Patch management (essential, but not instantaneous)
2. Signature-based rules (fragile when attackers mutate payloads)
3. Perimeter controls (often blind to app-layer abuse)

The Gladinet exploitation chain is a perfect storm for those defenses.

A “never-expiring” ticket is a defender’s nightmare

Huntress noted a specific tactic: the timestamp inside the access ticket is set to 9999, creating a ticket that effectively never expires. That means:

• One successful crafted URL can be reused.
• The attacker can come back later.
• Your logs show repeat access that can look like “someone bookmarking a resource.”

If your controls only alert on “failed logins” or “brute force,” you may not see anything.

Blank credentials that fall back to service identity

Another observed detail: attackers leave Username and Password fields blank, pushing the application to fall back to the IIS Application Pool Identity.

That’s not just clever—it’s operationally convenient. It can:

• Reduce noisy authentication events
• Blend into service-level access patterns
• Complicate forensics (“Which user was it?” becomes “Which worker process?”)

Chaining vulnerabilities is the new normal

This is the third Gladinet issue exploited in the wild this year, alongside CVE-2025-30406 and CVE-2025-11371. Huntress reported evidence of an orchestrated chain where attackers use one flaw to expand access and another for output or follow-on actions.

Chaining matters because many organizations triage vulnerabilities in isolation. Attackers don’t.

Where AI-based anomaly detection fits (and what it should watch)

Answer first: AI helps most when it monitors behavioral deviations—unusual file access, token reuse, endpoint anomalies, and sequence-of-actions patterns—rather than relying on single indicators.

When people say “use AI in cybersecurity,” it can sound vague. Here’s a concrete detection model for this incident that doesn’t depend on knowing every exploit string.

1) Model “normal” access to sensitive configuration files

A healthy production system has a very narrow set of legitimate reads for files like:

• web.config
• machine key-related configs
• application secrets stores

AI-powered monitoring can baseline:

• Which processes access those files
• From which hosts and network segments
• At what times
• With what frequency

Then alert on outliers such as:

• First-time access from an external IP path
• Repeated retrieval attempts within minutes
• A user agent / request pattern inconsistent with admin tooling

This is practical because even if the exploit changes, the goal often doesn’t.

2) Detect “impossible” token properties

Tickets that never expire (timestamp set to 9999) are not something legitimate clients typically generate.

A machine learning classifier or even a simpler anomaly model can flag:

• Unusual timestamp ranges
• Replayed tokens across long windows
• Token reuse across multiple source IPs
• Access tickets that result in high-value file retrieval

This is also where AI shines over static rules: you can detect families of suspicious tokens rather than a single known string.

3) Sequence detection: the attack has a rhythm

Gladinet exploitation isn’t random. It tends to follow a recognizable sequence:

1. Hit the file server endpoint (filesvr.dn style request)
2. Retrieve web.config
3. Extract machine key
4. Attempt ViewState deserialization
5. Try to pull execution output / stage follow-on activity

AI systems that build event graphs (request → file access → process execution → outbound traffic) can flag the chain earlier—often at step 1 or 2—before you’re investigating step 4.

If you’ve ever done incident response, you know how valuable that is.

4) Credential monitoring beyond “logins failed”

This incident is also a reminder that credential monitoring isn’t only about usernames and passwords.

The access ticket itself carries authorization data. If your monitoring is narrow (only identity provider events), you miss app-layer “credentials” embedded in tokens.

A modern approach is to monitor:

• Token issuance patterns
• Token validation failures
• Token reuse
• Access attempts where identity fields are blank but authorization succeeds

That’s not hype. It’s how you catch attacks that never touch your SSO logs.

What to do this week: a practical response plan

Answer first: Patch to the fixed Gladinet release, hunt for known request patterns, and rotate machine keys if compromise is suspected—then add behavioral monitoring so you’re not relying on patch speed alone.

Here’s a focused checklist for security and IT teams.

Step 1: Patch the affected products immediately

Gladinet released a fixed version: 16.12.10420.56791 (released December 8, 2025). If CentreStack or TrioFox is internet-exposed, treat this as urgent.

Given KEV status and active exploitation, “next maintenance window” isn’t a defensible plan.

Step 2: Threat hunt for high-signal indicators

Huntress advised scanning logs for the presence of a specific string tied to the encrypted web.config path:

• vghpI7EToZUDIZDdprSubL3mTZ2

Also look for:

• Requests to file server endpoints resembling filesvr.dn
• Repeated downloads of configuration files
• Requests that succeed without normal authentication context

Step 3: Rotate the machine key if there’s any sign of compromise

If attackers retrieved web.config, assume the machine key may be exposed. Rotating it breaks some persistence and can invalidate certain exploitation paths.

Operationally, key rotation can have app impact (ViewState validation, session state behavior). Plan it as a controlled change, but don’t let that become an excuse to delay if you have indicators of compromise.

Step 4: Add detections that survive the next variant

Patches close this door; attackers will try another.

Make sure you have alerts for:

• Unusual reads of web.config and other secret-bearing files
• Token reuse over long windows
• “Service identity fallback” behavior triggered by blank credentials
• External requests that cause sensitive file access followed by suspicious process execution

This is where AI detection earns its keep: it reduces the time between first exploit attempt and first human review.

People also ask: “If we patched, are we safe?”

Answer first: Patching removes the known exploit path, but you still need to verify exposure, hunt for persistence, and monitor for follow-on access.

Three reasons:

1. Exploit-first reality: Many orgs are compromised before they patch.
2. Key theft changes the timeline: If sensitive keys were exposed, the attacker’s access can outlast the original bug.
3. Chaining risk: Attackers chaining multiple vulnerabilities can pivot to other techniques even after one door is shut.

A clean patch report isn’t the same as “no incident occurred.” You need both patch confirmation and detection-driven validation.

The bigger lesson for AI in cybersecurity

Hard-coded keys are a software supply chain failure, but the operational lesson is broader: attackers win when defenders only look for known bad strings.

AI in cybersecurity is most valuable when it’s applied to behavior—requests that don’t match real user patterns, access that doesn’t match normal app flows, and sequences of actions that look like exploitation rather than business activity.

If your team is trying to decide where AI fits in your security operations, start here: use AI-based anomaly detection to watch the paths attackers must walk, not just the malware they might drop.

If you’re responsible for CentreStack or TrioFox environments, what would you rather learn first: that a patch was missed—or that an unusual, never-expiring access ticket is pulling your server configuration right now?