How Generative AI Is Accelerating the OT Attacker

Introduction

For years, operational technology has presented attackers with a difficult barrier: understanding the process.

Compromising a conventional IT system may require knowledge of operating systems, applications, identities and networks. Moving into an industrial environment adds another layer. An attacker may need to understand programmable logic controllers (PLCs), engineering software, industrial protocols, controller memory, process logic, maintenance practices and the physical equipment being controlled.

That barrier has not disappeared, but the growing use of generative AI in OT security threats may be helping attackers cross parts of it much faster.

In August 2026, the NSA, CISA, FBI, Department of Energy and Environmental Protection Agency issued a joint cybersecurity advisory warning owners and operators of industrial control systems of an active cyber threat targeting Siemens S7 Series PLCs. The agencies reported that threat actors were conducting reconnaissance and capability development against U.S.-based Siemens PLC installations using AI-generated exploitation scripts disguised as legitimate monitoring tools.

The advisory is significant because the activity is not theoretical. The agencies describe active targeting of Internet-exposed or poorly protected PLCs across sectors including Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, and Commercial Facilities.

The concern is not that generative AI suddenly turns an inexperienced attacker into a control engineer. It is that AI can accelerate how attackers acquire, apply and operationalise OT knowledge.

 

OT Has Always Had a High Knowledge Barrier

PLCs are not simply industrial versions of normal servers. They execute control logic that interacts directly with physical processes. Depending on the environment, a controller may be responsible for operating pumps, opening valves, controlling motors, regulating pressure or temperature, sequencing manufacturing equipment or supporting safety-related functions.

An attacker therefore needs more than network access. They may need to understand:

• What controller family is deployed
• Which protocol is used to communicate with it
• Which engineering systems are authorised to modify it
• How process data is organised
• What normal communication looks like
• Which operations are expected
• What physical process could be affected by a change

Acquiring that knowledge traditionally takes time. Industrial documentation can be extensive, PLC architectures differ between vendors and product generations, and engineering terminology may be unfamiliar to attackers coming from conventional IT environments.

Generative AI does not remove that complexity, but it can reduce the time required to begin working through it.

What the Current S7 Activity Actually Looks Like

The advisory provides a useful example of how AI-assisted attack development can connect with real industrial technology.

Threat actors are using Internet scanning services to identify Internet-exposed or insufficiently segmented Siemens S7 PLCs. They are then rapidly iterating exploitation code with AI assistance and taking advantage of devices with weak, default or minimally configured authentication.

According to the advisory, attackers are also combining AI-assisted scripting with the open-source snap7.dll and python-snap7 industrial automation libraries. The resulting custom tools can mimic legitimate OT monitoring solutions while providing read/write access to Siemens PLC memory, configuration data and ladder logic through the S7comm protocol.

That creates a much more concrete attack-development chain:

Internet scanning → exposed PLC → AI-assisted script development → S7comm interaction → PLC read/write capability

The individual building blocks already existed: Internet scanning services, publicly documented PLC vulnerabilities, open-source industrial libraries and Python-based automation tooling. What is changing is the speed at which an attacker can understand those components, connect them and adapt them to a specific target.

AI is not creating the attack surface. It is reducing the friction involved in exploiting it.

 

What AI Is Actually Accelerating

The advisory explicitly describes AI-assisted exploitation as an evolution in threat actor capability because it reduces both the technical expertise and the time required to develop working ICS exploitation scripts and malicious tools. It also notes that AI can help adversaries rapidly leverage additional attack vectors and adapt to defensive measures.

Generative AI can potentially help an attacker:

• Interpret unfamiliar PLC documentation
• Understand industrial terminology
• Explain protocol behaviour
• Summarise published vulnerabilities
• Identify relevant open-source libraries
• Generate scripting boilerplate
• Adapt existing code
• Troubleshoot implementation errors
• Translate concepts between programming languages
• Connect information from multiple public sources

