ThinManager SSRF CVE-2025-9065: Patch to v14.1 and OT security best practices

Rockwell Automation’s ThinManager has been flagged for a high-severity Server-Side Request Forgery (SSRF) flaw that can expose an industrial control system’s ThinServer service account NTLM credentials, according to a federal advisory reissued on September 9, 2025. The vulnerability—tracked under CVE-2025-9065 and assigned a CVSS v4 base score of 8.6—affects ThinManager releases in the 13.x and 14.0 lines and is exploitable with low attack complexity when an attacker has valid credentials (authenticated access). Rockwell has issued remediation in ThinManager v14.1; organizations that cannot immediately upgrade are urged to apply layered mitigations including SMB/NTLM hardening, network segmentation, and strict firewalling to limit exposure.

Background / Overview​

ThinManager is widely deployed in manufacturing and industrial environments to manage thin clients, remote terminals, and session brokering for operator workstations. Because it often runs with elevated service privileges (the ThinServer service account), any vulnerability that allows the server to be coerced into making network requests on behalf of an attacker can be serious in OT networks.
The recently documented SSRF issue stems from insufficient input sanitization when the product accepts and processes SMB paths. An authenticated user can submit crafted (attacker-controlled) SMB targets, causing the ThinServer process to initiate outbound SMB/NetBIOS/SMB2 connections to attacker-controlled hosts. During SMB authentication the ThinServer service account may attempt NTLM authentication, which can expose an NTLM challenge/response hash to the remote SMB endpoint. That hash can then be harvested by an attacker and used in offline cracking attempts or opportunistic credential replay techniques such as pass-the-hash or NTLM relay attacks—especially dangerous in mixed OT/IT environments where domain credentials or service account hashes can provide lateral access to critical infrastructure.
Key facts verified during reporting:

• The advisory assigns the SSRF vulnerability CVE-2025-9065 and reports a CVSS v4 base score of 8.6.
• Affected versions: ThinManager 13.0 through 14.0.
• Vendor remediation: the issue was addressed in ThinManager 14.1; Rockwell recommends upgrading to 14.1 or newer.
• Recommended compensating controls include blocking NTLM for SMB clients where possible and minimizing network exposure of control systems.

These core details were confirmed in the federal industrial control systems advisory and cross-checked against vendor release and product notes and Microsoft guidance on blocking NTLM over SMB.

---

Why this SSRF matters in OT environments​

SSRF is a different class of risk in industrial deployments​

SSRF vulnerabilities let an attacker trick a server into accessing resources the attacker cannot directly reach—internal management APIs, cloud metadata services, or other trust-bound resources. In OT, thin-server components commonly run with high privileges and have access to local system resources and industrial control buses. That means SSRF can facilitate:

• Credential exposure (e.g., NTLM hashes) when the server authenticates to a malicious endpoint.
• Stepping-stone proxying to reach otherwise segmented networks.
• Information discovery of internal hosts and services by abusing a trusted internal process.

NTLM hash exposure opens multiple attack paths​

The ThinManager SSRF is notable because the target protocol is SMB/NTLM. When ThinServer attempts to authenticate to a specified SMB share, it may reveal an NTLM challenge/response hash. Consequences include:

• Offline cracking of the service account password if the hash is captured and modern cracking techniques are applied.
• Pass-the-hash and relay-style attacks that let an attacker authenticate to other systems without needing the plaintext password.
• Privilege escalation if the ThinServer account has broader rights (for example, database or file access on other hosts).

In short, an SSRF that results in NTLM hash exposure is not just a local bug—it creates an identity-theft vector that adversaries can weaponize.

---

Technical breakdown: how the exploit works (high level)​

1. ThinManager accepts an input field where users can configure or reference network paths (the product supports SMB paths for remote content, camera URLs, mapped shares, etc.).
2. Due to weak input sanitation, a maliciously constructed SMB path is accepted. That path can point to an attacker-controlled SMB server (for example, an internet-facing host that the attacker controls) or to an internal host that the attacker can coerce into connecting to them.
3. ThinServer resolves and attempts to connect to the supplied SMB path. As part of SMB authentication, the ThinServer service account may initiate NTLM authentication with the SMB endpoint.
4. The attacker-controlled SMB endpoint captures the NTLM challenge/response exchange and either relays it to other targets (relay attack) or records it for offline cracking or reuse.
5. With the captured authentication material, the attacker can attempt lateral movement, impersonation, or other operations permitted by the service account’s privileges.

This is a classic SSRF exploitation pattern adapted to SMB authentication flows—authenticated client input results in a server-side network request that discloses credentials.

---

What is fixed and the upgrade posture​

• Rockwell corrected the SSRF issue in ThinManager v14.1. Organizations running ThinManager versions 13.0 through 14.0 are listed as affected.
• Administrators are strongly advised to plan an upgrade to v14.1 or later as the primary remediation step. Because ThinManager frequently runs inside operational networks with change-control constraints, schedule testing and staged rollouts in accordance with OT change management.

