ICS/OT exposure invites protocol-aware scanning and exploit probing

At a glance

What this is: Censys shows that exposed ICS/OT services are scanned with intent, and that Modbus in particular draws protocol-aware probing and exploit-tagged traffic.

Why it matters: For IAM, PAM and OT-adjacent security teams, the finding reinforces that Internet exposure is an access problem as much as a network one, because exposed control protocols create direct paths to unauthenticated interaction.

By the numbers:

• The honeypot recorded 764 ICS/OT events across nine days.
• Censys observed 188 unique source IPs hitting the honeypot.
• Modbus accounted for 191 events, or 25.0% of the traffic.

Context

ICS and OT protocols were designed for trusted, isolated networks, not direct Internet exposure. When Modbus, Siemens S7, BACnet or IPMI are reachable from the public Internet, they can be fingerprinted, enumerated and in some cases actively probed because the protocols often assume the network boundary is the control boundary.

This report matters because it shows that industrial exposure is not limited to accidental discovery. Protocol-aware scanning exists, and it can distinguish between a simple open port and a live control surface. That makes exposed OT services part of the same attack-surface problem that attack surface management already addresses in enterprise environments.

Key questions

Q: What breaks when ICS and OT protocols are exposed directly to the Internet?

A: The main failure is that the protocol boundary becomes a public control surface before any real trust decision occurs. Attackers can fingerprint the service, test valid function codes, and sometimes reach read or write semantics without needing a user session. Exposure turns discovery into pre-exploitation, which means segmentation and reachability control matter more than port secrecy.

Q: Why do protocol-aware scanners make exposed Modbus services higher risk?

A: Because protocol-aware scanners are not just checking whether a port exists. They can construct valid Modbus messages, maintain state and test control-path behaviour, which shows intent beyond inventory collection. That capability raises the likelihood of fuzzing, exploit testing or unsafe interaction with industrial logic, even if no write operation succeeds during the scan.

Q: What are the signs that an exposed OT service is being actively probed?

A: Look for valid protocol headers, repeated read or write function codes, malformed packets, multi-step exchanges and session behaviour that lasts longer than a simple port check. Those signals indicate an actor is moving beyond discovery and trying to understand how the service responds. In OT, that is often the earliest observable sign of targeted interest.

Q: What should defenders do when an industrial service cannot be taken offline immediately?

A: Restrict reachability first, then add segmented access, protocol-aware monitoring and deception so you can distinguish routine noise from deliberate probing. The goal is to reduce the number of actors who can touch the service at all, while making any remaining interaction visible enough to investigate before it becomes a control-path risk.

Technical breakdown

Why exposed industrial protocols are different from exposed IT services

Industrial control protocols differ from ordinary web or remote administration services because many were built without strong authentication, internet exposure or hostile traffic in mind. A scan against Modbus or S7comm is not just a reachability check. The protocol itself can expose register values, device behaviour or control functions if the session progresses beyond the handshake. That is why raw port visibility is not the whole story. The real risk appears when a scanner can form valid protocol messages and test read or write semantics, which indicates intent beyond simple inventory collection. See the OT Security Guide.

Practical implication: Treat exposed OT protocols as reachable control surfaces, not just open ports.

What protocol-aware Modbus probing looks like on the wire

A shallow scan stops at TCP connection setup or resets immediately after a handshake. A deeper Modbus interaction includes correctly structured MBAP headers, valid function codes and stateful request and response exchanges. That difference matters because the second pattern shows the operator knows the protocol and is testing whether the target will answer with meaningful data or accept control-oriented commands. Even when no write occurs, the presence of valid read and write primitives reveals capability testing. In OT environments, that is often the stage before exploitation, fuzzing or unsafe process manipulation. See the Network Ports and Protocols Security Guide.

Practical implication: Use packet inspection and protocol-aware monitoring to distinguish simple discovery from meaningful control-path testing.

Why port changes do not remove exposure risk

Port twisting can reduce casual discovery, but it does not eliminate exposure when scanners identify protocols by payload rather than port number. In this article, Modbus and S7comm were still recognised on non-standard ports, while BACnet and DNP3 were more dependent on their conventional port assignments. That asymmetry shows why obscurity is not a control. If an industrial service can still be fingerprinted, it remains reachable to adversaries who already know how to search for it. The governance failure is assuming that port relocation changes the trust model of the service.

Practical implication: Treat port changes as noise reduction, not as a compensating control for exposure.

Threat narrative

Attacker objective: The attacker objective is to identify live industrial services, test protocol behaviour and prepare for control-path abuse or exploitation.

1. Entry begins with Internet-wide discovery of exposed ICS and OT protocols, including Modbus, S7comm, BACnet and IPMI.
2. Credential or session-free interaction follows because these protocols were built to trust the network and often do not require authentication before meaningful interaction.
3. Escalation takes the form of protocol-aware probing, malformed payloads and read or write function testing against industrial logic surfaces.
4. Impact would be control-path manipulation, reconnaissance for later exploitation or unsafe process interference if the exposed service were real.

