After the Minnesota Water System Cyberattacks: Why Every Count of Exposed Rockwell PLCs Differs

By Adrian Cheek, Senior Cybercrime Researcher

Late July, attackers targeted operational technology at more than 30 community water systems across Minnesota. In Braham, attackers disabled computerized controls and briefly shut down the city’s well and water treatment plant. In Plymouth, cellular communications failed at two water towers and multiple wastewater lift stations.

Days later on July 30, 2026, CISA urged the Water and Wastewater Systems Sector to protect operational technology against activity targeting programmable logic controllers (PLCs). A joint FBI and EPA public service announcement named Rockwell Automation and Allen-Bradley MicroLogix 1100 and 1400 series controllers and recorded utilities in at least seven states reporting incidents since July 27. 

Within days, the exposure counts followed: Censys reported 4,148 internet-exposed Rockwell hosts worldwide on July 30, with 2,945 of them in the US. Our own collection over the same period returned 1,610. An earlier Censys snapshot from April 7 had reported 3,891 US hosts. Four measurements of one population, spanning a factor of two and a half, and none of them wrong.

These numbers differ because counting this population involves at least four methodological choices that nobody states, and the choices move the answer more than the underlying exposure does. 

Real utilities lost control of real infrastructure in this incident. When that happens, the number matters to the security lead at a municipal water utility trying to determine whether their systems are on that list. Undercounting provides false reassurance, while overcounting wastes response effort in a sector already stretched thin. Both carry costs that cannot be absorbed by a sector that’s already stretched thin.

This piece exists because the people who needed to act in the week after that advisory deserved a number they could trust and a method they could apply to their own network, not another figure to take on faith. We set out to get as close to a defensible count as passive data allows, to be transparent about where the methodology still falls short, and to give practitioners a concrete checklist for finding their own exposure rather than depending on someone else’s scan of it.

Collection was passive throughout. No host was probed, authenticated to or exploited, because everything here derives from banner data already held in public search indices.

Key Findings About Counting Exposed PLCs

• Host counts overstate installations by roughly half. In a 434-host US sample, the hosts collapse to 285 distinct contiguous address groupings, a factor of 1.52. 48% of hosts sit in a multi-host grouping, and the largest single run holds 19 adjacent addresses with identical service fingerprints. No published count applies this correction.
• Roughly a third of the matched hosts are cellular modems, not controllers. Across the 4,131 hosts returning Rockwell EtherNet/IP identity, 968 run Sierra Wireless ACEmanager and 535 run Cradlepoint administrative interfaces. The controller sits behind the modem. The count measures access paths.
• Public ICS scan data contains honeypots that the platforms themselves have labelled. Censys tags Conpot hosts HONEYPOT and includes them in its published totals. Our collection identified 42 hosts sharing the fabricated serial 0xdead1337 on cloud infrastructure, plus a second cluster of 15. Removing them cut the apparent ControlLogix population by more than a third.
• An entire class of controller is invisible to every EtherNet/IP count. PLC-5 and SLC-5/05 devices speak Client Server Protocol on TCP/2222. A separate collection returned 41 US hosts, 34 of which appear nowhere in the EtherNet/IP data.
• Geographic breakdowns of this population measure carrier infrastructure. Verizon hosts geolocate overwhelmingly to Euless, Hickory Hills, Plymouth Meeting, and Sunnyvale, which are aggregation points and not device sites. State-level distributions built on this data describe where carriers terminate traffic.
• Roughly half the population is not permanently reachable. A point-in-time collection returned 1,512 hosts; a month-long collection returned 2,810. Device serial and model as a stable identity show only 28 of 2,623 identities moving between addresses, which rules out address churn as the explanation.
• Attribution is possible for a small minority. Most hosts sit on carrier allocations with no sub-delegated registration, but a few sit on municipally registered autonomous systems and resolve to an operating organization by WHOIS alone. Those few are disproportionately municipal, which is the sector under attack.
• Exposure is not compromise. Every figure records reachability and device identity. Firmware revision, credential state and downstream process function are not determinable by passive means.

Summary Metrics

Headline figures. Censys counts as published by Censys ARC; Flare counts from passive collection, July 5 to August 4, 2026. All are floor figures.

One Host Is Not One Installation

