- › An August 3 Forescout scan counted 4,407 internet-facing Rockwell controllers worldwide, 2,844 of them in the United States.
- › Twenty-two sit in cities hit by the water utility attacks, and nineteen of those reach the internet over the same mobile carrier network.
- › The attackers did not exploit the 2017 buffer overflow those devices were vulnerable to. They changed IP addresses and set passwords on controllers that had none.
- › Setting a password on an unauthenticated controller locks the operator out of their own equipment, which is a denial of control rather than a data breach.
- › The exposure is usually a cellular modem somebody installed for remote support, not a firewall rule anyone deliberately wrote.
Picture a grey steel cabinet on a concrete pad, out past the treatment basins where the gravel road ends. No fence around it. Inside is a programmable logic controller (PLC) the size of a paperback that opens and closes a valve. It was installed in 2009, it has run without complaint ever since, and the last person who understood its configuration retired in 2019.
That cabinet has a cellular modem in it. Somebody added it around 2016 so the on-call tech would not have to drive out at 2am.
Forescout scanned for devices like it on August 3 and counted 4,407 internet-facing Rockwell Automation controllers worldwide, 2,844 of them in the United States. Twenty-two are in cities that got hit in the recent wave of water utility attacks. Nineteen of those twenty-two reach the internet over the same mobile carrier network.
They Skipped the Nine-Year-Old Vulnerability
Nineteen of those twenty-two controllers ran firmware vulnerable to CVE-2017-16740, a Modbus TCP buffer overflow scoring 8.6. A nine-year-old flaw, unpatched, sitting on the public internet, in equipment that moves drinking water.
The attackers did not use it.
They changed the IP addresses and set passwords on controllers that did not have one. That is the whole technique. They found equipment that answers anyone who asks, and they put a lock on it.
The plant did not lose data. It lost control. Operators could no longer see or command their own equipment, and the fix is not a patch or a restore from backup. It is somebody driving to the cabinet with a laptop and a serial cable.
Why the 2017 Flaw Was the Less Attractive Option
Put yourself on the other side of this and do the arithmetic, because the choice they made was rational.
Using the buffer overflow requires knowing the exact firmware revision, building or adapting an exploit, and accepting that a memory corruption bug against a nine-year-old embedded target will sometimes just crash the device. A crashed controller is loud. It pages someone. It starts an investigation while you are still deciding what to do next.
Setting a password requires a protocol client that Rockwell publishes documentation for. It works on every device in that state regardless of firmware revision. It is quiet, it is reliable, and the effect is immediate and durable. There is no detection signature for a legitimate configuration command sent by someone who should not be sending it.
An adversary optimizing for effect per hour of work picks the second option every time. This is the same lesson as the Snowflake breaches, whose perpetrator pleaded guilty this week to intrusions touching 100 million people: no product vulnerability was involved there either, just valid credentials against tenants that had not enforced multi-factor authentication.
The industry spends its attention on the exploit and the adversary spends theirs on the access.
How the Cabinet Got Online
Nobody in your organization decided to put a controller on the internet. That is worth stating plainly, because the reflex when this lands is to look for the person who made a bad call, and there usually is not one.
The sequence repeats across small utilities, manufacturing plants, and building management systems.
An operator needs remote visibility on a remote asset. Running fiber to the site costs real money and the site is three miles out. A cellular modem costs a few hundred dollars and works the same afternoon. The modem gets a public IP from the carrier because that is the default on that data plan. The controller behind it speaks EtherNet/IP on port 44818, which is an unauthenticated protocol that will identify the device and, depending on configuration, accept writes to it.
Nobody configured an exposure. Somebody solved a maintenance problem, and the exposure was the default state of the equipment they used to solve it.
That is why nineteen of twenty-two shared a carrier. It was not a coordinated targeting decision. It was a scan of one carrier’s address space finding the devices that answer.
What to Do About It
The work here is inventory and network placement. There is no product to buy that fixes an unauthenticated protocol on a device that cannot run an agent.
Find out what you actually have exposed
Search for your own public IP ranges and any cellular accounts your organization pays for, then check port 44818 and the other common industrial ports. Most organizations discover assets they did not know were reachable, and every one of them was installed for a defensible reason by somebody solving a real problem.
Get your PLCs off public addressing
Move remote sites behind a private access point name from your carrier, or a virtual private network (VPN), so the controller is reachable from your network and nowhere else. This is a call to your carrier’s account team and a configuration change, not a capital project, and it removes the entire class of attack.
Put authentication on the cellular modem itself
The modem is a networked device with a management interface and, in a lot of deployments, still has its shipping credentials. It is the hop everyone forgets because it is not on anyone’s asset list.
Keep current offline copies of your controller logic
If somebody sets a password on a controller you own, restoring it means reloading the program. Confirm you have the current logic file for every controller, stored somewhere that does not depend on the network the controller is on. Test that somebody who is not the retired engineer can actually load it.
Decide who owns operational technology in your organization
This is the finding underneath all the others. In most companies the information technology team does not touch plant equipment and the operations team does not do network security, so the cabinet in the field belongs to nobody. Assign it before the incident, because during one is a poor time to discover the ownership gap.
What This Costs Against What It Prevents
A private access point name and a VPN configuration for a remote site is a modest recurring line item and a day of engineering. Getting controller logic files backed up and tested is a week of somebody’s attention.
Against that, price a plant that cannot see or command its own equipment, with the recovery requiring a truck roll to every affected cabinet, while a regulator and a local newspaper both ask what happened to the water. The numbers are not close, and they were not close before this week either.
Go look up your own public address space. The scan takes an afternoon and you will not like what it finds, which is the point of running it.
Want a clear picture of where your organization’s physical and network exposure overlap? Take our free Human Attack Surface Score assessment, or contact us for a full risk assessment.
Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.
View Author Page →
