RDP Security: CPS Threats Spark Need for Secure Remote Access

Why Exposed Remote Access Still Matters in CPS

Hybrid work, remote monitoring and maintenance, and third-party access for system integrators or device vendors are now essential business requirements across many industries. This is especially true in critical infrastructure sectors with mission-critical remote sites, including utilities, transportation, and oil and gas.

Historically, organizations have managed remote access to cyber-physical system (CPS) networks at these sites through traditional VPNs or jump hosts using technologies, such as Remote Desktop Protocol (RDP) and Virtual Network Computing (VNC). These approaches were designed to extend networks, not control interactions, which increase the attack surface.

Since 2024, we have discussed the growing volume of exploits and credential-based attacks targeting VPN devices. In mid-December 2025, we published a blog detailing the scanning activity we observed against those devices. Two weeks later, the Russian attack on the Polish power grid reportedly relied on valid VPN credentials reused across sites for initial access.

In this research, we examine risks and threats affecting another common remote-access model: jump hosts and human-machine interfaces (HMIs) exposed through RDP and VNC. We analyze the global attack surface, highlight examples from the current threat landscape, and explain why modern secure remote access (SRA) is needed in CPS networks.

Why Remote Access Is Risky for CPS

CPS environments were not designed for remote access. Many of these systems lack the native identity, authentication, and authorization controls required for safe remote operations. We explored some of this insecure-by-design functionality in operational technology (OT) in our previous OT:ICEFALL research.

Remote access is also one of the least governed paths into CPS environments because of the continued use of VPNs and jump hosts. Once connected through these methods, users often gain broad, persistent access. Several factors compound this risk:

• VPNs and jump hosts extend trust instead of enforcing control: These systems grant broad network access, rely on shared or persistent credentials, and increase the blast radius in safety-critical environments.
• Undocumented and shadow remote access is common: OEM, contractor, and ad hoc remote connections often exist outside security and operations visibility, creating unmanaged backdoors into CPS environments.
• Legacy and proprietary protocols increase operational risk: CPS environments rely on protocols that were never designed for remote connectivity, increasing the risk of unauthorized changes, misconfiguration, or disruption.
• Limited session visibility undermines governance and accountability: Organizations often cannot prove who accessed CPS assets, whether access was approved and constrained, or what actions were performed.

The Global Attack Surface for RDP and VNC

Using Shodan, we currently see more than 1.8 million RDP servers and more than 1.6 million VNC servers exposed on the internet. They are distributed worldwide, as shown in the heatmap below:

• China has 22% of exposed RDP servers and 70% of exposed VNC servers.
• The US has 20% of exposed RDP servers and 7% of exposed VNC servers.
• Germany has 8% of exposed RDP servers and 2% of exposed VNC servers.

Some of these systems are honeypots, and not all provide access to enterprise networks. To reduce that noise, we map exposed instances to specific industries using Autonomous System Numbers (ASNs) from the public Stanford ASdb dataset. Most ASNs associated with these exposed servers belong to  ISPs or hosting providers which cannot be mapped to a specific industry. Many honeypots are also likely to be deployed on those ASNs. After excluding them, we identified 91,000 exposed RDP servers and 29,000 exposed VNC servers that could be categorized by industry.

Exposure volume alone does not define risk. Different sectors face different operational realities. For example:

• Transportation: These environments are typically multi-vendor and require access for several third parties which complicates remote access management.
• Manufacturing: These organizations are attractive ransomware targets, and RDP has frequently been used in past intrusions.
• Water utilities: These organizations are frequent hacktivist targets and often operate under budget constraints that limit security investment.

At the same time, several risks are common across sectors:

• The table below shows that 18% of observed RDP servers run end-of-life Windows versions. Another 42% run Windows 10, which remains the most common version despite reaching end of support last October. Organizations can still enroll in Windows 10’s Extended Security Updates (ESU) program, but that comes at a cost, and we cannot determine which servers are covered.

 

