Small choices often carry oversized consequences, and few choices loom larger than leaving a critical factory controller visible on the open internet where silent scans never sleep and a single request can reveal more than intended. Across industrial networks, a familiar tension persists: connect to move faster, or isolate to stay safe. The uneasy truth is that both goals can be pursued, but not by assuming legacy protocols will survive new exposure.
This article explores a coordinated, three-month campaign that probed programmable logic controllers and other Modbus/TCP endpoints across 70 countries. Its purpose is to answer practical questions that plant engineers, CISOs, and network teams ask every week: what exactly happened, how do attackers work through Modbus, how broad was the targeting, and what actions cut risk the most. Readers should expect a narrative that blends observed behavior, interpretation, and concrete defensive guidance.
The scope is specific yet widely relevant. The focus remains on Modbus/TCP reconnaissance and manipulation attempts observed from September to November 2025, with attention to function-code sequences, request volumes, and the operational impact of read-heavy traffic and selective write attempts. The discussion connects findings to sector exposure and geography, then closes with prioritized, actionable countermeasures.
Key Questions or Key Topics Section
What Made This Campaign Different From Background Noise?
Periodic scanning has long been part of the internet’s soundtrack, but this activity stood out by its consistency, choreography, and persistence. Attackers did not merely knock on doors; they followed repeatable playbooks that moved from device identification to targeted reads, and in a subset of cases to attempts at writes. Instead of random pokes, the telemetry showed sequences tailored for Modbus-enabled equipment.
The difference came into sharp focus through function-code patterns and timing. High-volume Read Holding Registers requests (0x03) arrived in sustained waves, interleaved with Read Device Identification calls (0x2B/0x0E). The result was a structured reconnaissance phase that profiled devices, extracted configuration and process data, and set the stage for deeper actions. In several instances, request rates pressed protocol limits, indicating an intent to degrade availability rather than simply map the surface.
Why Does Modbus/TCP Expose Such High Risk?
Modbus/TCP is straightforward, efficient, and widely supported, but it is also insecure by design. It lacks native authentication and encryption, so once a device is reachable over port 502, read and write operations are possible unless blocked by external controls. That design choice made sense in tightly isolated plants; it falters when devices sit one hop away from hostile hosts.
When adversaries can read at scale, they learn model types, memory maps, and process variables, which enables precise targeting. When they can write, the risk escalates to process manipulation, unsafe states, or disruption. No new vulnerability is necessary. Exposure alone turns a production controller into an open book, and sometimes an editable one, for whoever can speak Modbus fluently.
How Did Attackers Discover and Profile Devices?
Discovery began with device identification, commonly using 0x2B/0x0E to pull vendor, product, and firmware details. Almost immediately, many sources followed with fixed-range reads, a repeat block being eight registers starting at 0xB414. That fingerprint-then-target pattern revealed scripted logic keyed to known memory layouts, compressing the time from first contact to meaningful data extraction.
The cadence was revealing. Static Protocol Data Unit arguments and repeated sequences across unrelated targets pointed to automation, not manual exploration. Function-code frequency and order served as a breadcrumb trail: identify the device, then harvest register data likely to contain configuration or status. The tight coupling between these steps suggested preparation and intent, not curiosity.
How Broad Was the Geographic and Sector Footprint?
The activity touched 70 countries, but it was not evenly spread. Nearly half of observed targeting landed in the Americas, followed by Europe and Asia, with only a sliver in Oceania and near-zero in Africa. At the country level, the United States accounted for the largest share, with notable volumes in France, Japan, and Canada, and smaller yet meaningful pockets in several other industrialized nations.
Sector patterns reflected where Modbus still anchors core operations. Manufacturing topped the list, while consumer goods and healthcare also saw significant attention. Construction and technology followed close behind, with transportation, wholesale, and finance not far off, and a long tail categorized as other. The distribution underscored a practical motive: focus on regions and industries where PLC density and operational dependency are high.
What Did High-Volume Reads Reveal About Intent?
High-volume register reads using 0x03 formed the backbone of the campaign, totaling roughly 235,500 inbound requests from 233 sources. Even absent writes, such reads can give away configuration baselines, process values, and patterns that inform later staging. They also provide a way to test device responsiveness under stress and measure how far a controller can be pushed.
One striking case delivered about 158,100 rapid-fire reads at near-maximum sizes, often 124 registers per query. Sustained at that pace, Modbus polling can chew CPU cycles, clog queues, and trigger timeouts in supervisory applications, edging into denial-of-service territory. The tactic blurred the line between reconnaissance and degradation, suggesting that availability pressure was part of the playbook.
Were There Signs of Advanced Tradecraft?
A smaller set of sources requested expanded device identification using the 0200 variant, a rarely seen technique that seeks deeper metadata. Only six IPs generated 175 such requests, but they showed consistent behavior and stronger reputation signals, implying more seasoned operators or better-resourced infrastructure. Precision was the hallmark: fewer hosts, rarer codes, higher intelligence yield.
Equally telling were single-source to single-target sessions that stayed focused over time, indicating targeted attempts rather than aimless sweeps. Multiple intrusion prevention triggers mapped to the same sources, and public reputation services frequently tagged them as higher risk. Together, these signals painted a layered picture: a broad base of automated scanning topped by a sharper tip of specialized effort.
Did Attackers Attempt To Write to Controllers?
Yes, and those moments mattered most. Telemetry captured 3,240 Write Multiple Registers (0x10) requests from a single source, with bursts beginning at 0x0BB8 and writing between 27 and 122 registers. Even if blocked, these attempts test defenses and identify writable ranges. If accepted, they can alter logic, tweak setpoints, or flip modes in ways that appear routine to a busy operator.
The risk landscape changed with every write trial. Unlike reads, which mainly expose, writes can immediately influence outcomes. The pattern aligned with automation: repeatable offsets, consistent lengths, and an appetite to learn which registers respond. In control networks where safety and reliability dominate, that move shifted the conversation from privacy to process integrity.
What Do Reputation Patterns Say About the Operators?
Most sources carried low or no reputation scores, aligning with one-use or rotating infrastructure. That approach minimizes attribution and creates churn that blends into daily noise. However, a smaller cluster of sources displayed stronger reputational histories, matched by the rarer techniques described earlier, forming a distinct stratum of intent and capability.
These layers echo a common model in industrial targeting. Broad reconnaissance scales cheaply and casts a wide net; focused operations reuse infrastructure and accept a higher profile in exchange for efficiency and depth. The coexistence of both during the same window strengthened the assessment that the activity was coordinated rather than coincidental.
Are Internet-Exposed Modbus Devices Still Common Today?
Despite years of warnings, exposure persists. Public scans continue to find Modbus endpoints reachable over port 502, and recent external research counted 179 internet-facing ICS devices using Modbus. The absolute number may seem modest, but the operational weight behind each device is disproportionate, often anchoring lines, utilities, or building systems that others depend on.
Moreover, exposure is not always intentional. Remote maintenance shortcuts, cloud migrations without full segmentation, and inherited vendor defaults can all culminate in a public listener. The campaign’s breadth across countries and sectors confirmed that the problem is structural, not isolated to a few careless deployments.
What Practical Steps Most Effectively Reduce Risk?
The clearest step is to remove Modbus from the public internet. When immediate removal is not feasible, restrict reachability through allow lists, tightly scoped VPNs with strong authentication, and firewall rules that block unsolicited inbound traffic. Network segmentation should place controllers behind demilitarized zones and, where possible, one-way gateways for data export.
Prevention and detection must speak Modbus natively. Intrusion prevention systems, anomaly detectors, and protocol-aware monitors should flag identification queries paired with fixed-register reads, high-rate bulk requests, and any write attempts. Rate limiting and connection controls can blunt stress tactics. Visibility completes the loop: keep accurate inventories, disable unnecessary services, and constrain writable ranges in line with vendor guidance.
What Caveats Should Readers Keep in Mind?
Attribution remained out of scope. Reputation indicators and geolocation offered hints, not firm conclusions about who orchestrated the activity. The observations covered three months and represented what the sensors could see; unseen activity may have been broader or used different infrastructure. Outcomes beyond probing and attempted manipulation were not asserted.
Even with those constraints, the patterns were strong enough to draw practical conclusions. The choreography of function codes, the volume and pace of reads, the precision of fixed-range queries, and the reality of write attempts together described a coherent lifecycle. For defenders, that clarity is useful, even without attribution.
Summary or Recap
Across a concentrated period, adversaries executed a disciplined campaign against Modbus/TCP endpoints exposed to the internet. Their methods followed a clear arc: identify the device, extract meaningful register data, apply stress through large, rapid reads, and, in high-risk moments, attempt writes to change state. The behavior spanned 70 countries and many industries, with heavier focus on regions dense with industrial assets.
The root cause was not a novel zero-day but architecture: insecure-by-design protocol meets public exposure. Reputation patterns showed a wide base of low-profile automation bolstered by a smaller group using rarer, more telling techniques. Even when writes failed, the reconnaissance value of bulk reads created the conditions for tailored follow-ons.
Defenders benefit from simple priorities. Remove exposure where possible, segment rigorously, lock access behind authenticated tunnels, and monitor with protocol-aware tools that understand Modbus semantics. For deeper learning, consult vendor hardening guides for PLC families in use, current advisories from industrial CERTs, and recent surveys of internet-facing ICS services.
Conclusion or Final Thoughts
This assessment closed on a straightforward path forward: shrink the attack surface first, then harden what must remain reachable. Eliminating direct internet paths to Modbus, enforcing segmentation, and requiring authenticated access had emerged as the most reliable levers. Protocol-aware prevention and monitoring then added early warning, catching the telltale sequence from device identification to fixed-range reads to any write attempt.
Longer term, modernization plans benefited from the lesson that connectivity without controls created brittle plants. Teams that mapped registers, limited writable ranges, and validated vendor protections had reduced both the chance and the blast radius of misuse. By treating Modbus exposure as a design flaw to be engineered out—not a nuisance to be tolerated—the likelihood of disruptive reads or unsafe writes was driven down in practice.
