By RUGERO Tesla (@404Saint)
The problem with Modbus being on the internet
Modbus was designed in 1979. It was designed for closed, serial networks where the assumption was that if you could physically reach the device, you were supposed to be there. There was no authentication. No encryption. No concept of an untrusted caller.
That assumption held for a long time. Then came Ethernet. Then came remote monitoring. Then came cloud connectivity and the slow, steady erosion of the air-gap that industrial engineers spent decades taking for granted.
Today you can find Modbus devices on Shodan. Public IP addresses, port 502, responding to anyone who asks. Some of them are real PLCs in real facilities. Some are misconfigured. Some are honeypots. And telling those three apart without disrupting whatever process they're attached to is not as straightforward as it sounds.
That's the problem MEA is built to solve.
What MEA actually does
MEA is a passive behavioral analysis tool for Modbus devices. Passive matters here more than it might in an IT context. In ICS/OT environments, sending unexpected traffic to a live device isn't just a network etiquette issue — it can interrupt physical processes. You don't probe a PLC controlling a pump the same way you'd run nmap against a web server.
MEA works by observing. It reads register data, measures behavioral patterns over time, analyzes entropy, and monitors for changes. It doesn't write anything. It doesn't send commands. It gathers enough signal to tell you something meaningful about a device without touching its operation.
The three things it's trying to answer are:
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. Simulated registers tend to be static, randomized, or artificially varied in patterns that don't match how real sensors behave.
How exposed is it? What's reachable, what's responding, and does the exposure match what you'd expect from a device in this kind of environment?
What's the actual risk? Not a generic vulnerability score, but something grounded in what the device is doing and what access to it would mean.
How it works
Behavioral fingerprinting
The first thing MEA does when it connects to a device is start watching register values over multiple read cycles. Real industrial devices have a characteristic kind of noise. Temperature sensors drift. Flow meters fluctuate. A PLC running an active process shows register activity that reflects something happening in the physical world.
Simulators don't replicate this well. They either hold values constant, cycle through obvious patterns, or randomize in ways that don't match the statistical profile of real sensor data. MEA measures this and uses it as a signal for the real-vs-simulated classification.
Entropy analysis
Each register read gets an entropy score. The goal is finding anomalies — registers behaving in ways that don't fit the surrounding context. An unusually high-entropy register on a device where everything else is low-entropy is worth investigating. It might be normal. It might not be.
This is the same reasoning that drives entropy analysis in malware detection. Encrypted or packed data scores high because it's information-dense in a way that structured data usually isn't. The same principle applies to register data that doesn't match its neighbors.
Register monitoring over time
A single snapshot of a Modbus device tells you less than you'd think. MEA watches registers across multiple cycles and tracks changes. This catches things a one-time scan misses entirely — registers that only update under specific conditions, values that change in response to external events, patterns that only become visible when you're watching over minutes rather than seconds.
It also catches something more subtle: devices that look normal at first glance but show anomalous behavior under sustained observation. That gap between the initial impression and the longer-term pattern is where a lot of the interesting findings live.
Risk assessment
The risk output from MEA isn't a generic score plugged into a CVSS calculator. It's built from the combination of what the device is, how it's exposed, what its register behavior looks like, and what access to it would actually mean. A Modbus device responding on a public IP with registers that map to physical actuators is a different risk than the same device in a monitored DMZ with read-only exposure.
Context matters in ICS security in ways it often doesn't in IT security, and the risk output is designed to reflect that.
Who it's for
Security researchers doing passive reconnaissance on ICS infrastructure. Pentesters working authorized assessments who need to gather intelligence without risking operational disruption. Blue teams trying to understand their own exposure before someone else does.
The audit-ready report output is there for the third group especially. Finding something is half the work. Documenting it in a format that an operations team will actually read and act on is the other half.
A note on how to use this
MEA is a tool for authorized security work. ICS and OT environments carry real-world consequences in a way that most IT environments don't. Using this against infrastructure you don't have permission to analyze isn't just legally problematic — it's potentially dangerous to people and processes on the other side of that connection.
If you're doing research on public-facing devices via platforms like Shodan, understand what you're looking at before you connect to it. The passive-first design of MEA is deliberate, but passive still means connecting, and connecting to live industrial hardware uninvited is a line worth thinking carefully about before crossing.
The project
The full codebase, documentation, and usage examples are there. If you're working in ICS/OT security and you've approached the real-vs-simulated problem differently, I'd be interested in hearing about it.
All my projects: github.com/404saint
Built by RUGERO Tesla · GitHub: @404Saint
Offensive security researcher focused on ICS/OT, infrastructure security, and attack surface analysis.
Top comments (0)