What Happens When Modbus Is Exposed to the Internet

Modbus TCP is the most commonly exposed industrial protocol on the internet. As of early 2026, Censys identifies over 54,770 internet-facing Modbus services, while Shodan indexes more than 33,000. These are not honeypots or research devices, they are production PLCs, RTUs, HMIs, and protocol gateways in water plants, power substations, manufacturing floors, and building management systems.

Originally designed in 1979 by Modicon for serial communication between controllers, Modbus was never intended to face the public internet. The protocol has no authentication, no encryption, and no access control. Every well-formed command is executed on receipt, from any source, without question.

That is not a vulnerability in the traditional sense. The protocol is working exactly as designed, just in a context its designers never imagined. Threat actors understand this better than most defenders do.

This brief walks through what an attacker actually sees when they find an exposed Modbus device, what they can do with that access, which campaigns have already exploited it, and why traditional IT security tools consistently miss these exposures.

The Scale of Modbus Exposure

Modbus has the largest internet-exposed footprint of any OT protocol. Research presented at IEEE Euro S&P 2025 examined 17 industrial protocols and found approximately 140,000 globally exposed ICS systems, with Modbus exposure growing steadily since 2021.

The numbers are not abstract:

• 54,770+ internet-facing Modbus services identified by Censys
• 33,000+ Modbus devices indexed by Shodan
• A 2026 LeakIX internet scan discovered over 300 exposed Modbus TCP devices in its first hours of scanning, with devices returning vendor names, product models, firmware versions, and live register values

These devices span energy, water and wastewater, manufacturing, oil and gas, and building automation. The exposure is not evenly distributed. Censys data shows Modbus exposure is heaviest in Europe, while the Fox (Niagara) protocol dominates in North America. The patterns are regional and sector-specific, not random. And the majority of asset owners are unaware their devices are reachable from the internet.

What Modbus Looks Like from the Outside

When a Modbus TCP service is exposed on port 502, an external scanner sees a device that will respond to any well-formed request without requiring credentials. There is no handshake, no authentication challenge, no session management. The protocol simply accepts commands.

A basic Shodan query – port:502 product:"Schneider Electric", will return a list of internet-facing Schneider PLCs with their model numbers, firmware versions, and geographic locations. Similar queries work for Siemens, ABB, Wago, and other vendors. Nobody is breaking in here. The protocol is just doing what it does.

From the outside, an attacker can determine:

• Device identity. Function code 43 (Read Device Identification) returns the vendor name, product code, firmware version, and model number. This tells an attacker exactly what they are talking to and which known vulnerabilities apply.
• Register contents. Function codes 3 and 4 read holding and input registers, exposing real-time process values: temperatures, pressures, flow rates, valve states, setpoints. This is live operational data from a running process.
• Coil states. Function code 1 reads discrete outputs, revealing which actuators, pumps, or valves are currently active.
• Writability. Function codes 5, 6, 15, and 16 write to coils and registers. On an exposed device with no access control, an external actor can change setpoints, toggle outputs, or modify PLC logic parameters, directly affecting the physical process.

None of this requires an exploit or a CVE. There is no CVSS score to assign. The protocol is doing what it was built to do, and anyone with a TCP socket can talk to it.

Campaigns That Have Exploited Modbus Exposure

Attackers have been systematically working through industrial protocols for over a decade. Stuxnet targeted Siemens S7 controllers via PROFIBUS in 2010. Industroyer hit Ukrainian power infrastructure via IEC-104 in 2016. TRITON went after Schneider Triconex safety systems via a proprietary protocol in 2017. Modbus, the most widely deployed and least authenticated of them all, was the obvious next step. In 2022, a state-sponsored group built an attack framework with Modbus as a core module. In 2024, Modbus was used to cause physical damage for the first time.

FrostyGoop (January 2024)

FrostyGoop is the first known ICS malware to use Modbus TCP to directly cause real-world physical impact, according to Dragos’s analysis. Written in Golang and compiled as a Windows binary, the malware targeted ENCO controllers at a district energy facility in Lviv, Ukraine via port 502.

The attackers manipulated heating system setpoints, cutting heat to over 600 apartment buildings, more than 100,000 residents in the Sykhiv district, for nearly two days in sub-zero winter temperatures. No malware was deployed to the controllers themselves. The attackers just spoke Modbus to devices that would accept commands from any source.

Initial access was gained on April 17, 2023, by exploiting an unknown vulnerability in a publicly accessible MikroTik router, no specific CVE has been publicly attributed. That gave the attackers roughly nine months of dwell time before the operational impact in January 2024. Palo Alto Unit 42’s analysis found that FrostyGoop samples had been present on VirusTotal since at least October 2023 without triggering detections from any antivirus vendor.

Worth sitting with that for a moment: FrostyGoop did not exploit a software vulnerability in the PLCs. It just talked to them. The controllers did exactly what they were told because Modbus has no concept of “who is asking.”

And because the malware is not hardcoded to any specific vendor or device, every one of those 54,770+ internet-exposed Modbus services is a potential target for this exact attack methodology, as it exists today.

PIPEDREAM / INCONTROLLER (2022)

PIPEDREAM is a modular ICS attack framework attributed to the state-level threat group CHERNOVITE, as detailed in Dragos’s CHERNOVITE whitepaper. Its CODECALL module targets Schneider Electric PLCs using both Modbus and CODESYS protocols, scanning for devices, enumerating information, reading registers, and writing to coils and registers. Other modules target Omron PLCs (BADOMEN), OPC UA servers (MOUSEHOLE), and a Windows kernel driver exploit (LAZYCARGO) that handles gaining position on the host before the OT-facing modules talk to the PLCs.

