Listen to this Post
Introduction:
Operational Technology (OT) security is often portrayed as a battle of firewalls, intrusion detection systems, and AI-driven analytics. Yet beneath every industrial control system lies a far simpler reality: dry contacts. These passive, powerless electrical interfaces—two metal points that are either open or closed—form the atomic unit of OT state awareness, and without mastering them, your entire cybersecurity strategy rests on fragile sand.
Learning Objectives:
- Understand the definition and electrical behavior of dry contacts versus wet contacts in OT environments
- Learn to simulate, monitor, and manipulate dry contact states using Linux and Windows command-line tools
- Apply contact logic to detect physical tampering, automate incident response, and integrate OT state changes into modern SIEM workflows
You Should Know:
- Dry Contact Basics – The Switch That Powers No Logic
As Zakhar Bernhardt explains, a dry contact is simply two metal points with no internal power and no embedded logic. It behaves exactly like a household wall switch: flip it, metal touches or separates, and an externally powered circuit changes state. In industrial systems, this binary state represents everything—door open/closed, pump running/stopped, alarm active/inactive, emergency stop triggered or not.
Step‑by‑step identification and verification:
- Locate dry contact terminals on a PLC I/O module, relay, or sensor. They are typically labeled COM (common), NO (normally open), and NC (normally closed).
- Use a multimeter in continuity mode (resistance or beeper). Power off the circuit. Place probes across COM and NO: open circuit = no beep; closed circuit = beep.
- Check for external power – measure voltage across contacts with power applied. Dry contacts should show 0V when open and full system voltage (e.g., 24V DC) when closed, but the contact itself does not generate that voltage.
- Document expected states for security baselining: e.g., “Emergency stop NC closed under normal operation; open indicates trip.”
-
Simulating Dry Contact Logic on Linux with GPIO and Serial Lines
To test security monitoring scripts without physical hardware, you can emulate dry contact behavior using Linux GPIO pins (on Raspberry Pi or similar) or even serial handshake lines.
Linux GPIO simulation (using libgpiod):
Install gpiod utilities sudo apt install gpiod Read state of GPIO pin 18 (assumes contact is connected to this pin) gpio get 18 Simulate a dry contact closing (set output high – external circuit powered) gpio set 18=1 Simulate contact opening gpio set 18=0 Monitor pin changes continuously gpio monitor 18
Windows alternative – use DTR/CTS serial lines as dry contacts:
Open COM1 and control DTR line (acts like a dry contact closure)
mode COM1 BAUD=9600 PARITY=N DATA=8 STOP=1
$sp = <a href=":new("COM1").Open()">System.IO.Ports.SerialPort</a>::new("COM1")
$sp.DtrEnable = $true contact closed
$sp.DtrEnable = $false contact open
Python script to log state changes (cross‑platform):
import RPi.GPIO as GPIO Linux only; for Windows use pyserial
GPIO.setmode(GPIO.BCM)
GPIO.setup(18, GPIO.IN, pull_up_down=GPIO.PUD_UP)
while True:
state = GPIO.input(18)
print(f"Dry contact state: {'CLOSED' if state == 0 else 'OPEN'}")
time.sleep(0.5)
- Capturing OT Contact Logic in Flight Using Wireshark and Modbus
Dry contacts are read by PLCs, which then communicate over industrial protocols like Modbus TCP. By sniffing this traffic, you can observe contact state changes as they happen on the wire – a critical skill for intrusion detection.
Step‑by‑step capture and analysis:
1. Install Wireshark or use `tshark` command line.
- Start capture on the OT network interface (e.g.,
eth0):sudo tshark -i eth0 -Y "modbus.func_code == 1" -T fields -e frame.time -e modbus.coil_addr -e modbus.coil_value
– Filter `modbus.func_code == 1` captures “Read Coils” requests (coils are the Modbus representation of dry contact outputs).
3. Trigger a physical contact change (e.g., open a door sensor). Watch for the corresponding coil register toggling between 0 and 1.
4. Export a baseline of normal toggling frequency. Unexpected rapid toggling could indicate a relay attack or mechanical fault.
5. For offline analysis, save to a `.pcap` and use:
tshark -r capture.pcap -Y "modbus.func_code == 1 and modbus.coil_value == 1" -T fields -e frame.time -e modbus.coil_addr
4. Hardening Dry Contact Interfaces Against Physical Tampering
Dry contacts are vulnerable to simple physical attacks: wire cutting, bridging, or relay injection. Mitigate these with hardware and software controls.
Hardening configuration (example for Siemens S7‑1200):
- Enable input debounce (typically 6–10ms) to ignore short glitches from tampering attempts.
- Configure wire break detection if supported – many modern digital inputs can detect an open circuit versus a valid 0 state.
- Use sealed contacts (reed relays or optocouplers) to prevent external voltage injection.
Software monitoring script (Linux with Modpoll):
Install modpoll from https://www.modbusdriver.com/modpoll.html Read coil 10 every second and alert if state changes >3 times in 10 seconds modpoll -m tcp -a 1 -r 10 -c 1 -t 1 192.168.1.100 | while read value; do Count changes with a sliding window (simplified) echo "$(date) Coil10=$value" >> dry_contact.log done
Windows PowerShell watchdog:
while ($true) {
$state = (Invoke-WebRequest -Uri "http://plc/api/coil10" -UseBasicParsing).Content
if ($state -eq $lastState -and $toggleCount -gt 2) {
Write-Warning "Excessive toggling detected on dry contact 10"
Send alert to SIEM or email
}
Start-Sleep -Seconds 1
}
- Integrating Dry Contact State into OT SIEM Pipelines
Treat each dry contact change as a security-relevant event. Forward these events to a central SIEM using lightweight gateways.
Use `socat` to relay Modbus data to syslog:
On a Raspberry Pi connected to the PLC network socat TCP:192.168.1.100:502 UNIX-LISTEN:/tmp/modbus.sock,fork Then run a custom script that reads coils and logs to syslog
Example Python script using `pymodbus` and `logging` to syslog:
from pymodbus.client import ModbusTcpClient
import logging, syslog
client = ModbusTcpClient('192.168.1.100')
client.connect()
while True:
rr = client.read_coils(10, 1) read coil 10
if rr.isError():
syslog.syslog(syslog.LOG_ERR, f"Dry contact read error: {rr}")
else:
syslog.syslog(syslog.LOG_INFO, f"Dry contact 10 = {rr.bits[bash]}")
time.sleep(0.5)
Forward to SIEM (Splunk/ELK): Configure rsyslog on the gateway:
/etc/rsyslog.d/50-ot.conf . @192.168.1.200:514 forward all syslog to SIEM collector
What Undercode Say:
- Key Takeaway 1: AI and high‑level analytics are useless if you don’t understand the physical layer. Dry contacts are the irreducible state atoms of OT – every response, alarm, and control action ultimately depends on them.
- Key Takeaway 2: Security monitoring must include state change frequency and wire integrity checks; many OT attacks first manifest as anomalous contact toggling (e.g., opening a safety door before injection).
Analysis: The post by Zakhar Bernhardt cuts through the “AI slop trap” – where practitioners copy generic recommendations without grasping fundamental electrical logic. In OT security, a compromised dry contact can bypass even the most expensive firewall. For example, an attacker who physically shorts an emergency stop contact disables all downstream protection logic. Conversely, a security engineer who understands that dry contacts carry no power and no logic can build isolated, tamper‑evident sensing circuits. Bernhardt’s Labshock GRID initiative recognizes that modern power zones still rely on this 19th‑century invention. Your job is not to replace dry contacts, but to monitor them ruthlessly.
Prediction:
Over the next three years, as OT environments adopt “digital twins” and AI‑driven anomaly detection, the most overlooked vulnerabilities will remain physical dry contacts. Expect a rise in “contact injection” attacks – using low‑cost microcontrollers to toggle dry contact states at high speed, inducing control system confusion or wear‑out failures. The winning security architectures will combine real‑time contact state monitoring (via edge gateways) with behavioural baselines, and will reject any AI model that cannot explain its output in terms of open/closed circuits. Those who skip the basics will chase ghosts in the code while the real switch flips silently.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Zakharb Labshock – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
