The Evil PLC: using the PLC as an attack vector against the engineer

Claroty has released research detailing a new type of cyber attack that weaponises programmable logic controllers (PLCs) in order to exploit engineering workstations and further invade OT and enterprise networks.

These days, PLCs in industrial networks are becoming critical attack targets, with more exploits being identified every day. Dubbed the Evil PLC Attack, this particular attack targets engineers working on industrial networks, who configure and troubleshoot PLCs across critical industries such as utilities, electricity, water and wastewater, heavy industry, manufacturing and automotive, among others.

The attached report breaks down how the Claroty research team successfully hacked a PLC to achieve code execution on the engineer’s machine. Affected vendors include Rockwell Automation, Schneider Electric, GE, B&R, Xinje, OVARRO and Emerson.

Along with the code logic bytecode, which is the most important piece of information from the PLC’s perspective, when managing PLCs, engineering workstations also transfer auxiliary pieces of information, including:

• Metadata: project and program names, symbols data, dates (compilation, transfer), information about the engineering workstation and more.
• Configurations: hardware/network settings, memory maps and tags, I/O configuration, variable definitions, parameters and more.
• Original text code: source-code the engineer developed (plain-text code or binary serialised representation of the logic).
   

In many cases, PLCs do not process the metadata or the original text code. This type of data is stored on the PLC to support the ability of the engineer to retrieve a working project from the PLC without needing a local copy beforehand.

This architectural design is common practice in the industry and shared across most if not all ICS vendors. It allows engineers to switch between different engineering workstations and quickly perform upload procedures to retrieve the currently running program by getting the actual source code from the PLC.

Claroty decided to look for a different intrusion approach by focusing on the PLC as the tool rather than the target. In this case, the PLC was leveraged in order to access the engineering workstation. Once owned, the engineering workstation would be 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 quickest approach to luring an engineer to connect to an infected PLC would be for the attacker to cause a malfunction or a fault on the PLC. That will compel the engineer to connect using the engineering workstation software as a troubleshooting tool.

An attacker using the Evil PLC attack to gain a network foothold before infecting engineering workstations and accessing the OT network. For a larger image click here.

Claroty found various vulnerabilities in each PLC platform that allowed it to weaponise the PLC in a way that when an upload procedure is performed, specifically crafted auxiliary pieces of data would cause the engineering workstation to execute malicious code.

The Evil PLC Attack weaponises 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, the aim was 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.

Travelling integrators as attack vector

Another use case for this new attack vector becomes clear when examining modern OT management procedures. In many cases, third-party engineers and contractors manage and interact with many different OT networks and PLCs. With that in mind, attackers could use those system integrators as a pivot point, expanding their reach drastically.

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 weaponise 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 weaponise newly accessible PLCs inside other organisations, broadening their control even further.

More information

For a more detailed description of the Evil PLC attack and to download the report, click here.

Top image: ©stock.adobe.com/au/sasun Bughdaryan