Exposure Is Not a One-Time Finding: Monitoring Industrial Protocol Reachability After the CISA PLC Alert

Most remediation guidance is written as a task with an end state. Disconnect the controller, rotate the password, allowlist the engineering workstation, and the item is closed. CISA's 30 July 2026 alert on activity targeting PLCs in the Water and Wastewater Systems Sector fits that pattern: it lists mitigations and advises operators to act as soon as possible.
The difficulty is that the condition the alert describes is not naturally stable. Reachability is a property of a network configuration, and network configurations change. A temporary vendor connection opened for a maintenance window, a cellular modem installed to avoid a site visit, a firewall rule added during an outage and never removed: each of these recreates the exposure after the remediation ticket is closed. CISA's own note that the targeting includes cellular modems "that may not be documented or included in routine attack surface scans" describes exactly this failure mode.

Why one-time verification is insufficient

The alert describes attackers reaching exposed controllers, modifying passwords to lock out operators, and changing IP addresses to disconnect devices, with boil water notices and sustained manual operations as the result. The attacker's precondition is reachability at the moment of the attempt.
A verification performed once, at remediation time, confirms the state on that day. It does not constrain the state next month. Three common events reintroduce exposure:

• Vendor and integrator access. A support session may require a temporary path that is easier to leave in place than to remove.
• Cellular and out-of-band links. These are frequently installed by third parties and may never appear in the operator's own scanning scope.
• Configuration drift. Rules added under time pressure during an incident are rarely reviewed afterwards. Each of these produces the same observable outcome: a device that answers on the public internet. ## Building a monitoring baseline A repeatable external observation turns remediation from a one-time task into a monitored state. The method is straightforward. First, fix the query. For the protocol associated with the controllers named in the alert, the query used on 17 September 2026 was

port="44818" && service="ethernet-ip"

which returned 41,601 assets globally. A service-only variant, service="ethernet-ip", returned 41,609, and a bare port query, port="44818", returned 41,965. The convergence of these three counts is expected, since TCP port 44818 is the registered EtherNet/IP port, and it means the query is stable enough to serve as a baseline.
Second, restrict the query to the address ranges the organization controls, including ranges used by vendors and integrators. This converts a global figure into a set of specific assets.
Third, record the result with a timestamp, and repeat on a schedule. The absolute number matters less than its movement.
| Observation | Interpretation |
| --- | --- |
| New match in a previously empty range | A new external path exists; find its owner before assuming it is malicious |
| Match disappears after remediation | The change took effect as intended |
| Match reappears after remediation | The path was restored, possibly by an automated process or a third party |
| Match persists despite a recorded firewall change | A second path exists, or the rule did not apply as intended |
The last two rows are the ones a one-time verification cannot produce, and they are the ones that matter for an alert about reachable controllers.

What monitoring can and cannot establish

A recurring protocol query establishes whether an asset is externally reachable at the time of observation. It does not establish whether the device has been accessed, whether its password has been changed, or whether it is operating normally. Those questions require device-level and network-level evidence that an external scan does not provide.
It also does not classify the asset. The 41,601 EtherNet/IP assets observed on 17 September 2026 are not a list of water utilities. EtherNet/IP is used across manufacturing, building automation, and process control, and a protocol match carries no sector information. Attempts to narrow by vendor fingerprint were not productive on the same day: app="MicroLogix 1400" and module_id="1766-L32BWA" both returned zero results, reflecting fingerprint coverage limits in a lean industrial protocol rather than the absence of such devices.
The honest framing is that monitoring answers a narrow question well. It tells an operator whether the external path they removed has come back. Given that the alert's threat model depends entirely on that path existing, the narrow question is the right one to automate.

Operational recommendations

• Define the protocol query once, document it, and use the same query for every observation so that counts are comparable.
• Include vendor, integrator, and cellular ranges in the monitored scope, not just the organization's primary public ranges.
• Treat a reappearing match as an incident trigger rather than a data point, since it indicates an unmanaged change to an external path.
• Pair external monitoring with the internal controls CISA recommends: VPN or gateway mediation, password protection, IP allowlisting, and a known clean PLC image backup.
• Record observation timestamps and counts so that a later review can distinguish a real change from index drift. ZoomEye's contribution in this workflow is a consistent, external, repeatable measurement of protocol reachability. It complements internal configuration management by observing the network as an outsider would, which is the perspective the alert's threat model assumes. ## Limitations All counts cited are single-day observations from 17 September 2026 and are subject to index drift and probe coverage limits. A device that does not respond to external probes will not appear in a baseline even if it is reachable through other means. Monitoring of this kind detects changes in observed reachability; it does not detect compromise, credential changes, or operational anomalies on the device itself. ## References
• CISA, "CISA Urges Water and Wastewater Systems Sector to Protect OT Against Activity Targeting PLCs," 30 July 2026. https://www.cisa.gov/news-events/alerts/2026/07/30/cisa-urges-water-and-wastewater-systems-sector-protect-ot-against-activity-targeting-plcs
• ZoomEye queries executed 17 September 2026, counts as recorded above.