Industrial Control Systems (ICS) continue to face growing threats from unknown actors. Recent activity underlines the growing threat to critical national infrastructure, with ICS environments increasingly in the crosshairs. Examples include the recent targeting of Minnesota towns by unidentified threat actors, as well as threats from Iran to strike Industrial Control Systems (ICS) across Europe and the United States. One study found that damage to just nine electric substations could lead to eighteen months of blackouts across the United States.
As these threats have grown, so has attention from security researchers and threat hunters, resulting in an increasing number of honeypots deployed across the Internet. Honeypots in ICS are decoy systems designed to look like real industrial infrastructure or entire simulated plant environments. ICS threat hunters and security researchers, including red teamers, need strong operational awareness when conducting research in order to be effective at identifying new risks.
Security researchers have long relied on decoy infrastructure to capture malicious files and data samples, and we have applied this approach directly in past research. One notable example involved hosting free emailer services, an approach that carries significant risk if not set up anonymously. Throughout this work, we recorded and logged all traffic and system interactions for analysis, cross-referencing, and reporting on concerning or criminal activity. Law enforcement was involved throughout to ensure our safety.
This type of work highlights the importance of building realistic honeypot services that can capture actionable data and help expose genuine threat actors.
The Problem with Poorly Designed ICS Honeypots
Recent news has driven an increase in the number of security research companies deploying honeypots and research equipment to capture malicious traffic targeting these systems.
This surge in research, however, has introduced a great deal of unusable noise into the industry regarding the exposure of IACS devices, such as PLCs, on the Internet. Threat-hunting companies and news organizations that rely on Internet search archive services such as Shodan, ZoomEye, or Censys often present a troubling picture, though not always for the reasons they cite.
Below is a screenshot of a ZoomEye search for devices on the Internet listening on TCP port 502 (Modbus). The figure of 39,537 results can appear alarming until factors such as legacy time periods, unlikely ASNs, device signatures, SSL certificates, and inaccurate hash values are ruled out. When the search is narrowed to the period from January 1, 2026, to January 1, 2027, the number drops to approximately 4,000 devices. However, most of these are low-quality, unrealistic honeypots, as illustrated below.
Using the sample above, several red flags indicate that a host appearing to be a PLC device is in fact a honeypot. The exposed device claims to be a V570-57-T34, a PLC with a built-in HMI.
Source: https://www.unitronicsplc.com/vision-series-vision570/
The ASN associated with the device is Amazon, which is notable and unlikely for a genuine IACS environment, though Amazon does offer an IoT service designed for uploading ICS data.
Because Unitronics software can run on Windows hosts or within virtual environments, further analysis of this host was conducted to identify additional signs of poor operational security.
ZoomEye shows that the device presents a TLS certificate associated with GE iFIX, a SCADA solution, which could suggest that it is a genuine exposed ICS device.
However, Modbus does not use TLS certificates for communication, as it is a clear-text protocol. While this could potentially originate from a pass-through device, the V570-57-T34 with firmware 4.3.17 does not support TLS on its network card. In addition, GE iFIX SCADA software would not emulate a PLC on TCP/502.
Based on the manufacturer's documentation and using Shodan and Censys data on the IP address, it is unlikely that the claimed PLC or GE iFIX software would present the open service ports documented by these services.
Conclusion of this example: This host is a case of poor operational security (OPSEC) and is trivial to identify as a honeypot running non-custom ICS honeypot software. This honeypot is unlikely to capture any realistic threat actor samples or actionable data.
Lessons for Building Better ICS Honeypots
The first lesson from the example above is that ICS threat hunters need to use custom honeypot software that exposes only realistic ports and services matching the emulated device.
The second lesson is to avoid hosting honeypots on cloud service providers such as Amazon, DigitalOcean, or Linode, and to ensure the honeypot doesn't present TLS certificates on a clear-text protocol. So this raises the question, if a cloud provider isn’t being used, where can a threat hunter more effectively set up a honeypot?
Many ICS sites are remote and rely on RF, cellular, LoRa, or increasingly Starlink for monitoring and remote access.For example, Using Shodan and adjusting the search query to focus on a cellular provider, T-Mobile, on TCP port 502 returns 176 results. How do these results compare to the ZoomEye query?
A review of several randomly selected IP addresses from these results suggests they are far more likely to represent real devices, and can help threat hunters improve their honeypot deployments. Common themes among these results include the absence of captured SSL data for Modbus, and geographical locations and live ports that are consistent with genuine ICS devices.
Deploying a custom ICS honeypot on a cellular or LoRa service provider network can help threat hunters obtain better research data. Threat hunters with LTE capture devices can consider placing them near known ICS sites, or work with organizations that operate ICS environments to gain reasonable geographical metadata.
For safety reasons, it is worth noting that cellular triangulation can disclose the location of a device. Conducting threat hunting activities from an unsecured or personal location carries real risks and is not advisable.
Conclusion
Exposure of ICSon the Internet remains a genuine concern, even amid the noise generated by low-quality honeypots. The cellular provider search example in this article was intended to demonstrate simple techniques threat hunters can use to capture more reliable and actionable results. Despite ongoing news coverage and active threats, this single query revealed the potential exposure of 179 ICS devices in the United States from one service provider alone in 2026, underscoring the continued need for realistic, well-designed honeypot research.
LRQA's custom, safety-first penetration testing service for IACS environments is designed not only to identify an organization's attack surface, but also to help protect, monitor, and defend these environments against realistic threat actors. If you have questions about your ICS environment, please contact us for assistance.
Only OSINT was used in the creation of this article. No active scanning or device enumeration was performed. This article is for general informational and educational purposes only and does not constitute professional cybersecurity, legal, or technical advice. Tools, techniques, or examples referenced are for awareness only and should not be used to test systems or networks without proper authorization or guidance from a professional.
