4,407 Rockwell PLCs Sit on the Public Internet, 22 in Cities Hit by Water Utility Attacks

Detected by CaverLive detection for CVE-2017-16740 in the RedEye Intel Feed →

Forescout scanned the internet on August 3 and counted 4,407 exposed Rockwell Automation programmable logic controllers. 2,844 of them are in the United States. Twenty-two sit in cities where water utilities have reported cyberattacks since July 27, and 19 of those 22 ride the same mobile carrier network. Forescout could not confirm that any of the 4,407 were compromised, and the number counts controllers, not utilities or victims.

The part that should change your Monday: the effects described publicly in those water incidents did not require a vulnerability exploit. Attackers changed IP addresses and set passwords on controllers that were already reachable from the internet. Operators lost visibility, and in some cases control, of connected equipment. No CVE, no memory corruption, no zero-day. Just a device answering unauthenticated requests on a routable address.

What the exposure actually looks like

The reachable surface is EtherNet/IP on TCP port 44818. Depending on device configuration, an unauthenticated connection to that port lets an attacker identify the controller (vendor, product code, firmware revision, sometimes the project name) or write settings to it. That identification step is what makes mass scanning viable: an attacker does not need to guess what they hit, the device tells them.

Two independent snapshots agree on the scale. A July 30 Censys pull found 4,148 exposed Rockwell/Allen-Bradley EtherNet/IP hosts. Forescout's August 3 pull found 4,407. Different platforms, different queries, different days, so the figures are not directly comparable, but both clear 4,100. Forescout's historical series puts the June 2026 low at 4,169, down 47% from 7,814 in March 2020. Six years of ICS security advocacy cut the exposed population roughly in half and then flattened out.

Device breakdown from Forescout's results:

• MicroLogix 1400: 50% of exposed controllers
• MicroLogix 1100: 8% of exposed controllers
• Both families were named specifically in the FBI and EPA advisory
• The MicroLogix 1100 was discontinued by Rockwell on April 30, 2022, so a meaningful slice of this population is running end-of-life hardware

The cellular modem is the real attack surface

More than 70% of the US-based exposed controllers are on large mobile carrier networks. Censys attributed 59% of its 4,148 hosts to Verizon Business, AT&T Mobility, and T-Mobile USA. This is the classic small-utility remote-site pattern: a lift station or a well house with no fiber, a cellular router dropped in for SCADA polling and remote troubleshooting, and a public IP handed out by the carrier with nothing filtering inbound traffic.

Nineteen of the 22 controllers found in affected cities were on the same carrier network. That clustering matters more than the raw count. It suggests a shared integrator, a shared modem deployment template, or a shared APN configuration, and the FBI warned explicitly that similar third-party network setups may let attackers repeat a successful compromise across every customer sharing the vulnerable configuration. One integrator's default becomes a target list.

CVE-2017-16740 is a footnote, not the story

Forescout found that 19 of the 22 controllers in affected cities ran firmware susceptible to CVE-2017-16740, a Modbus TCP buffer overflow rated 8.6 by Rockwell. It affects MicroLogix 1400 Series B and C on firmware revision 21.002 and earlier, and Rockwell fixed it in revision 21.003. That patch has been available since 2017.

Two caveats keep this from being the headline. Exploitation requires Modbus TCP to be enabled, which Forescout could not verify on those hosts. And nothing in the reported attacker behavior needed the flaw. Forescout's own framing is the right one: firmware updates fix specific bugs but do not make direct public exposure of a PLC acceptable. Patch to 21.003 because nine-year-old known-vulnerable firmware on a control device is indefensible, not because it closes this campaign.

Keeping the logs long enough to matter

The last item on the checklist above is the one that quietly decides whether you ever reconstruct what happened: centralize logging from the cellular modems and the controllers. Every effect reported in these incidents leaves a trace at the moment it happens. An address changes. A password gets set. A session opens from somewhere new. None of it looks urgent in isolation, and all of it is what you need six weeks later when someone asks when the access began and what else it touched.

