Embedded System Ransomware and the Meaning of Criminal Operations

On 11 January 2023, the “Ghost Security Group” (commonly referred to as “GhostSec”) issued a bold claim (captured on Twitter, among other places) that they “encrypted the first RTU in history.” The claim rapidly came under scrutiny from several directions – for an excellent analysis of this specific case and claim, check out SynSaber’s blog on the subject. Yet the claim of “industrial ransomware” is hardly new – researchers have claimed (without providing specific details) that industrial-specific ransomware is possible in previous reporting, while others have speculated (including myself) on whether criminal entities will move from more traditional IT-centric ransomware to OT-focused efforts for years – including a horrible publicity stunt where an organization (now apparently defunct) “invented” ICS-focused ransomware in 2017.

The consensus opinion for years with respect to “industrial ransomware” is that such items would remain limited to IT-focused ransomware or variants thereof impacting IT-like systems in industrial environments. For example, a Windows-focused ransomware strain targeting Windows-based systems such as data historians, human machine interfaces (HMIs), or engineering workstations inducing a disruptive event. To date, this is what we have observed in the threat landscape, with various IT-focused strains, occasionally with industrial-specific “tweaks,” deployed for monetization purposes. Examples include, but are not limited to:

• EKANS ransomware.
• Variants of MegaCortex.
• Incidents tied to then-common families such as Ryuk and the Darkside ransomware service.

Thus “industrial ransomware” becomes IT strains operating in OT environments, absent direct interaction with lower-level embedded systems such as RTUs and programmable logic controllers (PLCs). While the specific details of GhostSec’s most recent claims merit some degree of suspicion, the idea of process-centric, low-level ransomware may seem appealing – but this demands further scrutiny as well.

First, we must consider: What is the point of ransomware? Multiple definitions exist from government agencies to several information security vendors, but all coalesce around the same general idea: 

Ransomware is malicious software designed to inhibit or prevent proper use of or access to systems or data to prompt the victim to pay the adversary to restore such access.

The central point of ransomware, therefore, is inducing the victim to pay. The technical complexity or sophistication of operations are irrelevant, so long as the victim submits payment to restore access to their systems. As a result, ransomware has largely remained fairly simplistic and straightforward, focused mostly on evading security tools and execution prevention. Instead, ransomware entities invested in a distributed system of specialization ranging from ransomware platform providers to initial access brokers to entities responsible for negotiating with and providing “customer support” for victims, all to ensure victim payment.

For ransomware providers, if a capability does not materially improve the victim’s willingness to pay (or the amount they will pay), it therefore would seem somewhat superfluous. We can observe this with the primitive “industrial” nature of existing ransomware examples such as MegaCortex, EKANS, and similar items. These families initially separated themselves from other strains through the inclusion of “process kill lists” that expanded beyond typical targets (security software) to embrace a variety of functional operations within the victim environment. Examples ranged from IT capabilities such as mail servers and associated processes to more industrial items such as product licensing servers, data historians, and similar applications. The purpose for doing so wasn’t to cause outright disruption, but rather to remove application locks on files such as licenses, mail, or databases to allow for their encryption – thus amplifying the “pain” of the ransomware event.

Given the nature of most industrial applications and systems, it is debatable whether ransomware executing on an HMI or similar system would even be that impactful as all operationally-vital systems would possess locks on critical files through their continuing function. Only by removing these locks – by killing the owning process – can ransomware operators extend encryption to these vital systems. However in this case, ransomware operators now take on the risk of causing not just IT disruption but potential process instability and disruption through the indiscriminate termination of processes in an industrial environment. The implications behind this are potentially severe as we now extend ransomware effects to physical outcomes, and all that goes with such activity.

Now, let us return to GhostSec’s RTU “ransomware.” Looking at provided screenshots, it seems to have worked as files have the actor’s suffix appended indicating encryption:

As noted in the previously-linked SynSaber writeup, the device in question is not a typical RTU, in that it is not running a custom embedded operating system, but instead a device running a flavor of Linux. This is reflected in the filesystem structure and various other items, but also it is worth pointing out something – one of the files (in yellow, while directories are in blue for the image) is pointedly not encrypted: busybox.

