Black Hat Asia 2026 (Singapore, Apr 23–24) — Briefings Deep Dives

We'll Eat Your Serial for Breakfast: Exploiting Serial-to-IP Converters in Critical Infrastructure

Talk 14 · ICS / OT security · analysis from the speakers' published deck

Sep 24, 2026 · conferences · 12 min read · 2318 words intermediate

We'll eat your serial for breakfast — the boxes bridging your grid to the internet.

conferences blackhat ics-ot critical-infrastructure embedded

Official recording, Black Hat YouTube channel · open on YouTube ↗

Stanislav Dashevskyi and Francesco La Spina (Forescout) turn their attention to a device class most security teams never think about: the serial-to-IP converter, the small box that translates old-world serial protocols (RS-232, RS-485, Modbus, Profibus, DNP3) into TCP/IP so decades-old industrial equipment, power grid RTUs, water-treatment controllers, rail signaling, medical devices, can be monitored and managed over a modern network. More than half of industrial control systems still run serial protocols underneath, and these converters are the retrofit that lets that equipment join Industry 4.0 without being physically replaced, replacement is often prohibitively expensive or operationally impossible. Nearly 20,000 such devices from major vendors sit exposed on the public internet, and attackers already know it: a 2015 Sandworm operation bricked Moxa serial-to-IP firmware, the 2016 Industroyer malware sent malicious commands through COM ports, and the 2025 attack on Poland's power grid used default credentials specifically to knock these converters offline and cut operators' remote control. Forescout's question was pointed: if attackers already value these devices enough to disable them, can they do worse than a denial of service? Auditing firmware from six vendors, they found the honest, uncomfortable answer, these are ordinary embedded Linux boxes with the same outdated-component and weak-hardening problems as any router or firewall, plus new critical remote-code-execution and authentication-bypass vulnerabilities in two of them, meaning full device takeover, not just disruption, is realistic.

Post 14 of my Black Hat Asia 2026 series. Analysis-first: the device class, the real-world attack context, the research findings by category, and the defenses. Specific injection strings and bypass payloads are omitted; the vendor advisories carry that detail.

1. Why "serial" is still everywhere in 2026

Serial communication (RS-232, RS-485, UART) is how devices that predate modern networking talk: one bit at a time, over a simple point-to-point or multi-drop link. It is unglamorous, but it is foundational to real-time monitoring and control of physical processes, and it hasn't gone away because the equipment speaking it hasn't gone away:

  • More than half of industrial control systems still rely on serial protocols like Modbus, Profibus, and DNP3, running power grids, water treatment plants, rail signaling, and maritime systems.
  • Networking equipment (routers, firewalls) still exposes serial console ports for configuration.
  • Point-of-sale devices like barcode scanners, and medical devices like bedside patient monitors and infusion pumps, frequently use serial internally or at the edge.

Ripping this equipment out isn't realistic: the devices are expensive, the downtime from replacing them is unacceptable in a power plant or hospital, and in some cases a physically separate serial link is itself a deliberate security control. So the industry's answer is retrofitting: attach a serial-to-IP converter (also called a serial device server) to the existing serial hardware, and it transparently bridges that traffic onto the IP network the rest of the enterprise already uses, enabling exactly the remote monitoring and real-time data collection that Industry 4.0 initiatives want, without touching the underlying physical process equipment at all.

2. A well-documented, already-targeted device class

This isn't a hypothetical attack surface. Forescout's research sits alongside a documented, twenty-year history:

YearIncident
2005First notable vulnerability disclosed in this device class (a Lantronix product)
2015The Sandworm group corrupted Moxa serial-to-IP device firmware to cut off field devices and slow recovery
2016The Industroyer malware sent malicious commands to remote terminal units via COM ports using the IEC 101 protocol
2022The AnonGhost group defaced internet-exposed Moxa OnCell devices in Russia
2025An attack against Poland's power grid used default credentials to misconfigure serial-to-IP converters, making them unreachable and cutting remote control

The 2025 Poland incident is worth a closer look, because Forescout's own published analysis traces the attacker's path across multiple asset types: initial access into VPN/firewall infrastructure, then default-credential access into RTUs, IEDs, and HMIs at renewable energy plants (via HTTP, SSH, and FTP interfaces), where the attackers uploaded corrupted firmware and deleted essential files, and separately, default HTTP credentials on Moxa Nport serial-to-IP converters used specifically to trigger a factory reset. The pattern across the whole intrusion: reach a device, use weak or default credentials, and either wipe it or reset it to sever remote visibility and control. Public documents (RFPs, SCADA project bids) also routinely leak exactly which converter models and configurations a given utility uses, giving attackers free OSINT reconnaissance before they even scan for the devices.