If you cannot immediately upgrade, follow the compensating mitigations described below. In all cases:

• Apply updates in test environments first, validate thin-client behavior and integrations, and then deploy to production in controlled maintenance windows.
• Rotate the ThinServer service account password after remediation to invalidate any captured NTLM hashes.

Note: if you maintain multiple ThinManager clusters, confirm each server is updated; attackers may pivot via any vulnerable server in the estate.

---

Immediate mitigations and compensating controls​

For organizations that cannot upgrade immediately, or as additional defense-in-depth even after patching, implement the following measures:

• Upgrade to ThinManager 14.1 (primary fix) as soon as it has passed OT change control checks.
• Block outbound SMB (TCP 445) and NetBIOS (TCP/UDP 139) from ThinManager servers to anything other than known, trusted internal SMB servers. Prevent outbound SMB to the internet or to untrusted segments.
• Limit access to the ThinManager management ports (default TCP 2031) by firewalling so that only authorized thin clients and administration hosts can reach the service.
• Block NTLM over SMB on clients where feasible. Modern Windows versions include an SMB NTLM blocking capability that lets administrators block NTLM authentication for outbound SMB connections—use Group Policy or PowerShell to configure blocking in environments that support it.
• Enable SMB signing and require Kerberos authentication for SMB where possible; SMB signing prevents some relay/ tampering attacks, and Kerberos resists simple NTLM hash replay.
• Rotate the ThinServer service account password and, where possible, migrate service accounts to Managed Service Accounts (MSAs) or group-managed service accounts to reduce credential management risk.
• Enforce least privilege for the ThinServer account—ensure it has only the rights required for ThinManager operation (no domain admin rights, no unnecessary file-share permissions).
• Monitor and detect outbound SMB connections from ThinManager hosts; alert on sudden SMB auth attempts to unusual destinations.
• Apply network segmentation: isolate OT control networks from business networks and the internet. Use industrial firewalls and jump hosts for remote access.
• When remote access is needed, prefer secure remote access solutions with strong authentication and monitoring (e.g., vetted VPNs with multifactor authentication and robust logging).
• Apply vendor security best practices and hardening guidelines for ThinManager and related infrastructure.

---

Concrete configuration recommendations and short checks​

• Limit TCP 2031 (ThinManager) access:
  1. Identify devices requiring access.
  2. Create firewall ACLs that only allow 2031 from those IPs/networks.
  3. Log and alert on denied 2031 traffic.
• Block NTLM outbound for SMB clients:
  1. Use Group Policy: Computer Configuration > Administrative Templates > Network > Lanman Workstation > Block NTLM (LM, NTLM, NTLMv2) — set to Enabled.
  2. Maintain an exception list for legacy servers that require NTLM using the Block NTLM Server Exception List policy.
  3. Alternatively, use New-SmbMapping PowerShell command with the BlockNTLM parameter to map required shares while blocking NTLM globally.
• SMB signing and Kerberos:
  1. Audit SMB endpoints for Kerberos capability and enable Kerberos for SMB where feasible.
  2. Enforce SMB packet signing for sensitive hosts.
• Service account rotation:
  1. Schedule an immediate rotation for ThinServer service account credentials after patching (or sooner if you suspect compromise).
  2. If NTLM hashes may have been harvested, consider replacing the account with a new principle and retire the old account entirely.
• IDS/Network monitoring:
  1. Detect and alert on ThinManager servers initiating SMB connections to external or unusual internal IP ranges.
  2. Use EDR/SIEM rules to flag NTLM authentication events originating from ThinServer hosts.

---

Detection and response guidance​

• Look for outbound SMB (TCP/445) attempts initiated by ThinManager servers to IP addresses that are:
  • Not in expected internal ranges,
  • Public IPs, or
  • Known malicious infrastructure.
• Search logs for NTLM authentication attempts where the client is the ThinServer host and the target is an external or suspicious endpoint.
• If an SMB-authentication hash exposure is confirmed or suspected:
  1. Immediately isolate the affected ThinServer host(s) from the network.
  2. Collect forensic artifacts (memory, local logs, network flows) for investigation.
  3. Rotate the relevant service account password(s) and any associated credentials.
  4. Check related systems (domain controllers, file servers) for anomalous authentication attempts or lateral movement.
  5. Treat potential compromise as high priority in OT incident response playbooks and follow established incident escalation.
• Use threat hunting to check for:
  • Unknown SMB sessions to attacker-controlled hosts,
  • Repeated authentication failures for sensitive accounts,
  • New user accounts or API keys added to ThinManager configuration.

---

Operational considerations and testing​