Busybox is a suite of applications providing UNIX-like functionality in smaller or less robust environments, such as embedded systems. As such, it is likely to be in use whenever the system itself is functioning – and in this specific case, it appears that GhostSec was unable to encrypt the Busybox binary potentially for this reason. While other items, such as shell scripts (*.sh) are impacted, in-use, running applications avoided their fate – meaning we should question the efficacy and extent of file encryption operations for this capability.

In order to extend encryption in a way that would be meaningful or substantially painful, the adversary would need to forcibly stop running processes to remove application locks – an action already accomplished in existing ransomware samples, but one that could lead to significant consequences, especially when performed at the level of an RTU. Moreover, we have not even considered the research and technical capability required to impact most actual RTUs and PLCs, running custom embedded operating systems, as opposed to this specific example which is, for all purposes, just a small Linux device. In any event, short of taking actions to compromise device functionality at a fundamental level, industrial-specific ransomware seems to be a pipedream.

Notably, researchers from Red Balloon have already (conceptually) “gone there” with an undated article on embedded system ransomware. This article identifies some of the challenges discussed above, but then takes a running leap over caution and convention by advocating for a rather extreme step: disabling or otherwise modifying industrial devices as part of the “ransom” activity. While such actions have taken place previously, such as the Serial-to-Ethernet converter “bricking” in the 2015 Ukraine event or the attempted denial of service attack on Siemens Siprotec protective relays in the 2016 Ukraine incident, these have all come in the context of deliberate, disruptive/destructive attacks with no desire, intention, or even capability for extracting payment from victims.

Essentially, Red Balloon (and some others) may have “found a way” to hold industrial asset owners at risk in such a fashion that might cause someone to pay a ransom, but in doing so the activities in question move from “mere” criminality to outright attacks or acts of terrorism. Basically, the proposition for “ransomware” in industrial environments becomes, “pay us or else we kill the PLCs.” That this might work is not questioned – that criminal actors would take such a drastic step towards physical process disruption and all that entails (from property damage to potentially even loss of life) seems beyond reason and experience. 

Criminal ransomware operators might not be the most caring persons in the room – but they do have a conception of self-preservation, and when their desire to continue operations clashes with impacts that may elicit a forceful response from governments and law enforcement. For example, there are multiple instances where ransomware entities, after impacting targets such as hospitals or schools or similar, have voluntarily provided decryption keys to avoid both significant negative attention as well as potential consequences for such actions. These acts are hardly universal, but given that they exist, it seems doubtful that such entities would take steps similar to those taken by state-directed entities engaging in cyberwarfare for the sake of some cryptocurrency.

Thus, irrespective of the technical merits of GhostSec’s RTU “ransomware,” the requirements and implications of “true” industrial ransomware at the RTU or PLC level make this a very unlikely domain for criminals to operate in. The payoffs appear too meager to justify both the technical investment and political risk associated with such an action, as outlined above. Instead, it simply makes greater sense economically for such entities to remain in the same space that they’ve resided in for some time: impacting IT and IT-like systems to elicit payment from organizations while attempting to avoid “worst case” societal impacts that bring greater attention from governments and law enforcement.

However, capabilities along the lines of what GhostSec attempted and Red Balloon described may certainly emerge. But rather than representing an emerging trend in criminal activity, such actions are instead likely to represent something more insidious: state-directed actor use of ransomware-like operations as a figleaf for disruptive cyberattacks. Such masquerading as ransomware has already taken place several times, to varying degrees of effect, impact, and misdirection. Yet the case outlined here of manipulating or disabling industrial equipment as part of a “ransomware” scenario as described by Red Balloon may be an interesting way to provide cover for cyber-physical operations where the initiating entity desires to obfuscate involvement and attribution.

To conclude, ransomware impacting industrial operations and environments is very much a “real thing” as documented by multiple parties. The scope and nature of such operations, though, will almost certainly be limited to what has been observed to date: operations targeting IT and IT-based systems, with inadvertent (and at times quite limited) industrial impacts. Scenarios outlined by GhostSec and Red Balloon will likely remain an area for proof of concepts and flashy presentations at hacker cons. Yet should such embedded device ransomware emerge in industrial environments (especially critical infrastructure networks), we should immediately question the nature and origin of such activity, as the economics and optics of such an event will favor a state-directed entity being responsible as opposed to more traditional criminal monetization.