An Open Source Tool for Safely Analyzing Exposed Modbus PLCs

Why active scanning is a liability on fragile industrial control streams, and how to fingerprint real PLCs vs. honeypots down to register entropy. The Problem with Modbus Being on the Internet Modbus was designed in 1979. It was built for closed, serial networks where the core architectural assumption was simple: if you could physically reach the wire, you were supposed to be there. There was no authentication. No encryption. No concept of an untrusted caller. That assumption held for decades. Then came Ethernet encapsulation. Then came remote monitoring. Then came cloud connectivity and the slow, steady erosion of the physical air-gap that industrial engineers took for granted. Today, you can find thousands of Modbus devices exposed on Shodan. Public IP addresses, port 502, responding to anyone who sends a valid request frame. Some of them are real Programmable Logic Controllers (PLCs) in actual facilities. Some are misconfigured building automation systems. Some are honeypots. Telling those three apart without disrupting whatever physical process they are attached to is not as straightforward as it sounds. That is the exact problem MEA (Modbus Exposure Analyzer) is built to solve. What MEA Actually Does MEA is a passive behavioral analysis tool for Modbus TCP devices. "Passive" matters infinitely more in an Operational Technology (OT) context than it does in traditional IT. In industrial environments, sending unexpected or aggressive traffic to a legacy device isn't just a network etiquette issue. It can trigger a buffer overflow, lock up the communications module, or interrupt a physical process. You do not probe a PLC controlling a high-pressure pump the same way you run a loud, multi-threaded nmap script against a standard web server. MEA works by observing. It reads register data over structured cycles, measures behavioral patterns over time, analyzes data entropy, and monitors for structural changes. It doesn't write anything. It doesn't send malicious payloads. It gathers enough signal to tell you something meaningful about a device without touching its operation. The core engineering goal is to answer three questions: Is this device real or simulated? Honeypots and simulators behave differently from genuine industrial hardware under sustained observation. Register values on real devices drift in ways that reflect actual physical processes (like thermal lag or fluid dynamics). Simulated registers tend to be static, entirely randomized, or artificially varied in linear patterns that don't match the physics of real sensors. How exposed is it? What registers are reachable, what function codes are responding, and does the exposure profile match what you would expect from a device in this environment? What is the actual risk? Not a generic vulnerability score generated by an automated scanner, but a contextual risk assessment grounded in what the data reveals about the device’s role. Under the Hood: How the Analysis Engine Works 1. Behavioral Fingerprinting The first thing MEA does when interacting with a target is track register values across multiple sequential read cycles. Real industrial sensors have a characteristic kind of physical noise. Temperature sensors drift by fractions of a degree. Flow meters fluctuate constantly based on mechanical variance. A PLC running an active loop shows data changes that mirror the real world. Simulators rarely replicate this accurately. They usually hold values completely constant, loop through obvious linear counters, or use standard pseudo-random number generators that fail statistical randomness tests for physical environments. MEA measures this variance and uses it as a primary signal for classification. 2. Register Data Entropy Analysis Each register read gets processed through an entropy scoring mechanism. The goal is anomaly detection. Finding specific registers that behave in ways completely out of sync with the surrounding address space. | Analysis Vector | Target Profile | Indicator | |----|----|----| | Low Entropy / Static | Setup registers, dead channels, or basic simulators | Values never change or follow rigid, predictable counters | | Natural Fluctuations | Real physical sensors (temp, pressure, flow) | Characteristic background noise and statistical drift over time | | Abnormal High Entropy | Packed data, encrypted payloads, or erratic simulators | Information-dense changes that stand out from adjacent low-entropy blocks | This is the same foundational logic that drives entropy analysis in malware detection to find packed or encrypted sections of a binary. The same math applies to register spaces that don't match their neighbors. 3. Structural Monitoring Over Time A single snapshot of a Modbus device tells you significantly less than you'd think. MEA watches registers across extended cycles to catch things a one-time scan misses entirely… registers that only update when specific physical conditions are met, or patterns that only emerge when analyzed over minutes rather than milliseconds. This tracking catches a subtle edge case: devices that look perfectly normal during the first few packets but display anomalous, repetitive, or artificial behavior under sustained observation. Context-Driven Risk Mapping The risk output from MEA isn't a static number plugged into a generic CVSS calculator. It is built by correlating what the device is, how its address space is exposed, and what its operational footprint looks like. A Modbus interface responding on a public IP with open registers mapping to physical actuators represents a catastrophic operational risk. The exact same protocol interface exposed within a monitored DMZ with strict read-only constraints represents an entirely different architectural problem. Context matters in industrial control security in ways it rarely does in IT, and the analysis engine is built to reflect that distinction. Who This Tool Is For Security Researchers: Doing highly targeted, passive reconnaissance on internet-facing infrastructure without risking accidental disruptions. Penetration Testers: Working authorized OT engagements who need to gather deep asset intelligence without tripping safety limits. Defensive Blue Teams: Auditing their own external network boundaries to understand what an attacker can map out before the connection is even flagged. The tool includes an audit-ready reporting engine specifically for the defensive side. Finding an exposure is only half the battle; documenting it in a clear, technical format that an operations team will respect and act on is the other half. A Note on OT Operational Safety MEA is built exclusively for authorized security work. Industrial control systems govern physical machinery, and unauthorized interference carries severe real-world consequences. Even though MEA relies on a passive analysis methodology, interacting with live production hardware without explicit authorization is an operational boundary that should never be crossed. If you are analyzing public infrastructure data, ensure you understand the downstream impact of your traffic before establishing a socket connection. The Project The complete codebase, architectural documentation, and usage implementation details are open-source and available on GitHub: Repository: github.com/404saint/mea Profile & Lab Ecosystem: github.com/404saint If you are working in the ICS/OT space and have approached the real-vs-simulated asset problem using different data filtering models, I’d be highly interested in hearing how you structured your parsing engine in the comments. \ \