• In OT environments, upgrades require coordination with process owners; schedule testing in a lab or staging environment that mirrors production demographics (thin clients, camera integrations, RDS/VDI, and downstream systems).
• Validate that ThinManager v14.1 preserves operational functionality: confirm thin client sessions, video streams, camera integrations, and RDS/FactoryTalk integrations work as expected.
• Check integration endpoints for hard-coded expectations about SMB behavior—some integrations may rely on older authentication methods; if so, prepare exception lists or compensating controls.
• If SMB NTLM blocking is enabled, maintain an allowlist for essential legacy servers and document reasons to keep exceptions.

---

Risk evaluation for critical manufacturing​

• Attack vector: Remote, authenticated. This increases risk in scenarios where ThinManager management functions are exposed to internal users or insecure administration networks.
• Impact: High. Exposure of the ThinServer service account’s NTLM hash can enable lateral movement, data exfiltration, and sabotage in OT networks—core components of manufacturing environments.
• Likelihood: Elevated in environments without strict segmentation and filtering or in organizations that allow broad internal access to ThinManager administration.

Given these factors, the vulnerability should be treated as high priority for industrial operators using ThinManager 13.x or 14.0.

---

Recommended remediation timeline (practical advisory)​

1. Immediate (0–7 days)
   • Inventory ThinManager instances and versions.
   • Block external/out-of-scope SMB traffic from ThinServer hosts (firewalls).
   • Limit TCP 2031 to authorized hosts only.
   • Plan coordinated change-control window for upgrade.
2. Short term (7–30 days)
   • Test and deploy ThinManager v14.1 in a staging environment and then production.
   • Rotate ThinServer service account credentials immediately after patching.
   • Configure SMB NTLM blocking and exceptions where supported and tested.
3. Medium term (30–90 days)
   • Review account privileges and enforce least privilege on service accounts.
   • Expand monitoring and threat hunting to detect lateral movement and NTLM abuse.
   • Document and update incident response playbooks with detection signatures related to SSRF and NTLM exposure.
4. Long term (90+ days)
   • Move away from NTLM reliance—plan for Kerberos-only SMB where feasible.
   • Harden architecture: reduce reliance on single, highly privileged service accounts and adopt managed service account models.
   • Implement regular vulnerability scanning and patching cadence for OT software.

---

Strengths and risks of the vendor mitigation approach​

• Strengths:
  • Vendor-issued patch (v14.1) addresses the root cause and is the definitive remediation.
  • Guidance to update aligns with secure software lifecycle practices.
• Risks / Limitations:
  • Many OT sites delay upgrades due to operational risk—some organizations may remain on vulnerable versions for extended periods.
  • Remediation requires OT change control and testing; without proper compensating controls the window of exposure remains.
  • Blocking NTLM or enabling SMB signing can create compatibility issues with legacy systems; operators must carefully test exceptions.

Given these trade-offs, layered mitigations are essential until organizations can fully deploy vendor fixes.

---

Detection rule examples and hunting queries (examples for SIEM / logging)​

• Network detection:
  • Alert on ThinServer hosts initiating SMB connections to IPs outside expected ranges or to public IP space.
  • Alert on SMB session establishment from ThinServer to any host not in allowlist.
• Authentication/log collection:
  • Detect NTLM authentication attempts where source is ThinServer host and destination is unusual.
  • Monitor for abnormal frequency of SMB authentication attempts from ThinServer processes.
• Host telemetry:
  • Detect creation or modification of API keys or outbound HTTP(S)/SMB configuration entries in ThinManager configuration files.

Note: create tuned alerts to reduce false positives, and baseline normal ThinManager behavior before enabling aggressive alerting.

---

Final assessment and guidance​

CVE-2025-9065 is a practical and meaningful risk for industrial environments running ThinManager versions 13.0 through 14.0 because it can convert a configuration parameter into a credential-exfiltration channel via SSRF to SMB. The vendor fix in ThinManager v14.1 is the primary mitigation and should be applied according to OT change-control policies. In parallel, operators should implement network-layer controls—limit outbound SMB, block NTLM where feasible, enable SMB signing and Kerberos, rotate service account credentials after patching, and increase monitoring for suspicious outbound authentication attempts.
At the time of this advisory’s reissue, federal ICS guidance and vendor product notes were used to verify version impact, CVE assignment, and recommended remediation steps. Where vendor advisory pages lag public advisories, administrators should confirm vendor guidance via their support channels and vendor portals, then proceed with testing and staged deployment. Any organization that cannot immediately apply the patch must assume elevated risk and apply the compensating controls in this report while accelerating remediation.
This vulnerability underscores persistent OT realities: industrial management tools often sit at the junction of IT and OT, and a single server-side flaw can have outsized consequences. Prioritize patching according to the risk to safety and production, and treat credentials exposed via network protocols as high-value artifacts deserving immediate rotation and containment.

---

Source: CISA Rockwell Automation ThinManager | CISA