• More than 19,000 exposed RDP servers are vulnerable to CVE-2019-0708 (BlueKeep) which is a seven-year-old wormable vulnerability that enables remote code execution over RDP. BlueKeep has been exploited by ransomware actors and by Iran-sponsored actors, according to CISA’s latest Cyber Vulnerability Insights Estimate.
• Almost 60,000 exposed VNC servers have authentication disabled, allowing anyone to interact with the applications presented by the device.
• More than 670 exposed VNC servers have authentication disabled and provide direct access to OT/ICS control panels. Some examples are shown in the image below.

Disabled authentication is an obvious security problem, but even systems with authentication enabled often rely on default, weak, or shared credentials.

The Threat Landscape: Emerging Threats Targeting VNC

The risks leave exposed remote-access assets open to compromise by threat actors to perform a range of activities, such as defacing systems, disrupting processes, wiping data, or moving laterally into the wider network.

Organizations with exposed remote access routinely face multiple classes of threat actors, including hacktivists, ransomware operators, or botnet operators.

In 2024, we described an attack on our honeypots in which Phobos ransomware was deployed through an RDP server. Many ransomware affiliates have since shifted toward exploiting vulnerabilities in edge devices as their preferred initial access vector. Even so, it is still easy to find RDP servers on Shodan displaying ransom notes on their login screens:

Below, we focus on two recent threats we observed specifically against VNC: hacktivists sharing tools and initial access for exposed servers and botnets exploiting servers with authentication disabled.

Hacktivists: Scanning and Sharing Access

Hacktivist activity targeting critical infrastructure has intensified since Russia’s invasion of Ukraine in 2022 and more recently following the escalation of conflict in the Middle East in February 2026.

Last December, CISA and several international agencies published a joint advisory on pro-Russian hacktivists targeting VNC. The advisory described common TTPs, including scanning the internet for exposed VNC servers and brute-forcing passwords. It specifically named four groups active against the US: Cyber Army of Russia Reborn (CARR), NoName057(16), Z-Pentest and Sector16.

Z-Pentest is a large alliance of hacktivist groups that includes the Infrastructure Destruction Squad (IDS), also known as Dark Engine. This group frequently develops custom tooling and shares it with other groups. Several of its tools appear AI-generated, so their efficacy is questionable. Yet, a recent example shows explicit interest in VNC.

On February 7, IDS shared the TRK25 ADVANCED SCADA tool, including full source code on its Telegram channel. The figure below shows the announcement and a small excerpt from the source code.

The source code indicates that the tool is a GUI-based scanner for specific ports associated with industrial protocols across attacker-supplied IP ranges:

• Both RDP and VNC are included as target, alongside OT-specific protocols, such as Modbus and OPC.
• The tool can take screenshots of scanned targets.
• The code contains placeholder variables for IP ranges in Russia, Ukraine, Germany, the U.S., and China. Given the group’s alignment, it is possible that the Russia and China lists were included to avoid scanning, while the others were intended as targets.
• The source code also included a list of 50 custom IP addresses, possibly used for testing or in live operations. When we analyzed that list on March 20, we observed:
  • 18 hosts offline
  • 12 hosts online in South Korea
  • 9 hosts online in Turkey
  • 4 hosts online in France
  • 2 hosts online in Taiwan
  • 5 hosts online in other countries: one each in Australia, Brazil, Canada, Estonia, and Greece
  • 19 of the online hosts exposed VNC servers

On February 23, the group shared a video of a purportedly compromised groundwater pumping station in Israel that it said was found with this tool. On March 9, the group shared another example of the tool being run against a specific target set, including a VNC screenshot of a control system in Turkey.

Between these two posts, the group also advertised the sale of access to an exposed SCADA system in Czechia, shown in the screenshot below. Announcements like this are becoming more common among hacktivist groups. Why? It is possible this method is a way to monetize targets with lower strategic value. This reflects an initial access broker model long familiar in IT and increasingly relevant in OT.

Unrelated to VNC, the group also advertised a ransomware builder called $$BLACKNET-00$$ for $500. An example of a simple Python-based ransomware sample created by the tool can be found on VirusTotal. The group shared an image of the sample on VirusTotal but redacted the hash. We were able to identify it based on file contents. The file was submitted to VirusTotal only once, on March 10, the same day that it was announced on Telegram from Egypt — although the group may have used a proxy in that country.

