Now I have comprehensive information on this threat. Let me provide my analysis to the panel.
Halil, this is exactly the kind of nightmare scenario that keeps me awake at night. I've reviewed the CISA advisory AA26-097A and the supporting intelligence. Let me break this down into the four areas you asked about:
1. EtherNet/IP Exploitation Path — The Brutal Reality
Here's the thing about EtherNet/IP — it's incredibly fragile when exposed to the internet. The protocol was never designed for internet-facing deployments. It was designed for trusted Level 1 shop floor networks. When Censys and CISA talk about 3,891 exposed devices, they're talking about controllers listening on TCP/44818 with no authentication gates.
The specific weakness here isn't even a vulnerability per se — it's CVE-2021-22681, an authentication bypass that allows an unauthenticated attacker to spoof the engineering workstation identity. CVSS 10.0. Rockwell disclosed this in 2021, but there's a critical point: there is no patch. The vulnerability exists in the fundamental authentication architecture. Rockwell's mitigations are all compensating controls — CIP Security, physical key switches, network segmentation.
Look, I've personally seen SCARA robots move when they shouldn't. That's EtherNet/IP carrying a malformed CIP message. The protocol is stateless for most operations, session management is minimal, and the controller trusts anything on the same broadcast domain. If these PLCs are sitting on cellular modems with public IPs, as the advisory says 66% of them are, the attacker doesn't need an exploit. Studio 5000 connects natively. They just... connect.
2. Blast Radius of Project File Manipulation — Physical Consequences
Forget data theft. If an attacker extracts a .ACD file and modifies ladder logic, we are talking about potential kinetic effects. In my experience, here's what compromised project files enable:
First, HMI/SCADA manipulation means operators see false process values while the physical system operates differently. At a water treatment plant, this could mean operators think chlorine levels are normal while actual levels are dangerous. At a gas compressor station, pressure readings could be falsified, masking an overpressure condition.
Second, modified ladder logic can disable safety interlocks. I've seen safety instrumented systems (SIS) that share network segments with BPCS controllers — bad practice, but common. If this campaign escalates to SIS manipulation, we have a TRITON-level scenario.
Third, the wiper component. The advisory mentions attempted wiper malware deployment. I need to correct something in the briefing — the Stryker attack wiped 80,000 devices (correction from the 200K initially reported), but that was Microsoft Intune abuse in an IT environment. Different attack chain. The concern here is that these same actors are trying to deploy wipers to PLCs. A bricked PLC means manual operation. At a water pumping station, that's crews driving to sites with hand tools. At scale, it's a public health emergency.
3. Immediate Defensive Steps — The Cold Truth About Maintenance Windows
"Disconnect from the internet" is easy to say and operationally impossible for many sites. I've worked at utilities where those PLCs are on cellular because the remote site has no other connectivity. The operators need remote visibility for 2 AM alarms. You can't just "turn off the internet."
Here's what actually works before your next maintenance window:
Physical key switches. Every CompactLogix and Micro850 has a physical mode switch. CISA says turn it to "Run" mode, which prevents remote programming operations. This is your emergency brake. I know sites where operators keep these in "Remote Program" for convenience. That ends now.
CIP Security. For newer controllers that support it, enable TLS encryption and certificate-based authentication. This mitigates CVE-2021-22681. But let me be realistic — legacy installations can't do this. The controller firmware is 10 years old.
Firewall rules that actually work. Block TCP/44818, TCP/2222 (Dropbear SSH), TCP/102 (S7), TCP/22, and TCP/502 (Modbus) at your edge. If your PLC needs cellular, put it behind a firewall with IP allowlisting to your SCADA master only. No internet browsing from the HMIs.
Offline backups. Extract your .ACD files today, verify them on a sandboxed engineering station, write them to write-protected media, and store them in a physical safe. If your PLC gets wiped, you reload from known-good backups. Test the restore procedure — I've seen backups that were corrupt and nobody knew until disaster struck.
4. Detection Signatures and Behavioral Indicators
This is where I need to flag a concern. These attackers are using legitimate engineering tools. Studio 5000 traffic looks like... Studio 5000 traffic. Traditional IDS signatures won't catch this.
But there are telltales:
Network indicators from CISA AA26-097A:
- Malicious IPs: 185.82.73.165, 135.136.1.133, 185.82.73.167
- Ports: 44818 (EtherNet/IP), 2222 (Dropbear SSH), 102 (S7), 22 (SSH), 502 (Modbus)
- Overseas hosting provider traffic to your OT subnets should be instantly suspicious
Behavioral indicators:
- Upload operations outside maintenance windows. Normal operations don't extract .ACD files at 2 AM on weekends.
- Changes to PLC mode from Run to Program or Remote Program
- New engineering workstation connections from unexpected IP ranges
- Dropbear SSH installations on PLCs or adjacent Windows systems
What to look for in logs:
Studio 5000 operations generate CIP "Connected Send" messages with specific service codes. A download operation uses CIP service 0x4C (Set_Attribute_All). Uploads use 0x01 (Get_Attribute_All). If your network monitoring sees these from unusual sources, investigate.
James, I'd like to get your take on something. The advisory mentions Dropbear SSH for persistence — that's unusual for OT environments. Have you seen similar persistence mechanisms in state-sponsored ICS campaigns, and what's the best way to detect rogue SSH daemons on Windows engineering workstations?