Breaches seen in the wild

• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Exposed OT protocols create an identityless trust problem: ICS services often accept protocol-level interaction before any meaningful identity decision is made, which is why exposure itself becomes the control failure. In an OT environment, the problem is not just reachability, but the assumption that only trusted parties will ever speak Modbus or S7comm. That assumption collapses the moment the protocol is placed on the public Internet. Practitioners should treat exposure as a governance defect, not a network accident.

Protocol awareness is now a real attacker capability, not a lab curiosity: The article shows that some scanners do more than enumerate ports. They parse payloads, maintain state and test whether a device will answer like a PLC or HMI. That means detection logic must distinguish background internet noise from behaviour that resembles pre-exploitation capability testing. Security teams that rely only on firewall presence or port-based filtering will miss the significance of these interactions.

Modbus is the clearest example of control-plane risk in exposed OT: The article’s strongest risk signal is not volume, but depth of interaction on Modbus. That protocol is especially dangerous because it can carry valid read and write semantics without a user-facing login flow. In other words, the attack surface is already close to the control plane. This is where OT security guide thinking matters most: exposure, segmentation and protocol governance must be designed together.

Security through obscurity fails faster in OT than many teams expect: Port changes may alter who finds a service first, but they do not change whether the service can be discovered by payload inspection. The article’s port-twisting results show that some protocols remain visible even when the obvious port hint is removed. Practitioners should assume that any exposed industrial service with a stable protocol fingerprint is already part of an adversary’s scanning pipeline.

The named concept here is protocol-aware OT reconnaissance: this is the stage where an attacker moves from discovering that a service exists to proving that it speaks a control protocol worth targeting. That distinction matters because it marks a shift from passive inventory collection to active pre-exploitation behaviour. Defenders should use that signal to prioritise exposed OT services for segmentation and external reachability reduction.

What this signals

Protocol-aware OT reconnaissance: the practical security shift is from asking whether a port is open to asking whether the actor behind the connection understands the industrial protocol well enough to test control paths. That is a stronger adversary signal than ordinary scanning, and it should feed external exposure prioritisation, not just IDS tuning.

The reader-facing implication is straightforward: inventory alone is not enough. Teams need to know which industrial endpoints are reachable, which protocols are exposed, and whether those protocols can be spoken by scanners that already know how to behave like an OT-aware adversary.

For practitioners

• Remove direct Internet exposure for ICS and OT protocols Place Modbus, S7comm, BACnet and similar services behind segmented remote access paths instead of exposing them on public interfaces.
• Segment OT access from enterprise networks Use zones and conduits, jump hosts or VPN-mediated access so industrial control traffic never relies on open inbound reachability.
• Monitor for protocol-aware scanning patterns Alert on valid function codes, malformed payloads, repeated read or write attempts and multi-packet exchanges that go beyond a TCP handshake.
• Deploy deception in exposed OT enclaves Use decoy services and canary controls to identify scanning behaviour early and separate routine noise from deliberate probing.
• Continuously inventory external attack surface Track exposed industrial endpoints, shifted ports and adjacent management services so new reachability is removed before it becomes routine.

Key takeaways

• Exposed industrial services are not merely discoverable, they can be interacted with in ways that reveal control behaviour and increase operational risk.
• The article’s honeypot evidence shows that protocol-aware probing exists, which means OT exposure should be treated as a real attack-surface problem rather than background noise.
• Reducing reachability and adding segmentation are more reliable controls than relying on port changes or obscurity to protect industrial protocols.

Related NHI Mgmt Group resources: OT Security Guide · Attack Surface Management Guide · OT and ICS Identity and Access Guide · Deception Technology Guide

Key terms

• Protocol-aware reconnaissance: Reconnaissance that goes beyond checking whether a port is open and instead sends protocol-valid messages to learn how a target behaves. In OT, this matters because valid control protocol exchanges can reveal device state, supported operations and whether the service is ready for exploitation.
• Industrial control protocol: A communications protocol used by PLCs, HMIs and related OT systems to read or change process state. These protocols were typically designed for trusted environments, so exposing them publicly can allow unauthenticated probing, fingerprinting and sometimes direct interaction with control logic.
• Attack Surface Exposure Score: A metric that measures how much internet-exposed infrastructure is carrying unresolved critical findings. It is useful for executive reporting because it links reachability and severity, giving leadership a clearer view of breach-relevant risk than raw vulnerability counts alone.
• Port twisting: The practice of moving a service to a non-standard port in an attempt to reduce discovery. It may reduce casual scanning noise, but it does not stop protocol-aware actors who can identify services by payload and behaviour rather than by port number alone.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.