Listen to this Post
A Threat Moving From Reconnaissance Toward Real-World Disruption
Industrial control systems rarely make headlines until something goes wrong. A compromised office computer can be rebuilt. A disrupted PLC controlling a water-treatment process, manufacturing line, chemical system, or energy facility is a very different problem.
That is why a new joint warning from U.S. federal agencies deserves serious attention. The advisory describes an active campaign targeting Siemens S7-series programmable logic controllers (PLCs) and warns that attackers are using Internet scanning, legitimate industrial automation libraries, and AI-assisted scripting to identify and study exposed systems.
The agencies behind the warning include the Cybersecurity and Infrastructure Security Agency (CISA), NSA, FBI, Department of Energy, and Environmental Protection Agency. Their message is unusually direct: organizations operating exposed Siemens PLCs should not treat this as a theoretical vulnerability.
The danger is not necessarily that attackers have already demonstrated widespread destructive control. The more important concern is that they appear to be learning the environment first.
That distinction matters.
An attacker who quietly identifies PLCs, determines their models, studies configurations, tests read operations, and develops customized tooling may be preparing for something considerably more disruptive later.
What the Joint Advisory Says
The advisory, identified as AA26-231A, covers Siemens S7-series PLCs across a broad range of generations, including older S7-200 systems and newer S7-1500 F-series safety controllers.
These devices are deeply embedded in industrial environments around the world.
They can control machinery, production processes, pumps, valves, sensors, safety functions, and other physical operations.
The advisory identifies several sectors as particularly exposed, including Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, Commercial Facilities, and the Defense Industrial Base.
That breadth is important because the threat is not limited to one type of industrial organization.
This Is Not Just Another Internet Scan
One of the strongest warnings in the advisory concerns the attackers’ behavior.
The agencies say threat actors are conducting reconnaissance and capability development against U.S.-based Siemens PLC installations.
In other words, they appear to be trying to understand what is out there before attempting more serious operations.
The campaign reportedly uses Internet scanning services such as Censys and ZoomEye to identify systems that can be reached from the public Internet.
Once potential targets are discovered, attackers can investigate whether the PLC responds to S7comm communications and determine what information can be retrieved.
That creates a dangerous progression:
Find the PLC → identify the model → communicate with it → read information → understand the environment → develop tooling → potentially move toward manipulation.
The final step is what defenders are trying to prevent.
AI Is Lowering the Barrier to Industrial Attacks
The most concerning element of the campaign is the reported use of AI-generated exploitation scripts.
Industrial cybersecurity traditionally required specialized knowledge. Attackers needed to understand PLC protocols, engineering software, controller architectures, and the peculiarities of industrial environments.
AI changes the economics of that process.
An attacker who knows what protocol to target can potentially use AI to accelerate the creation or modification of scripts, automate repetitive tasks, translate technical documentation into usable instructions, and adjust tooling as new information is discovered.
The important point is not that AI magically breaks Siemens PLC security.
It does not.
The bigger issue is that AI can compress the amount of time and expertise required to turn publicly available information into operational tooling.
That could allow relatively capable attackers to move faster than defenders expect.
Legitimate Industrial Libraries Become Part of the Problem
The campaign reportedly uses open-source components including snap7.dll and python-snap7.
These are not inherently malicious tools.
They are legitimate software libraries designed to allow applications to communicate with Siemens S7 PLCs.
That creates an uncomfortable security problem.
Security teams often rely on malware signatures, suspicious executable names, and known malicious software families to detect attacks.
But what happens when the attacker uses a legitimate industrial communication library?
The software may look completely normal.
The behavior is what becomes suspicious.
A Python process loading a PLC communication library on an engineering workstation might be perfectly legitimate during maintenance.
The same behavior on a workstation that has no reason to communicate with industrial controllers could be a major warning sign.
TCP Port 102 Is a Critical Piece of the Puzzle
Siemens S7 communications commonly rely on S7comm over TCP port 102.
That makes port 102 particularly important for defenders.
A PLC exposed directly to the Internet creates a fundamentally different risk profile from one isolated behind properly configured industrial firewalls and segmentation.
An exposed service can be discovered by automated Internet scanners.
Once discovered, it can potentially become part of an attacker’s target inventory.
For that reason, organizations should know exactly which systems expose TCP 102, why they expose it, and whether that exposure is actually necessary.
Read Operations Can Be a Warning Sign
Perhaps the most important behavioral detail is that the reported activity includes read operations.
At first glance, reading PLC information may seem harmless.
It is not necessarily harmless.
A read operation can help an attacker understand the target without immediately changing physical processes.
The attacker can learn about controller configuration, memory areas, programs, and potentially the logic governing an industrial process.
This creates a reconnaissance advantage.
The attacker does not have to flip a switch on day one.
They can spend days or weeks learning how the system works.
Why Pre-Positioning Is So Dangerous
The
Pre-positioning means an attacker is effectively preparing the battlefield.
Instead of immediately causing disruption, the attacker learns which systems exist, which ones are vulnerable, what technology they use, and what techniques work against them.
That approach can make a future attack substantially more effective.
Imagine discovering an intrusion only after an attacker already understands the PLC architecture, knows the relevant CPU model, has tested communication methods, and has developed customized scripts.
At that point, defenders are no longer dealing with a generic Internet attack.
They are dealing with an adversary that has already studied the environment.
The Physical World Changes the Risk Calculation
IT attacks often involve data theft, account compromise, or service outages.
OT attacks can cross the boundary from digital systems into physical processes.
A PLC may control something that moves, heats, pumps, mixes, opens, closes, shuts down, or continues operating.
That creates a unique risk.
Manipulation of industrial logic could potentially interfere with safety mechanisms, production processes, equipment behavior, or emergency procedures.
The consequences could include operational downtime, equipment damage, environmental impact, or safety incidents.
This is why industrial cybersecurity cannot be treated as simply another branch of traditional endpoint security.
Safety Controllers Deserve Special Attention
The
Safety systems exist to reduce the consequences of dangerous conditions.
Their role can include emergency shutdown functions, interlocks, and other protective mechanisms.
Organizations therefore need to understand not just whether a PLC is reachable, but what that PLC actually controls.
A vulnerable device controlling a test bench is not equivalent to a vulnerable controller sitting inside a critical production process.
Risk depends heavily on operational context.
Third-Party Remote Access Creates a Hidden Exposure
One of the easiest security gaps to overlook exists outside the organization itself.
Industrial facilities frequently depend on system integrators, equipment manufacturers, managed service providers, and engineering contractors.
Those partners may require remote access to PLCs for maintenance and troubleshooting.
Over time, temporary remote access can become permanent.
Credentials can remain active.
Firewall rules can remain open.
VPN configurations can be forgotten.
And nobody may realize that a controller is still reachable from an external network.
This is why the
Inventory Comes Before Everything Else
The first question defenders should ask is simple:
Where are all our Siemens PLCs?
Not where they are supposed to be.
Where are they actually connected?
Organizations should identify:
Siemens PLC models
Firmware versions
IP addresses
Network zones
Internet exposure
TCP 102 exposure
Remote-access pathways
Engineering workstations
Third-party connections
PLCs controlling safety-critical processes
Authentication and protection settings
Without accurate inventory, patching becomes a guessing game.
Internet-Exposed Controllers Should Move to the Front of the Queue
If a Siemens PLC is directly exposed to the public Internet, it deserves immediate attention.
That does not necessarily mean shutting down an operational plant without preparation.
OT environments have availability and safety requirements that make emergency changes complicated.
But organizations should determine why the exposure exists and whether it can be eliminated.
In most cases, industrial controllers should not be directly reachable from the public Internet.
Remote administration should instead pass through appropriately secured architectures with strong authentication, segmentation, monitoring, and access controls.
Blocking TCP 102 Can Remove an Easy Attack Path
One of the clearest recommendations is to block unnecessary access to TCP port 102 at network boundaries.
The goal is not simply to block the port everywhere.
Industrial systems still need legitimate communication.
The correct approach is to restrict communication so that only authorized hosts and network zones can reach the required PLC services.
A firewall rule that effectively says “the entire Internet can talk to this PLC” is very different from one that permits communication only between a known engineering workstation and a specific controller.
Authentication Should Never Be Optional
Organizations should also ensure that controllers are protected with appropriate authentication and protection mechanisms.
Legacy industrial environments sometimes contain devices that were deployed when security requirements were very different from today’s threat landscape.
That history cannot be ignored.
Controllers should be configured so that unauthorized users cannot freely access sensitive functions.
Protection levels should also be reviewed to limit what low-privilege or unauthenticated sessions can read or modify.
Monitoring S7comm Behavior
Traditional antivirus is not enough for this type of threat.
Defenders need visibility into industrial protocols.
Security teams should establish a baseline for normal S7comm traffic.
For example:
Which engineering stations normally communicate with PLCs?
Which PLCs communicate with each other?
When does maintenance normally occur?
Which systems should ever perform write operations?
Which IP addresses normally initiate connections?
Once those patterns are known, unusual behavior becomes easier to identify.
Hunting for Suspicious Python Activity
Another useful detection opportunity involves Python processes.
Security teams should investigate systems that unexpectedly load snap7.dll or otherwise use python-snap7 functionality.
This does not mean every occurrence is malicious.
Industrial engineering software can legitimately use similar components.
The context is what matters.
A Python process communicating with several PLCs from a workstation that has never previously performed such activity should receive additional scrutiny.
Geographic Anomalies Can Help
Unexpected geographic sources should also be investigated.
If a PLC normally communicates with engineering systems inside a facility but suddenly receives connections associated with unfamiliar external infrastructure, defenders should not dismiss the event.
Geolocation itself is not proof of malicious activity.
Attackers can use VPNs, proxies, compromised infrastructure, and cloud services.
Still, unexpected external communication can provide a valuable investigation signal.
Deep Analysis: Hunting for Siemens S7 Reconnaissance
Start With Network Visibility
Security teams can begin by looking for connections involving TCP port 102.
A basic Linux investigation can use:
sudo ss -tnp | grep ':102'
This can help identify active TCP sessions involving the S7comm port.
For historical analysis, network telemetry from firewalls, IDS platforms, NetFlow, or packet captures is significantly more useful.
Search Firewall Logs
A simple log search can identify systems communicating over TCP 102:
grep -E '(^|[^0-9])102([^0-9]|$)' /var/log/ 2>/dev/null
The exact command will vary depending on the logging platform.
The important objective is to determine whether connections are coming from approved engineering hosts or unexpected systems.
Monitor With tcpdump
On a Linux monitoring point, defenders can capture traffic involving port 102:
sudo tcpdump -ni any tcp port 102
This should be performed carefully in production environments.
Packet capture can generate substantial data, and monitoring must respect operational and privacy requirements.
Identify Unexpected Python Processes
Linux defenders can examine running Python processes with:
ps aux | grep -i python
They can then investigate process trees, command lines, network connections, and loaded libraries.
For example:
sudo lsof -p <PID>
This can help determine what files and network sockets are associated with a suspicious process.
Search for snap7 Usage
On systems where legitimate Snap7 development is not expected, defenders can search for related components:
find / -iname 'snap7' 2>/dev/null
Again, discovery does not equal compromise.
The purpose is to identify software that deserves contextual investigation.
Examine Network Connections
A more complete view of active connections can be obtained with:
sudo ss -tunap
Security teams should correlate suspicious connections with:
Process IDs
User accounts
Destination IPs
Source IPs
Connection times
Maintenance schedules
Known engineering systems
Hunt for Scanning Behavior
Repeated connections to many IP addresses over TCP 102 can indicate reconnaissance.
A SIEM rule could look for patterns where a single source attempts connections against a large number of internal or external addresses.
Conceptually:
IF source_host
connects_to > N unique_hosts ON destination_port = 102 WITHIN short_time_window THEN raise_alert
The threshold should be customized to the environment.
A legitimate vulnerability scanner and a malicious reconnaissance operation can produce superficially similar traffic.
Context is therefore essential.
Watch for PLC Write Activity
Read operations are concerning.
Unexpected write operations are even more significant.
Organizations should establish alerts for PLC changes outside authorized maintenance windows.
A useful detection model is:
Authorized Engineering Host
|
v
Scheduled Maintenance Window
|
v
Expected PLC Change
Anything outside that pattern deserves investigation.
Protect the Engineering Workstation
The engineering workstation can be just as important as the PLC itself.
If an attacker compromises the workstation used by engineers, they may inherit legitimate access to industrial systems.
Organizations should therefore harden engineering endpoints, restrict unnecessary Internet access, monitor scripting activity, and carefully control administrative privileges.
Engineering workstations should not be treated like ordinary office PCs.
Segment IT and OT Networks
Proper segmentation is one of the strongest defenses available.
A simplified architecture should look more like:
Internet
|
Firewall
|
DMZ
|
OT Firewall
|
Engineering Zone
|
PLC Network
|
Industrial Controllers
Rather than:
Internet
|
+- PLC
The second architecture is precisely the type of exposure attackers can discover through Internet-wide scanning.
Do Not Blindly Patch Industrial Systems
Patching remains important, but OT environments require additional caution.
A firmware update can affect industrial applications, communication drivers, engineering software, or third-party integrations.
Before making changes, operators should verify compatibility, maintenance requirements, recovery procedures, and rollback options.
This is one reason the advisory recommends working with Siemens ProductCERT for model-specific guidance.
What Undercode Say:
The Real Story Is Preparation
The most important part of this advisory is not that attackers discovered another industrial protocol.
It is that they appear to be preparing.
Reconnaissance is often the quiet stage that happens before defenders see the consequences.
AI Changes the Timeline
AI does not need to independently discover a PLC vulnerability to become dangerous.
It only needs to make an experienced
Legitimate Tools Are a Security Blind Spot
Using Snap7-related libraries makes detection harder because the software itself can be legitimate.
Security teams need to detect behavior rather than relying exclusively on malware names.
Industrial Systems Were Never Designed for the Modern Internet
Many PLC environments were built around assumptions of network isolation.
The Internet changed those assumptions.
Exposing old industrial architecture to modern automated scanning creates a completely different threat model.
Port 102 Should Be Treated Seriously
A public-facing TCP 102 service should trigger an immediate review.
The question should not be “Is it currently being attacked?”
The better question is “Why is it exposed at all?”
Reconnaissance Can Be More Valuable Than Exploitation
An attacker who understands a target can potentially return later with much greater precision.
Information gathered today can become operational capability tomorrow.
Read Access Still Matters
Reading configuration and logic can reveal how a facility works.
That information can be extremely valuable to an adversary.
Safety Systems Raise the Stakes
A compromise involving ordinary production equipment is serious.
A compromise involving safety-related controllers can become a much more dangerous event.
Third-Party Access Must Be Audited
Organizations should assume that remote access paths can outlive the original business requirement.
Every external connection should have an owner, justification, authentication mechanism, monitoring, and expiration strategy.
Industrial Credentials Need the Same Discipline as IT Credentials
Shared passwords and permanent contractor accounts create unnecessary risk.
Access should be unique, controlled, and regularly reviewed.
OT Monitoring Needs Its Own Strategy
Traditional endpoint telemetry cannot explain everything happening inside an industrial network.
Protocol-aware monitoring is increasingly important.
Network Segmentation Is Not Optional
Segmentation creates additional barriers between an attacker and the physical process.
Every additional barrier buys defenders time.
Visibility Comes First
Organizations cannot protect devices they cannot identify.
Asset discovery should therefore be treated as a security control rather than an administrative exercise.
External Scanning Is an Early Warning
If an organization can identify unauthorized scanning against its industrial infrastructure, it may detect adversaries before they reach deeper stages of an intrusion.
AI-Assisted Threats Will Become More Common
This campaign should not be viewed as an isolated experiment.
Attackers are increasingly likely to use AI for reconnaissance, scripting, documentation analysis, and operational adaptation.
Defenders Can Use AI Too
The same technology can help defenders analyze logs, identify anomalies, understand PLC configurations, and prioritize exposed assets.
The advantage will depend on who integrates automation into their workflow more effectively.
Security Teams Need OT Expertise
IT security personnel cannot always interpret industrial behavior correctly.
A connection that looks suspicious to an IT analyst could be normal engineering traffic.
A seemingly harmless PLC change could be extremely important operationally.
Engineers and Security Teams Must Work Together
The best industrial defense combines cybersecurity knowledge with process knowledge.
Neither side has the complete picture alone.
Remote Access Is a Prime Target
The more pathways into an OT environment, the larger the attack surface becomes.
Organizations should continuously remove unnecessary pathways.
Internet Exposure Should Be Exceptional
Directly exposing PLC services should require an extraordinary operational justification.
It should never happen simply because “it worked.”
Older Controllers Deserve Special Attention
Legacy devices often remain operational long after their original security assumptions became outdated.
They may be difficult to patch or replace.
That makes compensating controls especially important.
Safety Cannot Be Separated From Cybersecurity
In OT, cybersecurity decisions can eventually become safety decisions.
That changes the priority of the entire security program.
The Attack Surface Is Bigger Than the PLC
The PLC is only one component.
Engineering stations, HMIs, historians, remote-access servers, VPNs, integrators, and cloud-connected management systems can all provide pathways toward the controller.
Attackers Only Need One Weak Path
Defenders must protect the environment comprehensively.
Attackers only need one exposed or poorly protected entry point.
Monitoring Should Focus on Behavior
The most valuable alerts may not say “malware detected.”
They may say:
Unknown host connected to 47 PLCs.
That is potentially much more meaningful.
Maintenance Windows Matter
Changes outside approved maintenance windows deserve heightened scrutiny.
Predictable schedules provide defenders with useful detection baselines.
Organizations Should Test Their Assumptions
A firewall rule that is believed to block external access should actually be tested.
A contractor account believed to be disabled should actually be verified.
A PLC believed to be isolated should actually be scanned from the relevant network boundaries.
Security Architecture Should Assume Compromise
Strong OT architecture assumes that some IT or external system may eventually be compromised.
The goal is to prevent that compromise from becoming physical control.
The Cost of Preparation Is Lower Than the Cost of Recovery
Network segmentation, monitoring, inventory, and access control can be expensive.
Recovering from an industrial disruption can be dramatically more expensive.
The Warning Should Trigger Action
Operators should not wait for evidence of destructive activity.
The time to reduce exposure is while the campaign is still in its reconnaissance phase.
The Biggest Lesson
The biggest lesson is simple:
An exposed PLC is not merely another exposed computer.
It can be a gateway into the physical world.
✅ Joint Federal Warning
The article correctly describes the advisory as a coordinated warning involving multiple U.S. federal agencies, including CISA, NSA, FBI, DOE, and EPA.
✅ Siemens S7 Series Is the Target
The advisory described in the article concerns Siemens S7-series PLC environments and includes multiple generations of the platform.
✅ TCP Port 102 Is Relevant
S7comm communications commonly use TCP port 102, making unexpected exposure or scanning of that port an important defensive signal.
✅ AI-Assisted Tooling Is a Major Concern
The
⚠️ Reconnaissance Does Not Automatically Mean Successful PLC Takeover
The reported scanning and read activity should not be interpreted as proof that attackers have already gained destructive control over every targeted PLC.
The major concern is the possibility of preparation and capability development before more disruptive operations occur.
Prediction
(+1) Industrial Network Segmentation Will Accelerate
Organizations operating Siemens PLCs are likely to accelerate segmentation projects, especially where controllers remain reachable from corporate or public-facing networks.
(+1) OT Monitoring Will Become a Higher Priority
Industrial operators will increasingly deploy monitoring capable of understanding protocols such as S7comm rather than relying exclusively on conventional endpoint security.
(+1) AI-Assisted Industrial Threat Hunting Will Grow
Defenders are likely to use AI to correlate network behavior, engineering activity, configuration changes, and vulnerability information more quickly.
(+1) Third-Party Access Audits Will Increase
Managed service providers and system integrators are likely to face greater scrutiny as organizations reassess remote PLC access and long-standing credentials.
(-1) Exposed Legacy PLCs Will Remain a Difficult Problem
Older industrial environments cannot always be patched or replaced quickly, meaning some organizations will continue carrying significant cyber-physical risk even after implementing compensating controls.
(-1) Reconnaissance May Become Harder to Distinguish From Legitimate Engineering Activity
As attackers increasingly use legitimate industrial libraries and tools, traditional malware detection will become less effective against some OT campaigns.
(+1) The Biggest Defensive Advantage Will Be Visibility
Organizations that know exactly which PLCs they own, where those controllers are connected, who can reach them, and what normal S7comm traffic looks like will have a substantial advantage over attackers attempting to quietly map their environments.
The Bottom Line
This warning should not be dismissed as another routine cybersecurity advisory.
The most worrying aspect is the combination of Internet-exposed industrial systems, automated reconnaissance, legitimate PLC communication libraries, and AI-assisted scripting.
The attackers do not necessarily need to break everything immediately.
They can learn first.
They can identify weak systems, understand their targets, improve their tooling, and wait for an opportunity.
For organizations operating Siemens S7 infrastructure, the immediate priority should therefore be clear: find every exposed controller, eliminate unnecessary Internet access, restrict TCP 102, strengthen authentication and protection levels, audit third-party connections, monitor S7comm activity, and investigate unusual PLC read or write operations.
In industrial cybersecurity, prevention is not simply about protecting data.
It can mean protecting the machines, processes, facilities, and people that depend on those machines continuing to operate safely.
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: securityaffairs.com
Extra Source Hub (Possible Sources for article):
https://www.reddit.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
