Evil PLC Attack: Using a Controller as Predator Rather than Prey

Executive Summary 

• Team82 has developed a novel attack that weaponizes programmable logic controllers (PLCs) in order to exploit engineering workstations and further invade OT and enterprise networks. We’re calling this the Evil PLC Attack. Download the full report here (free PDF).

• The attack targets engineers working every day 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, among others.

• The Evil PLC Attack research resulted in working proof-of-concept exploits against seven market-leading automation companies, including Rockwell Automation, Schneider Electric, GE, B&R, XINJE, OVARRO, and Emerson.

• This paper will describe, in depth, not only how engineers diagnose PLC issues, write, and transfer bytecode to PLCs for execution, but also how Team82 conceptualized, developed, and implemented numerous novel techniques to successfully use a PLC to achieve code execution on the engineer’s machine.

• The full report includes a list of affected vendors and products, as well as links to their respective advisories and remediations (or mitigations).

Table of Contents

1. PLC Industrial Controller Attack Scenarios

2. Attack Scenarios

3. Research and Methodology

4. PLC Industrial Controller Attack Findings

5. Steps to Mitigate Industrial Controller PLC Attacks

Programmable logic controllers (PLCs) have for more than a decade been the focus of advanced attacks. From Stuxnet to the recently uncovered Incontroller/Pipedream platform, threat actors try to reach and control PLCs in order to modify the processes they oversee, cause disruption, physical damage, and threaten personal safety. 

But what if an attacker was able to flip that scenario on its head and turn the PLC into the predator rather than the prey? What if there was a way to weaponize PLCs in order to exploit engineering workstations, the powerful platforms used to configure and maintain PLCs? These workstation applications are often a bridge between operational technology networks and corporate networks. An attacker who is able to compromise and exploit vulnerabilities in an engineering workstation could easily move onto the internal network, move laterally between systems, and gain further access to other PLCs and sensitive systems. 

Team82 today has released a research paper that describes just such a novel attack, which it has named the Evil PLC Attack.

The attack targets engineers working every day 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, among others. 

The Evil PLC Attack research resulted in working proof-of-concept exploits against seven market-leading automation companies: Rockwell Automation, Schneider Electric, GE, B&R, XINJE, OVARRO, and Emerson. Most of the affected companies remediated or mitigated the vulnerabilities uncovered by Team82 in their respective products, as you can see in the table below. 

The research paper is freely available here: “Evil PLC Attack: Weaponizing PLCs.”

Evil PLC Attack Explained

OT networks may have dozens of PLCs overseeing industrial processes; an attacker wishing to physically disrupt a process would need to first perform an extensive enumeration of those controllers in order to find the right one to target. 

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. 

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. 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.

This 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.

It’s important to note that all the vulnerabilities we found were on the engineering workstation software side and not in the PLC firmware. In most cases, the vulnerabilities exist because the software fully trusted data coming from the PLC without performing extensive security checks.

PLC Industrial Controller Attack Scenarios

Team82 devices three distinct attack scenarios for the Evil PLC Attack. 

• Weaponizing PLCs to Achieve Initial Access: Attackers could use weaponized PLCs in order to gain an initial foothold on internal networks, or even for lateral movement.

• Attacking Traveling Integrators: Attackers could target system integrators and contractors as a means of entry to many different organizations and sites around the world.

• Weaponizing PLCs as a Honeypot: Defenders could use honeypot PLCs to attract and attack possible attackers, thus deterring and frustrating would-be attackers.

Weaponizing the PLC to Achieve Initial Access

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. 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.

Our research suggests that attackers could use the internet-facing PLCs as a pivot point to infiltrate the entire OT network. 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.

Attacking Traveling Integrators

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 attack would look like this: An attacker would locate a PLC in a remote, less secure facility that is known to be managed by a system integrator or contractor. 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.

Weaponizing PLCs as a Honeypot

This 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. 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.

Research and Methodology

We decided to focus on the following seven targets:

• OVARRO: TBox platform

• B&R (by ABB Group): X20 System platform

• Schneider Electric: Modicon platform (mainly M340, M580)

• General Electric (GE): Mark VIe platform

• Rockwell Automation: Micro800 Control Systems platform

• Emerson: PACSystems platform

• XINJE: XD Series platform

For each target/platform we tried to understand the whole download/upload mechanism by reverse engineering the firmware and the engineering workstation software. Our goal was to find discrepancies between what the PLC is using and what engineering workstation is using. If we were to find such inconsistencies, we could weaponize the PLC through a malicious download procedure to store a specifically crafted piece of data that won’t affect the PLC, but when parsed by the engineering platform it will trigger and exploit a vulnerability.

The research process of our Evil PLC Attack is as follows:

1. Setup: Setting up a testbed environment with a target PLC, compatible engineering workstation, and I/O field devices.

2. Building “Hello World:” Reading PLC manuals, watching instructional videos, and building a benign program to control simple processes.

3. Project File: Explore what is being stored in a project file (metadata, configurations, textcode) and how the data is serialized.

4. Reverse Engineering: Exploring the PLC hardware and firmware in addition to the engineering workstation software.

5. Upload/Download Procedures: Understand the mechanics of the upload/download procedures, and what data is transferred through the proprietary protocol.

6. Protocol Analysis: Analyze the proprietary protocol and its functionality, and build a fully featured client.

7. Find Discrepancies: Understand the differences between what information is transferred and stored in the PLC, without being parsed or used.

8. Hunt for Vulnerabilities: Research all the parsing code flows of all pieces of information that the engineering workstation transfers to the PLC that are not used/modified on the PLC.

9. Weaponize: Using the client, implement a malicious download procedure that stores specifically crafted data on the PLC.

10. Exploit: Engineer connects to the PLC and performs an upload procedure. The engineering workstation parses the specifically crafted data we implemented. The parsing flow triggers the vulnerability and executes our code.

For each target vendor platform, the full ecosystem that we needed to research consist of:

• The engineering workstation software

• Engineering workstation project file

• Proprietary protocol (PLC ←→ Engineering workstation)

• PLC firmware

• Logic code (bytecode, textcode)

PLC Industrial Controller Attack Findings

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. All of the findings were reported to the seven affected vendors in accordance with Team82’s coordinated disclosure policy.

5 Steps to Mitigate Industrial Controller PLC Attacks

All of the vulnerabilities described in this paper were reported to the affected vendors in accordance with Team82’s Coordinated Disclosure policy. Most vendors issued fixes, patches, or mitigation plans against the Evil PLC Attack. 

That said, getting to 100% patching level, especially in critical infrastructure, is not easy and therefore requires additional mitigation steps to reduce the risk of the Evil PLC Attack. Here are a few we recommend:

In the Evil PLC attack technique, 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 process of securing the connection to your PLCs is long, tedious, and when implemented incorrectly even ineffective, so we recommend implementing the following:

1. Network Segmentation and Hygiene: The first step in securing the connection to your PLCs is limiting access by strictly segmenting your network. Allow access to your PLCs only to a small set of engineering workstations, which reduces the attack surface in your network considerably.

2. Use Client Authentication: It is crucial to configure the PLC to use a client authentication mechanism to validate the identity of the client, 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. 

3. Even Better, PKI: A more robust solution is to use a full Public Key Infrastructure (PKI) system to validate and encrypt all traffic between the client, engineering workstation, and the server, the PLC. Mutual authentication, more commonly referred to as mutual TLS, helps to significantly reduce the risk of someone hacking your OT assets. However, the reality is that PKI is not yet implemented in many ICS product lines. 

4. Network Traffic Monitoring: The Evil PLC attack vector involves performing download/upload procedures to/from a PLC. As such, it is important to monitor your 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.

5. Stay Up To Date: 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 your OT software, which will protect you from attacks exploiting those one-day vulnerabilities.