The reason that logging does not exist at most small utilities is not ignorance, it is arithmetic. OT telemetry is chatty and repetitive, its value per event is close to zero right up until the week it is the only evidence you have, and per-gigabyte pricing turns "keep it for two years" into a line item nobody approves. So retention gets cut to thirty days, or the modem logs are never collected at all, and the forensic window closes before the investigation opens.

Changing that arithmetic is what we build Caver for: a security data platform that stores your telemetry in open Parquet on object storage you already own, so keeping years of modem and controller logs is a storage decision rather than a licensing negotiation. Same detections, same searches, on data you did not have to throw away.

Those are Forescout's numbers. Ours are worse.

Everything above is one vendor's controllers, counted once, on August 3. It is accurate and it is a slice. We run our own continuous scan of the exposed industrial internet, and the slice is not the picture.

As of the refresh that completed at 12:31 UTC on August 6, 14,620 industrial control devices in the United States are answering unauthenticated identity requests from the public internet, plus 13,590 outside it. Not Rockwell alone: Modbus, EtherNet/IP, DNP3, BACnet, S7 and Niagara Fox. 2,154 of the US devices carry a vulnerability that CISA lists as actively exploited. Today's crawl added 655 devices and dropped 122 against the previous one, a net gain of 533 in a single cycle.

These are real machines, not decoys

Any number pulled straight off a search engine is inflated, because the exposed-ICS population is full of deliberate bait. Security researchers, vendors and national CERTs run honeypots that answer industrial protocols exactly like a real PLC would, and a naive count treats every one of them as a victim.

Ours are filtered before anything is counted. Devices reporting a web-server fingerprint on an industrial port are dropped. Known tarpit operators are excluded by organisation, one of which alone was contributing 5,829 phantom hosts. BACnet responders get a two-probe fingerprint, a legitimate Who-Is followed by sixteen random bytes, because a real controller ignores the garbage and a decoy answers both: that check alone flagged 4,899 fakes, including a single operator's globally distributed fleet of 4,578 identical decoys spread across a dozen countries. Every device also gets an active port probe each cycle, from two separate vantage points, and ages out when it stops answering rather than lingering in a stale index.

We are not going to claim that catches everything. A well-built honeypot that faithfully emulates a controller will pass, and some of what is counted below is certainly still bait. The filtering removes the industrial-scale fakery that makes raw search-engine counts useless, and the residue is small enough that the shape of the problem holds.

Exposed industrial devices by state, August 6, 2026

United States only, after decoy filtering. "KEV" counts devices carrying at least one vulnerability on CISA's Known Exploited Vulnerabilities list, which is the column that should decide what you look at first.

#	State	Exposed devices	With KEV-listed CVE
1	California	1,799	209
2	Texas	1,798	315
3	New York	1,431	113
4	Illinois	937	258
5	Virginia	795	183
6	Pennsylvania	642	75
7	Florida	544	74
8	Massachusetts	476	26
9	Georgia	415	82
10	Ohio	394	72
11	North Carolina	384	32
12	Michigan	361	31
13	Colorado	311	30
14	Tennessee	302	89
15	Indiana	275	33
16	Maryland	252	15
17	New Jersey	248	13
18	Washington	243	43
19	Missouri	223	35
20	Minnesota	216	38
21	Louisiana	181	31
22	Alabama	171	18
23	Connecticut	168	8
24	Kansas	157	27
25	Wisconsin	155	25
26	Arizona	154	40
27	Nebraska	154	25
28	South Carolina	137	26
29	Iowa	115	23
30	West Virginia	109	14
31	Kentucky	96	9
32	Utah	94	5
33	Oklahoma	92	21
34	Mississippi	85	8
35	New Mexico	75	10
36	Arkansas	73	9
37	District of Columbia	70	1
38	Rhode Island	70	1
39	Oregon	63	6
40	Idaho	63	32
41	New Hampshire	45	7
42	Montana	38	8
43	Maine	35	1
44	South Dakota	32	7
45	North Dakota	31	13
46	Delaware	29	1
47	Vermont	21	2
48	Nevada	20	1
49	Wyoming	20	7
50	Alaska	17	1
51	Hawaii	4	1

Sector attribution is deliberately absent from that table. Most of these devices sit behind cellular carrier and ISP address space, so the organisation the address belongs to is the carrier, not the utility operating the equipment. Anyone publishing a confident count of exposed water utilities from internet scanning alone is guessing. Attribution to a specific operator takes the assessment, not the scan.