Botnets: the REDHEBERG Example

While searching for exposed VNC servers on Shodan, we noticed a distinct pattern: several servers displayed the image below, cropped here to remove an offensive racist message, advertising a botnet for activities, such as DDoS and residential proxy services.

By March 20, almost 40,000 devices appeared compromised. That represented a rapid growth from February 21, when the image was first noticed on roughly 16,000 devices after it began appearing on February 20.

The image includes several “anti” symbols, specifically anti-furry, anti-Palestine, anti-Israel, and anti-transgender, although we have no evidence that the botnet is used for political purposes. It also references three IP addresses, all hosted by the French virtual private server (VPS) provider REDHEBERG Association declaree on AS52053:

• 39.218[.]48 running SSH on port 22 and HTTP on port 3128
• 39.218[.]32 running SSH on port 22 and HTTP on port 80
• 39.218[.]251running SSH on port 22

The second address hosted an ELF executable built using Golang with SHA1 9e285213683d2dcdcbe1e32a0a21b292d88421bd. This sample was first observed on February 20. It functions as a reverse shell that connects by WebSocket to the hardcoded command-and-control endpoint ws[:]//170.39.218[.]32:8080/shell, as shown below.

The sample also contains a French-language status string indicating that the connection was lost and would be retried in two seconds:

Pivoting from that sample on VirusTotal, we found another sample with SHA1 917ce430ec5d44996c8b20e8549dd60425036881, also first seen February 20, that behaved similarly with two differences:

• The hardcoded server changed to ws[:]//128.0.118[.]14:8080/shell. That IP address is managed by OVH SAS, which is another VPS provider located in France.

The French-language messages were slightly different, as shown in the image below:

 

Why  Secure Remote Access Is the Right Response

Mitigating these risks requires a fundamentally different approach to remote access. In CPS environments, secure remote access should function as a controlled operational workflow, not only a network connection.

Every action in CPS can have physical and safety implications. Access should be governed with the same rigor as procedures on the plant floor. Rather than placing a user directly on an OT network, modern SRA inserts a control plane between users, networks, and assets, so that access is deliberate, contextual, and auditable.

Implementing SRA starts with continuous, real-time visibility into every asset on the network. When organizations understand what assets exist, where they are, how they are behaving, and whether they are in an acceptable security posture, access decisions can be based on live asset intelligence rather than static inventories or assumptions.

Using that context, an SRA gateway, such as the recently launched Forescout SRA can mediate each interaction between a user and an OT asset. Users do not communicate directly with PLCs, HMIs, or engineering workstations. Instead, the gateway isolates sessions and renders them as secure, browser-delivered image streams. The user sees pixels, not protocols, which reduces exposure of fragile protocols, such as RDP, SSH, VNC, or proprietary control traffic.

This model enables two core outcomes:

• Precision access control: Asset inventory validates that the asset is known, expected, and aligned with policy. SRA limits the user to a specific asset, a defined task, and a bounded time window. Least privilege is enforced not only at login, but throughout the session. If conditions change, such as asset posture, network state, or authorization, access can be adjusted or revoked without exposing the OT network.
• Full accountability. Every access session is tied to a verified identity which is fully monitored, recorded, and cryptographically signed. Organizations gain an audit trail showing who accessed which system, when, for what purpose, and what actions were performed. This level of visibility supports compliance efforts for frameworks, including NERC CIP, IEC 62443, NIST, and TSA directives, and provides valuable evidence during incident investigation.

SRA turns remote access from a high-risk operational necessity into a controlled and repeatable process. It provides isolation, context, precision, and accountability, helping organizations support remote operations without compromising safety, uptime, or control.

IoCs

• bd6548791d1753de8d68ea80c38e663962294817a31fad274d44003e7458dd80
• 2cad0061f51e66ccd06b6505f096d6c352a6418d2f0e8389f5c8bdb93db7e575
• dec918241d8dc5c21721a1c73daea9b53cf53cfe4ed843cc2eb093b095ba816f
• 39.218[.]48
• 39.218[.]32
• 39.218[.]251
• 0.118[.]14