None of these capabilities needs to be perfect to provide value. An attacker may use AI to shorten the time required to understand an unfamiliar protocol operation, troubleshoot code without manually working through extensive documentation, or gain enough understanding of a Siemens PLC family to begin experimentation.

The attacker does not necessarily need AI to discover something new.

AI can make existing knowledge easier and faster to operationalise.

 

From Reconnaissance to Capability Development

One of the more important details in the advisory is that the observed activity is not limited to immediate attempts at disruption.

The agencies assess that the actors are conducting persistent reconnaissance and testing exploitation techniques against specific PLC models in order to improve their ability to compromise them.

They also assess that read access is being used to understand target environments and potentially position attackers for future write operations that could cause disruption or other operational effects.

That distinction matters. A PLC read operation may not immediately change the physical process, but it can provide information that supports later activity.

An attacker may learn:

• How data blocks are organised
• Which values are changing
• What configuration information is available
• How the controller responds to particular requests
• Which logic or memory areas may be operationally important

The attack path can therefore develop gradually:

Generative AI can accelerate several of those stages without ever needing to fully understand the physical process on behalf of the attacker.

From Cyber Access to Physical Process

This is where OT differs fundamentally from a conventional enterprise environment. A compromised PLC is not simply another compromised endpoint. The controller may influence physical equipment and processes.

The advisory warns that unauthorised PLC access could result in disruption of industrial processes, safety incidents, equipment damage, extended downtime, compromise of sensitive operational data and cascading impacts across interconnected systems.

A malicious sequence can therefore move through a chain such as:

That is why OT expertise still matters. AI can help an attacker understand S7comm, generate a script or explain PLC memory structures. But it does not automatically tell the attacker what changing a particular value will do to a real production process.

Industrial systems contain dependencies. A pump may depend on a valve state, a process parameter may interact with another control loop, and a controller may participate in sequencing across multiple pieces of equipment. Safety systems may also operate separately from normal process control.

The physical environment therefore remains a major knowledge barrier. But an attacker may not need complete understanding to conduct reconnaissance, test capabilities or prepare for later activity.

Legitimate Industrial Actions Can Still Be Dangerous

Another challenge is that the tools and operations involved may not look obviously malicious.

python-snap7, for example, is an industrial automation library. S7comm is a legitimate industrial protocol. Engineering workstations are expected to communicate with PLCs, and engineers legitimately read data blocks, modify configurations and update controller programs.

The problem is therefore not always the command itself.

It is the operational context.

Consider a write operation to a PLC. During an approved maintenance window, initiated by an authorised engineer from the expected engineering workstation, the activity may be normal.

The same operation has a very different security meaning when it:

• Comes from a non-engineering workstation
• Occurs outside an approved change window
• Uses an unexpected account
• Has no associated work order
• Targets an unusual data block
• Follows automated reconnaissance
• Changes ladder logic without an approved engineering activity

The protocol, library and command can all be technically legitimate while the behaviour itself is malicious.

In OT, context changes meaning.

 

The Engineering Context Makes Detection Hard

Engineering workstations are particularly important because they already contain the software and privileges needed to configure industrial equipment.

If an attacker compromises one, they may be able to interact with PLCs through trusted applications, approved network paths and legitimate industrial protocols. The suspicious behaviour may therefore not be a single event, but a sequence:

Every individual action may look plausible in isolation. The anomaly appears when the events are correlated.

This is why industrial detection cannot rely only on whether a particular command exists. Defenders need to know who normally performs it, from where, against which controller and under what operational conditions.

What Defenders Should Actually Look For

The advisory provides several concrete detection opportunities.

It recommends hunting for anomalous S7comm behaviour, including connections from non-engineering workstations, unusual data-block access and write operations outside approved change windows.

It also highlights sequential scanning on TCP port 102, repeated PLC connection attempts, unexpected snap7.dll usage, Python scripts with S7comm functionality, off-hours activity, automated connection patterns and configuration changes without corresponding work orders or change tickets.

That means defenders can look for relationships such as:

Unexpected source → S7comm → unusual PLC → unusual operation

Off-hours activity → engineering account → PLC write → no change ticket