Forescout's motivating question, given all this, is direct: are these devices meaningfully different from an ordinary network edge device, such that denial of service really is the ceiling of what an attacker can do to them? Or is there a worse category of attack hiding underneath the DoS incidents everyone has already seen?

3. What they actually found: it's a Linux box with a serial port bolted on

The research combined automated analysis (software bill of materials, known-vulnerability matching, binary hardening checks) across firmware from six leading vendors, with manual analysis of proprietary components to find new vulnerabilities. The automated findings alone are a useful data point for anyone who assumed these were simple, low-risk appliances:

MetricFinding
Open-source components per firmware image~80 on average; vendors use very different, often older, Linux kernel versions, which drag in older, more vulnerable dependent components
Known vulnerabilities per firmware image~212 on average affecting open-source components (68% low/medium severity, 29% high, 3% critical); 89 had public exploits available
Binary hardening: stack canariesOnly 23% of binaries use them
Binary hardening: RELRO44%
Binary hardening: PIE (address-space layout randomization support)67%
Binary hardening: W^X (no writable+executable memory)84%

Firmware built on newer Linux kernels (and therefore carrying fewer historical CVEs) also tended to apply these binary protections more consistently, a reasonable proxy for a vendor's overall security maturity. But the headline conclusion is the one worth sitting with: serial-to-IP devices are complex Linux machines with a large attack surface, no different in kind from a traditional networking edge device like a gateway, router, or firewall. The "serial" part is, architecturally, just one more peripheral, a serial port plus a userspace binary that translates its data to and from TCP/IP, bolted onto an otherwise ordinary embedded Linux system with the same outdated-component and weak-hardening problems Forescout has documented in OT routers before.

Why the "it's just a translator" framing is dangerous (my note). Treating a serial-to-IP converter as a dumb protocol bridge, rather than as a general-purpose computer that happens to run a translation function, leads teams to under-invest in patching, credential hygiene, and network segmentation around it. The research's core contribution is reframing the risk model: this is a full Linux attack surface sitting directly between your IP network and your physical process, not a passive wire.

4. New critical vulnerabilities: two vendors, full device takeover

Beyond the supply-chain analysis, manual review of proprietary components turned up 23 new vulnerabilities across two vendors, 5 of them critical, spanning remote code execution (via OS command injection or buffer overflows), authentication bypass, firmware tampering, denial of service, and sensitive information disclosure. Rather than reproduce the specific exploitation techniques, the categories tell the story:

  • Pre-authentication OS command injection in a device's web-management interface, reachable without valid credentials, in one product line's login-logging path.
  • Multiple post-authentication OS command injections across configuration pages, stemming from a general lack of input validation once an attacker has any valid session.
  • Authentication-bypass techniques against the web management interface, allowing an attacker to reach restricted administrative functionality without a valid password.
  • Memory-safety issues (buffer overflows) in a second vendor's web management binary, whose real-world exploitability was reduced by the process running unprivileged and auto-restarting on crash, though the researchers note the lack of position-independent-executable protection on that binary would make defeating address randomization more practical than it should be.
  • Firmware integrity-check weaknesses in the second vendor's devices, sufficient to allow construction of custom, unsigned firmware, the precondition for a persistent backdoor.
  • Flaws in proprietary remote-configuration protocols (used for bulk, unattended configuration of fleets of these devices), including unauthenticated network-setting changes and unauthenticated remote reboot, echoing the exact "change network settings without authentication" tactic seen in the real Poland attack, plus authentication-bypass conditions in the protocol's client-session handling, and a fail-open behavior after factory reset that lets any device on the local network claim an unconfigured unit.

Taken together: an attacker who reaches one of these devices over the network, in several documented cases without needing any valid credentials at all, can plausibly achieve full, root-level control, not merely knock it offline.

5. What full device takeover actually enables in an OT environment

The practical significance is what a compromised serial-to-IP converter can do beyond what a DoS on it does, because it sits at a genuinely privileged network position: between the IP-connected control system and the serial-connected physical-world equipment.

From internet-exposed edge device to physical process 1. Initial access exposed edge device 2. Lateral movement RCE into serial-to-IP box 3. MitM / tampering between SCADA and field devices Physical process sensors, actuators a compromised converter isn't just "offline" — it can sit as an attacker-controlled man-in-the-middle between the control room and the field, or pivot further into serial-only devices via their own protocol flaws