The largest correction is also the simplest. Exposed hosts do not sit alone. They sit in blocks of adjacent addresses, on one carrier, usually with identical service fingerprints, which is what a single site with several devices looks like from outside.

Figure 1. Adjacency analysis of 434 United States hosts sampled from Censys results, August 3-4 2026. Grouping merges addresses within eight of each other in the same /24.

The clearest example: addresses 107.91.131.225 through 107.91.131.254 on AT&T Mobility at Alpharetta, Georgia. 19 hosts, every one running lighttpd and PHP, every one answering on 80, 161 and 44818, most labelled PLC and SCADA. That is one deployment. Counted as published, it is 19 exposures.

The pattern repeats throughout the sample: 

• 11 Verizon hosts at 166.154.108.226 to 237, nine of them Sierra Wireless AirLink gateways on the same ports
• 10 identical hosts at 63.46.41.170 to 179
• Nine Cradlepoints at 166.149.14.240 to 254
• Seven Comcast hosts at 50.195.6.226 to 232

Collapse under three grouping rules. The contiguous-run figure is the conservative choice: it merges only genuinely adjacent addresses in the same /24.

Applied to the 2,945 United States hosts Censys reported on July 30, this implies roughly 1,900 distinct installations, and as few as 1,600 if grouped at /24.

Why Contiguous Runs Approximate Installations

The grouping rule rests on how carriers allocate addresses. A site running several devices on cellular links typically activates them together, on one account, from one batch of SIMs, and the carrier assigns addresses from a contiguous pool. The devices then hold those addresses, because the sticky-allocation behavior documented elsewhere in this report applies to them as it does to single devices. Adjacency is therefore a byproduct of procurement and provisioning, not a coincidence.

The service fingerprints support the reading. In the 19-host Alpharetta run, every host presents the same web server, the same scripting runtime and the same three open ports. In the 11-host Sunnyvale run, 9 of eleven are Sierra Wireless AirLink gateways answering on identical ports. In the 10-host run at 63.46.41.170 to 179, all 10 are indistinguishable in their service profile. Devices belonging to unrelated organizations do not converge on identical fingerprints while also occupying consecutive addresses.

Where the Heuristic Fails

The heuristic fails in both directions, and the two errors do not cancel. 

• It merges too aggressively where a carrier pool hands consecutive addresses to unrelated subscribers who activated at the same time, which is plausible for a regional integrator selling to several small utilities in one week. 
• It merges too little where one site holds devices on non-adjacent addresses, across a /24 boundary, or across two carriers, all of which appear in the sample and are counted as separate installations. The second error is the more common of the two in the data observed, which makes the 1.52 figure a conservative estimate of the true collapse.

Two further caveats bound the result. The sample was drawn from paged search results and not randomly, and adjacent addresses tend to appear together in paged output, so large groupings may be over-represented. And the rule cannot distinguish a site with five controllers from a site with one controller and four gateways, because both present as five hosts. The correction changes host counts into installation counts. It does not produce a device count.

Four Measurements, One Population

Figure 2. Published and collected counts of United States hosts identifying as Rockwell Automation / Allen-Bradley, with the software fingerprints of the matched hosts.

The Censys query is protocol-scoped and reads a structured identity field: EtherNet/IP anywhere, vendor name equals Rockwell Automation/Allen-Bradley. Our collection used Shodan’s free-text product string. Removing the port constraint from the Shodan query changed the result by seventeen hosts, from 1,610 to 1,593, so port scope does not explain the gap. What remains is scanner coverage and fingerprint parsing: a host returning a valid identity response that one engine maps to a product label and the other does not.

That has a consequence for a claim we would otherwise have made. Searching TCP/44818 in the United States returns 62,060 hosts, of which roughly 1,950 carry any product label in Shodan. The tempting conclusion is that 97% of the port is not industrial devices. The defensible conclusion is narrower: 97% carry no device label in that engine, and the Censys comparison suggests some of them are returning identity that Shodan is not surfacing. The port remains a poor proxy, and the vendor facet shows why, with 125 Socks proxies, 80 nginx servers, 23 OpenSSH daemons, ASUS routers, a QNAP appliance and a TRENDnet webcam sharing it. But the 97% figure describes one engine’s labelling, not the population.

