Listen to this Post
Introduction:
A recent discovery by OT security expert Pascal Ackerman has reignited a long-standing cybersecurity crisis: the exposure of industrial control systems (ICS) to the open internet. A simple Shodan search revealed nearly 6,000 Rockwell Automation devices—Programmable Logic Controllers (PLCs) that manage critical manufacturing and infrastructure—accessible from anywhere in the world. This exposure is not just a theoretical risk; it represents an open invitation for threat actors to disrupt physical processes, with many of these devices sitting on networks provided by top telecom carriers, highlighting a severe breakdown in operational technology (OT) security fundamentals.
Learning Objectives:
- Identify how Shodan search queries can be used to discover exposed industrial control systems (ICS) and the associated risks.
- Understand the technical distinction between telecom-provided IP space and actual device ownership in OT exposure.
- Learn to implement firewall rules and network segmentation strategies to mitigate exposure of industrial protocols like EtherNet/IP (Port 44818).
You Should Know:
- Hunting for Exposed OT: Using Shodan and Nmap to Map the Risk
The initial discovery leveraged Shodan.io, a search engine for internet-connected devices. The specific query used was likely “Rockwell Automation” or “port:44818” (the default port for Rockwell’s EtherNet/IP protocol). This reveals not only the device type but often internal IP addresses and organizational ownership data.
To replicate this discovery and understand your own exposure, security professionals and asset owners can use the following methodology:
Step-by-Step Guide to OT Asset Discovery:
- Using Shodan (Web Interface): Navigate to Shodan.io and use search filters such as `port:44818` to find EtherNet/IP devices, or `”Allen-Bradley”` to target Rockwell products. Combine filters like `country:”US”` to narrow results.
- Using Shodan (CLI): For automated searches, use the Shodan CLI tool on Linux.
Install Shodan CLI pip install shodan Initialize with your API key shodan init YOUR_API_KEY Search for exposed Rockwell devices shodan search --limit 10 --fields ip_str,port,org "port:44818 Rockwell"
- Using Nmap for Verification: If you have permission to scan your own assets, use Nmap to identify misconfigured devices. Note: Scanning third-party IPs without authorization is illegal.
Scan a specific host for the EtherNet/IP port nmap -p 44818 --script enip-info <target_ip>
- Windows Alternative: Use PowerShell with Test-NetConnection to check for open ports.
Test-NetConnection -ComputerName <target_ip> -Port 44818
- The Telecom Mirage: Understanding IP Ownership vs. Device Ownership
As highlighted by Gregory Martz and Khris Woodring, a critical misinterpretation often occurs when viewing Shodan results. The “Organization” field listing a telecom provider (e.g., AT&T, Verizon) does not mean the telecom owns the PLC. Instead, it indicates the device is connected via a cellular router (LTE/5G) that uses the telecom’s public IP space. This distinction is vital for incident response; the responsibility for securing the PLC lies with the industrial asset owner, not the ISP.
Step-by-Step Guide to Risk Assessment for Cellular-Connected OT:
- Identify Cellular Gateways: In your network inventory, locate all cellular routers. These devices often have built-in firewalls that may be misconfigured.
- Check for Inbound NAT (Network Address Translation): Access the router’s management interface (often via web or SSH). Review the NAT or Port Forwarding rules. If a rule exists mapping external port 44818 to an internal PLC IP (e.g., 192.168.1.10), the device is critically exposed.
- Linux Command to Verify NAT Traversal (from external perspective with permission):
Use netcat to banner grab and see if the service responds nc -vn <public_ip> 44818
If you receive a response, the port is open and likely forwarding traffic.
- Implement egress filtering: Ensure that cellular routers only initiate outbound connections (VPN tunnels) and do not allow inbound connections from the internet. Configure firewall rules to block all inbound traffic except from a trusted VPN concentrator.
- Protocol Deep Dive: EtherNet/IP (CIP) and the Danger of Port 44818
The Common Industrial Protocol (CIP) used by Rockwell Automation over EtherNet/IP (Port 44818/TCP) is designed for efficiency and real-time control, not security. It lacks native encryption or strong authentication, making it trivial for an attacker to enumerate devices, read logic, and issue malicious commands like starting/stopping motors or altering process values.
Step-by-Step Guide to Simulating an Attack (On Your Own Lab Environment):
– Tool: Wireshark: Capture traffic on a mirrored port where a PLC is connected.
– Filter: `tcp.port == 44818`
– Analyze the “CIP” packets to see unencrypted data, including tag names and values.
– Tool: Python (CIP Library): Using a library like pycomm3, an attacker could enumerate and control a vulnerable device.
from pycomm3 import LogixDriver
Connect to the PLC (Replace with your lab IP)
with LogixDriver('192.168.1.10') as plc:
Read a tag value
value = plc.read('My_Tag')
print(f'Tag value: {value}')
Write to a tag (DANGEROUS)
plc.write('Motor_Start', 1)
– Mitigation: Deploy a firewall with Application Layer Gateway (ALG) or Deep Packet Inspection (DPI) specifically for CIP. Create Access Control Lists (ACLs) that strictly limit which IPs can communicate with the PLC.
Example iptables rule on a Linux-based firewall to allow only a specific management host iptables -A INPUT -p tcp --dport 44818 -s 192.168.100.50 -j ACCEPT iptables -A INPUT -p tcp --dport 44818 -j DROP
- The Long-Standing Failure: Why These Exposures Persist Despite Regulations
Comments from Jason McKinley (2019 discovery) and Isaac J. highlight a critical failure in the security lifecycle: lack of accountability. Even after responsible disclosure, devices remain exposed for years. The primary culprits are third-party integrators who deploy cellular routers for remote access without implementing VPNs or proper firewall rules, and asset owners who lack visibility into their OT networks.
Step-by-Step Guide to Hardening Remote Access:
- Replace Inbound NAT with Outbound VPN: Configure cellular routers to establish a VPN connection to a centralized gateway (e.g., using OpenVPN, IPsec, or a SASE agent). This ensures no ports are open to the internet.
- Linux VPN Server (OpenVPN) Setup Example:
Install OpenVPN on a server apt-get update && apt-get install openvpn -y Generate server keys and configs (using easy-rsa) make-cadir ~/openvpn-ca cd ~/openvpn-ca Follow standard easy-rsa steps to build CA and server certs
- Windows Firewall (for management workstations): Restrict inbound connections to the PLC network.
Block inbound EtherNet/IP traffic on a Windows management machine if it is mistakenly exposed New-NetFirewallRule -DisplayName "Block EtherNet/IP" -Direction Inbound -LocalPort 44818 -Protocol TCP -Action Block
5. Proactive Defense: Continuous Monitoring and Threat Hunting
To prevent becoming a Shodan statistic, asset owners must adopt continuous monitoring. Tools like Shodan’s monitoring service or dedicated OT security platforms can alert when a new device or port appears on the public internet.
Step-by-Step Guide to Automated Scanning for External Exposure:
- Use Shodan Monitor: Configure Shodan to monitor your organization’s IP ranges. Set up alerts for any detected industrial protocols (Modbus, CIP, BACnet, etc.).
- Linux Cron Job with Masscan: For authorized scanning of your own IP ranges to catch rogue devices.
Install Masscan (fast port scanner) apt-get install masscan -y Scan your public IP range for port 44818 (Replace with your IP range) masscan -p44818 203.0.113.0/24 --rate=1000
- Develop an Incident Response Playbook: If an exposed device is found, immediately isolate it by blocking the port at the perimeter firewall. Engage the asset owner to implement a VPN solution.
What Undercode Say:
- Key Takeaway 1: Telecom providers are not the owners of exposed PLCs, but their infrastructure inadvertently enables critical vulnerabilities; security cannot be outsourced to ISPs.
- Key Takeaway 2: The continued exposure of EtherNet/IP (Port 44818) after nearly a decade of warnings demonstrates a systemic failure in OT supply chain security and integration practices.
The article highlights a recurring theme in ICS security: convenience (cellular remote access) continues to override security. The risk is exacerbated by the fact that many industrial devices lack the capability for secure, encrypted communications natively. Asset owners mistakenly rely on “air gaps” that don’t exist, while integrators deploy devices with default configurations. The solution requires a cultural shift where “secure by design” applies to the connectivity layer, mandating that all remote access must traverse a VPN or SD-WAN with strict authentication, ensuring that no industrial protocol ever touches a public-facing IP address.
Prediction:
As we move deeper into 2026, the convergence of IT and OT will accelerate, but so will the frequency of scanning for exposed industrial devices. We predict a major regulatory shift, likely from CISA or similar bodies, mandating that any device using CIP or Modbus over port 44818 or 502 must be isolated behind a managed firewall with verifiable security controls. Failure to comply will result in liability for outages caused by state-sponsored or ransomware groups exploiting these vectors, fundamentally altering how industrial cybersecurity insurance is underwritten.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Pascal Ackerman – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
