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,3...