The Exposed Host Is Usually a Modem

Censys publishes the software fingerprints of its matched hosts, and they do not describe controllers. Across 4,131 hosts, 968 run Sierra Wireless ACEmanager and 535 run Cradlepoint. Port facets agree: 536 on 9443 and 426 on 8443, which are gateway administrative interfaces.

Individual records make the mechanism explicit. A host on AT&T Mobility at Leesburg, Virginia fingerprints as Sierra Wireless ALEOS, runs ACEmanager on 9191 and 9443, and answers EtherNet/IP on 44818 with Allen-Bradley identity. The modem is the host. The controller is one hop behind it, reachable through a port forward.

This is the installation path the federal guidance identifies as undocumented and excluded from routine attack surface review, observed at national scale in a competitor’s published dataset. It also means a remediation instruction aimed at the controller may be aimed at the wrong device.

Four Device Classes Behind One Vendor Label

The sample contains at least four distinct things returning Rockwell identity:

• Cellular gateway: Dominate the population
• Panel HMIs: Red Lion Crimson on 789 and 790, C-more on 11102 and 10200, recurring across hundreds of hosts
• Bare controllers: Occasionally fingerprinted directly, with operating system strings such as “Rockwell Automation 1756-ENBT” and “1769-Lxxe”
• Miscellaneous devices: a Hikvision camera labelled CAMERA and IOT answering EtherNet/IP, a MikroTik router running Obvius AcquiSuite building automation software, a Cisco IOS device, and a power metering site running Ubiquiti UniFi Protect alongside Modbus, telnet, SSH and ten HTTP services on one public address

Honeypots Are Counted Unless You Remove Them

42 United States hosts in the Flare collection returned the EtherNet/IP serial number 0xdead1337. Every one reported the product string 1756-L61/B LOGIX5561. Every one reported its own address as 0.0.0.0. All sat on Microsoft Azure, Amazon Web Services, DigitalOcean or Cloudflare. A second cluster on serial 0x006c061a covered a further 15.

Controllers are installed at sites, and a serial number is unique to the device that carries it. 42 hosts sharing one serial on rented infrastructure is a honeypot fleet. Counting it as exposed infrastructure inflates the ControlLogix population by more than a third.

The Censys data confirms it from the other direction. Censys applies its own HONEYPOT label to Conpot hosts and includes them in the published total: Shadowserver infrastructure at San Jose, Azure hosts at Boydton, Phoenix and Amsterdam, Amazon hosts at Ashburn, Stockholm and Hong Kong, a HostPapa host at Dallas, and university and commercial hosts in Indonesia and Iran. Several answer EtherNet/IP on arbitrary ports, one across four ports at once, alongside DICOM, Bitcoin, OPC UA and Redis. The label is in the data. The exclusion is a one-line change that no published count makes.

Two Exclusion Rules

• Exclude hosts on cloud and hosting autonomous systems. Industrial controllers are installed at sites, not rented by the hour. This removed 83 hosts from the Flare population.
• Exclude any device serial appearing on eight or more unrelated hosts. Serial numbers are unique to a device, so repetition across netblocks indicates a template. This removed a further 11 not already caught.

What Is Actually There

After exclusions, 1,512 Rockwell controllers were reachable from the public internet in the US across the collection window.

Identified device families in the clean Flare population. MicroLogix 1400 and 1100 are the families named in the FBI and EPA public service announcement.

998 hosts fall in the two MicroLogix families named in the federal advisory, which is 66% of the identified estate. Adjusted for adjacency, that corresponds to roughly 650 distinct installations.

Figure 3. Density of internet-exposed Rockwell controllers across the contiguous United States. Positions are deliberately degraded: source coordinates are carrier and city centroids, each host is randomly displaced, and the surface is kernel-smoothed. No individual host, site or operator can be located from this image.

Half are Not Permanently Exposed

Two collections against the same query produced materially different counts. A point-in-time pull returned 1,512 clean hosts. A pull accumulated across a month returned 2,810.

The obvious explanation is carrier address churn, one device surfacing repeatedly on new addresses. The data rules that out. Using device serial number and model as a stable identity, only 28 of 2,623 distinct identities appeared on more than one address across the entire collection. The carriers are assigning these devices sticky addresses.