What a census does not tell you about your own plant

Forescout's number is a census. One internet-wide sweep on August 3, counted, published. It is good work and this entire post leans on it. But a census answers how many, and every operator reading it is asking four different questions: is one of those mine, is that still true this week, does it matter more than the other twelve things on my list, and what does my regulator call it.

A snapshot cannot answer any of the four. That gap is the reason we built our own ICS exposure monitoring rather than reading vendor research and forwarding it to clients.

Is one of them mine

Ours is searchable by the things an operator actually knows: utility name, state, vendor, protocol, sector. You do not have to recognise yourself in an aggregate. A water district in Tennessee can pull up its own state, its own name, and the specific devices attributed to it, then export the row and hand it to the board. "4,407 worldwide" does not survive that meeting. "These two, on this carrier, answering on 44818" does.

Is that still true this week

The exposure count in this post will be wrong by the time you finish reading it, which Forescout says plainly. Our view refreshes daily and keeps 90 days of history, so each device carries a trend rather than a single reading, and devices that stop answering age out through port-probe decay instead of silently vanishing from a fresh scrape. Every refresh also diffs against the day before, so a newly exposed controller is an event with a date on it. That is the difference between finding out at your next annual assessment and finding out tomorrow.

Does it matter more than the other twelve findings

Every device is matched against a curated ICS vulnerability catalog and then correlated live against CISA's Known Exploited Vulnerabilities list, roughly 1,600 CVEs, on each refresh. Exposures tied to something under active exploitation are ranked and flagged above exposures tied to something merely theoretical.

This story is a clean illustration of why that ordering matters. CVE-2017-16740, the Modbus overflow on 19 of the 22 controllers, is not on the KEV list, requires a service Forescout could not confirm was enabled, and matches nothing in the reported attacker behavior. A tool that sorts by CVSS puts an 8.6 at the top of your week. The finding that deserves the top of your week is the one with no CVE attached at all: a controller answering unauthenticated requests on a public address.

What does my regulator call it

Each exposure carries the citation for the sector it belongs to, EPA AWIA for water systems, NERC CIP for electric, NIST 800-82r3 and IEC 62443 for control systems generally, so the finding arrives already translated into the language of the audit it will end up in. We also cross-reference the live CISA ICS advisory feed against the same catalog, so an advisory that touches something you actually run is marked as such instead of being one more RSS item.

Recovery if you are already locked out

Rockwell advisory SD1790 covers the specific scenario operators are hitting: an attacker set a password on the controller and the owner can no longer connect. The procedure resets a MicroLogix 1400 or 1100 to factory defaults, after which you redownload a known-good project file. SD1790 carries no CVE because it is recovery guidance, not a vulnerability disclosure.

Open questions the advisories do not answer

Neither the government alerts nor Forescout's analysis explains how attackers found, selected, or initially accessed their targets. No agency has attributed the campaign. Even the scope is unsettled: the FBI and EPA July 30 public service announcement covers utilities in at least seven states, and as of August 6 the FBI page still says seven while Forescout's writeup describes the announcement as confirming at least 12. Treat the state count as unresolved, not as a bound on who is affected.

Do this week

• Inventory every controller with a public IP. Search your carrier bills and modem management portals for static public addressing, not just your firewall rules.
• Confirm whether TCP/44818 is reachable from outside. Test from an external host, not from the plant network.
• Move remote sites to a private APN or force all SCADA traffic through a VPN terminating inside your network. Nothing on a control network should answer an unsolicited inbound connection.
• Update MicroLogix 1400 Series B and C to firmware revision 21.003 or later, and disable Modbus TCP if you are not using it.
• Build a replacement plan for MicroLogix 1100 units. The line has been discontinued since April 2022 and will not receive further fixes.
• Export, store offline, and hash every PLC project file. Compare ladder logic across sites that should be identical.
• Enable and centralize logging on cellular modems and controllers so an IP change or password set is something you detect rather than something an operator reports.

The 4,407 number will move with the next scan. The underlying condition will not, until someone takes the controllers off the public internet.