Earlier this year, Censys published Who’s Knocking on Your Door? An Analysis of Exposed Services and Their Risks, which explored what happens when common Internet services are left exposed. The takeaway was clear: anything reachable from the public Internet will be scanned, fingerprinted, and occasionally exploited.
But what about industrial services?
What happens when you expose Modbus, Siemens S7, BACnet, IPMI, and other OT-adjacent protocols directly to the Internet with no banners and no hints?
To find out, I deployed a multi-protocol ICS/OT honeypot for nine days. What it saw is a microcosm of what Censys sees across 145,000+ exposed industrial systems worldwide:
What we found confirmed that if you put ICS/OT protocols online, someone will talk to them — and many will know exactly what they’re doing.
This is that story.
From Exposed Web Servers to Exposed PLCs
The original Censys study focused on exposed IT services such as SSH, SMB, and web admin portals — systems that attackers routinely seek out.
But ICS/OT protocols are different:
- They lack authentication.
- They assume a trusted, isolated network.
- They provide direct access to equipment behavior.
Yet Censys continues to identify large numbers of exposed OT systems worldwide — including PLCs, HMIs, building management systems, and energy systems.
So we built a honeypot that pretends to be one.
Building a PLC That Listens to the Internet
We exposed four industrial protocols:
- Modbus TCP
- Siemens S7comm
- BACnet
- IPMI (often adjacent to OT networks)
No banners.
No web dashboards.
Just raw ports, exactly how misconfigured ICS devices often appear on the public Internet.
The honeypot captured parsed protocol fields, function codes, scan vs exploit behavior, malformed packets, and full enrichment (country, ASN, etc.).
Total capture window: November 23 – December 1, 2025.
What Hit Us: 764 ICS/OT Events in Nine Days
Across 188 unique source IPs, the honeypot received:
• 395 S7comm events (51.7%)
• 191 Modbus events (25.0%)
• 99 IPMI events (13.0%)
• 79 BACnet events (10.3%)
S7comm accounted for more than half of all traffic, matching global scanning patterns.
Modbus, however, is where the dangerous payloads landed.
Not All Scanners Are Equal
We classified each source into behavior categories:
- Generic scanners (74%)
- ICS-aware scanners (26%)
- Multi-protocol ICS scanners (~3%)
1 in 4 scanners showed ICS protocol awareness, demonstrating that industrial scanning is intentional — not random Internet noise.
Modbus: Small Share of Traffic, Big Share of Risk
From Port Scans to Protocol Fluency: Visualizing Risk on the Wire
Not all connections to ICS/OT services represent the same level of risk. While many scanners simply check whether a port is open, others demonstrate clear protocol awareness by constructing valid industrial protocol messages and engaging in multi-step exchanges.
To illustrate this difference, the packet-level behavior of two Modbus TCP connections is contrasted below: a shallow scan and a high-risk, protocol-aware interaction.
Shallow Interaction: Port Awareness Only
In the majority of observed cases, scanners performed only minimal interaction with the exposed Modbus service. These sessions typically consisted of a basic TCP handshake, sometimes followed by an immediate reset.
Observed characteristics:
- No Modbus payloads transmitted
- Session duration measured in milliseconds
- Identical behavior across many unrelated ports
- No attempt to maintain state or issue function codes
This behavior is consistent with high-speed Internet-wide scanners performing service discovery rather than interaction. While noisy, these connections do not indicate intent to manipulate or control an industrial process.
Risk classification: Low
Intent: Reconnaissance and inventory
Attacker Honeypot
-------- --------
SYN ---------------------->
<------------------ SYN-ACK
ACK ---------------------->
(optional)
RST ---------------------->Shallow Modbus TCP Interaction — TCP Handshake Only
Deep Interaction: Protocol-Aware and Stateful
A smaller but more concerning subset of connections demonstrated full Modbus protocol awareness. These sessions included correctly structured Modbus Application Protocol (MBAP) headers and valid function codes, sometimes chained across multiple requests.
Observed characteristics:
• Valid Modbus function codes (e.g. read and write operations)
• Proper transaction identifiers and register addressing
• Multi-packet request/response exchanges
• Longer session duration and stateful behavior
This type of traffic requires specific knowledge of the Modbus protocol and goes well beyond generic scanning. While the honeypot prevented any real-world impact, the intent to interact with industrial control logic is evident.
Risk classification: High
Intent: Capability testing and potential pre-exploitation
Attacker Honeypot
-------- --------
SYN ----------------------------------->
<------------------------------- SYN-ACK
ACK ----------------------------------->
MBAP Header + Function Code 0x03
(Read Holding Registers)
-------------------------------------->
<-------------------------------
Response: Register Values
MBAP Header + Function Code 0x10
(Write Multiple Registers)
-------------------------------------->
<-------------------------------
Write AcknowledgementProtocol-Aware Modbus TCP Interaction – Read/Write Exchange
Why This Distinction Matters
At the network level, both shallow and deep interactions appear as inbound connections to the same port. However, at the packet level, the difference is stark.
Shallow scans represent background Internet noise. Protocol-aware exchanges represent actors who understand industrial protocols and are testing how far they can go.
This distinction explains why Modbus, despite accounting for a smaller share of total traffic than S7comm, carries a disproportionately higher risk profile in the dataset.
From the data:
- 13.1% of Modbus traffic was exploit-tagged
- The same 13.1% was malformed
This suggests fuzzing, PoC exploit attempts, broken payloads, or attempts to crash a Modbus server.
S7comm received more traffic, but all S7 events were classified as scans — not exploit attempts.
Modbus remains one of the most targeted ICS protocols on the Internet.
Where Scanners Came From (Geography & ASN)
Using enrichment data (country + ASN), we ranked the top scanning origins.
Most sources were cloud providers, research networks, scanner infrastructures, or large hosting environments.
This reinforces that industrial scanning is now a normalized part of the Internet ecosystem.
What This Means for ICS and OT Defenders
Our honeypot — a tiny, quiet PLC simulation — saw:
- Daily ICS scanning.
- Multiple ICS-aware scanners.
- Modbus exploit attempts.
- Reconnaissance from diverse ASNs and regions.
This mirrors what Censys sees at global scale. ICS exposure is real, persistent, and increasingly targeted.
Recommended actions:
- Never expose ICS/OT protocols directly.
- Use segmentation + VPN for OT access.
- Continuously scan your own attack surface.
- Deploy honeypots in OT DMZs.
- Treat ICS ports like exposed RDP or databases.
Conclusion
If IT services attract constant attention, ICS/OT services attract intentional, protocol-aware reconnaissance.
Your PLC will be scanned.
Your Modbus interface will be probed.
Your S7 endpoint will be fingerprinted.
Your management interfaces will be mapped.
If your ICS/OT systems touch the Internet, they are already part of someone’s reconnaissance pipeline.
The safest ICS device is the one attackers can’t reach.
Extended Observation on Standard Ports
After extending the runtime of the original honeypot, additional data confirmed the initial findings while strengthening confidence in scanner classification. S7comm remained the most frequently contacted protocol, dominated by reconnaissance-only behavior. Modbus continued to attract fewer scanners overall, but accounted for the majority of malformed and exploit-tagged payloads, reinforcing its role as the highest-risk protocol among those observed.
No transition from reconnaissance to operational manipulation was observed on standard ports. Even protocol-aware scanners consistently stopped short of write or control operations, indicating that the majority of activity represents mapping and capability discovery rather than immediate attack.
Port-Twisting Experiment: Do Scanners Understand Protocols or Just Ports?
To distinguish between port-based scanning and true protocol awareness, a second honeypot was deployed using non-standard ports (standard port +1) and an adjusted protocol mix. Modbus was exposed on port 503, S7comm on 103, EtherNet/IP on 44819, BACnet on 47809, and DNP3 on 20001. IPMI was intentionally omitted.
This honeypot ran for a shorter duration, but results were normalized by exposure time to allow fair comparison. The goal was not volume, but behavior: could scanners still identify and speak ICS protocols when port numbers no longer provided hints?
Findings from Port-Twisted Exposure
Modbus and S7comm both received protocol-correct traffic on their non-standard ports. In both cases, sessions included valid handshakes and limited data exchange, proving that some scanners identify these protocols by payload rather than port alone.
EtherNet/IP traffic was also observed on its twisted port, but interactions were shallow, consisting primarily of handshakes and resets without deeper CIP object access. This suggests emerging but immature support for EtherNet/IP scanning.
In contrast, BACnet and DNP3 received no traffic on their non-standard ports. Despite being observed on standard ports previously, neither protocol was discovered off-port during the observation window.
What Port Twisting Reveals
These results show a clear divide in the ICS scanning ecosystem. Some protocols — notably Modbus and Siemens S7 — are actively fingerprinted by payload and can be identified even when ports are shifted. Others, such as BACnet and DNP3, remain almost entirely dependent on well-known port numbers.
Importantly, no increase in exploitative or destructive behavior was observed on twisted ports. Protocol-aware scanners behaved the same way they did on standard ports: reconnaissance-focused, non-destructive, and automated.
Conclusions
Internet-wide scanning of ICS/OT protocols is not accidental. It is deliberate, structured, and in many cases protocol-aware. However, that awareness is uneven. Only a subset of protocols are actively identified beyond their default ports, and even fewer scanners demonstrate the capability or intent to perform impact-oriented actions.
For defenders, this reinforces two key points: first, security-through-obscurity such as port changes is ineffective against determined reconnaissance; second, reducing Internet exposure remains the single most effective mitigation. If an ICS service is reachable, it will be found — sooner or later.
Key Takeaways
• Packet-level analysis reveals clear intent: most scanners stop at discovery, but a smaller subset actively speaks industrial protocols and tests control paths.
• Port numbers still matter. Many ICS protocols — especially BACnet and DNP3 — are discovered almost exclusively via their well-known ports.
• Protocol awareness exists, but it is uneven. Modbus and Siemens S7 are routinely fingerprinted by payload, even when ports are shifted, while others are not.
• Reconnaissance clearly dominates. Across both experiments, scanners consistently stopped short of destructive or operational actions.
• Security through obscurity is not a defense. Port changes alone do not prevent discovery of critical ICS services.
• The safest ICS service is one that is not reachable from the public Internet — and preferably not reachable at all.
Modbus TCP Activity Timeline
The timeline below visualizes Modbus TCP activity over time, grouped by originating organization or ASN. Bubble size represents activity volume, while highlighted points indicate malformed or exploit-tagged events. This view clearly shows that Modbus, while not the most frequently contacted protocol, attracts a disproportionate share of higher-risk interactions.
Honeypot Telemetry & Analysis Dashboard
Throughout the experiment, a custom-built dashboard was used to aggregate honeypot telemetry, protocol parsing results, enrichment data, and behavioral classifications. This operational view enabled real-time validation of scanner behavior and supported the analysis presented in this report.
Port-Twisting Experiment – Validated Results
Port-Twisting Validation with Corrected Logs (Extended Dataset):
After correcting the port-twisted honeypot configuration and incorporating additional raw event logs and enriched session data, the port-twisting experiment was re-evaluated over an extended observation window (December 17, 2025 – January 13, 2026), totaling 1,016 events.
The updated dataset confirms the original conclusions while providing greater statistical confidence.
Observed protocol activity on non-standard ports:
– Modbus TCP on port 503: 311 events
– Siemens S7comm on port 103: 366 events
– DNP3 on port 20001: 81 events
– BACnet on port 47809: 15 events
– EtherNet/IP (standard port 44818): 180 events
Depth of interaction remained limited. Only a small fraction of Modbus (approximately 4.2%) and S7comm (approximately 2.7%) sessions progressed beyond connection establishment to protocol-level data exchange. No confirmed write operations or sustained control sequences were observed.
DNP3 and BACnet, despite visibility on their twisted ports, did not exhibit protocol-aware exchanges during this period, reinforcing the conclusion that these protocols remain heavily dependent on well-known port discovery.
Crucially, the extended dataset did not reveal escalation over time, transitions from reconnaissance to manipulation, or the emergence of new protocol fingerprinting capabilities. Scanner behavior remained consistent, automated, and non-destructive.
This validation strengthens the conclusion that while some scanners can identify Modbus and Siemens S7 by payload rather than port alone, the dominant intent remains reconnaissance and capability testing rather than active exploitation.