Mandiant, who tracked the same toolset under the name INCONTROLLER, called it “exceptionally rare and dangerous” because it targeted native industrial protocols without requiring vendor-specific engineering software. Dragos’s analysis found PIPEDREAM can execute 38% of known ICS attack techniques and 83% of known ICS attack tactics per the MITRE ATT&CK for ICS framework.

PIPEDREAM was intercepted before it was used operationally, a rare case of discovering an ICS attack capability before deployment. But the investment tells you something: a state-sponsored group built a multi-module framework with Modbus as one of its core attack protocols. That capability does not go away.

Solar Farm Modbus Attacks (2025-2026)

Security researchers have demonstrated internet-based attacks against solar power infrastructure using open Modbus ports on power inverters and energy management systems. These attacks allow manipulation of energy production, disruption of grid-tied inverters, and falsification of monitoring data, in some cases within minutes of discovering exposed devices. Scanning tools can discover and test exposed Modbus services across large IP ranges within minutes.

Modbus Protocol Vulnerabilities (Ongoing)

Beyond the inherent insecurity of the protocol itself, specific implementation flaws continue to surface. In 2025, Cisco Talos fuzzed the Modbus protocol handling on a Socomec DIRIS M-70 IIoT power monitoring gateway and found multiple denial-of-service conditions triggered by malformed Modbus messages, resulting in six new CVEs. Separately, CISA advisory ICSA-25-238-03 addressed an improper input validation vulnerability (CVE-2025-6625) in Schneider Electric Modicon M340 controllers and associated communication modules, including Modbus/TCP Ethernet modules.

Why IT Security Tools Miss This

Traditional vulnerability scanners and IT-focused attack surface management tools consistently fail to detect exposed Modbus services:

1. Port coverage. Most IT scanners focus on common ports (80, 443, 22, 3389). Port 502 is not in their default scan profiles. A device can be fully exposed on the internet and invisible to the IT security team’s tooling.
2. Protocol awareness. Even if port 502 is scanned, IT tools see an open TCP port. They do not speak Modbus, so they cannot fingerprint the device, read registers, or assess what is actually exposed. The difference between “port 502 open” and “Schneider Modicon M340 running firmware v3.20 with writable registers” is the difference between a finding and actionable intelligence.
3. No CVE to match. An exposed Modbus device is not a “vulnerability” in the traditional sense. There is no CVE, no CVSS score, no patch to apply. IT tools are built around CVE-based prioritization and have no framework for “this device accepts unauthenticated commands from the internet.” The risk is architectural, not software-based.
4. Asset blindness. These devices are typically not in the IT asset inventory. They were provisioned by OT engineers, connected to operational networks, and never registered in CMDB or ITSM systems. If the asset is not in inventory, no scanner will target it.

OT-specific external attack surface management exists to fill exactly this gap. You need protocol-level scanning that actually understands industrial communication, not just TCP port enumeration.

What Asset Owners Should Do

Immediate Actions

• Discover what is exposed. You cannot protect what you do not know about. An external scan specifically targeting port 502 with Modbus protocol-aware probes is the starting point. Do not assume your IT vulnerability scanner covers this.
• Segment aggressively. Modbus devices should never be directly reachable from the internet. Place them behind firewalls with explicit allow-lists. If remote access is required, use a VPN or jump host with multi-factor authentication, and ensure the VPN itself is patched and monitored.
• Monitor for scanning activity. Threat actors continuously scan for Modbus services. If you see inbound connection attempts on port 502 from unknown IPs, treat it as active reconnaissance against your OT environment.
• Assess the blast radius. For every exposed device, understand what it controls. A building management system and a water treatment chemical dosing controller have very different risk profiles, even if the Modbus exposure is identical.

Structural Improvements

• Compensate for protocol limitations. IEC 62443-3-3 provides guidance on compensating for insecure legacy protocols like Modbus through network controls, including zone isolation and application-aware firewalls. NIST SP 800-82 Rev. 3 offers specific recommendations for securing Modbus deployments, including protocol-aware deep packet inspection and encrypted tunneling where Modbus must traverse untrusted networks.
• Evaluate protocol migration. Where feasible, consider migrating to OPC UA, which supports authentication, encryption, and certificate-based access control. Both IEC 62443 and NIST SP 800-82 recommend supplementing or replacing Modbus with more secure alternatives where operationally practical.
• Map to compliance frameworks. For electric sector operators, NERC CIP requires electronic security perimeters around BES Cyber Systems, exposed Modbus devices are a direct compliance gap. For all sectors, IEC 62443 zone and conduit models explicitly address the need to isolate legacy protocol traffic from untrusted networks.

An Architecture Problem, Not a Software Bug

Modbus exposure is an architecture failure, not a software bug you can patch. The protocol does exactly what it was designed to do. The problem is where it is doing it: on the public internet, where anyone can interact with it.

Over 54,000 Modbus devices sit on the internet. Nation-state groups have built custom tooling to talk to them. Ransomware operators target the perimeter devices that provide network access to OT environments where these protocols run, per Dragos. And the exposure count keeps climbing.

Knowing which of your devices are in that count is where remediation starts.