Firmware Tampering in Field Devices: How It Happens and How to Detect It

Why firmware is a prime target

Firmware is the software closest to the hardware: it runs directly on the device processor, before any operating system, with direct access to physical resources. In OT devices (PLCs, RTUs, industrial gateways, smart sensors) firmware is what determines the device behavior at the most fundamental level.

This privileged position makes it an attractive target for attackers seeking long-term persistence. Modified firmware survives any operating system reinstallation, any credential change, any application software update. It is invisible to conventional security tools that operate at the OS level. And in OT devices with lifecycles measured in decades, it can lie dormant for years before being activated.

How tampering happens: vectors and techniques

Firmware tampering can occur through several vectors:

Compromised firmware update: the most common vector in connected devices. If the firmware update process does not verify the integrity and authenticity of the file before installing it, an attacker who can intervene in the distribution channel (man-in-the-middle, compromise of the update server, file substitution) can make the device install modified firmware.

Physical access to the debug port: many OT devices have physically accessible JTAG or UART ports, designed for factory diagnostics and programming during manufacturing. These ports are often not disabled in the final devices and allow direct access to the device memory, including modification of the firmware.

Exploitation of vulnerabilities in the existing firmware: if the current firmware has vulnerabilities (buffer overflow, command injection, weak authentication on the management interfaces), these can be used to achieve arbitrary code execution on the device, which can then modify the firmware itself.

Supply chain: as discussed in the article on supply chain attacks, firmware can be compromised before delivery, during the manufacturing or distribution process.

Persistence and stealth: why it is hard to detect

Modified firmware has characteristics that make it exceptionally hard to detect with traditional tools:

Invisibility to the operating system: an endpoint security agent installed at the OS level does not see the firmware. It cannot read the contents of the flash memory where the firmware is stored, and it cannot monitor its execution.

Normal behavior most of the time: firmware well designed for persistence runs its legitimate functions normally, activating the malicious behavior only in response to specific triggers: an external command, a date, a process condition. Normal operational monitoring sees nothing unusual.

Survival across resets: even a factory reset of the device, in most cases, does not overwrite the firmware. The modified firmware survives. Removing it requires an explicit reflash operation with verified firmware.

Difficulty of comparison: to detect that firmware has been modified, you need to compare it with a trustworthy reference version. This requires having authenticated reference versions, access to the device memory to extract the current firmware, and tools for the comparison. In many OT environments, this capability does not exist.

Detection techniques: what actually works

Despite the difficulties, there are approaches to detect firmware tampering:

Hash-based integrity measurement: extract the firmware from the device and compare its cryptographic hash with the hash of the authentic firmware provided by the manufacturer. It is the most direct method, but it requires the ability to extract the firmware (not always trivial) and reliable reference versions.

Remote attestation: some modern devices implement attestation mechanisms based on security chips (TPM or hardware equivalents) that allow remote verification of firmware integrity. It is the most robust solution, but it requires dedicated hardware support that is often absent in legacy devices.

Network behavior analysis: a device with compromised firmware that communicates with external C2 infrastructure leaves traces in the network traffic. Monitoring the network communications of OT devices, compared with a baseline of normal behavior, can detect anomalous connections even when the firmware itself is invisible.

Timing analysis: computation operations of modified firmware can have different timing signatures compared with the original firmware. Response-time analysis techniques, applied systematically, can detect anomalies.

Periodic scanning with specialized tools: some OT security tools include the ability to query specific devices to verify the firmware version and integrity in a non-invasive way.

Protecting the firmware lifecycle

Prevention is more effective than detection:

Secure boot: devices that support secure boot verify the cryptographic signature of the firmware at startup. Unsigned firmware or firmware with an invalid signature is not executed. It is the most effective control, but it requires hardware support that many legacy devices do not have.

Signing and verification of updates: any firmware update process must verify the cryptographic signature of the file before installation. It must not be possible to install unsigned firmware or firmware with an invalid signature.

Disabling the debug ports: JTAG and UART ports on production devices should be disabled physically or logically where possible. At a minimum, physical access to the devices should be controlled.

Inventory of firmware versions: maintain an up-to-date inventory of the firmware versions of all OT devices. Discrepancies against the expected version are a signal to investigate.

Firmware protection is an area where the gap between modern and legacy OT systems is particularly acute. In new deployments it is possible to require devices with secure boot support and update signing. For existing systems, compensating controls (network monitoring, controlled physical access, systematic inventory) are the best that can be done.

The MON5 angle

Detecting compromised firmware from inside the device is often impossible, but its network behavior gives it away. MON5 works exactly on this level: passive out-of-band NDR on native OT protocols (Modbus, Siemens S7, OPC UA, PROFINET, EtherNet/IP) and ML anomaly detection that builds the baseline of every device and flags unexpected communications, altered response patterns, traffic outside business hours.

Continuous asset inventory also keeps track of firmware versions, making discrepancies against the expected state visible. To find out which field devices are a blind spot today, start with an OT assessment.