Topic starter
25/10/2026 11:07 am
TL;DR: Protocol-aware probing of exposed Modbus and related ICS/OT services points to deliberate interest rather than background noise, Censys found. Industrial reachability and segmentation now matter because scanners can interact with control protocols, not just detect them.
Editorial analysis by NHI Mgmt Group, based on content published by Censys: “Who's Knocking on Your PLC? A Honeypot View of Internet-Wide Interest in ICS/OT Protocols”.
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.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Exposed industrial services are not merely discoverable, they can be interacted with in ways that reveal control behaviour and increase operational risk.
Glossary terms: Protocol-aware reconnaissance, Industrial control protocol, Attack Surface Exposure Score, Port twisting
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:15 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: ICS/OT exposure invites protocol-aware scanning and exploit probing
This post was modified 7 days ago by NHI Mgmt Group