Blog · 2026-07-20
Someone keeps knocking on the control room
Our honeypots run no industrial equipment, yet 2,661 hosts sent a real Modbus, DNP3, S7comm or IEC-104 handshake in five months. Decoding the payloads: which scanners, which PLCs they hunt, and how far each probe goes.
TL;DR: Between 16 February and 18 July 2026, our internet-facing sensors received valid Modbus, DNP3, S7comm, or IEC-104 requests from 2,661 unique hosts. Modbus and DNP3 scanners generally attempted to identify the device they reached, while most S7comm and IEC-104 traffic stopped after the initial connection. This post examines the requests and the scanner behaviour behind them.
Internet scanning is often associated with websites, remote-desktop servers, and exposed databases. However, industrial equipment is scanned as well: programmable logic controllers (PLCs), telecontrol stations, and other devices that would normally sit behind an industrial network.
Our sensors are not connected to a real plant and do not control any physical process. They only speak Modbus, DNP3, S7comm, or IEC-104 when a remote system attempts to initiate a conversation. This makes the traffic useful for understanding what scanners are trying to identify.
Looking at the request
The bytes sent by a scanner often tell us far more than the port it connected to. These protocols are generally unencrypted, so there is no TLS fingerprint or SSH banner to rely on. The request itself becomes the fingerprint.
For example, the Modbus request above is sent by zgrab2, a tool commonly used for internet-wide scanning. Its transaction ID is always 0x5A47, which translates to ZG in ASCII. The request asks a device to identify itself by returning its vendor name, product code, and firmware version. We observed 560 distinct source addresses sending this exact eleven-byte request.
DNP3 looks slightly different. The frame uses control byte 0xC9, a Request Link Status message that a DNP3 outstation should answer regardless of its configuration. Because the protocol has a link-layer destination address, the scanner tries address 0, then 1, then 2, continuing to 99 within the same connection. In effect, it is asking: “Is there an outstation here, and which address does it use?” This resembles the enumeration performed by Redpoint dnp3-info and Nmap scripts.
Same protocol, different scanners
Small differences between requests are useful for separating scanner families. On Modbus, all scanners request device identity information, but not all use the same transaction ID. The 560 zgrab2 systems use ZG; another 278 addresses use 0x1337. Others use incrementing counters, suggesting a stateful scanner that tracks its own requests.
S7comm traffic indicates which Siemens PLC a scanner expects to find. The connection request contains a TSAP value that encodes the target rack and slot. Most sources, 615 hosts, targeted rack 0 slot 2: the default position for an S7-300 or S7-400 CPU. Another 79 targeted slot 1, a common position for S7-1200 and S7-1500 systems. Trying both gives a scanner a chance of finding PLCs across multiple Siemens generations, similar to the Nmap s7-info script.
We also observed 67 sources sending a malformed S7 connection request with twelve-byte TSAP values filled with AAAA and BBBB. This is not behaviour expected from a legitimate S7 client.
For IEC-104, the initial frame divides the traffic into two groups: 357 hosts started with TESTFR and 292 used STARTDT. This likely reflects different client libraries or scanner implementations.
How much do scanners ask?
Not every scanner progresses beyond establishing that a port responds. Modbus and DNP3 scanners generally attempt to identify the device. About 90% of Modbus sources requested device identity information, and 85% of DNP3 sources performed the address sweep. Some Modbus systems also tried unit IDs 1 through 9, possibly looking for serial devices behind a Modbus-to-serial gateway.
S7comm and IEC-104 traffic was usually less extensive. Only 29 of the 823 S7comm hosts negotiated an S7 session, and just 4 requested the CPU model and firmware. Of 656 IEC-104 hosts, 33 sent a General Interrogation request, which asks a telecontrol station to report the points it monitors. Most sources completed the initial connection step and moved on.
This likely reflects the maturity of available tooling. Modbus and DNP3 have well-established modules in scanning tools, while S7 and IEC-104 reconnaissance often appears limited to a basic connection test.
Why payload validation matters
A protocol label is not proof that a request belongs to that protocol. Counts based solely on ports or unverified classifier output can make industrial scanning appear more common than it is. The payload needs to be checked before drawing conclusions from the numbers.
The collection pipeline uses nDPI, a deep-packet classifier. This is more useful than assigning a protocol solely by port number, but it can still make mistakes. nDPI classified 1,367 ordinary GET / HTTP/1.1 requests to port 20000 as DNP3. It also classified 154 HTTP requests to port 44818 as EtherNet/IP. This happens because the protocol dissectors can fall back to the port number when the payload does not match their expectations.
After reviewing the raw traffic, EtherNet/IP on port 44818 proved to be almost entirely web-scanner traffic: 99% HTTP requests and one genuine industrial request. It is therefore not included in the results above.
Applying this check to the dataset left only traffic beginning with a protocol-specific signature: a Modbus MBAP header, DNP3 0x0564, an S7 TPKT header, or IEC-104 0x68. The apparent total fell from 3,331 to 2,661 hosts.
The same applies to any ICS scanning dataset. Counting everything that reaches a port, or trusting a classifier without inspecting the request, includes web scanners that merely connected to an industrial port. The resulting number is larger, but it does not accurately represent industrial reconnaissance.
Indicators
Two hosts sent valid handshakes to all four industrial protocols. Both were hosted by commercial providers rather than an identified research network:
128[.]136[.]131[.]84, AS13649 Flexential (US): all four protocols, 550 probes, active from mid-May through early July.86[.]54[.]31[.]32, AS12989 Black HOST (CA): all four protocols, first seen in February and still active in July.
Data in our Lookup tool:
Internet-wide scanning includes both research activity and potentially unwanted reconnaissance. These addresses are best treated as investigation leads to compare with your own edge logs, rather than as a blocklist.
See it for yourself
Every request behind these numbers can be queried. The protocol label is based on nDPI, so the payload should still be verified when investigating a result.
Some links to industrial probes:
You can also use Claude, Gemini, Codex with our MCP using the following tool: search_events(app_protocol="dnp3"). See https://honeylabs.net/mcp
Conclusion
There is active scanning for industrial equipment on the internet. Some activity is likely broad indexing by researchers, but other systems make more detailed requests to determine what is exposed. The important point is not to assume that every connection to an industrial port is an industrial scan. Inspecting the first few bytes is often enough to tell the difference.
If you operate systems that speak these protocols, it is worth confirming whether they accept requests from networks you do not control.
Indicators here are defanged following draft-grimminck-safe-ioc-sharing, so they are safe to paste into a ticket without arming an address.