StallGrid: Measuring Internet-exposed Engagement in Protocol-Native OT Tarpits
arXiv:2609.34708v1 [cs.CR] 28 Sep 2026
Arthur Cordeiro, Casper Andersen, and Emmanouil Vasilomanolakis Technical University of Denmark, Lyngby, Denmark {arur,emmva}@dtu.dk [email protected]
Abstract. Operational technology systems face exposure to scanning and protocol-specific attack tools, where compromise risks disrupting physical processes rather than just data. Traditional OT defenses rely on blocking and filtering under strict patch constraints, while tarpitting delays scanners through sustained protocol-level interaction. Modbus TCP and IEC-104 carry no native authentication or integrity protection. Application-layer tarpitting, which stalls scanners inside a legitimate protocol exchange, has been studied for IT and IoT protocols, but not for OT/ICS, whose session semantics (state machines, exception codes) create stalling opportunities IT/IoT lack, and whose patchconstrained environments need exactly this kind of alternative defense. We present StallGrid, to our knowledge the first application-layer tarpits for OT/ICS, stalling scanners via Modbus Exception Codes 0x05/0x06 and prolonged residence in IEC-104’s connected state machine. Five variants (three Modbus TCP, two IEC-104) ran simultaneously for 24 days online, logging 6,709 sessions, 2,039 cumulative per-tarpit unique IPs, and over 2,000 hours of accumulated connection engagement. GreyNoise enrichment attributes 87–97% of stall time to malicious-tagged IPs, just 22–30% of connecting addresses; protocol-level behavior further correlates with malicious classification, a fingerprinting signal beyond raw stall time. Shorter induced delay (1.5s) yielded more total engagement than longer delay (3s), observed across both protocols. These results position protocol-native tarpitting as a practical, low-cost complementary defense for OT/ICS environments where patching remains infeasible. Keywords: OT · Tarpits · Deception
1
Introduction
Attacks against operational technology (OT) and industrial control systems (ICS) represent a latent risk. FrostyGoop manipulated heating controllers over Modbus [6]; Industroyer [4] and CosmicEnergy [20] implemented IEC 60870-5104 (IEC-104) command sequences to operate breakers in electrical power grids; Triton targeted a safety instrumented system [19]. Several of these campaigns are tied to sabotage OT systems, and the capability they demonstrate is specific
2
Arthur Cordeiro, Casper Andersen, and Emmanouil Vasilomanolakis
rather than generic: purpose-built code speaking industrial protocols to disrupt physical processes. The early tarpit studies were narrow responses to specific threats: LaBrea slowed the CodeRed worm with zero-window TCP replies [17], the Linux Netfilter TARPIT target generalized the trick at the transport layer [24], distributed SMTP tarpitting delayed protocol acknowledgements to slow spam [16], and Malpity automatically exploited vulnerabilities in specific malware binaries to trap infected hosts [35]. Transport-layer tarpits are deterministic and protocolagnostic, but that same regularity makes them easier fingerprintable: Degreaser identifies them from TCP-level artifacts at internet scale [2], and the countermeasures proposed in response [33] introduce detectable artifacts of their own, sustaining an arms race with no stable advantage for the defender. Even recent transport-layer tarpits built against IoT worm propagation face the same structural exposure [14]. This motivated a shift toward application-layer tarpits, which stall inside a legitimate protocol exchange and therefore require the scanner to possess protocol knowledge and maintain session state to disengage. Endlessh [36] demonstrated the idea for SSH banner exchange, and Franco et al. survey the broader IoT, IIoT, and cyber-physical-systems deception literature [12]. EventHorizon [31] recently tested the approach empirically: an eight-week global deployment of multiprotocol application-layer tarpits covering Telnet, MQTT, UPnP, and CoAP. Application-layer tarpitting is now an empirically studied defensive technique. The evidence base, however, lies entirely in the generic IoT space. OT/ICS differs from IoT along the dimensions that govern both tarpit design and defensive value. Modbus and IEC-104 carry no native authentication or integrity protection [23, 5], patching is constrained by availability requirements and equipment lifecycles measured in decades [34, 32], and the consequence of compromise is physical process disruption with safety implications rather than data loss or botnet recruitment [28, 1]. This is not merely theoretical: Yaben et al. find, via internet-wide measurement, that a substantial share of internet-facing OT and IoT devices are neglected, running obsolete software with no realistic maintenance path [37]. Conventional countermeasures compound the problem: botnet takedowns and blacklisting are short-lived once infrastructure relocates [13]. No prior work designs, deploys, or empirically evaluates application-layer tarpits for OT protocols. This paper answers that question empirically. We design, implement, and deploy application-layer tarpits for Modbus and IEC-104 on the open internet, and evaluate them against live scanning traffic enriched with independent threat intelligence. In summary, the contributions of our paper are as follows: – OT-specific application-layer tarpits. We design and implement tarpits for Modbus and IEC-104 that stall using protocol-native semantics: Modbus Exception Codes 0x05 and 0x06, and prolonged residence in the IEC-104 connected state without promising data delivery. To the best of our knowledge these are the first application-layer tarpits targeting OT/ICS protocols.
Measuring Internet-exposed Engagement in Protocol-Native OT Tarpits
3
– Live empirical deployment. We deploy five tarpit variants simultaneously for 24 days: three Modbus configurations (1.5 s delay with 0x05 and 0x06 replies, 3 s delay with the same replies, and 1.5 s delay with 0x06 only) and two IEC-104 configurations (1.5 s and 3 s delay), each on a dedicated public IP. Together they attract several thousand sessions and accumulate over 2,000 cumulative hours (approximately 83 days) of scanner engagement time. – Threat-intelligence-corroborated effectiveness. Enriching every connecting address with GreyNoise tags shows that roughly 87–97% of stall time, depending on the variant, is attributable to independently classified malicious-tagged IPs. Protocol-level behavior, specifically Modbus functioncode distribution and IEC-104 protocol-compliance violations, correlates with that classification, yielding fingerprintable defensive signal beyond raw time consumption. – Delay/engagement trade-off. We characterize how induced reply delay shapes scanner behavior. Shorter delays (1.5 s) accumulate more total stall time and more connections per address than longer delays (3 s) in both protocols – but not more unique scanners: IEC-104’s 3 s tarpit in fact drew more unique IPs (605) than its 1.5 s tarpit (338). Longer delays instead show lower aggregate time per session and are measurably harder for common scanning tools to register as a live protocol responder. This gives an actionable parameterization trade-off for future OT tarpit deployments. – Experiment Artifacts. Both tarpits are implemented as standalone, epollbased servers and released as reference artifacts with the anonymized collected data (Appendix A).1 The remainder of the paper proceeds as follows. Section 2 reviews prior work; Section 3 and Section 4 present our design and deployment; Section 5 reports results; Section 6 discusses findings, Section 7 covers limitations and mitigations, and Section 8 concludes and suggests future directions.
2
Related Work
Transport-layer tarpits established stalling as a defensive primitive. LaBrea [17], the Netfilter TARPIT target [24], and distributed SMTP tarpitting [16] hold a connection open beneath the application protocol, regardless of what the connecting party is trying to speak. That uniformity is also their weakness. Degreaser separates them from real hosts at internet scale [2], the countermeasures proposed in response carry artifacts of their own [33], and recent transportlayer deployments against IoT worm propagation inherit the same exposure [14]. Application-layer tarpits answer this by stalling inside a protocol exchange the scanner must understand to disengage, which forces it to hold session state for as long as it stays. Malpity [35] and Endlessh [36] demonstrated the mechanism, and EventHorizon [31] delivered the first internet-scale empirical validation of it, spanning Telnet, MQTT, UPnP, and CoAP. Every application-layer tarpit 1
https://anonymous.4open.science/r/StallGrid-A765/
4
Arthur Cordeiro, Casper Andersen, and Emmanouil Vasilomanolakis
tested so far therefore speaks either an IT protocol such as SMTP or SSH, or an IoT one. None has been built or tested for an industrial protocol, and that is the space this paper occupies. OT is hardware-limited and hard to maintain: legacy control systems resist frequent patching and demand real-time availability guarantees stricter than those of conventional IT [3]. Security has to adapt to that constraint, not the other way around. The deception work that does target OT reflects this constraint rather than escaping it. Ramachandruni and Poornachandran deploy a Modbus honeypot against SCADA attack vectors [28], and Grigoriou et al. build one for IEC 60870-5-104 [15]. Both accept and log traffic passively instead of stalling it. They observe an attacker. They do not impose cost on one. Passive imitation on its own is not sufficient either. Mladenov et al. scan the internet for exposed industrial honeypots and fingerprint them at rates reaching 92% in some protocol categories [22]. A system an attacker can recognize as a decoy has already lost whatever advantage it was deployed for. Yaben et al. measure how OT networks sit exposed on the public internet [38], and the population they find is already large. This environment needs a defense that operates within its hardware and resource limits rather than against them. We introduce the first protocol-aware, application-layer tarpit framework targeting Modbus and IEC-104. For each protocol, we derive stalling behaviour from interaction primitives already defined by the standards [23, 5], namely Modbus Exception Codes 0x05 and 0x06 as well as the IEC-104 connected state. We implement dedicated tarpit behaviours from these primitives that go beyond generic transport-level throttling. In contrast to prior OT deception work, which passively observes and logs attacker activity, our approach is tailored to concrete protocol semantics and imposes engagement cost directly. Importantly, by covering both Modbus’s transactional request-response exchange and IEC-104’s persistent connected session, we also address two distinct session models and evaluate scanner engagement with each under real-world scanner interaction. No prior system combines OT-protocol specificity, active stalling that imposes engagement cost, live internet deployment, and independent threat-intelligence corroboration (Table 1); this paper closes that combined gap.
Table 1: Positioning against the closest related deception systems. System Modbus honeypot [28] IEC-104 honeypot [15] EventHorizon [31] This work
OT Imposes Live Threat-intel protocol stall cost deployment corroborated Yes Yes – Yes
– – Yes Yes
Yes Yes Yes Yes
– – Yes Yes
Measuring Internet-exposed Engagement in Protocol-Native OT Tarpits
3
5
Design
The system comprises two independent tarpits, one per protocol, each emulating the passive server-side role: the Modbus server and the IEC-104 controlled station, accepting only client-initiated connections and never originating traffic. Each runs as a dedicated process implemented in C for deterministic response timing under many concurrent connections. Both share one architectural principle: the stall is produced entirely from protocol-native semantics that keep every exchange specification-compliant, rather than from transport-layer manipulation such as TCP zero-window signaling [30]. 3.1
Modbus Tarpit
Modbus is strictly request-response: the server may transmit only in reply to a client request, never unsolicited [23]. The tarpit exploits this by answering every request not with the requested register, coil, or diagnostic data, but with a Modbus exception response. The specification defines two exception codes whose semantics instruct the client to keep waiting rather than abandon the exchange: 0x05 and 0x06 (Fig. 1a) [23]. Before issuing either, the tarpit inserts a configurable delay sized relative to the approximately two-second default per-request timeout used by common Modbus scanning tools (e.g., Nmap, Metasploit), maximizing socket lifetime without crossing the abandonment threshold. The two codes compose, singly or in sequence: an initial 0x05 reply followed by 0x06 on all subsequent requests is one example. A Read Device Identification alternative (Function Code 43) was also considered, using the More Follows field to invite indefinite chunked retrieval [23], but was not implemented in the current system (Fig. 1b). Acknowledge. Code 0x05 is defined to mean that the server has accepted the request and is processing it, but that a long duration will be required. This response exists to prevent a client timeout [23]. Issuing it licenses the client to keep the connection open indefinitely, awaiting a promised reply the tarpit never sends. The specification’s own wording removes the client’s incentive to disconnect. Server Device Busy. Code 0x06 is defined to mean that the server is engaged in a long-duration program command and that the client should retransmit later, once free [23]. The tarpit answers every retransmission with the same code and keeps no additional state. The client’s own spec-compliant retry behavior sustains the exchange. 3.2
IEC-104 Tarpit
IEC-104 is a stateful, timer-governed protocol, not a fixed request-response exchange. A connection becomes an active data-transfer session only after a STARTDT activation/confirmation exchange. Once active, correctness is enforced
6
Arthur Cordeiro, Casper Andersen, and Emmanouil Vasilomanolakis Client
Server
Function Code
Data Request
Normal Response Exception Code Either normal response or Exception code
(a) Common chronologic schema of a Mod- (b) Our implemented Exception-code stratbus client-server model. egy stalling with 0x05/0x06 codes.
Fig. 1: Modbus request-response behavior and the implemented exception-code stalling strategy under bounded 1.5-/3-second response delays.
by two timers: t1 , the maximum wait for acknowledgment of a sent frame before the connection is deemed failed, and t3 , the maximum idle time before a link-test frame must confirm liveness [5]. The tarpit completes the STARTDT handshake as the controlled station. It then answers the client’s General Interrogation command (Type ID 100, C_IC_NA_1) with a synthetic sequence of I-frames describing information objects of a simulated substation (Fig. 2a), following a standard 110 kV topology used in related IEC-104 intrusion-detection research [8]. For every subsequent command, the tarpit withholds the corresponding data and returns only a supervisory (S-format) APDU, which the standard defines as a receipt acknowledgment carrying no information object.
Supervisory Acknowledgment. Sending the S-format APDU resets the client’s t1 timer without conveying any information object. The link stays formally valid regardless. To survive the t3 interval, the tarpit answers TESTFR activation frames with a TESTFR confirmation, without exchanging application data. Both timers that would otherwise terminate the connection, t1 and t3 , are continuously neutralized (Fig. 2b). The General Interrogation reply remains the only substantive data ever transmitted, and the connection’s state machine stays valid at every layer the client checks even as it makes no further application-layer progress [5]
Measuring Internet-exposed Engagement in Protocol-Native OT Tarpits
7
(a) General Interrogation reply delayed by (b) Supervisory acknowledgment resetinduced latency. ting t1 and t3 .
Fig. 2: IEC-104 stalling strategies using delayed General Interrogation responses and supervisory acknowledgments.
4
Implementation Overview
4.1
Tarpit Implementations
The induced delays were fixed at 1.5 s and 3 s, bracketing the ≈ 2 s per-request timeout assumed by common Modbus scanning tools [26][21]. IEC-104 has no such fixed client default; its connections instead abandon on the t1 /t3 timers [5]. The same 1.5 s/3 s pair was reused there regardless, for cross-protocol comparability. Deployment IP availability limited the study to five tarpits: three Modbus, two IEC-104 (Table 2). Tarpits 1 and 2 share an identical 0x05→0x06 reply strategy and vary only the configured delay magnitude. Tarpit 5 repeats Tarpit 1’s 1.5 s delay but replies with 0x06 only, varying the initial acknowledgment code instead. Tarpits 3 and 4 apply the same 1.5 s/3 s contrast to IEC-104. Each tarpit runs on its own public IP with no rotation or replication of a given delay configuration across IPs (Section 4.3), so these pairings support observed associations between delay and scanner behavior, not an isolated causal effect of delay magnitude alone.
8
Arthur Cordeiro, Casper Andersen, and Emmanouil Vasilomanolakis Tarpit ID # Protocol Strategy 1 2 3 4 5
Modbus Modbus IEC-104 IEC-104 Modbus
Exception Code (0x05→0x06) Exception Code (0x05→0x06) Supervisory Acknowledgment Supervisory Acknowledgment Exception Code (0x06 only)
Response Delay 1.5 s 3s 1.5 s 3s 1.5 s
Table 2: Deployed tarpit implementations: protocol, stalling strategy, and induced delay.
4.2
Metrics
Three categories quantify tarpit behavior. Effectiveness covers connection engagement and intelligence gathered. We report stall time, the connection-open duration summed across sessions, as the primary engagement measure, with concurrent-connection count as a secondary signal; no non-tarpitted control condition was deployed, so stall time is reported as an absolute accumulatedconnection-time quantity rather than as a reduction relative to a baseline (Section 5 treats cross-configuration comparisons accordingly). An open connection is counted as one occupied socket, not necessarily one continuously occupied scanner-side CPU thread; the frequency of client requests supplements this as a coarser activity signal. Network-overhead benchmarking, relevant to higherfrequency IoT threats, falls outside OT’s low-frequency reconnaissance scope and is not measured. Intelligence gathered comes from requests-per-client and concurrent-client counts as proxies for probing intent, and from protocol/client state-machine integrity as a behavioral signal. Practicality, measures whether a tarpit survives the protocol-level handshake check, a valid MBAP header or a STARTDT confirmation, that scanners use to discard non-devices. It is also read from the ratio of silent to requesting connections and their respective durations, which indicates selective engagement of protocol-aware scanners, and from the preference for application-layer stalling over transport-layer manipulation such as TCP zero-window, safer for legacy OT networks. Defensive role, covers the capture of scanner commands for behavioral fingerprinting and the detection of protocol violations, out-of-order packets, invalid sequence numbers, malformed function codes, as a high-fidelity non-compliance signal. It also covers the fusion of captured network data with external threat intelligence, chosen as an independent, third-party reputation source rather than a bespoke classifier to avoid circularity with the tarpit’s own engagement metrics, toward actionable situational awareness beyond simple IP blocking. We treat its tags as corroboration rather than ground truth throughout (Section 6).
Measuring Internet-exposed Engagement in Protocol-Native OT Tarpits
4.3
9
Setup
All five tarpits were hosted on individual DigitalOcean instances in Santa Clara, California, exposing each instance directly to internet-wide scanning. Tarpit 1 went live on May 9, Tarpits 2–4 on May 14, and Tarpit 5 on May 20. All five then ran simultaneously for 24 days before being taken down on June 12. The Modbus tarpits accumulated unequal total uptime, so the subsequent analysis additionally controls for the overlapping period during which all three were live concurrently. Before any tarpit was exposed to the public internet, an internal pre-deployment pass confirmed both that external scanning tools would fingerprint each instance as a genuine device and that a compliant protocol client could complete the expected interaction sequence. Nmap [18], Metasploit [21], and Zgrab2 [7], the same tool population assumed of scanners in the wild, probed each instance during this stage. The Modbus tarpits were further exercised against the pymodbus [27] client library and the IEC-104 tarpits against lib60870-C [25] (via ctypes), covering handshake, keep-alive (TESTFR), supervisory acknowledgment, and generalinterrogation sequences across twelve test cases. Round-trip timing, via Zgrab2 for Modbus, confirmed that the configured 1.5 s/3 s stall held consistently beyond the handshake stage before any tarpit went live. Deployment complied with the scanning-ethics constraints detailed in Appendix B.
5
Results
5.1
Key Findings
This evaluation answers four questions, in the order posed: (RQ1) does stall time scale with the induced per-reply delay for Modbus (Subsection 5.2)? (RQ2) does the same hold for IEC-104 (Subsection 5.3)? (RQ3) how does engagement compare across the two protocols (Subsection 5.4)? (RQ4) how much of that engagement is attributable to independently classified malicious-tagged sources (Subsection 5.5)? No non-tarpitted control was deployed (Section 4.2), so RQ1 and RQ2 use the closest available same-protocol baseline: tarpits sharing an identical reply strategy and differing only in configured delay. Because each tarpit also runs on a distinct public IP with no rotation across configurations, these comparisons are reported as observed associations rather than isolated delay effects (Subsection 6.2 returns to this limitation). Table 3 summarizes per-tarpit session counts, unique IP addresses, connection statistics, and total stall time over the full deployment period. I) Delay-independent stall time, Modbus. During the overlap period, the two 1.5-second Modbus tarpits (Tarpit 1, Tarpit 5) accumulate 563.1 and 577.83 hours of stall time respectively, 75.7% and 80.3% more than the 320.5 hours accumulated by the 3-second tarpit (Tarpit 2), despite the shorter per-reply delay.
10
Arthur Cordeiro, Casper Andersen, and Emmanouil Vasilomanolakis
Table 3: Per-tarpit summary over the full deployment period. Protocol
ID
Sessions
IPs
CM
CP
Mean
Median
Total
Modbus
1 2 5
1537 1092 976
422 352 322
3.64 3.09 3.03
20 28 26
1,877 s 1,411 s 2,136 s
10 s 10 s 10 s
800.46 h 427.89 h 577.83 h
IEC-104
3 4
1345 1759
338 605
3.96 2.91
12 12
294 s 184 s
12 s 10 s
107.38 h 88.91 h
CM: Mean Connections per IP.
CP: Concurrence Peak.
Total: Stall time.
II) Delay-independent stall time, IEC-104. Tarpit 3 (1.5s) accumulates 107.38 hours of stall time against 88.91 hours for Tarpit 4 (3s), 20.7% more, even though Tarpit 4 draws 30.7% more sessions and 77.9% more unique IPs. III) Cross-protocol stall-time asymmetry. Over the overlap period, IEC-104 draws 26.5% more average sessions than Modbus (1212 vs. 958.3) yet accumulates 84.5% less average stall time per tarpit (75.39 vs. 487.1 hours); pairwise comparisons range from 298% to 650% more stall time for Modbus tarpits over IEC-104 tarpits. IV) Threat-intelligence correlation. Malicious-tagged IPs account for 87.3%–97.4% of total stall time across all five tarpits, despite comprising only 22–30% of the unique addresses that connected to any of them (Table 7). 5.2
Modbus Tarpit Performance
For the Modbus tarpits, stall time does not scale with the induced per-reply delay. During the overlap period, the 1.5-second tarpits (Tarpit 1, Tarpit 5) accumulate 563.1 and 577.83 hours of stall time respectively, 75.7% and 80.3% more than the 320.5 hours accumulated by the 3-second tarpit (Tarpit 2), despite the shorter per-reply delay. Over the full deployment period, mean connection durations run 7.77 and 12.08 minutes longer, respectively, on the 1.5-second tarpits than on Tarpit 2, more than offsetting the shorter per-reply wait (Table 3). Mean connection duration (1,877–2,136 s across the three tarpits) far exceeds the median (10 s for all three, Table 3), indicating a heavy-tailed distribution in which a comparatively small number of long-duration sessions account for a disproportionate share of total stall time. Table 4 shows Tarpit 1 receiving the most requests over the full deployment (562) and Tarpit 5 the fewest (385), while Tarpit 5’s stall time still exceeds Tarpit 2’s (472 requests). The difference in active connections is minimal between the three Modbus tarpits, with peaks following similar, semi-synchronized patterns (Figure 3). The distribution of connection durations, shown in Figure 4, has disconnect spikes around 1.5 s for all three tarpits, with only the 3-second-delay tarpit showing a second spike near 3 s. Function Code 43 (Read Device Identification, MEI) accounts for the majority of Modbus requests: 72.7% of all requests over the full deployment (1,031 of
Measuring Internet-exposed Engagement in Protocol-Native OT Tarpits
11
Table 4: Modbus tarpit’s response, Exception Code overall distribution per tarpit. Tarpit
Requests
EC05
EC06
1 2 5
562 472 385
420 336 0
141 131 381
EC05: Exception Code 0x05 (Acknowledge). EC06: Exception Code 0x06 (Server Device Busy).
Fig. 3: Modbus active connections over time
Fig. 4: Modbus connection-duration CDF
1,419) and 72.1% during the overlap period, against 21.4%/22.5% for Function Code 17 (Report Server ID) and 5.9%/5.3% for Function Code 03 (Read Holding Registers) (Table 5). Selective engagement is visible in the silent-versus-requesting split: only 27.3%, 31.2%, and 28.9% of connections to Tarpit 1, 2, and 5 respectively ever issue a valid request, with the requesting and silent populations showing markedly different disconnect-time distributions (Figure 7).
12
Arthur Cordeiro, Casper Andersen, and Emmanouil Vasilomanolakis
Table 5: Modbus client’s valid requests, Function Code overall distribution per tarpit. Tarpit
FC03
FC17
FC43
1 2 5
20 (3.5%) 40 (8.5%) 24 (6.2%)
124 (22.1%) 98 (20.8%) 82 (21.3%)
418 (74.4%) 334 (70.7%) 279 (72.5%)
Total
84
304
1,031
FC03: Read Holding Registers. FC17: Report Server ID. Identification (MEI).
5.3
FC43: Read Device
IEC-104 Tarpit Performance
For the IEC-104 tarpits, stall time again does not scale with the induced perreply delay. Tarpit 3 (1.5s) accumulates 107.38 hours of stall time against 88.91 hours for Tarpit 4 (3s), 20.7% more, even though Tarpit 4 draws 30.7% more sessions and 77.9% more unique IPs. Tarpit 3 also holds a mean connection duration of 294s against Tarpit 4’s 184s, 59.7% longer (Table 3). Table 6 shows comparable protocol-log volumes between the two: Tarpit 3 receives 7% more STARTDT commands and sends 9% more server-initiated TESTFR, while Tarpit 4 receives 22% more I-frames and 12% more client-initiated TESTFR.
Tarpit
STARTDT rcvd
I-frames rcvd
TESTFR rcvd (client)
TESTFR sent (server)
3 4
139 129
45 55
108 121
445 408
Table 6: IEC-104 sessions-log summary: handshake/keep-alive counts per tarpit.
Both IEC-104 tarpits experience temporal peaks in active connections at the same time, though less closely synchronized than the Modbus tarpits (Figure 5). Their connection-duration distributions (Figure 6) show disconnect spikes around 1.5 s and 5 s for both tarpits, with Tarpit 4 additionally showing larger spikes at 3 s and 6 s. Tarpit 3 shows a further spike near 10 s, and both tarpits show later spikes around 30 s and 1000 s. IEC-104 shows a near-total absence of protocol-state-machine violations: no client was disconnected for an invalid sequence number or excessive request rate, and the only application-layer command observed on either tarpit was the type100 General Interrogation. Full compliance with the expected specification sequence is nonetheless partial rather than universal: 57% of Tarpit 3 (1.5s) sessions and 71% of Tarpit 4 (3s) sessions adhere fully to it. A silent-versus-requesting
Measuring Internet-exposed Engagement in Protocol-Native OT Tarpits
13
Fig. 5: IEC-104 active connections over time
Fig. 6: IEC-104 connection-duration CDF
split also holds for IEC-104, with silent connections persisting toward the 1000second mark (Figure 8). 5.4
Cross-Protocol Comparison
Protocol choice compounds the pattern seen within each protocol. Over the overlap period, IEC-104 draws 26.5% more average sessions per tarpit than Modbus (1212 vs. 958.3) yet accumulates 84.5% less average stall time per tarpit (75.39 vs. 487.1 hours). Pairwise comparisons range from 298% to 650% more stall time for Modbus tarpits over IEC-104 tarpits. This per-tarpit average, however, does not hold once volume is summed across each protocol’s full complement of tarpits. Over the full deployment period, aggregate connection volume favors Modbus: 3,605 sessions (1,537+1,092+976) against IEC-104’s 3,104 (1,345+1,759), 16.1% more, and 1,096 cumulative unique IP addresses against IEC-104’s 943, 16.2% more. The reversal follows from tarpit count: Modbus’s three deployments each draw somewhat less traffic than either IEC-104 tarpit individually, but their number pushes cumulative scanning volume for the protocol above IEC-104’s two-tarpit total. Peak concurrency shows
14
Arthur Cordeiro, Casper Andersen, and Emmanouil Vasilomanolakis
the same aggregate skew: the three Modbus tarpits average 24.7 concurrent connections (20, 28, 26) against an identical 12 for both IEC-104 tarpits, more than double. IEC-104 records near-zero hard protocol-state-machine violations: no client is disconnected for an invalid sequence number or an excessive request rate (Subsection 5.3). Full compliance with the expected specification sequence nonetheless holds for only 57% of Tarpit 3 sessions and 71% of Tarpit 4 sessions, leaving 43% and 29% of sessions respectively partially non-compliant without triggering a hard violation; no analogous metric exists for Modbus. The two protocols nonetheless share several structural features. Both show the same non-monotonic relationship between induced delay and accumulated stall time: the shorter-delay tarpit accumulates more stall time than the longerdelay tarpit, for Modbus (Subsection 5.2) and for IEC-104 (Subsection 5.3) alike. Their connection-duration CDFs also share a timing signature, with a disconnectspike cluster around 1.5 s in both (Figure 4 for Modbus, Figure 6 for IEC-104), coinciding with each protocol’s shorter-delay tarpit. A further parallel holds in client engagement: only 27.3%–31.2% of Modbus connections ever issue a valid request (Subsection 5.2), and a comparable silent-versus-requesting split holds for IEC-104 sessions, with requesting and silent populations showing distinct disconnect-time distributions in both protocols (Figures 7, 8).
Fig. 7: Disconnect-time CDF, Modbus (requesting vs. silent)
Reconnection behavior is the one dimension where IEC-104 draws more repeat engagement than Modbus. The Modbus tarpits show reconnection rates of 32.9% (Tarpit 1 and 5) and 34.1% (Tarpit 2), while the IEC-104 tarpits show 48.2% (Tarpit 3) and 48.9% (Tarpit 4), 14–16 percentage points higher.
Measuring Internet-exposed Engagement in Protocol-Native OT Tarpits
15
Fig. 8: Disconnect-time CDF, IEC-104 (requesting vs. silent)
5.5
Threat-Intelligence Correlation
This subsection examines how GreyNoise’s malicious classification correlates with stall time, protocol compliance, and client persistence across both protocols.
Table 7: Session-level summary, by GreyNoise classification of the connecting IPs. Malicious
Benign
Unknown
Protocol
ID
tw
sn
tw
sn
tw
sn
Modbus
1 2 5
720.0 (89.9%) 416.5 (97.4%) 504.6 (87.3%)
977 (63.6%) 636 (58.2%) 576 (59.1%)
80.2 (10.0%) 8.8 (2.1%) 70.7 (12.2%)
434 (28.3%) 337 (30.9%) 279 (28.6%)
0.3 (0.0%) 2.5 (0.6%) 2.5 (0.4%)
125 (8.1%) 119 (10.9%) 120 (12.3%)
IEC-104
3 4
95.4 (88.8%) 78.9 (88.8%)
811 (60.3%) 876 (49.8%)
11.6 (10.8%) 9.5 (10.7%)
384 (28.5%) 682 (38.8%)
0.4 (0.4%) 0.5 (0.6%)
150 (11.2%) 201 (11.4%)
tw: stall time.
sn: session/disconnect count.
Table 7’s session-share column ranks the tarpits by relative malicious exposure: Tarpit 1 highest at 63.6%, then Tarpit 3 (60.3%), Tarpit 5 (59.1%), Tarpit 2 (58.2%), and Tarpit 4 lowest at 49.8%, a 13.8-percentage-point spread end to end. Pooled by protocol, malicious-tagged IPs account for 60.8% of Modbus sessions against 54.3% of IEC-104 sessions. Every tarpit’s malicious time-share also exceeds its malicious session-share, and the disproportion is sharpest exactly where the malicious minority is smallest: from 1.41 times (Tarpit 1, 89.9%/63.6%) up to 1.78 times (Tarpit 4, 88.8%/49.8%), falling monotonically as session-share rises across the five tarpits.
16
Arthur Cordeiro, Casper Andersen, and Emmanouil Vasilomanolakis
Excluding known scanning services (Shodan.io, ShadowServer.org, Infrawatch), every Modbus IP issuing more than three requests across sessions and every IP sustaining long-duration connections is tagged malicious (Figure 9), consistent with every one of the twenty most active clients across all five tarpits, spanning both protocols, carrying a malicious tag. A function-code breakdown of the same Modbus traffic sharpens this picture. Every one of the 84 FC03 (Read Holding Registers) requests recorded across the three tarpits (Table 5) originated from a malicious-tagged IP, though from only a handful of distinct clients; FC17 (Report Server ID), the second-largest category at 304 requests, rarely came from malicious-tagged IPs; and FC43 (Read Device Identification), the dominant category at 1,031 requests, was used broadly across all three GreyNoise classifications rather than concentrating in any one. Session duration diverges just as sharply by classification. Over the overlap period, more than 80% of benign-tagged Modbus sessions disconnect within 10 seconds, against only 20% of malicious-tagged sessions in the same window. The remaining malicious sessions spread across a rounded disconnect curve out to 1,000 seconds, and roughly a third persist to the 2.2–2.3-hour mark before disconnecting, consistent with the concentration of long-duration malicious connections beyond the roughly 7,000-second mark noted above. Among IEC-104 sessions that do not fully complete the expected specification sequence, the malicious-classification rate increases by 24.7% for Tarpit 3 and by 29.4% for Tarpit 4 relative to compliant sessions.
Fig. 9: GreyNoise classification of long-duration Modbus connections
6
Discussion
6.1
Protocol Compliance and Threat-Intelligence Corroboration
We treat GreyNoise tags as a corroboration heuristic, not ground truth, reflecting scanner reputation from independent telemetry rather than a verified label per session. Read cautiously, Section 5.5 (Table 7) shows a real disparity: malicioustagged IPs are only 22–30% of unique connecting addresses across the five tarpits,
Measuring Internet-exposed Engagement in Protocol-Native OT Tarpits
17
Fig. 10: Unique-IP counts by tarpit and GreyNoise classification
yet account for 87.3–97.4% of total stall time. Their session share is already a majority or plurality on its own (49.8–63.6% per tarpit; 60.8% pooled for Modbus, 54.3% for IEC-104). It is the address-versus-stall-time gap, not the session share, that constitutes the minority-owns-majority pattern here. One plausible reading: a small set of persistent, reputation-flagged sources drives most engagement – though tagging itself may simply correlate with the persistence that produces long stalls. A second signal concerns compliance drift. IEC-104 shows near-zero hard state-machine violations alongside only 57%/71% full-sequence compliance for Tarpits 3 and 4 (5.3). Non-compliance here means soft drift, such as I-frames preceding STARTDT acknowledgment, not malformed traffic. Among non-fullycompliant sessions, the malicious-classification rate is 24.7% and 29.4% higher, respectively, than among compliant sessions (5.5). This may reflect deliberate fingerprinting – probing state-machine edges before committing further effort – or naive automation that never fully implements the handshake. The data cannot disentangle these. Hard-violation detection alone would catch almost none of this: soft compliance drift is the more sensitive discriminator here, and could feed OT intrusion-detection heuristics as a candidate feature, though legitimate non-standard implementations could produce identical drift benignly. Modbus shows an analogous but distinct signal: not sequencing, but which function code a client chooses (5.5, Table 5). Function Code 43 (Read Device Identification), the dominant request at roughly 73% of Modbus traffic, appears broadly across malicious, benign, and unknown sources: a generic probe any scanner might send, malicious or not. Function Code 17 (Report Server ID, 304 requests) was likewise rarely malicious-tagged. Function Code 03 (Read Holding Registers), a rarer sensor-level read, appeared only 84 times, yet every instance was malicious-tagged, from just a handful of distinct clients – too small a sample to generalize with confidence. As with IEC-104, anomalies concentrate on the suspicious side while dominant traffic stays tag-agnostic. Here the signal is
18
Arthur Cordeiro, Casper Andersen, and Emmanouil Vasilomanolakis
command choice, not sequence compliance, and FC03 remains fully valid, not malformed. 6.2
Delay and Stall-Time Sensitivity
The delay-to-stall-time association is non-monotonic, and the same association was observed across two structurally different tarpitting strategies. Modbus’s shorter-delay tarpits (1.5s) accumulate 75.7–80.3% more total stall time than its longer-delay tarpit (3s); IEC-104’s shorter-delay tarpit (1.5s) accumulates 20.7% more than its longer-delay tarpit (3s) (5.2, 5.3). A second metric points the same direction in both protocols: mean connection duration is also longer on the shorter-delay tarpit, by 7.77 and 12.08 minutes over the full deployment period for Modbus Tarpits 1 and 5 versus Tarpit 2, and by 59.7% for IEC-104 Tarpit 3 versus Tarpit 4. Two different tarpitting mechanisms – Modbus’s Exception Code strategy and IEC-104’s state-machine stalling – and two independent metrics pointing the same direction is what makes this an association worth reporting, not an artifact of one implementation. It stops short of an isolated causal effect of delay, however: each tarpit occupies its own public IP, delay was not rotated or replicated across IPs (4.1), and IP-specific scanning patterns (e.g., which scanning services happen to target a given address) could contribute to the gap alongside delay itself. The Modbus comparison also rests on heavily right-skewed data – mean connection duration (1,877–2,136 s) far exceeds the median (10 s) for all three tarpits (5.2) – so a relatively small number of long sessions likely drive most of the measured difference in total stall time. This effect concentrates in the minority of traffic that engages at the protocol level: only around 27–31% of Modbus connections ever issue a request (5.2), and raw connection counts otherwise include a large non-requesting population that delay tuning does not touch. A similar split is known for IEC-104 (5.3). Delay reshapes already-engaged clients’ behavior, not the full incoming volume. 6.3
Reconnection Rate and Traffic Analysis
Reconnection rate is a distinct engagement dimension from stall time: a protocol can be revisited often without being expensive per visit, or vice versa. IEC104 tarpits show markedly higher reconnection rates (48.2–48.9%) than Modbus tarpits (32.9–34.1%, 5.4). Two further patterns bear on how that traffic should be read. Connection activity across the deployment period follows a cyclical, roughly daily peak-and-trough shape (3, 5) rather than a flat or purely random arrival process, consistent with scheduled, looped scanning infrastructure of the kind large-scale internet-scanning services routinely run. The longest engaged (non-silent) Modbus sessions, separately, cluster near a duration that lines up with standard TCP keep-alive default timing – roughly two hours plus periodic probe overhead (4) – rather than any duration the tarpit itself induces, suggestive of default OS- or tool-level keep-alive behavior sustaining the session rather than deliberate human persistence. Together, reconnection rate, daily periodicity, and keep-alive-aligned session ceilings point toward scheduled/automated tooling as
Measuring Internet-exposed Engagement in Protocol-Native OT Tarpits
19
the dominant driver of sustained engagement. This reading must be hedged: none of these signals individually rules out a human-in-the-loop process, such as an analyst periodically re-triggering the same tool or manually following up on a scanning service’s output. 6.4
Per-Protocol Engagement and Aggregated Stall Time
Per-tarpit averages and aggregate totals answer different questions. Section 5.4’s data show them diverging here: per tarpit, IEC-104 draws 26.5% more average sessions than Modbus (1212 vs. 958.3), while Modbus accumulates roughly 546% more average stall time per tarpit than IEC-104 (487.1 vs. 75.39 hours; pairwise, 298–650% more for individual Modbus tarpits over individual IEC-104 tarpits). Summed across each protocol’s full deployment, this pattern reverses: three Modbus tarpits draw 3,605 total sessions and 1,096 cumulative unique IPs against two IEC-104 tarpits’ 3,104 sessions and 943 IPs, 16.1% and 16.2% more. The reversal traces to tarpit count, not any single Modbus tarpit outperforming an IEC-104 tarpit: each Modbus tarpit alone draws less traffic than either IEC-104 tarpit, but three combined exceed two. Peak concurrency shows the same skew – Modbus’s three tarpits average 24.7 concurrent connections against an identical 12 for both IEC-104 tarpits, though with only two data points the equality may be coincidental, not a structural ceiling. Per-node efficiency and total defensive yield are separate metrics that can favor different protocols – a distinction any deception-deployment composition decision should track explicitly. With only three and two tarpits, we cannot say whether this reversal holds at larger deployments or different protocol mixes, nor why IEC-104’s per-tarpit session and stall-time trends run opposite directions.
7
Limitations and Mitigations
Tarpitting is structurally fingerprintable. It requires a specific, repeatable sequence of events to function, and a sufficiently capable scanner can detect that sequence; this is a property of the technique, not a defect of this deployment. Mladenov et al. [22] found industrial deception technologies detected at rates reaching 92% in some protocol categories, and Yaben et al. [38] developed techniques specifically to fingerprint noise and uncommon connections behaviors, in OT environments. A second limitation compounds it: all five tarpits ran on same-region instances, each on its own public IP, with no configuration rotation across IPs (Section 4.3). Per-IP conditions are not guaranteed homogeneous. Two same-protocol tarpits differing only in configured delay showed a ≈6% discrepancy in daily unique-IP counts, consistent with IP-specific exposure variance rather than a controlled comparison. This hosting choice was deliberate: separate IPs, rather than a shared host, limit an adversary’s ability to correlate the tarpits and fingerprint the deployment as a whole. Varying the configured reply delay (1.5s vs. 3s) produced no observed difference in threat-intelligence classification: no tarpit was flagged as
20
Arthur Cordeiro, Casper Andersen, and Emmanouil Vasilomanolakis
suspicious, or identified as a tarpit, at a rate that tracked its delay setting. The narrow 22–30% malicious-classification band observed for connecting client IPs across all five tarpits (6.1) points the same way, though it measures a different signal: client reputation, not the tarpits’ own.
8
Conclusion and Future Work
We designed and deployed application-layer tarpits for Modbus and IEC-104, using protocol-native semantics: Modbus Exception Codes 0x05/0x06 and prolonged residence in IEC-104’s connected state machine. To our knowledge, these are the first protocol-native application-layer tarpits for OT/ICS evaluated in a live Internet deployment, extending application-layer tarpitting beyond the generic IoT services targeted by prior work. Five variants ran for 24 days on the open internet, three Modbus and two IEC-104, logging 6,709 sessions and 2,039 cumulative per-tarpit unique-IP observations over 2,000 hours of engagement. GreyNoise enrichment attributes 87–97% of that stall time to independently classified malicious sources, though only 22–30% of connecting addresses carry that tag: a small, persistent population drives most engagement. Two findings complicate a simple engagement-maximizing view of deception. Rare Modbus function-code requests and soft IEC-104 compliance drift both correlate with malicious classification, a fingerprinting signal beyond dwell time. The delay-engagement relationship is also non-monotonic: shorter delays yielded more stall time and longer connections than longer ones in both protocols. With only five variants deployed, per-protocol efficiency trends remain unconfirmed. Two directions follow from these findings. First, our deployment covers only Modbus and IEC-104; OT/ICS spans a wider set of legacy protocols built with little security in mind, and extending the same tarpitting approach across that protocol pool is a direct, low-risk expansion of this work. Second, and more pressing for defenders: Section 7 shows tarpitting is structurally fingerprintable, and prior work has already demonstrated detection of industrial deception technologies [22, 38]. Hardening the deception layer against exactly this adversary is the natural next step before wider OT tarpit deployment.
Measuring Internet-exposed Engagement in Protocol-Native OT Tarpits
A
21
Open Science
For the sake of reproducibility and the artifacts check, we provide the tarpit code and the material used from the tarpit logs: a Modbus TCP tarpit, an IEC 60870-5-104 (IEC-104) tarpit, and the raw connection logs from all five deployments described in the evaluation. These logs allow independent verification of the reported measurements. Source IP addresses are irreversibly pseudonymized through a salted hash, applied consistently across all five logs so repeated connections from the same source remain linkable across deployments. This supports the reconnection-rate analysis in Section 6 without exposing real IP addresses. Timestamps and protocol-level fields, including function codes, frame types, information object addresses, and exception codes, are left unmodified. Code and logs are available at https://anonymous.4open.science/r/ StallGrid-A765/.
B
Ethical Considerations
The EU NIS 2 Directive mandates proactive defense measures from covered entities to prevent and minimize incident impact, motivating tarpitting as a compliant strategy [11]. Both tarpits comply with applicable unauthorized-access and IT-disruption statutes by construction, never disrupting third-party operations. Connecting client IP addresses constitute personal data under Article 4 of the GDPR [10], and Article 89 exempts such processing for scientific research [9]. The collected data is processed solely for this research, by its authors. The ethical justification follows a self-defense and proportionality framework from prior work on defensive cyber deception [29]: harm to a connecting scanner (wasted time and resources probing a non-functional endpoint) does not exceed the harm prevented (reconnaissance against real critical infrastructure). The goal is characterizing aggregate active engagement behavior and assessing tarpit defensive potential, not attributing individual attacks or deanonymizing operators. By design (Section 3), both tarpits accept only client-initiated connections and never originate outbound traffic. Logged data is restricted to connection metadata: timestamps, client IP addresses, and protocol-level fields (function codes, frame types, information object addresses, exception codes). No request-supplied payload is executed or relayed: the tarpits implement only enough protocol statemachine logic to sustain a connection, without simulating device functionality or control. Regarding network bandwidth impact, prior application-layer tarpit deployments report negligible aggregate bandwidth, well under a single HD video stream, since tarpit replies are short, protocol-compliant messages rather than retransmitted payloads [31]. OT networks are, by definition, bandwidth-constrained industrial environments, so this deployment is not an exception.
22
Arthur Cordeiro, Casper Andersen, and Emmanouil Vasilomanolakis
References
1. Alcaraz, C., Zeadally, S.: Critical infrastructure protection: Requirements and challenges for the 21st century. International Journal of Critical Infrastructure Protection 8, 53–66 (2015). https://doi.org/https://doi.org/10.1016/j.ijcip.2014.12.002 2. Alt, L., Beverly, R., Dainotti, A.: Uncovering network tarpits with degreaser. In: Proceedings of the 30th Annual Computer Security Applications Conference. pp. 156–165. ACSAC ’14, Association for Computing Machinery, New York, NY, USA (2014). https://doi.org/10.1145/2664243.2664285 3. Cárdenas, A.A., Amin, S., Sastry, S.: Research challenges for the security of control systems. In: Proceedings of the 3rd USENIX Workshop on Hot Topics in Security (HotSec ’08). USENIX Association, San Jose, CA, USA (2008) 4. Cherepanov, A.: Win32/Industroyer: A new threat for industrial control systems. Tech. rep., ESET Research (June 2017), https://www.welivesecurity.com/ wp-content/uploads/2017/06/Win32_Industroyer.pdf, accessed: 2026-03-03 5. Dansk Standard: Telecontrol equipment and systems – part 5-104: Transmission protocols – network access for IEC 60870-5-101 using standard transport profiles. Standard DS/EN 60870-5-104, Dansk Standard, København (jan 2007), 2. udgave. Identical to IEC 60870-5-104 ED 2.0:2006 and EN 60870-5-104:2006. Replaces DS/EN 60870-5-104:2001. DS projekt: 56519 6. Dragos, Inc.: Intelligence brief: Impact of FrostyGoop ICS malware on connected OT systems. Tech. rep., Dragos Industrial Cybersecurity (July 2024), https://hub.dragos.com/report/ frostygoop-ics-malware-impacting-operational-technology, accessed: 2026-03-03 7. Durumeric, Z., Adrian, D., Stephens, P., Wustrow, E., Halderman, J.A.: Ten years of zmap. In: Proceedings of the 2024 ACM on Internet Measurement Conference. pp. 139–148 (2024) 8. Egger, M., Eibl, G., Engel, D.: Comparison of approaches for intrusion detection in substations using the iec 60870-5-104 protocol. Energy Informatics 3(1), 15 (oct 2020). https://doi.org/10.1186/s42162-020-00118-4 9. European Parliament and Council of the European Union: General Data Protection Regulation (GDPR) Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes. GDPR.eu Platform (2016), https://gdpr.eu/ article-89-processing-for-archiving-purposes-scientific-or-historical-research-purposes-or-statis accessed: 2026-06-25 10. European Parliament and Council of the European Union: Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation). Official Journal of the European Union L 119, 1–88 (2016), https://eur-lex. europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679 11. European Parliament and Council of the European Union: Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive) (2022), https://eur-lex.europa.eu/ legal-content/EN/TXT/?uri=CELEX%3A32022L2555, accessed: 2026-06-25
Measuring Internet-exposed Engagement in Protocol-Native OT Tarpits
23
12. Franco, J., Aris, A., Canberk, B., Uluagac, A.S.: A survey of honeypots and honeynets for internet of things, industrial internet of things, and cyber-physical systems. IEEE Communications Surveys & Tutorials 23(4), 2351–2383 (2021). https://doi.org/10.1109/COMST.2021.3106669 13. Georgoulias, D., Pedersen, J.M., Falch, M., Vasilomanolakis, E.: Botnet business models, takedown attempts, and the darkweb market: A survey. ACM Computing Surveys 55(11) (Feb 2023). https://doi.org/10.1145/3575808 14. Griffioen, H., Doerr, C.: Could you clean up the internet with a pit of tar? investigating tarpit feasibility on internet worms. In: IEEE Symposium on Security and Privacy (S&P). pp. 2551–2565 (2023). https://doi.org/10.1109/SP46215.2023.10179467 15. Grigoriou, E., Liatifis, A., Grammatikis, P.R., Lagkas, T., Moscholios, I., Markakis, E., Sarigiannidis, P.: Protecting IEC 60870-5-104 ICS/SCADA systems with honeypots. In: 2022 IEEE International Conference on Cyber Security and Resilience (CSR). pp. 345–350. IEEE (2022) 16. Hunter, T., Terry, P., Judge, A.: Distributed tarpitting: Impeding spam across multiple servers. In: Proceedings of the 17th USENIX Conference on System Administration (LISA ’03). pp. 259–266 (2003) 17. Liston, T.: Labrea: Sticky honeypot and worm mitigation tool. In: USENIX Workshop on Malicious Code (Malcode) (2001) 18. Lyon, G., The Nmap Project: Nmap Scripting Engine (NSE) Scripts Documentation. https://nmap.org/nsedoc/scripts/ (2026), accessed: 2026-06-25 19. Mandiant Intelligence: Attackers deploy new ICS attack framework ‘TRITON’ and cause operational disruption to critical infrastructure. Tech. rep., Mandiant (FireEye) (December 2017), https://www.mandiant.com/resources/blog/ attackers-deploy-new-ics-attack-framework-triton, accessed: 2026-03-03 20. Mandiant Intelligence: COSMICENERGY: New OT Malware Possibly Related to Russian Cybersecurity Exercises. Tech. rep., Google Cloud (May 2023), https://cloud.google.com/blog/topics/threat-intelligence/ cosmicenergy-ot-malware-russian-response/, accessed: 2026-03-03 21. Metasploit Project Developers: Metasploit framework: Modbus client utility scanner module (modbusclient.rb) (2026), https://github.com/rapid7/ metasploit-framework/blob/master/modules/auxiliary/scanner/scada/ modbusclient.rb, hosted on the official Rapid7 Metasploit-Framework GitHub Repository. Accessed: June 29, 2026 22. Mladenov, M., Erdődi, L., Smaragdakis, G.: All that glitters is not gold: Uncovering exposed industrial control systems and honeypots in the wild. In: 2025 IEEE 10th European Symposium on Security and Privacy (EuroS&P). pp. 133–152 (2025). https://doi.org/10.1109/EuroSP63326.2025.00017 23. Modbus Organization: MODBUS application protocol specification v1.1b3. Protocol specification, Modbus Organization, Inc. (April 2012), https://www.modbus. org/file/secure/modbusprotocolspecification.pdf 24. Morris, J.: Netfilter TARPIT target. linux xtables-addons Project Documentation (2006) 25. MZ Automation GmbH: lib60870: A Library for IEC 60870-5-101/104 Protocols in C. https://github.com/mz-automation/lib60870 (2026), accessed: 2026-06-25 26. Nmap Project: modbus-discover.nse: Nmap scripting engine (NSE) script. https: //github.com/nmap/nmap/blob/master/scripts/modbus-discover.nse (2026), accessed: June 27, 2026 27. pymodbus-dev: pymodbus: A Full Modbus Protocol Implementation in Python. https://github.com/pymodbus-dev/pymodbus (2026), accessed: 2026-06-25
24
Arthur Cordeiro, Casper Andersen, and Emmanouil Vasilomanolakis
28. Ramachandruni, R.S., Poornachandran, P.: Detecting the network attack vectors on scada systems. In: 2015 International Conference on Advances in Computing, Communications and Informatics (ICACCI). pp. 707–712 (2015). https://doi.org/10.1109/ICACCI.2015.7275694 29. Reid, I., Okeke-Ramos, A., Serafin, M.: Exploring the ethics of cyber deception technologies for defensive cyber deception. In: 10th International Conference on Socio-Technical Perspectives in Information Systems: STPIS 2024. pp. 140–148 (2024) 30. Rowe, N.C.: Designing deceptions for protecting industrial control systems. In: Foundations of Cyber Deception: Modeling, Analysis, Design, Human Factors, and Their Convergence, pp. 203–228. Springer (2026) 31. Safargalieva, A., Maddaloni, D., Vasilomanolakis, E.: Eventhorizon: Measuring attacker engagement in multiprotocol iot tarpits. In: 23rd Conference on Detection of Intrusions and Malware & Vulnerability Assessment. Springer (2026) 32. Schachinger, F.K., Rosenstatter, T., Pache, U.: Purity: An industrystandard-based security framework for it-ot convergence. IEEE Access (2026). https://doi.org/10.1109/ACCESS.2026.11478247 33. Shing, L.: An improved tarpit for network deception. Ph.D. thesis, Monterey, California: Naval Postgraduate School (2016) 34. Stouffer, K., Lightnam, J., Pillitteri, V., Rockwell, G.: Guide to operational technology (OT) security. Standard NIST Special Publication (SP) 800-82 Rev. 3, National Institute of Standards and Technology (NIST), Gaithersburg, MD, USA (September 2023). https://doi.org/10.6028/NIST.SP.800-82r3 35. Walla, S., Rossow, C.: MALPITY: Automatic identification and exploitation of tarpit vulnerabilities in malware. In: 4th IEEE European Symposium on Security and Privacy (EuroS&P). pp. 590–605 (2019). https://doi.org/10.1109/EuroSP.2019.00049 36. Wellons, C.: Endlessh: SSH tarpit that slowly sends an endless banner. https: //github.com/skeeto/endlessh (2019) 37. Yaben, R., Lundsgaard, N., August, J., Vasilomanolakis, E.: Towards identifying neglected, obsolete, and abandoned IoT and OT devices. In: Proceedings of the 8th Network Traffic Measurement and Analysis Conference (TMA Conference 2024). IEEE, United States (2024). https://doi.org/10.23919/TMA62044.2024.10558996 38. Yaben, R., Anguita, M., Vasilomanolakis, E.: Measuring what matters: Revisiting internet exposure of ot networks. Computers & Security p. 104911 (2026)