The devices are intermittently reachable, dropping off and returning as their links come and go. The daily population moves by roughly 1% between consecutive days. Censys itself recorded a decline from 3,891 US hosts in April to 2,945 in July, which could be remediation, could be duty cycle, and cannot be separated from a pair of snapshots.

This changes what “exposed” means for the sector. A controller reachable four days a week is no safer than one reachable seven, but it is harder to inventory, harder to scan for, and harder to confirm as remediated. An operator who checks once and finds nothing may have checked while the link was down.

A Class of Controller Invisible to Every Count

Every figure discussed so far comes from EtherNet/IP. Older Allen-Bradley controllers do not speak it.

The PLC-5 and SLC-5/05 families use Client Server Protocol on TCP/2222, which predates EtherNet/IP entirely. A collection on that port returned 41 United States hosts answering with CSPV4 and a session identifier. 34 of them appear nowhere in the EtherNet/IP dataset.

These are among the oldest programmable controllers still in industrial service. Water and wastewater systems run long equipment lifecycles, and a controller installed in the 1990s may still be operating a lift station today. Any survey of this sector scoped to the modern port undercounts the oldest and least defensible part of the estate, and every count in Figure 2 has this gap.

ATT&CK for ICS Mapping

The activity described in the federal reporting maps onto the ATT&CK for ICS matrix. Each technique below is tagged by whether this dataset evidences it directly or whether it rests on the federal and incident reporting.

Table 4. ATT&CK for ICS techniques. Dataset-evidenced techniques are supported by artifacts in this collection. External techniques rest on the CISA alert, the FBI and EPA public service announcement, and public incident reporting.

This sits in Initial Access and Impact, well away from Exploitation. There is no software vulnerability to patch and no exploit signature to fire on. Access is obtained because the device answers on the public internet, so the detections that earn their keep are authentication monitoring on the management plane and alerting on controller parameter and program changes.

Key Judgments

High Confidence: 

• Published host counts for this population overstate the number of distinct installations by approximately half. The 1.52 collapse held within 0.02 across samples of 330, 334 and 434 hosts, and 48% of hosts sit in a multi-host grouping.
• A substantial minority of hosts returning Rockwell identity are cellular gateways forwarding to a controller behind them, based on 968 ACEmanager and 535 Cradlepoint fingerprints across 4,131 matched hosts in Censys data.
• Published counts include honeypot infrastructure. Censys applies its own HONEYPOT label to hosts inside its reported total, and we identified 57 further decoy hosts by repeated serial number.

Moderate Confidence: 

• The true US population of distinct Rockwell installations reachable at any given moment is between 1,600 and 2,100. This rests on the Censys point-in-time count adjusted by the observed adjacency collapse, and the sampling for that adjustment was not random.
• A substantial share of these installations were placed by integrators and vendors and are absent from operator asset inventories. The carrier concentration, the gateway fingerprints, and the federal guidance on undocumented cellular modems all point this way, but ownership cannot be established from passive data.
• Point-in-time counts understate the population by roughly half because of intermittent reachability. Two collection windows differed by that margin and device identity analysis rules out address churn, but a longer observation period would be needed to establish the duty cycle.

Low Confidence: 

• Any estimate of how long these devices have been exposed. Banner history was not available to this collection, so first-observation dates could not be established and no claim is made about whether exposure predates the current activity.

What Security Teams Can Do This Week

For any water or wastewater operator, or any organization running Allen-Bradley controllers:

• Test your own address space for the device classes in this report before assuming the inventory is complete. The check costs nothing and does not depend on anyone else.
• Ask your integrators and vendors directly which cellular-connected devices they have installed on your sites and whether the administrative interfaces on those devices are reachable from the internet. A device the operator does not know about will not appear on an internally generated inventory.
• Check the gateway as well as the controller. If a modem is forwarding a port to a PLC, hardening the PLC alone leaves the path open, and the modem’s own administrative interface is frequently exposed on 9191, 9443, 8080 or 8443.
• Remove controllers from direct internet exposure and route operational remote access through a virtual private network or gateway device, with no direct path to the controller. Apply source address allowlisting where remote access must be retained.
• Confirm you hold a known clean backup of each controller image. Observed activity includes modification of controller passwords to lock out operators, and CISA directs that this confirmation follow disconnection.
• Check on more than one day. Intermittent reachability makes a single check unreliable, and finding nothing on one attempt does not confirm the estate is clean.
• Enumerate TCP/2222 separately if any part of the estate runs PLC-5 or SLC-5/05 equipment. The modern port scan will not find it.
• Look at what else is on the address. Across the matched population, 884 hosts expose VNC, 534 expose a database and 522 expose network file sharing. The controller is often not the only thing reachable at that site.

