By 2025, protocol-level attacks against industrial control systems (ICS) have become a sustained global trend, with 2024 standing out as a clear inflection point in both volume and impact. Attackers no longer need exotic zero‑days to disrupt critical infrastructure; increasingly, they achieve real‑world effects simply by abusing insecure protocols and exposed devices that underpin modern industrial operations.
Protocol attacks hit the real world
In early 2024, residents in Lviv, Ukraine, experienced this shift firsthand when a new ICS malware family, dubbed FrostyGoop, disrupted district heating to more than 600 apartment buildings for almost two days during sub‑zero temperatures. Investigations showed that FrostyGoop directly abused the Modbus TCP protocol over port 502 to send commands to exposed ENCO controllers after gaining access through a vulnerable internet‑facing router and poorly segmented networks.
FrostyGoop did not rely on a complex exploit chain; it “spoke” Modbus like a legitimate system, reading and writing registers to manipulate measurements and control behaviour on devices operating without authentication or encryption at the protocol layer. Researchers now track FrostyGoop as one of a small but growing set of ICS‑specific malware families, and its use of Modbus TCP means any compatible device not just ENCO hardware is potentially in scope across energy, water, manufacturing and other sectors.
Default credentials and exposed PLCs
Just months earlier, attackers linked to the Iranian‑aligned Cyber Av3ngers group had shown that even simpler weaknesses could jeopardise critical services. In late 2023, they compromised a Unitronics PLC‑HMI at the Municipal Water Authority of Aliquippa in Pennsylvania, accessing the device over the internet and defacing its interface as part of a politically motivated campaign.
The technical path was alarmingly basic: many Unitronics devices were exposed to the open internet on a dedicated TCP port and still used default credentials, allowing attackers to log in without any advanced exploitation. Following the incident, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) issued urgent guidance warning operators about widespread exposure of Unitronics PLCs in water, wastewater, agriculture and other critical sectors, highlighting issues such as unchanged default passwords, direct internet access and missing multi‑factor authentication.
145,000+ ICS devices exposed online
These incidents sit on top of a much larger exposed attack surface. Late‑2024 research from Censys identified more than 145,000 internet‑exposed ICS services across 175 countries, with over one‑third located in the United States. The exposed systems span protocols such as Modbus, IEC 60870‑5‑104, CODESYS, OPC UA and BACnet, many of which were originally designed decades ago for trusted, isolated environments.
The study also found widespread exposure of human‑machine interfaces (HMIs) and similar systems, noting that these assets are rapidly probed by automated scanners and that a significant share of interacting IPs display malicious or suspicious behaviour. Regional protocol preferences vary, but the fundamental pattern is consistent: critical industrial protocols are being operated over untrusted networks without modern security controls.
Why protocol-level attacks work so well
Industrial communication protocols typically prioritise reliability and interoperability over security, reflecting their origins in closed, vendor‑controlled networks. Common weaknesses include no built‑in authentication, clear‑text traffic without encryption and an implicit assumption that anything on the network is trustworthy. Once attackers gain a foothold via an exposed router, misconfigured remote access or a compromised edge device they can often issue legitimate‑looking protocol commands directly to controllers and field devices.
This style of intrusion, often described as “living off the land” in OT environments, is difficult for traditional IT security tools to detect because traffic appears protocol‑compliant and operationally normal. Defending against these attacks requires OT‑aware monitoring that understands industrial protocols and can identify anomalous command patterns, device states and timing deviations, rather than relying solely on malware signatures or generic intrusion rules.
The numbers behind the rising threat
Recent reporting shows how sharply the industrial threat landscape has escalated around 2024 and into 2025. Dragos’ 2025 OT/ICS “Year in Review” highlights a major year‑on‑year increase in ransomware targeting industrial and OT environments in 2024, with many incidents leading to partial or complete operational shutdowns. The same research tracks FrostyGoop as a novel ICS malware family and points to additional OT‑focused threats emerging from both state‑aligned and criminal actors.
Complementary analyses note that a majority of reported cyber incidents now affect OT systems to some extent, and that a large proportion of those cases are disruptive or espionage‑driven rather than purely financially motivated ransomware. Together, these findings confirm that what began as isolated, high‑end nation‑state activity has evolved into a more accessible and frequent class of attacks targeting industrial protocols and devices.
Key lessons for ICS operators
Across FrostyGoop, the Unitronics incidents and the exposed‑ICS data, several recurring weaknesses stand out. Inadequate segmentation between IT and OT networks often allows attackers to pivot from a compromised IT asset or edge device straight into critical control systems. Direct internet exposure of PLCs, RTUs, HMIs and other control equipment creates a low‑friction entry point that many adversaries are actively scanning for at scale.
Protocol implementations are rarely tested with the same rigour as traditional IT applications, leaving logic flaws, parsing bugs and unsafe state handling undiscovered until attackers exploit them. At the same time, basic hygiene issues default passwords, weak authentication, missing asset inventories and delayed patching continue to be common root causes in otherwise sophisticated environments.
Eliminating exposure and hardening remote access
Removing or hardening internet exposure should be a top priority for any organisation running ICS environments. Control devices such as PLCs, RTUs and safety controllers should not be directly reachable from the public internet; remote access should instead flow through secure VPNs, jump hosts or remote access gateways with strong authentication and tightly scoped permissions. Security teams should routinely scan their own external footprint using tools similar to those of attackers such as search engines that index exposed services and external attack surface management platforms to identify and remediate any exposed industrial assets.
Where remote connectivity is required for vendors or field engineers, least‑privilege access, monitored sessions and controlled change processes are critical to prevent forgotten maintenance links or misconfigurations from becoming the starting point for a major incident. Combined with robust configuration management, this approach significantly reduces the likelihood that a single exposed device leads to systemic disruption.
Making protocol security a testing priority
Traditional penetration tests and vulnerability scans often overlook protocol‑level risks, focusing on operating systems, web services and perimeter infrastructure instead. ICS environments need dedicated protocol security testing that can uncover implementation flaws, unsafe state transitions and error‑handling issues within the protocols themselves.
Fuzz testing is particularly effective here, because it automatically generates malformed or unexpected protocol messages and observes how devices respond, revealing vulnerabilities that may never surface under normal conditions. For a broader introduction to fuzzing, see CyTAL’s guide, “What Is Fuzz Testing? The Complete Beginner’s Guide,” available at https://cytal.co.uk/blog/what-is-fuzz-testing-the-complete-beginners-guide/. This approach is especially valuable for proprietary or custom protocol implementations, legacy devices with limited documentation and multi‑vendor systems where interoperability can expose unexpected edge cases.
Why ProtoCrawler matters for protocol security
General‑purpose tools rarely provide deep, protocol‑aware fuzzing for complex ICS and telecom environments. ProtoCrawler, CyTAL’s specialised fuzz testing solution, is designed specifically for protocol security testing in industrial and critical infrastructure contexts, with an emphasis on comprehensive coverage and actionable results. ProtoCrawler models target protocols, generates intelligent malformed inputs, executes large‑scale tests and then analyses and reports issues in a way that supports both engineering teams and compliance requirements.
This makes ProtoCrawler particularly well‑suited to finding the kinds of protocol issues exploited in incidents like FrostyGoop and the Unitronics compromises parsing errors, unsafe command handling and unexpected state transitions that traditional testing often misses. To learn more about ProtoCrawler’s capabilities for protocol security testing, visit the product page at https://cytal.co.uk/products/protocrawler/.
Why continuous OT visibility matters
Defending against protocol‑level attacks depends on understanding what “normal” looks like in an OT network and detecting deviations quickly. Yet independent assessments suggest that only a small fraction of OT environments are continuously monitored with tools that correctly interpret industrial protocols. Without protocol‑aware visibility, attackers can quietly map, explore and manipulate ICS networks using legitimate‑looking commands over extended periods.
Deploying OT‑specific monitoring platforms that can parse protocols like Modbus, DNP3, IEC 60870‑5‑104 and OPC UA enables operators to baseline typical device behaviour and flag unusual commands, timing patterns or communication paths. When combined with accurate asset inventories and change detection, this monitoring gives defenders a far better chance of detecting and containing attacks before they trigger safety incidents or long‑running outages.
The regulatory and business context in 2025
By 2025, regulators and national cybersecurity agencies are increasingly explicit that ICS and OT security are core business responsibilities. In Europe, NIS2 is raising expectations for visibility, testing and incident response across operators of essential and important services, while in India, ITSAR establishes testing requirements for telecom and related equipment. In the United States and UK, sector‑specific regulations and guidance from bodies such as CISA and the NCSC reinforce that critical infrastructure operators are expected to demonstrate robust OT security practices.
The NCSC, for example, has highlighted that cyber security is now a matter of business survival, not just IT hygiene, and has specifically called out techniques like fuzz testing as valuable for gathering objective evidence about product and network equipment security. For a deeper dive into this perspective, see CyTAL’s analysis of the NCSC’s stance at https://cytal.co.uk/blog/ncscs-stark-warning-cyber-security-is-now-a-matter-of-business-survival/. These regulatory trends reflect the reality that outages affecting heating, water, energy and manufacturing can quickly translate into economic losses and wider societal impact.
Practical next steps for defenders
For organisations operating ICS environments, several priorities stand out. First, build a comprehensive asset inventory and exposure map so you know exactly which devices exist, where they are located on the network and whether they are reachable from the internet. Second, validate network segmentation to enforce strong separation between IT and OT zones, with carefully controlled interfaces and monitored data flows.
Third, eradicate default credentials, implement strong authentication on all ICS components and introduce OT‑aware continuous monitoring to detect suspicious protocol activity. Fourth, schedule regular protocol‑focused security testing with fuzzing at the core to uncover implementation flaws and logic issues before attackers do. Finally, ensure incident response plans explicitly address OT scenarios and that engineers and operators are trained to respond safely to cyber incidents in industrial environments.
Frequently asked questions
Q: What makes protocol‑level attacks different from traditional cyber attacks?
A: Protocol‑level attacks focus on weaknesses in the design and implementation of communication protocols themselves, rather than exploiting a specific software bug or misconfiguration. Many industrial protocols lack authentication and encryption, so once an attacker gains network access, they can often send valid‑looking commands directly to control systems without needing a discrete vulnerability.
Q: Why were industrial protocols designed without security features?
A: Most legacy industrial protocols were created in the 1970s and 1980s for use in physically isolated, closed networks where all participants were assumed to be trusted. The design priorities were reliability, real‑time performance and cross‑vendor interoperability, with security effectively delegated to physical isolation and perimeter controls.
Q: Can traditional antivirus or endpoint protection stop ICS malware like FrostyGoop?
A: Traditional endpoint tools have limited effectiveness against ICS‑specific threats because much of the malicious activity occurs over legitimate industrial protocols rather than through easily identifiable malware binaries. FrostyGoop, for example, relied heavily on abusing Modbus commands that look similar to normal operational traffic, making detection by signature‑based tools difficult.
Q: How can organisations identify if their ICS devices are exposed to the internet?
A: Organisations should perform regular external scans of their public attack surface using tools comparable to those used by attackers, including search engines that index open services and dedicated attack surface management platforms. These scans, combined with internal asset inventories, help identify ICS devices that are unintentionally exposed and should be relocated behind secure gateways or removed from direct internet access.
Q: What is the difference between IT and OT network security?
A: IT security traditionally focuses on protecting data confidentiality, integrity and availability, often in that order, whereas OT security prioritises safety, physical process continuity and system availability. OT environments frequently contain legacy systems, tight real‑time performance constraints and safety‑critical processes, so security controls must be carefully tailored and tested to avoid disrupting operations.
Q: Is fuzz testing safe for production ICS environments?
A: Fuzz testing should normally be performed in controlled test environments that mirror production systems, because intentionally sending malformed inputs can, in some cases, cause instability or unexpected behaviour. With careful planning, protocol‑aware tools and appropriate safeguards, fuzz testing can be integrated safely into pre‑deployment pipelines and lab setups to uncover vulnerabilities before changes reach production.
Q: How does ProtoCrawler support fuzz testing for ICS and telecom protocols?
A: ProtoCrawler is a dedicated fuzz testing solution that models target protocols, generates intelligent malformed inputs, automates large‑scale execution and produces structured reports for engineers and compliance teams. It is designed to meet demanding security and regulatory requirements in telecom and industrial contexts, including frameworks such as ITSAR, by providing deep protocol coverage and actionable findings.
Q: How often should industrial control systems undergo security testing?
A: Critical ICS environments should be tested at key lifecycle points during commissioning, after significant changes, following incidents and at least annually for high‑risk systems while also being supported by continuous OT‑aware monitoring. Protocol‑specific testing, including fuzzing, is especially important when introducing new device types, updating firmware or integrating equipment from multiple vendors.
Q: What regulatory requirements apply to ICS security?
A: Requirements vary by region and sector, but examples include NIS2 for operators of essential and important services in Europe, sector‑specific rules and guidance from bodies like CISA in the United States, and ITSAR for telecom and related products in India. Many organisations also align to industry standards such as IEC 62443 for industrial automation and control systems to demonstrate good practice and support regulatory compliance.
For additional context on fuzz testing and protocol security, you can explore CyTAL’s resources, including “What Is Fuzz Testing? The Complete Beginner’s Guide” at https://cytal.co.uk/blog/what-is-fuzz-testing-the-complete-beginners-guide/ and ProtoCrawler’s product page at https://cytal.co.uk/products/protocrawler/.
Recent ICS breach analysis reveals attackers increasingly target protocol-level vulnerabilities across multiple communication standards:
Frequently Targeted Industrial Protocols:
- Modbus/TCP – Lacks authentication, enabling unauthorized read/write operations when exposed
- DNP3 – Parser vulnerabilities and authentication weaknesses exploited in utility sector attacks
- IEC 60870-5-104 – Telecontrol protocol vulnerabilities enabling unauthorized command injection
- IEC 61850 – Complex implementations containing parsing flaws and access control weaknesses
Smart Infrastructure Attack Vectors:
- COSEM/DLMS – Smart meter vulnerabilities enabling billing fraud and service disruption
Network Protocol Exploitation:
- ARP – ARP spoofing enabling man-in-the-middle attacks in flat industrial networks
- DHCP – Rogue DHCP servers redirecting ICS traffic through attacker-controlled infrastructure
Underlying Parsing Vulnerabilities:
- ASN.1 – Encoding standard parser flaws affecting multiple industrial and telecom protocols
Learning from real-world attacks means proactively testing your protocols before attackers do. Explore ProtoCrawler’s vulnerability discovery capabilities or request a security assessment tailored to your threat landscape.