StallGrid: Measuring Internet-exposed Engagement in Protocol-Native OT Tarpits

1 Introduction

• OT/ICS compromise can disrupt physical processes, while patching is constrained by availability requirements and long equipment lifecycles.The paper contrasts this setting with prior application-layer tarpit evidence from generic IoT protocols.Source: §1 · p. 2
• The paper introduces the first application-layer tarpits for OT/ICS, using Modbus exception codes 0x05/0x06 and prolonged residence in IEC-104’s connected state.The approach is evaluated against live scanning traffic enriched with independent threat intelligence.Source: §1 · p. 2
• Five variants ran simultaneously for 24 days, attracting several thousand sessions and accumulating over 2,000 hours of scanner engagement.The variants comprised three Modbus configurations and two IEC-104 configurations.Source: §1 · p. 3
• 87–97% of stall time was attributable to malicious-tagged IPs, while protocol-level behavior also correlated with malicious classification.The paper presents protocol behavior as a fingerprinting signal beyond raw time consumption.Source: §1 · p. 3
• Shorter 1.5 s delays accumulated more total stall time and more connections per address than 3 s delays in both protocols, but not more unique scanners.IEC-104’s 3 s tarpit drew 605 unique IPs, compared with 338 for its 1.5 s tarpit.Source: §1 · p. 3

2 Related Work

• Prior application-layer tarpits addressed IT and IoT protocols, but none had been built or tested for an industrial protocol.Earlier examples include SSH and a multiprotocol deployment covering Telnet, MQTT, UPnP, and CoAP.Source: §2 · pp. 3–4
• OT patching is constrained by hardware limits and real-time availability requirements, motivating defenses that operate within those constraints.The cited OT honeypots observe attackers but do not stall them.Source: §2 · p. 4
• Existing OT deception systems passively accept and log traffic, whereas this work uses protocol semantics to impose engagement cost directly.The framework spans Modbus’s transactional exchange and IEC-104’s persistent connected session.Source: §2 · p. 4
• The paper identifies a combined gap: no prior system paired OT-protocol specificity and active stalling with live deployment and independent threat-intelligence corroboration.The positioning is summarized against related deception systems in Table 1.Source: §2 · p. 4, Table 1 · p. 4

3 Design

• The design produces stalls through protocol-native semantics that keep exchanges specification-compliant, rather than through transport-layer manipulation.The two independent tarpits emulate passive server-side roles and accept only client-initiated connections.Source: §3 · p. 5

3.1 Modbus Tarpit

• For Modbus, each request receives a delayed exception response using code 0x05, code 0x06, or both in sequence.Code 0x05 indicates accepted, long-duration processing; 0x06 directs the client to retransmit later, and repeated retransmissions receive the same code.Source: §3.1 · p. 5

3.2 IEC-104 Tarpit

• For IEC-104, the tarpit completes STARTDT, answers General Interrogation with synthetic I-frames, then sustains the session with supervisory acknowledgments and TESTFR confirmations.S-format acknowledgments reset t1 without conveying information objects, while TESTFR confirmations maintain liveness across t3.Source: §3.2 · pp. 5–6

4.1 Tarpit Implementations

• Five configurations use 1.5 s or 3 s delays: three Modbus variants and two IEC-104 variants.Modbus Tarpits 1 and 2 vary delay with the same 0x05→0x06 strategy; Tarpit 5 uses 0x06 only, and IEC-104 Tarpits 3 and 4 vary delay.Source: §4.1 · p. 7, Table 2 · p. 8

4.2 Metrics

• Engagement is measured primarily as absolute accumulated connection-open time, with concurrent connections as a secondary signal and no non-tarpitted control.Network-overhead benchmarking is outside the study’s scope; requests per client and protocol-state integrity serve as behavioral signals.Source: §4.2 · p. 8
• The evaluation also measures protocol-check survival, silent versus requesting connections, protocol violations, and threat-intelligence corroboration.GreyNoise tags are treated as corroboration rather than ground truth.Source: §4.2 · p. 8

4.3 Setup