Fig. 1 — Once compromised, a serial-to-IP converter can serve as an active man-in-the-middle between SCADA and field devices, or as a pivot point into other serial-only equipment, rather than simply going dark.

The researchers extend this to a more speculative but grounded scenario: a well-resourced attacker who gains this level of access and takes more time before acting, rather than immediately disrupting service, could tamper with the supply chain itself, for example intercepting deliveries of these devices in transit and installing modified firmware before a utility ever powers one on. They draw the comparison to the 2024 exploding-pager incident in Lebanon, a real-world case of a compromised supply chain for ordinary-looking devices used to inflict physical harm at scale. Applied here, a compromised serial-to-IP fleet wouldn't only deny remote control; it could inject falsified sensor readings to mislead operators or feed corrupted values directly into serial industrial protocols, a far more damaging outcome than any denial-of-service.

6. Defenses

  • Treat serial-to-IP converters as full network endpoints, not passive translators. Patch them, inventory their software components, and include them in vulnerability-management scope, the same as any router or firewall.
  • Eliminate default and weak credentials on every management interface (HTTP, SSH, FTP, and any proprietary bulk-configuration protocol). This single control would have blunted both the 2025 Poland incident and several of the flaws Forescout found.
  • Never expose management interfaces to the internet. Nearly 20,000 devices from major vendors are already reachable online; put these devices behind a VPN or a segmented management network with no direct internet path.
  • Restrict who can use bulk/remote-configuration protocols, and verify their authentication cannot be bypassed by a malformed message or a factory-reset fail-open state; these protocols manage entire fleets at once, so a flaw in one compromises many.
  • Verify firmware integrity end-to-end, including in the supply chain (delivery, storage, installation), not only via the device's own (sometimes weak) self-check mechanism.
  • Monitor for anomalous behavior on the serial side too, not just the IP side, since a compromised converter's most damaging action may be injecting or altering serial-protocol traffic rather than generating unusual network packets.
Isn't a serial-to-IP converter a low-value target compared to the SCADA server itself?

The opposite: it's often the easier, less-monitored target that sits directly on the path to the physical process, and because it's typically dismissed as "just a translator," it gets less security attention and patching than the SCADA/HMI systems it feeds. Multiple real incidents (Sandworm, Industroyer, the 2025 Poland attack) specifically targeted this device class.

If DoS is already common against these devices, why does RCE matter more?

A DoS'd converter goes offline, visibly, and operators know they've lost remote control. A compromised-but-functioning converter can silently tamper with data flowing between the control room and the field, or serve as a pivot into other serial-only equipment, which is far harder to detect and can cause direct physical/safety consequences rather than just an availability gap.

Does replacing serial equipment with modern IP-native gear solve this?

Not practically, in most cases. The equipment behind these converters is often decades old, extremely expensive to replace, and in continuous operational use where downtime is unacceptable (a power grid, a hospital). That's precisely why serial-to-IP retrofitting exists, and why securing the converter itself is the realistic path forward for most operators.

What's the single highest-leverage fix?

Eliminating default and weak credentials on every management interface. It was the entry technique in the real 2025 Poland attack and underlies several of the newly found authentication-bypass and remote-configuration-protocol flaws; it's also the cheapest control to apply across an existing fleet without new hardware or firmware.

Takeaways

  • Serial-to-IP converters bridge decades-old, hard-to-replace industrial equipment onto IP networks, and more than half of ICS still runs the serial protocols underneath.
  • Attackers already know these devices matter: Sandworm, Industroyer, and the 2025 Poland grid attack all specifically targeted them, mostly via default credentials, to cut remote control.
  • Under the hood they are ordinary embedded Linux boxes with the same outdated-component and weak-binary-hardening problems as any router or firewall, not a distinct, lower-risk category.
  • New research found 23 vulnerabilities (5 critical) across two vendors, including pre- and post-auth RCE, authentication bypass, and firmware-integrity weaknesses, enabling full device takeover, not just disruption.
  • A compromised converter can act as an active man-in-the-middle between SCADA and field devices, or a pivot into other serial-only equipment, a materially worse outcome than denial of service.
  • The highest-leverage defenses are unglamorous: kill default credentials, keep management interfaces off the internet, patch like any other network device, and verify firmware integrity through the supply chain.

References & further reading

← prev: Qualcomm BootROM next: Ethereum Differential Testing →
© cvam — written in plaintext, served warm