Menu
Thanks to a spate of high-profile ransomware attacks in recent years, the cyber insecurity of critical infrastructure has lodged in the public consciousness and sparked grave concerns among leaders and operators in critical industries. In most attacks, the ransomware impacted companies’ IT systems or SCADA/HMI systems first — and subsequently impacted OT systems (in some cases, the affected end user shut down OT as a method of isolation and protection).
But the possibility of ransomware loading directly onto embedded devices, and demanding ransom for the resumption of normal operation, has not been considered seriously. Beyond a small number of experts, there is a general assumption that a direct ransomware attack on this layer of the OT system cannot or will not be done.
Our research has determined that this is wishful thinking. A ransom attack on an embedded device is not only possible: Cyber criminals could very well determine that such an attack is worth the investment of significant time and effort, especially since the consequences for end users, and the public they serve, could be extremely serious.
We are not claiming this process is simple. Compared to a PC, embedded devices contain little or no data — the common currency that drives most ransomware attacks — and there are many challenges involved in preventing recovery through the simple reconfiguration of the device, or escalating the attack beyond a single device. However, the findings we will present here are sufficiently convincing to make the case for higher security standards and solutions for embedded devices that support any mission-critical application.
RBS researchers took a novel approach to embedded device ransomware
Traditional ransomware typically operates by encrypting files on a victim’s computer or network. An attack can be compounded if a bad actor is able not only to encrypt data but exfiltrate it, thereby adding weight to the ransom demand with the threat of public revelation of proprietary or sensitive data.
But there is little meaningful data to encrypt on most embedded devices. While these devices contain custom programming for specialized functions, there are three general methods for countering a determined attacker:
But as with more conventional IT-based ransomware attacks, what data that is contained on an embedded device may be valuable intellectual property. Should an attacker threaten to exfiltrate this data and publicly release it, the threat of competitive or reputational damage may prove sufficient incentive for companies to pay the ransom.
However, the most serious threats concern the availability and integrity of mission-critical devices, such as protective relays in electricity grids or safety shut-off valves in oil and gas processing plants. With these devices, threat of disablement can be an extremely effective ransomware tactic. Malware that modifies the device’s behavior can be even more devastating, since bypassing safety-critical protection algorithms can result in extensive physical damage. Even dispatching technicians to the site of the attack could be pointless if the threat emerged with a demand for immediate or rapid payment.
Given how essential many devices are to safety and delivery of critical resources, a successful intrusion could effectively ransom a large segment of critical infrastructure, such as a manufacturing plant or a segment of an electrical grid. In the latter case, the compromise of protective relays can be used to directly impact the delivery of electricity or protection of the electrical equipment. If the device is capable of shutting down power transmission, or its protection algorithms can be disabled, enormous swaths of physical infrastructure, such as wires and transformers, are at risk in the event of an electrical fault. Should an attacker target a manufacturing plant, even reverting to manual operation may not end the threat, since in many cases the embedded devices are still necessary for operation and overall safety.
While it is difficult to estimate the residual damages of an attack of this nature, consider that the outages experienced by the Texas Electric Grid affected almost 70% of the state’s population, and the average outage lasted 42 hours, including 31 hours in a single, continuous outage block.[2] And while it is difficult to determine the totality and scope of damages related to any particular cyberattack, consider that the Colonial Pipeline Company paid $4.4 million to ransomware attackers even before they knew the extent of the intrusion. The company accepted the necessity of shutting down adjacent OT systems in the face the of unmanageable risks to public safety and company infrastructure.[3]
A real-world scenario in which ransomware was loaded and enabled on an embedded device — resulting in payment of the ransom, or a win for the attacker — would follow one of these sequences:
For the purposes of our research, Red Balloon Security does not address the first and final bullets above, since there is existing proof of concept for both the device access and the endgame for a ransomware attack.
The short answer to these questions (unfortunately for end users and anyone who relies on systems controlled by these devices) is: yes and yes.
Accessing a device’s firmware is often as simple as downloading and purchasing it from a vendor’s website. Occasionally, the vendor may restrict access by requiring the buyer to maintain an account, but simply agreeing to the purchase of an authorized product provides the purchaser with account access. In a few cases the firmware will be encrypted, which would require an attacker to extract an unencrypted copy out of the device itself.
Furthermore, most embedded devices contain accessible JTAG/debug ports, and their firmware sometimes may even contain symbols, which make it much easier to understand how a device operates and expedite the vulnerability discovery and exploitation process.
Accessing the device’s firmware through a remote vulnerability can be achieved by leveraging hard-coded “factory login” credentials, hidden services and debugging utilities or through vulnerabilities in communications protocols that can be discovered through fuzzing or static analysis. One study found that in H1 2021, 355 of 637 vulnerabilities on ICS devices allowed remote execution or commands.[5]
While devices are fuzz-tested by many manufacturers, and those devices can even be certified as such, the certifications are of limited value, and they do nothing to address serious vulnerabilities. The problem is that researchers, or hackers, can conduct fuzzing in a great many ways. During Red Balloon Security’s work, deep and robust fuzz testing conducted over a few weeks found not only a crash/denial-of-service vulnerability on a protective relay, but also one that allowed remote code execution in devices that had been previously tested — and certified.
Building a remote exploit requires knowledge and time, but the knowledge is becoming more widespread as the vulnerabilities of embedded devices receive more attention from good and bad actors. Exploitation is made easier by the flat structure of the devices’ firmware, which typically has little memory separation and few levels of privilege.
More challenging is deciding what to ransom, which relies on calculus that considers the device’s purpose; its operation; and what elements of its functionality can be altered so that the device remains interactive, even while the attacker disables it sufficiently to present a need for recovery or alert the end user to the threat of physical damage. An attack at this sophistication level will require an understanding of the application the devices support, and identifying key processes and variables by their names and purposes. It could be a time-consuming process, but time is on the side of a dedicated attacker, especially those with resources.
Ransom demands can be more severe if the attacker is able to compromise more than one device. While it is possible that a supply chain attack or physical intervention could compromise multiple devices, it would be more efficient to spread the ransomware from one device to another. This presents another layer of challenge, but our research confirms its feasibility. Once an attacker controls one embedded device, it is the same as controlling a terminal session on a PC: The device can be scanned, its communications with other devices can be viewed, and ransomware can be pushed out using exploits, just as it would be from a compromised PC.
Attempting to infect multiple devices from the control room level will likely be ineffective, since intrusion protection systems will be running on the network between the control room and the devices. This functionality will prevent a spread such as seen with the PLC Blaster worm, or at least it will help alert operators. In most cases, the intrusion will be detected quickly, and few devices would be compromised in the interval.
However, there is less monitoring of device-to-device communications, due to real-time constraints, excessive complexity and the cost effectiveness of concentrating network monitoring at choke points. Therefore, compromising multiple devices within a substation plant zone could occur outside a user’s monitoring scope.
Spreading from one substation or zone to another adds another layer of complexity, since there may be firewalls limiting the traffic to specific protocols and connections between devices. However, it is possible for infection to spread via a communications protocol, such as IEC61850 or Modbus, which firewalls would let pass through. Contagion would be occurring within a trusted zone, because the network protections are often applied to a zone boundary or a conduit between zones. Once an attacker is inside this perimeter, there is nothing other than the programming login (which can be bypassed by accessing the device through an unauthenticated vulnerability) to stop east/west spread.
Notifying the end user directly from the device is also challenging, since unlike a PC, for example, the majority of embedded devices do not have a screen. Even when they do, these devices are not normally accessed or checked by personnel. The attacker must create a path or means of alerting the troubleshooting staff once the device’s functionality is compromised.
With many devices, a configuration website presents an easily identifiable path, although troubleshooters may not often consult it. The LCD screen, if available, is an attractive option and will be utilized once initial troubleshooting moves to local. A syslog message is likely to end up with the SIEM/SOC team if the end user deploys one to monitor their embedded devices. But an attacker with sufficient command of devices may simply approach a corporate IT team with a direction to inspect their devices, depending on the overall ransom strategy.
Since in most cases there is nothing to really encrypt on the embedded device, there needs to be a way for the ransomware to maintain persistence on the device. The process will entail these steps:
Replacing the entire device, of course, could bypass any of these methods, but if an attacker has managed this level of intrusion, a replacement device could easily be infected in turn. In many cases, it can take considerable time and effort to replace a device, and a sophisticated attacker could infer replacement time and demand payment in a narrower time frame. And if enough devices are affected, replacement quickly can become unfeasible.
It depends, but in many cases, the number could be surprisingly small. The most likely recovery option (assuming that the ransomware is able to prevent firmware update/flash) is to replace a compromised device with a spare. But all an attacker must achieve, particularly in remote or hard-to-access environments is the corruption of one more device than can be replaced in the time frame cited in the ransom demand.
In the case of protection relays, most end users would exhaust their supply of replacements after perhaps 10 devices went down (this assumes the attacker can prevent firmware update/flash). What’s more, the end user would have to identify exactly which devices had been affected, a task made all the more difficult (and time-consuming) if the attacker took a stealthy approach to device infection (this is not incompatible with providing proof of infection). In most instances, the victim may well need to replace the entire fleet of devices to be certain restoration was complete.
Thanks to a spate of high-profile ransomware attacks in recent years, the cyber insecurity of critical infrastructure has lodged in the public consciousness and sparked grave concerns among leaders and operators in critical industries. In most attacks, the ransomware impacted companies’ IT systems or SCADA/HMI systems first — and subsequently impacted OT systems (in some cases, the affected end user shut down OT as a method of isolation and protection).
But the possibility of ransomware loading directly onto embedded devices, and demanding ransom for the resumption of normal operation, has not been considered seriously. Beyond a small number of experts, there is a general assumption that a direct ransomware attack on this layer of the OT system cannot or will not be done.
Our research has determined that this is wishful thinking. A ransom attack on an embedded device is not only possible: Cyber criminals could very well determine that such an attack is worth the investment of significant time and effort, especially since the consequences for end users, and the public they serve, could be extremely serious.
We are not claiming this process is simple. Compared to a PC, embedded devices contain little or no data — the common currency that drives most ransomware attacks — and there are many challenges involved in preventing recovery through the simple reconfiguration of the device, or escalating the attack beyond a single device. However, the findings we will present here are sufficiently convincing to make the case for higher security standards and solutions for embedded devices that support any mission-critical application.
RBS researchers took a novel approach to embedded device ransomware
Traditional ransomware typically operates by encrypting files on a victim’s computer or network. An attack can be compounded if a bad actor is able not only to encrypt data but exfiltrate it, thereby adding weight to the ransom demand with the threat of public revelation of proprietary or sensitive data.
But there is little meaningful data to encrypt on most embedded devices. While these devices contain custom programming for specialized functions, there are three general methods for countering a determined attacker:
But as with more conventional IT-based ransomware attacks, what data that is contained on an embedded device may be valuable intellectual property. Should an attacker threaten to exfiltrate this data and publicly release it, the threat of competitive or reputational damage may prove sufficient incentive for companies to pay the ransom.
However, the most serious threats concern the availability and integrity of mission-critical devices, such as protective relays in electricity grids or safety shut-off valves in oil and gas processing plants. With these devices, threat of disablement can be an extremely effective ransomware tactic. Malware that modifies the device’s behavior can be even more devastating, since bypassing safety-critical protection algorithms can result in extensive physical damage. Even dispatching technicians to the site of the attack could be pointless if the threat emerged with a demand for immediate or rapid payment.
Given how essential many devices are to safety and delivery of critical resources, a successful intrusion could effectively ransom a large segment of critical infrastructure, such as a manufacturing plant or a segment of an electrical grid. In the latter case, the compromise of protective relays can be used to directly impact the delivery of electricity or protection of the electrical equipment. If the device is capable of shutting down power transmission, or its protection algorithms can be disabled, enormous swaths of physical infrastructure, such as wires and transformers, are at risk in the event of an electrical fault. Should an attacker target a manufacturing plant, even reverting to manual operation may not end the threat, since in many cases the embedded devices are still necessary for operation and overall safety.
While it is difficult to estimate the residual damages of an attack of this nature, consider that the outages experienced by the Texas Electric Grid affected almost 70% of the state’s population, and the average outage lasted 42 hours, including 31 hours in a single, continuous outage block.[2] And while it is difficult to determine the totality and scope of damages related to any particular cyberattack, consider that the Colonial Pipeline Company paid $4.4 million to ransomware attackers even before they knew the extent of the intrusion. The company accepted the necessity of shutting down adjacent OT systems in the face the of unmanageable risks to public safety and company infrastructure.[3]
A real-world scenario in which ransomware was loaded and enabled on an embedded device — resulting in payment of the ransom, or a win for the attacker — would follow one of these sequences:
For the purposes of our research, Red Balloon Security does not address the first and final bullets above, since there is existing proof of concept for both the device access and the endgame for a ransomware attack.
The short answer to these questions (unfortunately for end users and anyone who relies on systems controlled by these devices) is: yes and yes.
Accessing a device’s firmware is often as simple as downloading and purchasing it from a vendor’s website. Occasionally, the vendor may restrict access by requiring the buyer to maintain an account, but simply agreeing to the purchase of an authorized product provides the purchaser with account access. In a few cases the firmware will be encrypted, which would require an attacker to extract an unencrypted copy out of the device itself.
Furthermore, most embedded devices contain accessible JTAG/debug ports, and their firmware sometimes may even contain symbols, which make it much easier to understand how a device operates and expedite the vulnerability discovery and exploitation process.
Accessing the device’s firmware through a remote vulnerability can be achieved by leveraging hard-coded “factory login” credentials, hidden services and debugging utilities or through vulnerabilities in communications protocols that can be discovered through fuzzing or static analysis. One study found that in H1 2021, 355 of 637 vulnerabilities on ICS devices allowed remote execution or commands.[5]
While devices are fuzz-tested by many manufacturers, and those devices can even be certified as such, the certifications are of limited value, and they do nothing to address serious vulnerabilities. The problem is that researchers, or hackers, can conduct fuzzing in a great many ways. During Red Balloon Security’s work, deep and robust fuzz testing conducted over a few weeks found not only a crash/denial-of-service vulnerability on a protective relay, but also one that allowed remote code execution in devices that had been previously tested — and certified.
Building a remote exploit requires knowledge and time, but the knowledge is becoming more widespread as the vulnerabilities of embedded devices receive more attention from good and bad actors. Exploitation is made easier by the flat structure of the devices’ firmware, which typically has little memory separation and few levels of privilege.
More challenging is deciding what to ransom, which relies on calculus that considers the device’s purpose; its operation; and what elements of its functionality can be altered so that the device remains interactive, even while the attacker disables it sufficiently to present a need for recovery or alert the end user to the threat of physical damage. An attack at this sophistication level will require an understanding of the application the devices support, and identifying key processes and variables by their names and purposes. It could be a time-consuming process, but time is on the side of a dedicated attacker, especially those with resources.
Ransom demands can be more severe if the attacker is able to compromise more than one device. While it is possible that a supply chain attack or physical intervention could compromise multiple devices, it would be more efficient to spread the ransomware from one device to another. This presents another layer of challenge, but our research confirms its feasibility. Once an attacker controls one embedded device, it is the same as controlling a terminal session on a PC: The device can be scanned, its communications with other devices can be viewed, and ransomware can be pushed out using exploits, just as it would be from a compromised PC.
Attempting to infect multiple devices from the control room level will likely be ineffective, since intrusion protection systems will be running on the network between the control room and the devices. This functionality will prevent a spread such as seen with the PLC Blaster worm, or at least it will help alert operators. In most cases, the intrusion will be detected quickly, and few devices would be compromised in the interval.
However, there is less monitoring of device-to-device communications, due to real-time constraints, excessive complexity and the cost effectiveness of concentrating network monitoring at choke points. Therefore, compromising multiple devices within a substation plant zone could occur outside a user’s monitoring scope.
Spreading from one substation or zone to another adds another layer of complexity, since there may be firewalls limiting the traffic to specific protocols and connections between devices. However, it is possible for infection to spread via a communications protocol, such as IEC61850 or Modbus, which firewalls would let pass through. Contagion would be occurring within a trusted zone, because the network protections are often applied to a zone boundary or a conduit between zones. Once an attacker is inside this perimeter, there is nothing other than the programming login (which can be bypassed by accessing the device through an unauthenticated vulnerability) to stop east/west spread.
Notifying the end user directly from the device is also challenging, since unlike a PC, for example, the majority of embedded devices do not have a screen. Even when they do, these devices are not normally accessed or checked by personnel. The attacker must create a path or means of alerting the troubleshooting staff once the device’s functionality is compromised.
With many devices, a configuration website presents an easily identifiable path, although troubleshooters may not often consult it. The LCD screen, if available, is an attractive option and will be utilized once initial troubleshooting moves to local. A syslog message is likely to end up with the SIEM/SOC team if the end user deploys one to monitor their embedded devices. But an attacker with sufficient command of devices may simply approach a corporate IT team with a direction to inspect their devices, depending on the overall ransom strategy.
Since in most cases there is nothing to really encrypt on the embedded device, there needs to be a way for the ransomware to maintain persistence on the device. The process will entail these steps:
Replacing the entire device, of course, could bypass any of these methods, but if an attacker has managed this level of intrusion, a replacement device could easily be infected in turn. In many cases, it can take considerable time and effort to replace a device, and a sophisticated attacker could infer replacement time and demand payment in a narrower time frame. And if enough devices are affected, replacement quickly can become unfeasible.
It depends, but in many cases, the number could be surprisingly small. The most likely recovery option (assuming that the ransomware is able to prevent firmware update/flash) is to replace a compromised device with a spare. But all an attacker must achieve, particularly in remote or hard-to-access environments is the corruption of one more device than can be replaced in the time frame cited in the ransom demand.
In the case of protection relays, most end users would exhaust their supply of replacements after perhaps 10 devices went down (this assumes the attacker can prevent firmware update/flash). What’s more, the end user would have to identify exactly which devices had been affected, a task made all the more difficult (and time-consuming) if the attacker took a stealthy approach to device infection (this is not incompatible with providing proof of infection). In most instances, the victim may well need to replace the entire fleet of devices to be certain restoration was complete.
Thanks to a spate of high-profile ransomware attacks in recent years, the cyber insecurity of critical infrastructure has lodged in the public consciousness and sparked grave concerns among leaders and operators in critical industries. In most attacks, the ransomware impacted companies’ IT systems or SCADA/HMI systems first — and subsequently impacted OT systems (in some cases, the affected end user shut down OT as a method of isolation and protection).
But the possibility of ransomware loading directly onto embedded devices, and demanding ransom for the resumption of normal operation, has not been considered seriously. Beyond a small number of experts, there is a general assumption that a direct ransomware attack on this layer of the OT system cannot or will not be done.
Our research has determined that this is wishful thinking. A ransom attack on an embedded device is not only possible: Cyber criminals could very well determine that such an attack is worth the investment of significant time and effort, especially since the consequences for end users, and the public they serve, could be extremely serious.
We are not claiming this process is simple. Compared to a PC, embedded devices contain little or no data — the common currency that drives most ransomware attacks — and there are many challenges involved in preventing recovery through the simple reconfiguration of the device, or escalating the attack beyond a single device. However, the findings we will present here are sufficiently convincing to make the case for higher security standards and solutions for embedded devices that support any mission-critical application.
RBS researchers took a novel approach to embedded device ransomware
Traditional ransomware typically operates by encrypting files on a victim’s computer or network. An attack can be compounded if a bad actor is able not only to encrypt data but exfiltrate it, thereby adding weight to the ransom demand with the threat of public revelation of proprietary or sensitive data.
But there is little meaningful data to encrypt on most embedded devices. While these devices contain custom programming for specialized functions, there are three general methods for countering a determined attacker:
But as with more conventional IT-based ransomware attacks, what data that is contained on an embedded device may be valuable intellectual property. Should an attacker threaten to exfiltrate this data and publicly release it, the threat of competitive or reputational damage may prove sufficient incentive for companies to pay the ransom.
However, the most serious threats concern the availability and integrity of mission-critical devices, such as protective relays in electricity grids or safety shut-off valves in oil and gas processing plants. With these devices, threat of disablement can be an extremely effective ransomware tactic. Malware that modifies the device’s behavior can be even more devastating, since bypassing safety-critical protection algorithms can result in extensive physical damage. Even dispatching technicians to the site of the attack could be pointless if the threat emerged with a demand for immediate or rapid payment.
Given how essential many devices are to safety and delivery of critical resources, a successful intrusion could effectively ransom a large segment of critical infrastructure, such as a manufacturing plant or a segment of an electrical grid. In the latter case, the compromise of protective relays can be used to directly impact the delivery of electricity or protection of the electrical equipment. If the device is capable of shutting down power transmission, or its protection algorithms can be disabled, enormous swaths of physical infrastructure, such as wires and transformers, are at risk in the event of an electrical fault. Should an attacker target a manufacturing plant, even reverting to manual operation may not end the threat, since in many cases the embedded devices are still necessary for operation and overall safety.
While it is difficult to estimate the residual damages of an attack of this nature, consider that the outages experienced by the Texas Electric Grid affected almost 70% of the state’s population, and the average outage lasted 42 hours, including 31 hours in a single, continuous outage block.[2] And while it is difficult to determine the totality and scope of damages related to any particular cyberattack, consider that the Colonial Pipeline Company paid $4.4 million to ransomware attackers even before they knew the extent of the intrusion. The company accepted the necessity of shutting down adjacent OT systems in the face the of unmanageable risks to public safety and company infrastructure.[3]
A real-world scenario in which ransomware was loaded and enabled on an embedded device — resulting in payment of the ransom, or a win for the attacker — would follow one of these sequences:
For the purposes of our research, Red Balloon Security does not address the first and final bullets above, since there is existing proof of concept for both the device access and the endgame for a ransomware attack.
The short answer to these questions (unfortunately for end users and anyone who relies on systems controlled by these devices) is: yes and yes.
Accessing a device’s firmware is often as simple as downloading and purchasing it from a vendor’s website. Occasionally, the vendor may restrict access by requiring the buyer to maintain an account, but simply agreeing to the purchase of an authorized product provides the purchaser with account access. In a few cases the firmware will be encrypted, which would require an attacker to extract an unencrypted copy out of the device itself.
Furthermore, most embedded devices contain accessible JTAG/debug ports, and their firmware sometimes may even contain symbols, which make it much easier to understand how a device operates and expedite the vulnerability discovery and exploitation process.
Accessing the device’s firmware through a remote vulnerability can be achieved by leveraging hard-coded “factory login” credentials, hidden services and debugging utilities or through vulnerabilities in communications protocols that can be discovered through fuzzing or static analysis. One study found that in H1 2021, 355 of 637 vulnerabilities on ICS devices allowed remote execution or commands.[5]
While devices are fuzz-tested by many manufacturers, and those devices can even be certified as such, the certifications are of limited value, and they do nothing to address serious vulnerabilities. The problem is that researchers, or hackers, can conduct fuzzing in a great many ways. During Red Balloon Security’s work, deep and robust fuzz testing conducted over a few weeks found not only a crash/denial-of-service vulnerability on a protective relay, but also one that allowed remote code execution in devices that had been previously tested — and certified.
Building a remote exploit requires knowledge and time, but the knowledge is becoming more widespread as the vulnerabilities of embedded devices receive more attention from good and bad actors. Exploitation is made easier by the flat structure of the devices’ firmware, which typically has little memory separation and few levels of privilege.
More challenging is deciding what to ransom, which relies on calculus that considers the device’s purpose; its operation; and what elements of its functionality can be altered so that the device remains interactive, even while the attacker disables it sufficiently to present a need for recovery or alert the end user to the threat of physical damage. An attack at this sophistication level will require an understanding of the application the devices support, and identifying key processes and variables by their names and purposes. It could be a time-consuming process, but time is on the side of a dedicated attacker, especially those with resources.
Ransom demands can be more severe if the attacker is able to compromise more than one device. While it is possible that a supply chain attack or physical intervention could compromise multiple devices, it would be more efficient to spread the ransomware from one device to another. This presents another layer of challenge, but our research confirms its feasibility. Once an attacker controls one embedded device, it is the same as controlling a terminal session on a PC: The device can be scanned, its communications with other devices can be viewed, and ransomware can be pushed out using exploits, just as it would be from a compromised PC.
Attempting to infect multiple devices from the control room level will likely be ineffective, since intrusion protection systems will be running on the network between the control room and the devices. This functionality will prevent a spread such as seen with the PLC Blaster worm, or at least it will help alert operators. In most cases, the intrusion will be detected quickly, and few devices would be compromised in the interval.
However, there is less monitoring of device-to-device communications, due to real-time constraints, excessive complexity and the cost effectiveness of concentrating network monitoring at choke points. Therefore, compromising multiple devices within a substation plant zone could occur outside a user’s monitoring scope.
Spreading from one substation or zone to another adds another layer of complexity, since there may be firewalls limiting the traffic to specific protocols and connections between devices. However, it is possible for infection to spread via a communications protocol, such as IEC61850 or Modbus, which firewalls would let pass through. Contagion would be occurring within a trusted zone, because the network protections are often applied to a zone boundary or a conduit between zones. Once an attacker is inside this perimeter, there is nothing other than the programming login (which can be bypassed by accessing the device through an unauthenticated vulnerability) to stop east/west spread.
Notifying the end user directly from the device is also challenging, since unlike a PC, for example, the majority of embedded devices do not have a screen. Even when they do, these devices are not normally accessed or checked by personnel. The attacker must create a path or means of alerting the troubleshooting staff once the device’s functionality is compromised.
With many devices, a configuration website presents an easily identifiable path, although troubleshooters may not often consult it. The LCD screen, if available, is an attractive option and will be utilized once initial troubleshooting moves to local. A syslog message is likely to end up with the SIEM/SOC team if the end user deploys one to monitor their embedded devices. But an attacker with sufficient command of devices may simply approach a corporate IT team with a direction to inspect their devices, depending on the overall ransom strategy.
Since in most cases there is nothing to really encrypt on the embedded device, there needs to be a way for the ransomware to maintain persistence on the device. The process will entail these steps:
Replacing the entire device, of course, could bypass any of these methods, but if an attacker has managed this level of intrusion, a replacement device could easily be infected in turn. In many cases, it can take considerable time and effort to replace a device, and a sophisticated attacker could infer replacement time and demand payment in a narrower time frame. And if enough devices are affected, replacement quickly can become unfeasible.
It depends, but in many cases, the number could be surprisingly small. The most likely recovery option (assuming that the ransomware is able to prevent firmware update/flash) is to replace a compromised device with a spare. But all an attacker must achieve, particularly in remote or hard-to-access environments is the corruption of one more device than can be replaced in the time frame cited in the ransom demand.
In the case of protection relays, most end users would exhaust their supply of replacements after perhaps 10 devices went down (this assumes the attacker can prevent firmware update/flash). What’s more, the end user would have to identify exactly which devices had been affected, a task made all the more difficult (and time-consuming) if the attacker took a stealthy approach to device infection (this is not incompatible with providing proof of infection). In most instances, the victim may well need to replace the entire fleet of devices to be certain restoration was complete.
It is possible to deploy multiple protection relays to control a transformer or breaker or to protect a device. This could be to cover different protection functions. Often, it provides redundancy, in which case the method of compromise depends on the configuration:
It is possible to deploy multiple protection relays to control a transformer or breaker or to protect a device. This could be to cover different protection functions. Often, it provides redundancy, in which case the method of compromise depends on the configuration:
It is possible to deploy multiple protection relays to control a transformer or breaker or to protect a device. This could be to cover different protection functions. Often, it provides redundancy, in which case the method of compromise depends on the configuration:
Our research process began with the theoretical approach outlined above. Here are the specific steps we took to establish proof of concept:
1. Location of vulnerabilities through fuzzing of the communications protocols. Multiple crashes/DoS and even remotely exploitable, unauthenticated vulnerabilities were found within 24 hours (excluding one-off setup time).
2. Construction of an exploit, utilizing the protocol parsing vulnerability.
3. Steps taken after establishing remote code execution on a protection relay:
a. Changing access passwords (to prevent FW update).
b. Accessing a fully privileged shell with credentials modified in the previous step.
c. Downloading additional material to be used in the ransomware.
d. Locating and modifying the protection function parameters.
e. Disabling protection functions.
f. Modifying the LCD screen.
g. Modifying the website.
4. Implementing a deployment script to speed up and automate deployment.
5. Generalization of exploitation and post-exploitation across different instances of the vulnerable device.
6. Implementing an east/west propagation script to run on the device itself. (This step was scoped and is possible but was not completed to avoid the existence of self-propagating malware).
Note: The ransomware is running inside the existing operating system and FW application, not replacing it, which maintains basic device functionality and ensures the device is not flagged as a “dead” device.
Per industry standard, Red Balloon Security disclosed our findings to the device manufacturer, who issued a remediation report in January 2022. See also: CISA ICS advisory, February 2022.
Red Balloon Security’s research confirms that a ransomware payload can be delivered to an embedded device through a sophisticated but reproducible methodology. When deployed, ransomware can directly impact the operation and safety of OT systems controlled by these devices, which has serious implications for any organization that maintains them.
Furthermore, our research identified several logical and feasible methods of device access that could be used to deploy ransomware: compromised links on the supply chain, migration from IT systems, and hands-on manipulation of a device in the field.
Simply put, the OT systems are so essential to the maintenance of key industrial processes and critical systems, a compromise immediately can have implications for the security posture of key industries.
While recent government actions have raised awareness and stimulated action for addressing the threat of ransomware in OT systems, protection of embedded devices are not included in the action steps.
The fact that these devices are typically not data-rich targets contributes to this oversight, but a more serious issue is that manufacturers, end users and researchers have not sufficiently considered the possibility that dedicated attackers with sufficient industry knowledge could, in fact, engineer an attack that compromises devices under conditions that leave the end user with a non-choice between payment and severe consequences for their equipment, reputations or even public safety. We hope our research will lead to more serious consideration of these potential scenarios, and more extensive prevention.
However, solutions that attempt to create more layers of security around these devices will take protection only so far. Security at the device level, which does not impede operation of the device or the system it supports, is a critical next step in securing many elements of industry and public infrastructure. Red Balloon Security’s solutions for runtime protection and device monitoring are geared to providing more real-time defense of some of industry’s most crucial, and potentially vulnerable devices.
Our research process began with the theoretical approach outlined above. Here are the specific steps we took to establish proof of concept:
1. Location of vulnerabilities through fuzzing of the communications protocols. Multiple crashes/DoS and even remotely exploitable, unauthenticated vulnerabilities were found within 24 hours (excluding one-off setup time).
2. Construction of an exploit, utilizing the protocol parsing vulnerability.
3. Steps taken after establishing remote code execution on a protection relay:
a. Changing access passwords (to prevent FW update).
b. Accessing a fully privileged shell with credentials modified in the previous step.
c. Downloading additional material to be used in the ransomware.
d. Locating and modifying the protection function parameters.
e. Disabling protection functions.
f. Modifying the LCD screen.
g. Modifying the website.
4. Implementing a deployment script to speed up and automate deployment.
5. Generalization of exploitation and post-exploitation across different instances of the vulnerable device.
6. Implementing an east/west propagation script to run on the device itself. (This step was scoped and is possible but was not completed to avoid the existence of self-propagating malware).
Note: The ransomware is running inside the existing operating system and FW application, not replacing it, which maintains basic device functionality and ensures the device is not flagged as a “dead” device.
Per industry standard, Red Balloon Security disclosed our findings to the device manufacturer, who issued a remediation report in January 2022. See also: CISA ICS advisory, February 2022.
Red Balloon Security’s research confirms that a ransomware payload can be delivered to an embedded device through a sophisticated but reproducible methodology. When deployed, ransomware can directly impact the operation and safety of OT systems controlled by these devices, which has serious implications for any organization that maintains them.
Furthermore, our research identified several logical and feasible methods of device access that could be used to deploy ransomware: compromised links on the supply chain, migration from IT systems, and hands-on manipulation of a device in the field.
Simply put, the OT systems are so essential to the maintenance of key industrial processes and critical systems, a compromise immediately can have implications for the security posture of key industries.
While recent government actions have raised awareness and stimulated action for addressing the threat of ransomware in OT systems, protection of embedded devices are not included in the action steps.
The fact that these devices are typically not data-rich targets contributes to this oversight, but a more serious issue is that manufacturers, end users and researchers have not sufficiently considered the possibility that dedicated attackers with sufficient industry knowledge could, in fact, engineer an attack that compromises devices under conditions that leave the end user with a non-choice between payment and severe consequences for their equipment, reputations or even public safety. We hope our research will lead to more serious consideration of these potential scenarios, and more extensive prevention.
However, solutions that attempt to create more layers of security around these devices will take protection only so far. Security at the device level, which does not impede operation of the device or the system it supports, is a critical next step in securing many elements of industry and public infrastructure. Red Balloon Security’s solutions for runtime protection and device monitoring are geared to providing more real-time defense of some of industry’s most crucial, and potentially vulnerable devices.
Our research process began with the theoretical approach outlined above. Here are the specific steps we took to establish proof of concept:
1. Location of vulnerabilities through fuzzing of the communications protocols. Multiple crashes/DoS and even remotely exploitable, unauthenticated vulnerabilities were found within 24 hours (excluding one-off setup time).
2. Construction of an exploit, utilizing the protocol parsing vulnerability.
3. Steps taken after establishing remote code execution on a protection relay:
a. Changing access passwords (to prevent FW update).
b. Accessing a fully privileged shell with credentials modified in the previous step.
c. Downloading additional material to be used in the ransomware.
d. Locating and modifying the protection function parameters.
e. Disabling protection functions.
f. Modifying the LCD screen.
g. Modifying the website.
4. Implementing a deployment script to speed up and automate deployment.
5. Generalization of exploitation and post-exploitation across different instances of the vulnerable device.
6. Implementing an east/west propagation script to run on the device itself. (This step was scoped and is possible but was not completed to avoid the existence of self-propagating malware).
Note: The ransomware is running inside the existing operating system and FW application, not replacing it, which maintains basic device functionality and ensures the device is not flagged as a “dead” device.
Per industry standard, Red Balloon Security disclosed our findings to the device manufacturer, who issued a remediation report in January 2022. See also: CISA ICS advisory, February 2022.
Red Balloon Security’s research confirms that a ransomware payload can be delivered to an embedded device through a sophisticated but reproducible methodology. When deployed, ransomware can directly impact the operation and safety of OT systems controlled by these devices, which has serious implications for any organization that maintains them.
Furthermore, our research identified several logical and feasible methods of device access that could be used to deploy ransomware: compromised links on the supply chain, migration from IT systems, and hands-on manipulation of a device in the field.
Simply put, the OT systems are so essential to the maintenance of key industrial processes and critical systems, a compromise immediately can have implications for the security posture of key industries.
While recent government actions have raised awareness and stimulated action for addressing the threat of ransomware in OT systems, protection of embedded devices are not included in the action steps.
The fact that these devices are typically not data-rich targets contributes to this oversight, but a more serious issue is that manufacturers, end users and researchers have not sufficiently considered the possibility that dedicated attackers with sufficient industry knowledge could, in fact, engineer an attack that compromises devices under conditions that leave the end user with a non-choice between payment and severe consequences for their equipment, reputations or even public safety. We hope our research will lead to more serious consideration of these potential scenarios, and more extensive prevention.
However, solutions that attempt to create more layers of security around these devices will take protection only so far. Security at the device level, which does not impede operation of the device or the system it supports, is a critical next step in securing many elements of industry and public infrastructure. Red Balloon Security’s solutions for runtime protection and device monitoring are geared to providing more real-time defense of some of industry’s most crucial, and potentially vulnerable devices.
[1] This option is often unfeasible due to the lack of replacement devices. Replacement transformers in the electricity grid, to cite just one, prominent example, are in chronically short supply.
[2] “The Winter Storm of 2021,” Hobby School of Public Affairs, University of Houston.
[3] Wall Street Journal, “Colonial Pipeline CEO Tells Why He Paid Hackers a $4.4 Million Ransom, May 19, 2021.
[4] Red Balloon Security did not create fully fledged ransomware with self-propagating capabilities for the purposes of this research, for two reasons: 1) it was not necessary to create ransomware to prove that ransomware can be loaded to an embedded device and 2) for ethical reasons, we are disinclined to produce functional ransomware, especially when there are no valid reasons for the exercise.
[5] Claroty Biannual ICS Risk and Vulnerability Report, H1 2021.
[1] This option is often unfeasible due to the lack of replacement devices. Replacement transformers in the electricity grid, to cite just one, prominent example, are in chronically short supply.
[2] “The Winter Storm of 2021,” Hobby School of Public Affairs, University of Houston.
[3] Wall Street Journal, “Colonial Pipeline CEO Tells Why He Paid Hackers a $4.4 Million Ransom, May 19, 2021.
[4] Red Balloon Security did not create fully fledged ransomware with self-propagating capabilities for the purposes of this research, for two reasons: 1) it was not necessary to create ransomware to prove that ransomware can be loaded to an embedded device and 2) for ethical reasons, we are disinclined to produce functional ransomware, especially when there are no valid reasons for the exercise.
[5] Claroty Biannual ICS Risk and Vulnerability Report, H1 2021.
[1] This option is often unfeasible due to the lack of replacement devices. Replacement transformers in the electricity grid, to cite just one, prominent example, are in chronically short supply.
[2] “The Winter Storm of 2021,” Hobby School of Public Affairs, University of Houston.
[3] Wall Street Journal, “Colonial Pipeline CEO Tells Why He Paid Hackers a $4.4 Million Ransom, May 19, 2021.
[4] Red Balloon Security did not create fully fledged ransomware with self-propagating capabilities for the purposes of this research, for two reasons: 1) it was not necessary to create ransomware to prove that ransomware can be loaded to an embedded device and 2) for ethical reasons, we are disinclined to produce functional ransomware, especially when there are no valid reasons for the exercise.
[5] Claroty Biannual ICS Risk and Vulnerability Report, H1 2021.
Sal Stolfo was an original founding member of Red Balloon Security, Inc.
© 2022 Red Balloon Security.
All Rights Reserved.
Contact us now to discover more about Red Balloon Security’s range of solutions and services or to arrange a demonstration.
Reach out to learn more about our embedded security offering and to schedule a demo.
Reach out to learn more about our embedded security offering and to schedule a demo.
Reach out to learn more about our embedded security offering and to schedule a demo.
Reach out to learn more about our embedded security offering and to schedule a demo.