• All five DigitalOcean instances ran in Santa Clara for 24 days, with each tarpit on its own public IP.Pre-deployment checks exercised scanning tools and compliant clients; Modbus timing checks confirmed the configured delays before exposure.Source: §4.3 · p. 9

5.1 Key Findings

• 1.5-second variants accumulated 75.7% and 80.3% more Modbus stall time, and 20.7% more IEC-104 stall time, than their 3-second counterparts.For IEC-104, the 3-second tarpit nevertheless drew 30.7% more sessions and 77.9% more unique IPs.Source: §5.1 · pp. 9–10
• Malicious-tagged IPs accounted for 87.3%–97.4% of total stall time while comprising only 22–30% of connecting unique addresses.The reported shares vary across the five tarpits.Source: §5.1 · p. 10

5.2 Modbus Tarpit Performance

• Modbus connection durations were heavy-tailed: mean durations of 1,877–2,136 seconds exceeded the 10-second median for all three tarpits.Function Code 43 represented 72.7% of full-deployment requests; only 27.3%–31.2% of connections ever issued a valid request, and requesting versus silent connections had different disconnect-time distributions.Source: §5.2 · pp. 10–11

5.3 IEC-104 Tarpit Performance

• IEC-104’s 1.5-second tarpit accumulated 107.38 hours of stall time versus 88.91 hours for the 3-second tarpit, with a 59.7% longer mean connection duration.No clients were disconnected for hard state-machine violations, although only 57% and 71% of sessions fully followed the expected sequence; silent connections persisted toward 1,000 seconds.Source: §5.3 · pp. 12–13

5.4 Cross-Protocol Comparison

• IEC-104 averaged 26.5% more sessions per tarpit than Modbus but 84.5% less average stall time; pairwise comparisons favored Modbus by 298%–650%.Both protocols shared disconnect spikes near 1.5 seconds and a silent-versus-requesting split.Source: §5.4 · pp. 13–14
• Across all deployments, Modbus recorded 3,605 sessions and 1,096 unique IPs versus IEC-104’s 3,104 sessions and 943 IPs; Modbus also averaged more than twice the peak concurrency.These are observed associations: each tarpit used a distinct public IP, and no non-tarpitted control was deployed.Source: §5.1 · p. 9, §5.4 · pp. 13–14

5.5 Threat-Intelligence Correlation

• Malicious-tagged IPs’ stall-time share exceeded their session share at every tarpit, ranging from 1.41 times at Tarpit 1 to 1.78 times at Tarpit 4.Across pooled sessions, malicious-tagged IPs represented 60.8% of Modbus sessions and 54.3% of IEC-104 sessions.Source: §5.5 · p. 15
• More than three Modbus requests per IP and long-duration connections were associated with malicious tags, while over 80% of benign-tagged Modbus sessions ended within 10 seconds.All 84 FC03 requests came from malicious-tagged IPs; among IEC-104 sessions not fully compliant with the expected sequence, malicious classification was 24.7% and 29.4% higher for Tarpits 3 and 4, respectively.Source: §5.5 · p. 16

6.1 Protocol Compliance and Threat-Intelligence Corroboration

• Malicious-tagged IPs are 22–30% of connecting addresses but account for 87.3–97.4% of total stall time.Their session share is 49.8–63.6% per tarpit; GreyNoise tags are treated as corroboration, not ground truth.Source: §6.1 · pp. 16–17
• IEC-104 non-fully-compliant sessions show 24.7% and 29.4% higher malicious-classification rates, while Modbus FC03 was malicious-tagged in all 84 requests, a sample too small to generalize.IEC-104 drift was soft, not malformed; the data cannot distinguish deliberate probing from naive automation, and FC43 was a generic probe across classifications.Source: §6.1 · pp. 17–18

6.2 Delay and Stall-Time Sensitivity

• Modbus 1.5 s tarpits accumulated 75.7–80.3% more stall time than the 3 s tarpit, and IEC-104’s 1.5 s tarpit accumulated 20.7% more.Only around 27–31% of Modbus connections issued a request, and separate public IPs without delay rotation or replication prevent isolating delay as the cause.Source: §6.2 · p. 18

