Evil PLC Attack weaponizes PLCs to exploit engineering workstations, breach OT and enterprise networks
Researchers at Claroty’s Team82 developed a novel technique called the Evil PLC Attack in which programmable logic controllers (PLCs) are weaponized and used to compromise engineering workstations. An attacker with a foothold on an engineering workstation can have access to anything else on the OT network to which an engineer connects that machine, including other PLCs. The attack targets engineers working on industrial networks, configuring and troubleshooting PLCs to ensure the safety and reliability of processes across critical industries such as utilities, electricity, water and wastewater, heavy industry, manufacturing, and automotive.
“The Evil PLC Attack research resulted in working proof-of-concept exploits against seven automation companies, including Rockwell Automation, Schneider Electric, GE, B&R, Xinje, OVARRO, and Emerson,” according to a whitepaper released by Team82, Claroty research team, titled, ‘Evil PLC Attack: Weaponizing PLCs.’ The paper describes how engineers diagnose PLC issues, write, and transfer bytecode to PLCs for execution, apart from how Team82 conceptualized, developed, and implemented numerous novel techniques to successfully use a PLC to achieve code execution on the engineer’s machine.
“Using our thorough research methods, we were able to find previously unreported vulnerabilities that allowed us to weaponize the affected PLCs and attack engineering workstations whenever an upload procedure occurred,” Claroty researchers wrote in a blog post on Saturday. All of the findings were reported to the seven affected vendors in accordance with Team82’s coordinated disclosure policy. Additionally, most of the affected companies remediated or mitigated the vulnerabilities uncovered by Team82 in their respective products, they added.
Claroty researchers said that the Evil PLC Attack turns the PLCs into the tool rather than the target. “By weaponizing one PLC, an attacker may in turn compromise the engineer’s workstation, which is the best source for process-related information and would have access to all the other PLCs on the network. With this access and information, the attacker can easily alter the logic on any PLC,” they added.
The trick would be to lure an engineer to connect to a compromised PLC; the quickest way is to cause a fault on the PLC, Claroty said. That is a typical scenario an engineer would respond to, and connect using their engineering workstation application as a troubleshooting tool. “This was Team82’s approach as we decided to research this novel attack vector, by finding vulnerabilities in each of the seven engineering workstation platforms that allowed us to weaponize the PLC in a way that when an upload procedure is performed—upload procedures involve the transfer of metadata, configurations, and textcode from the PLC to the engineering workstation—our specifically crafted auxiliary pieces of data would cause the engineering workstation to execute our malicious code,” they added.
Claroty discloses that the technique weaponizes the PLC with data that isn’t necessarily part of a normal static/offline project file, and enables code execution upon an engineering connection/upload procedure. “Through this attack vector, the goal is not the PLC, such as it was, for example, with the notorious Stuxnet malware that stealthily changed PLC logic to cause physical damage. Instead, we want to use the PLC as a pivot point to attack the engineers who program and diagnose it and gain deeper access to the OT network,” the post added.
“It’s important to note that all the vulnerabilities we found were on the engineering workstation software side and not in the PLC firmware,” the researchers wrote. In most cases, the vulnerabilities exist because the software fully trusted data coming from the PLC without performing extensive security checks, they added.
Team82 devices identified three distinct attack scenarios for the Evil PLC Attack. These include weaponizing PLCs to achieve initial access, attacking traveling integrators and weaponizing PLCs as a honeypot.
Claroty researchers determined that attackers could use weaponized PLCs to gain an initial foothold on internal networks, or even for lateral movement. PLCs that are exposed to the internet generally lack security such as authentication and authorization, and are revealed through a Shodan and Censys search. An attacker able to access a PLC in this way is able to modify parameters or their behavior and logic through malicious download procedures.
Opportunistic attackers identify internet-facing PLCs, connect to them using commercial engineering workstation software, and upload the current project, which includes code and settings from the PLC, Claroty said. Then, the attackers will modify the logic of the project, and perform a download procedure to change the PLC logic with their modifications. One example of such an incident was the 2020 attack on Israel’s water supply, where attackers exploited accessible PLCs and attempted to flood the water supply with chlorine, it added.
“Our research suggests that attackers could use the internet-facing PLCs as a pivot point to infiltrate the entire OT network,” the researchers said. “Instead of simply connecting to the exposed PLCs and modifying the logic, attackers could arm these PLCs and deliberately cause a fault that will lure an engineer to them. The engineer, as a method of diagnostics, will perform an upload procedure that will compromise their machine. The attackers now have their foothold on the OT network.”
Claroty also found that attackers could target system integrators and contractors as a means of entry to many different organizations and sites around the world. Modern OT management often involves third-party engineers and contractors interacting with many different networks and PLCs. In this attack scenario, the system integrator is the pivot point between the PLC and engineering workstation that has oversight of numerous OT networks.
The attacker would locate a PLC in a remote, less secure facility that is known to be managed by a system integrator or contractor, the researchers said. The attacker will then weaponize the PLC and deliberately cause a fault on the PLC. By doing so, the victim engineer will be lured to the PLC in order to diagnose it. Through the diagnosis process, the integrator will do an upload procedure and have their machine compromised. After gaining access to the integrator’s machine, which by design is able to access many other PLCs, attackers could in turn attack and even weaponize newly accessible PLCs inside other organizations, broadening their control even further, they added.
Defenders could use honeypot PLCs to attract and attack possible attackers, thus deterring and frustrating would-be attackers, Claroty determined. The attack vector is useful from a defensive perspective where it could be used to trap attackers. Given that attackers often use the same commercial tools as engineers, defenders can purposely set up publicly facing weaponized PLCs, and allow attackers to interact with them. These PLCs will act as a honeypot, attracting attackers to interact with them.
“However, if an attacker falls into the trap and performs an upload from the decoy PLC as part of the enumeration process, the weaponized code will execute on the attacking machine,” according to the researchers. This method can be used to detect attacks in the early stage of enumeration and might also deter attackers from targeting internet-facing PLCs since they will need to secure themselves against the target they planned to attack, they added.
Claroty said that getting to 100 percent patching level, especially in critical infrastructure, is not easy and thus provided additional mitigation measures that help reduce the risk of the Evil PLC Attack. “Weaponizing is the first step and therefore, we recommend limiting physical and network access to PLCs as much as possible. There is no question that such devices shouldn’t be accessible externally or exposed online. But also internal access should be limited to authorized engineers and operators only,” the researchers said.
Claroty recommends network segmentation and hygiene to ensure that the connection to PLCs is limiting access only to a small set of engineering workstations, which reduces the attack surface in the network considerably. It also suggested using client authentication to validate the identity of the client and the engineering station. Currently, some vendors implement such communication protocols, where instead of allowing any engineering workstation to communicate with the PLC, only a specific and predefined set of engineering workstations are able interact with the PLC, by requiring the engineering workstation to present the PLC with a certificate.
With the Evil PLC attack vector performing download/upload procedures to/from a PLC, it is important to monitor OT network traffic and detect these types of events in particular, and if such a procedure would occur in an unexpected situation, it could indicate an exploitation attempt. Furthermore, as attackers and defenders alike research this new attack vector further, more vulnerabilities like the ones shown above will be discovered, and OT vendors will patch those vulnerabilities. It is important to stay up to date with OT software, which will protect from attacks exploiting those one-day vulnerabilities.
A complimentary guide to the who`s who in industrial cybersecurity tech & solutions
Free DownloadRelated
