Overview
.jpg)
This blogpost is a follow-up to part 1, describing the destructive bricking TTPs used on December 29th of 2025 in a series of coordinated cyber attacks against a number of targets connected to Polands electric grid.
This incident involved a TTP which we have been warning about for a long time, namely bricking critical OT devices as an attack amplification strategy and included exploitation of a variant of CVE-2024-8036 which was discovered by Midnight Blue a few years ago.
While the previous blogpost discussed the Polish incident and presented a technical taxonomy of embedded device bricking TTPs, this blogpost will investigate how real and widespread this risk actually is in OT environments by looking at other real-world incidents as well as device security posture.
We will also argue why we think we will see more "commodity embedded wiper attacks" in the future and why standards compliance such as IEC 62443 will not save OT defenders here.
Destructive TTPs such as wiping or even bricking are not novel in the slightest. Already in the late '80s, viruses like Lamer Exterminator for the Amiga or Festering Hate for the Apple II had destructive payloads that involved wiping storage media data blocks. The infamous CIH virus from 1998 took things a step further by not only overwriting a hard drive's partition table but also attempting to flash the BIOS and rewrite early boot routines with invalid code, effectively bricking its targets until BIOS flash chips were reprogrammed or replaced.
Likewise while Mirai is typically credited with popularizing IoT/embedded malware in 2016, Psyb0t was already widely infecting routers in 2009 and the leaked NSA Advanced Network Technology (ANT) catalog from 2008 shows a myriad of implants for routers, firewalls, BIOSes, satellite phones and hard drives, parts of which would become publicly available with the Shadow Brokers leak from 2016 [1,2]. Similar capabilities against routers and switches held in parallel by the CIA were revealed in the 2017 Vault 7 leaks while Chinese and Russian actors have developed strong capabilities for network equipment and IoT, building up massive Operational Relay Box (ORB) networks over the past decade. The BrickerBot malware of 2017 was one of the first large-scale instances combining these aspects: destructive TTPs applied by embedded device malware. BrickerBot destroyed more than 10 million IoT devices by writing random data to various block devices supposedly in an attempt to prevent them from getting added to the Mirai botnet spreading like wildfire at the time.
With that in mind, let's take a look at some high-profile cyber-attacks against OT environments where the bricking of embedded devices played a role.
The BlackEnergy attack [1,2] by Russian state-sponsored hackers on dozens of substations of 3 different Ukrainian DSOs left over 230.000 people without power for 3 to 6 hours. During this incident attackers manually opened circuit breakers after HMI takover, wiped SCADA servers using KillDisk, and overwhelmed call centers with DoS attacks.
However, it is less widely reported that the attackers allegedly also bricked at least 16 serial-to-Ethernet converters responsible for telecontrol between SCADA servers and remote substations. Bricking these converters, similar to 2025 attack in Poland, meant process operators could no longer remotely reset opened circuit breakers and instead had to dispatch personnel to manually reset them at the substation locations themselves. Some reports state that all affected converters required physical replacement after restoration attempts failed. The affected device models in question, Moxa UC 7408-LX-Plus and the iRZ RUH2 3G, both suffered from vulnerabilities that allowed authenticated users to push malicious, unsigned firmware (CVE-2016-4500, CVE-2016-2309).
According to some product notes, firmware upgrades for the Linux-based Moxa UC 7408-LX-Plus devices can take place through a combination of UART commands over a serial link and an Ethernet-based TFTP connection which is unlikely to have been the attack vector given that this requires triggering from serial interface. Alternatively, the user manual suggests retrieving firmware updates via FTP from a Telnet or SSH shell on the serial converter itself and then using the upfirm command to perform a firmware update. Given that this is a straightforward embedded Linux device, the most likely attack vector taken was probably an attacker abusing default credentials, sniffing credentials over Telnet, or exploiting one of the myriad remote code execution vulnerabilities in this Moxa device and subsequently either abusing native firmware update commands or just corrupting block devices directly.
The iRZ RUH2 3G is similarly Linux-based and has the ability to push firmware updates via its web interface, though SSH shell access is possible too - suggesting an attack vector very similar to the Moxas.
Predatory Sparrow is a highly capable but underreported threat actor targeting OT systems in the Middle East. While the group claims to be an anti-Iranian hacktivist group, it is widely alleged they are a front for an Israeli state-sponsored actor. Given how little in-depth attention this threat actor has received it is worthwhile to discuss this incident in more detail.
In 2021, on October 26th, a cyber attack claimed by Predatory Sparrow took out over 4000 fuel stations across Iran. This attack coincided with the anniversary of the 2007 fuel rationing riots. A repeat attack against Iranian fuel systems was carried out by Predatory Sparrow in 2023.
During the 2021 incident, within a few hours all Point-of-Sale (POS) devices were effectively "soft-bricked" and went out of service. They instead displayed a message containing the phone number (64411) of a hotline to the Office of the Supreme Leader of Iran. During a previous cyber attack by Predatory Sparrow against the Iranian railways this number was also displayed on hacked Passenger Information Systems. With the POS devices going out of service, Iranians could no longer use their government subsidized fuel smart cards which allow them to get a monthly quota of fuel at heavily reduced rates thus effectively spiking domestic fuel cost and leading to long lines at fuel stations which lasted for days. The message behind this cyber attack was clearly hinting at the threat of triggering fuel riots.
Interestingly the detailed reporting made available by DarkCell suggests that while the attackers wiped central management servers and disabled POS devices through "soft-bricking", they were likely in a position to permanently brick them as well. Instead, their approach forced defenders to "only" rebuild the central management infrastructure and manually restore individual POS devices but not physically replace them.
As illustrated in the above diagram, the Iranian smart fueling system was built from a mix of home-grown solutions and integrated commercial products. The upper layer management systems consist of IPC servers which operate and monitor gas pumps and are also responsible for updating and retrieving firmware and configuration, and customer data to and from POS devices. IPC servers are then aggregated and managed remotely in region groups via so-called Pooler servers which in turn connect to management servers in a data center. Attacker access to this upper layer management infrastructure would have enabled them to push firmware and configuration data to the POS devices.
When zooming in on the POS devices and directly associated components, the reporting makes clear that those were based on legacy products by the French company Ingenico integrated by the Iranian system integrator Idea-Negr. Tender, system integrator, and investor documents found through OSINT suggest the POS device in question was the Ingenico i9400 launched in 2005.
While little is publicly available about these legacy devices, several OSINT sources [1,2,3,4,5] indicate most of Ingenico's older POS terminals (such as the 9400/9500 and 6780/7780) are built around their UNICAPT32 application platform. UNICAPT32 runs on Ingenico's proprietary Millennium ASIC processor which consists of an ARM32 CPU and a High Security Core (HSC) module for payment processing security. The UNICAPT32 platform uses proprietary operating system which can load several user-programmable applications which control the terminal to allow for different use cases ranging from fuel stations to ticket kiosks or vending machines. These user applications are downloaded to the POS device via either serial, USB, or Ethernet link and handled by the maintenance application which passes the application on to the System and Security Application (SSA) performing decryption and authentication.
This strongly suggests Predatory Sparrow exploited the POS devices by downloading a user application to them from compromised management infrastructure. The malicious user application then likely showed a custom message with the hotline phone number on the POS screen and removed the original POS application functionality. This would "soft brick" it in a way that allowed for relatively easy restoration.
One aspect we haven't seen highlighted before is that Predatory Sparrow didn't have to approach the Ingenico POS devices as complete blackboxes, since they have been prolificly discussed targets on hobbyist reverse-engineering forums as well as underground carder and skimmer communities rife with examples and guides on how to write custom user applications for them.
However, according to DarkCell, the attackers claimed to have at least 2 vulnerabilities in Ingenico products and exploited one during their attack. One of the claimed vulnerabilities was supposedly a local privilege escalation exploit inside a vulnerable Unicapt system call allowing a regular user application to achieve system level privileges. This would have likely enabled them to bypass any firmware signing mechanisms and wipe flash storage to hard-brick all POS devices. The fact that the attackers didn't do this and instead claimed to have reported the vulnerability to Ingenico (who denied receiving the report), has been interpreted as strategic signaling rather than compassionate restraint: We could have hit you even harder and we might do so next time.
The ViaSat hack during the initial stages of the 2022 Russian invasion of Ukraine has been well documented and has served as one of the pivotal cases in drawing increased attention to wiper attacks against embedded devices [1,2,3,4]. The attack targeted the ViaSat KA-SAT network, which provides broadband satellite internet access in the Ka band based on Tooway technology, and involved wiping tens of thousands of SurfBeam2 modems through the use of the AcidRain embedded wiper malware.
While the KA-SAT modems cannot really be seen as "OT devices" and the attack was not targeted to OT per se, the attack did have OT-related spillover by disconnecting remote monitoring and control of 5.800 Enercon wind turbines in Germany. The incident should also be on many OT asset owners' radars given how much remote connectivity in OT environments hingest on various satellite and RF modems with dubious security posture. Indeed, the Iranian smart fuel infrastructure described above relied on VSAT terminals to connect both pooler servers to the data center as well as for direct connections from fuel stations themselves.
After obtaining initial access via a VPN gateway to the management plane of the ViaSat KA-SAT core ground network, the attackers deployed the AcidRain wiper to the satellite modems via SSH using compromised credentials. AcidRain's wiper functionality consists of recursive file deletion combined with either overwriting raw block devices or erasing them through dedicated IOCTLs.
Shortly after the ViaSat hack Ruben Santamarta presented several alternative routes to compromising and wiping the satellite modems via the TR-069 CPE WAN Management Protocol (CWMP) without requiring credentials to the SSH service, highlighting just how much attack surface these kind of devices have.
In 2024, a variant of AcidRain dubbed AcidPour, reportedly used in wiper attacks against Ukrainian telcos, was discovered with extended embedded wiping capabilities. Some parties have observed similarities between AcidRain and the raw block device wiper functionality of the VPNFilter malware for Linux-based routers discovered in 2018. Interestingly, VPNFilter also had a Modbus traffic sniffing module indicating an interest in OT by this attacker.
The wave of back-and-forth opportunistic hacktivism following the Russian invasion of Ukraine in 2022 has included targeting of low hanging fruit internet-exposed OT systems [1,2] with simple TTPs such as modifying parameters or shutting down devices.
While many of these incidents are heavily embelished or downright fabricated by the threat actors themselves as part of propaganda and psychological warfare efforts, there have been some attempts at wiping Linux-based industrial routers. These have included a simple filesystem wipe of an iRZ RL01 used at a luxury appartment in Moscow by the pro-Ukrainian hacktivist group Team OneFist and a rather strange attempt at encrypting the filesystem of a Belarusian Teleofis RTU968 by GhostSec. While the impact of these incidents is probably minimal, they do show a growing awareness of and willingness to deploy destructive TTPs against OT devices on part of a much more opportunistic part of the threat landscape.
Between June 2023 and April of 2024 the allegedly Ukrainian state-sponsored group Blackjack carried out a destructive attack utilizing their FuxNet malware against the Moskollektor company responsible for (among other things) monitoring water and sewage sensor networks in Moscow.
After obtaining initial access through exposed cellular routers and tunneling to internal enterprise systems, Blackjack deployed their FuxNet malware over either SSH or a proprietary sensor management protocol to hundreds of Linux-based cellular routers (model iRZ RL22w) and gateways (models MPSB and TMSB by the Russian company AO SBK) connected to the sensor infrastructure via RS-485 based serial bus.
The malware subsequently bricked these devices by locking out remote access, shutting down communications, wipes the filesystem in several ways (through file deletion utilities, writing to block devices, and incomplete filesystem writes), and attempting to physically destroy NAND flash through cycle exhaustion as discussed here.
As discussed in part 1 developing embedded wiper payloads isn't that difficult, especially for Linux-based devices as evidenced by the above examples. Not only is it more straightforward to develop a wiper for a Linux-based embedded system than it is for deeply embedded devices with monolithic firmwares or RTOSes, such wipers also scale applicability across many different vendors and devices as shown by VPNFilter, AcidPour, and the various IoT bots with bricking capabilities. It is only a matter of time before such capabilities trickle down to less well resourced and more unconstrained threat actors, especially those part of escalatory dynamics.
Given that newer OT devices are increasingly Linux-based, the relevance of such "commodity embedded wipers" is likely to increase as well. The majority of industrial routers, switches, firewalls, and increasingly gateways and protocol converters are already Linux-based. And while Linux is quite rare in most currently deployed RTUs, PLCs, or IEDs around the world newer product lines such as Phoenix Contact's PLCnext ecosystem, Siemens' SICAM 8 power automation platform, and Wago's PFC100 and PFC200 product families are all explicitly Linux-based. Linux support from major PLC logic runtime platforms such as CODESYS, providing the 'brain' to PLCs from many manufacturers, has also helped drive adoption.
Similarly, during the BlackEnergy attack, some reports also mention that the KillDisk malware targeting Windows-based SCADA servers also wiped at least one ABB/Hitachi RTU560 HMI card running Windows Embedded (reported to be the 560CMU02 but more likely to have been the 560HMR01). This shows that sometimes, embedded systems can get swept up more conventional wiper attacks as well if they run common OSes like Windows or Linux.
Of course, the big elephant in the room is not that it's increasingly easy to write wiper payloads for OT devices but that it's so easy to deploy them on those devices. If we look at the incidents dicussed in this blogpost and part 1, the majority of cases are simple TTPs such as default credentials on SSH/FTP and/or unsigned firmware update mechanisms.
But defenders shouldn't let that comfort them too much. Let's say you have properly hardened your OT devices and networks according to whatever industry guidelines or (inter)national standards are relevant. You've set secure credentials on all relevant interfaces, disabled unnecessary services, rolled out firewalling and microsegmentation to ensure only the right hosts can reach out over the right protocols to the right devices. You've effectively forced an attacker to compromise a hardened Engineering Workstation (EWS) or device management server before they can even think about bricking those devices.
That's a good level of security posture to aim for and will keep out a lot of the small fry attackers, but persistent adversaries such as the ones discussed above have shown repeatedly that they are able to compromise high-value assets such as EWSes or device management servers. Defenders should be aware of exactly what kind of residual risk they're dealing with in such scenarios.
Prior work [1,2] by Midnight Blue researchers has shown many prominent OT device product lines did not have any form of secure firmware signing. Since none of the products in question have hardware root-of-trust capabilities, it is quite difficult to introduce secure boot and firmware signing functionality to them by means of a software patch rather than a hardware revision.
Of course, this doesn't hold for the newest flagship product lines of major vendors anymore. For example, the Siemens S7-1200 G2, Allen-Bradley ControlLogix 5580, Schneider Electric M580, Honeywell's ControlEdge PLC/RTU, and Siemens SIPROTEC 5 all explicitly advertise secure boot and/or firmware signing.
So let's assume that on top of proper hardening you also only use newer OT devices with secure boot and firmware signing capabilities and let's assume these features work as advertised. As discussed in part 1, this still leaves an attacker with the possibility of obtaining Remote Code Execution (RCE) through some sort of vulnerability and then leveraging that access to deploy their wiper.
One often overlooked way to achieve this on PLCs and RTUs is through downloads of maliciously modified application logic similar to the TTPs likely used by Predatory Sparrow against the fuel station POS devices in Iran. Many PLCs and RTUs support legitimate application logic (e.g. IEC 61131-3 FBD/ST/IL) downloads which in practice often consist of blocks of unsigned native machine code. As demonstrated in prior work by Midnight Blue researchers, such functionality can be abused by attackers to get an initial foothold within a PLC or RTU's execution space. In most cases, this means game over since there is often no privilege separation between firmware/OS and runtime tasks - meaning any sort of code execution immediately allows an attacker to invoke low-level routines responsible for modifying persistent storage (and thus bricking).
In fact, certain CMU modules of the Hitachi RTU560 bricked in the Polish electric grid attack can optionally be equipped with PLC functionality based on the ProConOS logic runtime system. ProConOS does not authenticate its logic downloads (CVE-2022-31800, CVE-2022-31801), so depending on RTU configuration this could have presented an alternative attack vector during the incident.
The attack surface is, unfortunately, much larger. Recent years have seen a true deluge of RCE vulnerabilities being discovered in embedded TCP/IP stacks, proprietary OT protocol stacks [1,2], and embedded webservers [1,2,3], many of which remain unpatched in practice and many more likely lurking beneath the surface of decades of tech debt. Such vulnerabilities don't just pop up in legacy products but also in new flagship product lines [1,2,3] showing device hardening on this front has not progressed much in the past decades. And while government directives instructing product manufacturers to use emory-safe languages and avoid entire bug classes are well-intentioned, they do little to harden the OT devices currently in the field nor the newest OT product lines currently rolling off the assembly lines to be fielded for the next decade plus - all of which have the vast majority of their code written in unsafe languages.
While there is certainly a place for standards driven efforts (such as IEC 62443) within larger cybersecurity programmes, far too often a lot of time and money is spent by asset owners and device manufacturers alike on this without fully realizing that the actual security improvements bought by this are quite minimal. This goes especially for device-level security.
As asset owners and device procurers, all you really have to go on are the onepager IEC 62443 certificates themselves and the more extensive conformance statements. Neither, however, contain any real technical detail outside of which security requirements are met at what security level and a few generic comments. Compare this to Apple who publicly provide at least some basic technical details.
The problem really starts with standards like IEC 62443-4-2 itself. When looking at security requirements such as Embedded Device Requirement (EDR) 3.2 ("Protection from malicious code"), 3.10 ("Support for updates") and 3.14 ("Integrity of the boot process") the standard offers only very high-level wording in the requirement itself and supplemental guidance merely states that detection and prevention techniques may include "binary integrity and attributes monitoring, hashing, and signature techniques", that "the embedded device shall validate the authenticity and integrity of any software update or upgrade prior to installation" and that "embedded devices shall use the component's product supplier roots of trust to verify the authenticity of the firmware, software, and configuration data needed for the component’s boot process prior to it being used in the boot process".
For example, when it comes to firmware signing and secure boot, not a word is said about what to sign, how to sign it, and what algorithms to select on the basis of which security properties. Nor about the endless pitfalls and failure modes that such security features can encounter in practice and which actually hardened platforms like the iPhone or Xbox had to overcome through years of public beatings.
On top of that, the security posture of a particular requirement is evaluated against Security Levels (SL) which are defined very vaguely as shown below:
Does an embedded wiper like AcidPour or FuxNet deployed over SSH constitute sophisticated means with moderate resources? And are they outside of your threat model as a result? If so, the 14 year old kid who developed and spread the Silex variant of the BrickerBot IoT wiper would be quite flattered to be included in that category as well.
It doesn't help that the standard didn't mandate a concrete Evaluation Methodology (EM) for a long time and that acceptance criteria of published EMs such as the one from TeleTrusT tend to be just as permissive as the standard. Last year, IEC 62443-6-2 was published as repeatable and reproducible EM for IEC 62443-4-2 based on the TeleTrusT EM. A lot of the more concrete evaluation requirements come from mandating adherence to Secure Development Lifecycle (SDLC) requirements in IEC 62443-4-1 but these often come down to a mix of paper exercises, limited functional testing, and very general statements about "boundary/edge condition" testing.
This means an evaluation can be as low effort as running a Nessus OT scan (something explicitly recommended) for known vulnerabilities and uploading a firmware image to a generic cloud analysis platform that is incapable of dealing with proprietary firmware formats, let alone non-Linux based ones.
It means that products developed by IEC 62443-4-1 certified organizations can still include TCP/IP stacks riddled with dozens of easy-to-find vulnerabilities that emerge after some basic fuzzing despite the standard explicitly requiring auditors to evaluate this.
It can also mean that testing signature verification is done by taking a legitimate firmware image, flipping a few bits, and checking to see if the target device rejects it. Which gives you exactly zero security insights since this would also hold for a simple CRC checksum. Or testing logic download authentication by opening up the engineering software, attempting a download, and checking if a password box pops up that allows for configurable users. Which again gives you very little security insights since all of this can be completely useless client-side security.
Take for example the recent CVE-2026-0714 in the IEC 62443-4-2 SL2 certified Moxa UC-1200A series IPCs. These IPCs proudly claim TPM-backed secure boot functionality and while it seems there is at least some PCR integrity measurements before releasing the decryption key from the TPM, this key can be sniffed in plain text from the SPI bus - a well known risk when using discrete TPMs.
In short, the concrete implementation of the evaluation methodology comes down to the individual auditor(s), their expertise, and the willingness of the certifying authority to spend the proper amount of time on the evaluation. If the auditors responsible for certifying a product have never broken a secure boot implementation or found actual zero-day vulnerabilities through fuzzing, standards like IEC 62443 are not going to help them move the needle on device security beyond the bare minimum. Asset owners and device procurers should be aware of this.
While the number of publicly confirmed embedded wiper attacks against OT devices is small, this is a threat with serious potential because of straightforward and increasingly commodity TTPs (observed in-the-wild) which can amplify the impact of an OT attack by an order of magnitude. We strongly recommend defenders prioritize evaluating their resilience against this threat and take at least the following measures to raise the barrier:
Finally, realize that even with all of these measures there will still be some residual bricking attack risk from more advanced and persistent adversaries. Evaluate how realistic this risk is and whether additional compensating controls are required through a proper technical analysis of the most critical OT devices in question. Adjust recovery strategies for a mass-bricking event accordingly.
This course, aimed at asset owners, system integrators, EPC contractors, and OT equipment manufacturers will provide participants with a comprehensive and in-depth understanding of the key concepts and challenge in securing embedded systems - with a special focus on Operational Technology (OT). This training combines fundamentals and theory with real-world case studies and hands-on exercises in order to teach participants about everything from threat modeling tailored to embedded systems and the MITRE EMB3D™ framework to common embedded systems attack vectors and counter-measures.
Special attention is given to an overview of common anti-patterns encountered in embedded OT systems, by providing dozens of detailed breakdowns of vulnerabilities of different types in RTUs, PLCs, DCS controllers, routers, and protocol converters of major vendors across the tech stack ranging from bootloaders all the way to network protocols.
For those interested in advancing their OT device security assessment skills, Midnight Blue provides the training OT Device Security: Hands-on Adversary Tactics for Effective Threat Modeling and Hardening on an in-house basis.
An overview of the course can be found here.
All items
