Bypassing Hypervisor Isolation to Root Siemens S7 PLCs

TLDR: Researchers at Black Hat 2024 demonstrated a firmware modification attack against Siemens S7 PLCs that exploits a hypervisor vulnerability to load arbitrary code. By replacing the software PLC firmware via a simple drag-and-drop file operation, an attacker can achieve persistence and remote command execution. This research highlights the critical need for secure boot and hardware-backed integrity checks in industrial control systems.

Industrial control systems are often treated as black boxes, protected by layers of proprietary firmware and the assumption that physical access is the only path to compromise. That assumption is dead. The recent research presented at Black Hat 2024 on the Siemens S7 PLC line proves that even the most "rugged" and "secure" industrial hardware can be turned into a persistent C2 node if the underlying hypervisor architecture is flawed.

The attack centers on the Siemens ET 200SP PLC, which runs a software PLC (SWCPU) alongside a Windows Embedded operating system on an Intel Atom CPU. The hypervisor is supposed to act as an iron wall between these two environments. However, the researchers discovered that this wall is porous. By reverse-engineering the hypervisor, they found that it lacks proper integrity checks when loading the SWCPU firmware. It will happily load any ELF file that contains a specific magic string at the beginning of the file.

The Mechanics of the Firmware Hijack

The vulnerability is essentially an arbitrary file loading flaw. Because the hypervisor does not verify the digital signature or the integrity of the SWCPU firmware, an attacker with administrative access to the Windows Embedded side can simply overwrite the existing firmware file.

The researchers demonstrated this by dragging and dropping a modified ELF file into the C:\Boot\Siemens\SWCPU\ directory. Upon the next reboot, the hypervisor loads the malicious firmware instead of the legitimate one. This is a classic T1547.001 boot-level persistence technique, but applied to an industrial controller. Once the malicious firmware is running, the attacker has full control over the PLC's logic, allowing them to manipulate I/O, exfiltrate process data, or disable safety systems.

Turning the PLC into a C2 Node

What makes this research particularly dangerous is how the attackers established communication. Rather than building a custom, noisy network stack, they hijacked the PLC's built-in web server. The web server is a legitimate feature used by technicians for maintenance, but it provides a perfect, stealthy channel for command and control.

By hooking the open and read system calls within the SWCPU, the researchers were able to intercept HTTP requests. When the web server attempts to serve a file, the hook checks if the requested filename contains a specific prefix. If it does, the hook intercepts the request and returns data from a memory buffer controlled by the attacker. This allows for a bidirectional C2 channel:

• Commands: The attacker sends a request like http://localhost:81/dbg7_W_190C2B8D_PWND. The hook parses the command, identifies the W (write) operation, and executes the payload.
• Exfiltration: The attacker requests a file like http://localhost:81/dbg7_R_190C2B8D. The hook reads the requested memory address and returns the contents via the CSS file, which the web client then displays.

This technique effectively turns the PLC's own management interface into a covert channel, bypassing traditional network-based intrusion detection systems that might be looking for non-standard protocols.

Pentesting Industrial Environments

For those of us working on red team engagements or security assessments in OT environments, this research changes the threat model. We can no longer assume that the PLC logic is immutable. If you gain a foothold on an engineering workstation or any system with access to the PLC's file system, you have the potential to achieve permanent, undetectable control over the process.

During an assessment, look for the presence of these software-based PLCs. Check the file system permissions on the directories where firmware is stored. If you can write to those directories, you don't need a complex exploit chain to gain control; you just need to drop a file. This is a stark reminder of why A01:2021-Broken Access Control is the top risk in the OWASP Top 10. In an industrial context, broken access control doesn't just lead to data theft; it leads to physical process manipulation.

The Path to Mitigation

Defending against this requires moving beyond perimeter security. The primary failure here is the lack of a secure boot chain. If the hypervisor verified the signature of the SWCPU firmware against a hardware-backed root of trust, the drag-and-drop attack would fail immediately.

If you are responsible for securing these systems, ensure that the engineering workstations are hardened and that access to the PLC's file system is strictly limited to authorized personnel. Monitor for any unauthorized file modifications in the boot directories. While patching existing PLCs in the field is notoriously difficult due to uptime requirements, the industry must demand that vendors implement hardware-verified boot processes in all future hardware. We are past the point where "security through obscurity" is a viable strategy for critical infrastructure.