Tags:

AI Just Lowered the Bar for PLC Attacks

Alright, mi gente, let’s talk about this one without the sci-fi.

On August 19, 2026, NSA, CISA, FBI, DOE, and EPA dropped a joint advisory AA26-231A warning that threat actors are actively hunting internet-exposed Siemens S7 PLCs. Not a rumor. Not a tabletop. Reconnaissance and capability development, right now, against U.S. plants.

And here’s the part that should make plant engineers and OT security sit up together: they didn’t need a shiny new zero-day to do it.

They needed TCP 102 reachable from the wrong place, some public scanning services, a legitimate library a lot of us already use, and AI to write the scripts faster than a junior engineer can Google S7comm.

That’s not Hollywood. That’s an accelerant on a problem we’ve known about for years.

What’s actually happening

The agencies say the pattern looks like this.

First, actors use internet scanning services, the advisory names Censys and ZoomEye, to find Siemens S7 controllers that are sitting on the public internet or poorly segmented from it. If your PLC answers on S7comm (typically TCP port 102), it is findable. Fácil.

Then they use AI assistance to generate exploitation and recon scripts from public documentation and open-source industrial libraries. Specifically snap7.dll and python-snap7. Those are not malware. Snap7 is a legitimate engineering library. The abuse is the point: they wrap it in Python, dress the scripts up as OT monitoring tools, and start talking to your controller like they belong there.

What they get: read/write access to memory, configuration data, and ladder logic.

What the agencies assess it as: pre-positioning. Map the plant. Test techniques against specific CPU models. Get ready for effects later, process disruption, safety interlock tampering, equipment damage, stolen recipes, the ugly list.

No named APT. No victim count. No “first AI ICS superweapon.” Just an unattributed, active campaign against exposed gear.

Who should care (hint: not only Siemens shops)

This hits the whole S7 family:

  • S7-200 — all CPU variants
  • S7-300 — all, including 314, 315, 317
  • S7-400 — all
  • S7-1200 — 1211C through 1217C
  • S7-1500 — all, including F-series safety controllers

If that last one didn’t make you pause, read it again. Safety CPUs.

Sectors the agencies say are most targeted: Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, Commercial Facilities. Defense industrial base is in the “could be next” column.

And mira, the advisory is explicit: PLC targeting is broader than Siemens. If you run anyone else’s controllers that still answer from the internet, this is your homework too. Same class of weakness we’ve already seen produce real incidents — internet-exposed controllers plus weak or default authentication. The Unitronics water-sector mess in 2023 was that movie. This is that movie with a faster screenwriter.

This is not a patch Tuesday story

I need you to hear this clearly, familia.

AA26-231A is not a single CVE. There is no one firmware flash that “closes” the advisory. The agencies point at known vulnerabilities, weak or default authentication, and devices that should never have been reachable from untrusted networks.

On classic S7-300/400, S7comm authentication is weak or missing. Network reachability is the boundary. On newer S7-1200/1500, S7comm+ is better, challenge-response, integrity, and still not a substitute for segmentation if firmware is old, PUT/GET is left open, or an integrator left a cellular modem sitting on a public IP.

We’ve known S7 was fragile if you could talk to it for over a decade. Specialized protocol knowledge used to be the brake. AI just made that brake softer. The attack is still: find the exposed box, speak the protocol, read, then write.

So the fix is not “buy an AI defender.” The fix is pull the controller off the internet, lock who can talk S7comm, then patch and hunt.

The integrator blind spot

This part is easy to skip and expensive to skip.

The agencies specifically flag third-party service providers and system integrators who may have remote access you don’t realize is exposing you. Cellular modems. Vendor VPNs. Hosted jump boxes. Address space that isn’t even in your ASN.

You can have a beautiful OT firewall diagram and still have an S7 reachable through a contractor’s SIM card.

If you do one uncomfortable thing this week, call your integrators and ask, por favor: is any of our S7 reachable from a public IP, a cellular modem, or a vendor jump host? Get it in writing.

CISA’s Primary Mitigations to Reduce Cyber Threats to Operational Technology says the same thing: talk to the people who installed the gear.

Monday-morning checklist

Not next quarter. Monday.

Hour 0–1 — Stop the bleeding

  • Ask networking: any ACL or NAT letting TCP 102 in from outside the OT zone, or from the internet?
  • Block TCP 102 at the perimeter. The advisory says block it entirely at perimeter firewalls. Do that.
  • Search Censys, ZoomEye, Shodan — and CISA’s Stuff off Search workflow — for your public IPs and your integrators’. Flag anything that looks like S7 or OT.
  • Call the integrator/MSP. Cellular, vendor VPN, hosted jump box: yes or no.

Hour 1–3 — Inventory

  • Every S7-200/300/400/1200/1500, including F-series. Firmware. Plant/area. Who can program it.
  • Every host with TIA Portal, STEP 7, or WinCC engineering access.
  • Anything in a DMZ or sitting next to the internet — those get patched and hardened first.

Same day — Access and config

  • Enable PLC passwords. Set protection levels stricter than “full access.”
  • On 1200/1500: review PUT/GET. Disable it if operations don’t need it.
  • Kill unused web servers. Kill unused protocols (Modbus TCP, PROFINET if you’re not using them).
  • Change default SNMP community strings. Still. In 2026.
  • Allowlist engineering stations by MAC/IP. MFA on every remote path into OT.

Same week — Detect and patch

  • Baseline who is allowed to speak S7comm. Alert on non-engineering hosts. Alert on Python or PowerShell opening port 102.
  • Hunt snap7.dll and python-snap7 on machines that aren’t approved engineering stations. Hunt mystery “OT monitoring” tools.
  • Alert on PUT/GET writes and ladder/config changes outside change windows. Off-hours S7comm is not “the night shift being productive.”
  • Check Siemens ProductCERT for your CPU and firmware. Test updates in non-prod. Update TIA Portal and STEP 7 too.
  • If you need model-specific help: productcert@siemens.com or Siemens Industrial Cybersecurity Services at services.automation@siemens.com.

Ongoing — Don’t get cute

  • Practice running the process manually. That’s Primary Mitigations #5, and it’s the one people skip until they can’t.
  • Offline backups of logic and gold-image firmware. Not on the same network as the PLC.
  • Send AA26-231A to every integrator and require written confirmation they applied the mitigations.

Final thought

AI didn’t invent the exposed PLC problem. It just made it cheaper to exploit.

If your Siemens S7, or any other controller, is reachable from the internet, weakly authenticated, and speaking S7comm to whoever knocks on 102, you are not waiting for a clever adversary. You are waiting for a script.

Pull it off the public internet. Lock who can talk to it. Then patch, hunt, and sleep a little better.

Stay sharp, mi gente.
Secure the basics.
Because in OT, the basics are still what keep the process running.

Gracias for reading.

Source: CISA/NSA/FBI/DOE/EPA, Defending Against an Active Threat to Siemens S7 Series PLCs (AA26-231A), August 19, 2026.

Leave a comment