Methodology and Limitations

This analysis was produced entirely from passive sources. No active scanning, probing, authentication or exploitation was performed against any host referenced here, and no traffic was sent to any in-scope asset. Device identity comes from banner data already held in public search indices. Censys figures are as published by Censys ARC and were not re-derived.

The adjacency analysis is based on 434 United States hosts transcribed from paged Censys results between August 3-4 2026. Grouping merges addresses within eight of each other in the same /24. Sampling was not random, and because adjacent addresses tend to appear together in paged output, large groupings may be over-represented. The population figure is therefore stated as at least 1.4 rather than as a point estimate.

Organizations are not named, and no host is linked to any utility that reported an incident. That is a deliberate editorial choice. A correct match would point at infrastructure that may still be compromised, and an incorrect one would name an organization that was never attacked. Neither serves a defensive purpose in a published article.

Four further limits apply:

• The counts are floors. Devices behind carrier network address translation on private access point names are unreachable by any external collection method and do not appear here. Hosts that accept connections without returning an identity payload cannot be classified.
• Most hosts are not attributable to an operating organization. Carrier and provider allocations carry no sub-delegated registration data. A small minority sit on municipally registered autonomous systems and are attributable by WHOIS alone.
• Geolocation on mobile netblocks reflects carrier aggregation points and not device sites, so all geographic breakdowns in this report describe carrier infrastructure.
• Exposure is not vulnerability. Firmware revision, credential state and downstream process function were not established for any host, and no claim is made that any device is exploitable or controls anything consequential.

The headline counts are a triage signal and a lower bound. Nothing here should be read as a confirmed compromise without authenticated validation against asset inventory and device logs.

A Defensible Number, an Honest Method, and a Checklist for the Defenders Who Need Both

Exposure counts are not objective measurements. They are the product of decisions that are rarely stated: which search engine was queried, how that engine parses a device identity response, whether the count includes honeypots, whether adjacent addresses at one site are counted once or six times, whether the host being counted is the controller or the modem in front of it, and whether legacy protocols were enumerated at all. Each of those decisions moves the total, and together they move it further than the underlying exposure does across a whole quarter.

That has a practical consequence for anyone reading a figure in an advisory, a vendor blog or a news report. The useful question is not whether the number is right. It is which of these decisions the number reflects, and whether the same decisions were applied to the figure it is being compared against. A count that fell from 3,891 to 2,945 between April and July may describe remediation, or intermittent reachability, or a change in scanner coverage, and nothing in the number itself separates them.

The “red Fords” comparison is a useful way to think about all of this: the established narrative says every exposed device is a Rockwell controller, the way every red car is assumed to be a Ford. Rockwell devices are genuinely there, but so are Sierra Wireless modems, Cradlepoint gateways, Red Lion HMIs, honeypots, and a scanner’s best guess at a fingerprint, all wearing the same label. Treating the count as one thing when it’s several is exactly how a 2,945 becomes a 1,610 becomes a 1,512 without the underlying exposure moving at all.

The actionable takeaway isn’t about getting to a better published number, instead, it’s to stop looking at published counts altogether and check your own network instead. For anyone running this equipment, this report is effectively a checklist: test your own IP space rather than trusting someone else’s scan of it; ask your integrators and vendors what they’ve installed, since much of this exposure was placed by a third party and never made it into an internal inventory; check the gateway as well as the controller, since hardening one while leaving the other exposed solves nothing; check more than once, since roughly half these devices are not permanently reachable and a clean scan today says little about tomorrow; and don’t skip legacy protocols, a PLC-5 or SLC-5/05 running Client Server Protocol on TCP/2222 is invisible to every count in this report and most of the scans being run today.