Sequential TCP/102 scanning → PLC enumeration → repeated S7comm access → data-block reads

No single event necessarily proves malicious activity, but several weak signals can combine into a much stronger detection.

This is where context becomes more useful than a simple indicator.

The defensive question is increasingly not only:

“Have we seen this script before?”

but:

“Does this behaviour make sense in this industrial environment?”

 

Why Signature-Based Detection Is Not Enough

AI-assisted development also puts additional pressure on detection strategies that depend heavily on known malware, file hashes or static signatures.

Attackers can rapidly modify scripts, generate new implementations and use legitimate libraries while still performing the same industrial operations. Two scripts may look completely different while issuing similar commands to the same PLC.

That makes behavioural analysis increasingly important.

A defender may never have seen a particular Python script before, but the network and operational behaviour could still be suspicious:

New workstation → TCP/102 → critical PLC → repeated data-block reads → write operation

The script is unknown. The behaviour is not.

 

What Generative AI Means for OT Security

AI-assisted exploitation does not make established OT security controls obsolete. It makes them more important.

The advisory recommends inventorying Siemens S7 PLCs, verifying firmware versions, identifying systems accessible from untrusted networks, mapping engineering workstations and applying critical security updates. It also recommends ensuring PLCs are not directly accessible from the Internet, auditing S7comm exposure on TCP port 102, separating IT and OT networks, restricting engineering access and strengthening authentication.

Monitoring provides another layer. Organisations should monitor S7comm activity, alert on unauthorised PUT/GET operations, log engineering connections, establish baselines for legitimate behaviour, monitor for unexpected snap7.dll usage and watch for ladder logic changes.

Together, these controls create a broader defensive model:

The final step is critical. OT environments generate large amounts of telemetry, and not every unusual event is malicious. Maintenance happens, engineers troubleshoot, production conditions change and systems are upgraded.

What defenders need is enough context to determine whether an event represents normal operational variation or genuine security risk

The OT Attacker Is Getting Faster

The current Siemens S7 activity should not be interpreted as evidence that generative AI has made industrial systems easy to compromise.

OT environments remain technically complex, and successful attacks still depend on access, vulnerable or poorly protected systems, target knowledge and some understanding of the industrial environment.

What is changing is the amount of friction involved in developing that capability.

Known vulnerabilities, public documentation, open-source industrial automation libraries and Internet-scanning infrastructure already exist. Generative AI can help attackers connect those pieces, understand them and adapt them more quickly.

The advisory summarises the risk clearly: the combination of known vulnerabilities, accessible exploitation libraries and AI-assisted development creates a high-probability attack scenario against inadequately protected PLC installations.

Generative AI may not make OT attacks easy. But it can make difficult attack-development tasks significantly faster.

 

Conclusion

While OT systems remain difficult to compromise effectively, the current Siemens S7 activity provides evidence that generative AI is beginning to reduce some of the technical friction traditionally associated with industrial attack development.

For defenders, the implication is clear: detection cannot rely entirely on known scripts, signatures or previously observed tools. OT security increasingly depends on understanding behaviour in context — who is interacting with industrial equipment, from where, using which technology, whether that activity is expected and what it could mean for the physical process.

Logstail brings together monitoring, SIEM correlation, asset and vulnerability context, case management, SOAR playbooks, EASM, and governance workflows across the incident lifecycle.

This helps organisations identify activity that begins in IT, understand how it may affect OT, prioritise incidents according to operational impact, and coordinate response without applying unsafe IT actions to industrial systems.

Through AICOT,  coordinated and developed by Logstail, this foundation is strengthened with AI-driven OT monitoring, risk prioritisation, and context-aware response capabilities for critical infrastructure environments.

Follow the project on LinkedIn and X for project updates and practical insights into AI-driven OT cybersecurity.

The AICOT project has received funding from the European Union’s Digital Europe Programme under Grant Agreement No. 101249826. Views and opinions expressed are those of the authors and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre.

Contact Our Experts  or Sign Up for Free