6.3 Reconnection Rate and Traffic Analysis

• IEC-104 tarpits had 48.2–48.9% reconnection rates versus 32.9–34.1% for Modbus, while daily cycles and keep-alive-aligned Modbus session ceilings suggest automated tooling.These signals do not rule out a human-in-the-loop process, such as an analyst periodically rerunning a tool.Source: §6.3 · pp. 18–19

6.4 Per-Protocol Engagement and Aggregated Stall Time

• Summed across deployments, Modbus had 3,605 sessions and 1,096 cumulative unique IPs versus IEC-104’s 3,104 sessions and 943 IPs, despite lower per-tarpit session averages.The aggregate reversal follows from comparing three Modbus tarpits with two IEC-104 tarpits; the study cannot establish whether it holds at larger deployments or different protocol mixes.Source: §6.4 · p. 19

• Tarpitting is structurally fingerprintable because it requires a repeatable event sequence that a sufficiently capable scanner can detect.Prior work found industrial deception detection rates reaching 92% in some protocol categories and developed OT techniques to fingerprint noise and uncommon connection behaviors.Source: §7 · p. 19
• All five tarpits ran on same-region instances with separate public IPs and no configuration rotation, and same-protocol delay variants differed by about 6% in daily unique-IP counts.The discrepancy is consistent with IP-specific exposure variance, so per-IP conditions cannot be assumed homogeneous.Source: §7 · p. 19
• Separate IPs were intended to limit adversary correlation, and no tarpit was identified at a rate that tracked its configured delay.The 22–30% malicious-classification band describes client reputation, not whether the tarpits themselves were detected.Source: §7 · pp. 19–20

8 Conclusion and Future Work

• Five variants ran for 24 days, logging 6,709 sessions, 2,039 cumulative per-tarpit unique-IP observations, and over 2,000 hours of engagement.GreyNoise attributed 87–97% of stall time to malicious-tagged sources, which accounted for 22–30% of connecting addresses.Source: §8 · p. 20
• Rare Modbus function-code requests and soft IEC-104 compliance drift correlated with malicious classification beyond dwell time, while 1.5-second delays yielded more engagement than 3-second delays in both protocols.The paper characterizes protocol behavior as a fingerprinting signal and reports the shorter-delay pattern across both protocols.Source: §8 · p. 20
• The deployment covered only Modbus and IEC-104, and the authors identify fingerprinting resistance as a next step before wider OT tarpit deployment.They also propose extending the approach to other legacy OT/ICS protocols.Source: §8 · p. 20

A Open Science

• Code, tarpit materials, and raw connection logs from all five deployments are provided for reproducibility and independent verification.The materials include a Modbus TCP tarpit and an IEC-104 tarpit.Source: A Open Science · p. 21
• Source IP addresses are irreversibly pseudonymized with a salted hash applied consistently across logs, preserving cross-deployment linkability for reconnection-rate analysis.The approach avoids exposing real IP addresses while retaining the ability to link repeated connections from the same source.Source: A Open Science · p. 21
• Timestamps and protocol-level fields, including function codes, frame types, information object addresses, and exception codes, remain unmodified.Source: A Open Science · p. 21

B Ethical Considerations

• The paper states that NIS 2 mandates proactive defense for covered entities and that GDPR Article 89 exempts scientific-research processing of personal data.It says the collected data is processed solely for this research by the authors.Source: B Ethical Considerations · p. 21
• The authors frame tarpitting as a proportional self-defense measure because wasted scanner time and resources do not exceed the harm the approach aims to prevent.The goal is aggregate engagement analysis, not attribution of individual attacks or deanonymization.Source: B Ethical Considerations · p. 21
• The tarpits accept only client-initiated connections, collect connection metadata, and neither execute nor relay request-supplied payloads.They implement only enough protocol state-machine logic to sustain connections, without simulating device functionality or control.Source: B Ethical Considerations · p. 21
• The paper cites prior deployments reporting aggregate bandwidth well under a single HD video stream, while noting that OT networks are bandwidth-constrained.Source: B Ethical Considerations · p. 21