Evil PLC: the Silent Threat

Over time, the use of PLCs has spread on an industrial scale in a number of different sectors, with the aim of improving processes in plants. As well as undergoing a clear evolution with regard to the capacity, communication and robustness, PLCs have also become a target for different groups of attackers or researchers, as in the case of PLC-Blaster.

As a device that allows control of industrial processes, attacks can lead to a series of complex management situations for plant operators, more used to dealing with other problems such as lack of maintenance of the devices, power outages, etc. On a cybersecurity level, an attack on a PLC can lead to:

• Loss of availability caused by consumption of resources after sending of tranches specifically developed to generate that situation, illicit modification of firmware, etc.
• Modification of behaviour with a direct impact on production. This situation could lead to major impact on safety levels.
• Lateral movement through the network. The compromising of these device could lead the attackers to use the assets communicated with the PLC to infect them or to propagate a virus throughout the network, such as in the case of PLC-Blaster.

In terms of research and, as an alternative to the points commented above, the Claroty group Team 82 have conducted an investigation of the potential threat affecting different PLCs, called Evil PLC. The study was with both PLCs, and engineering software used at stations for programming same in mind. What's more, each manufacturer can use a specific protocol to establish communications between the PLC and the engineering station, and this was also taken into account when analysing the threats.

- Summary of manufacturers, technologies, communications and associated vulnerabilities -

The architectures of PLCs at CPU level are varied, from NXP ColdFire to ARM, MIPS, PowerPC and x86. In terms of the operating systems or firmware, there is also an extensive variety but the operating systems used are generally real time (RTOS) with specific features depending on each supplier. These systems include QNX, uCOS and VxWorks among others. Some more modern PLCs on the market allow for the execution of some versions of Linux Kernel with slight modifications.

How does Evil PLC work?

The threat can take advantage of a PLC in 2 different ways, depending on the vision sought in the preparation or “weaponization” phase as per the taxonomy of the Lockheed Martin Corporation, Cyber Kill Chain (CKC). This phase, within the process of the taxonomy, is based on search, research, identification and selection of objectives. It can also be linked to the recognition thanks to the passive open code analysis techniques of the systems accessible from the internet to detect potential vulnerabilities.

The attack vectors published in the research are:

• Use of a PLC as an access point of an industrial network In this scenario, the operators would access the PLC and download its programming logic in order to modify it maliciously to infect the engineering station. One of the most flexible ways of initiating this action, considering it is usually executed during maintenance or controlled stoppage, consists of modifying some value that has repercussions for the industrial process. The vulnerabilities detected by the researchers in development platforms would allow for the execution of malicious code in a strategy downloading process within an engineering station. This process refers to actions taken with by operators within the engineering stations when they programme PLCs and need to upload the programming logic to change the behaviour of the PLC.

- Visual scheme of the first attack scenario considered. -

• Programming of malicious code through suppliers/integrators. Given that support and maintenance of the PLCs in the industrial world is often handled by external suppliers/integrators, they may use a laptop computer. In this scenario, an attacker could trick the maintenance engineers, compromising their system during the diagnosis process of a compromised machine. After obtaining access to the integrating machine, which by design is capable of accessing many other PLCs, the attackers could extend their control over other organisations.

- Visual scheme of the second attack scenario considered -

Given it is necessary to hold initial access to the PLC to bring about the 2 scenarios commented on above, some tools such as metasearch platforms could be an excellent option, as they allow for searches in assets that are exposed to the Internet, thanks to a series of specific tags or filters. Some tools from this sphere are: Shodan, ZoomEye o Censys.

• Preparation of a PLC like honeypot. Although the first two attack vectors present a show a completely offensive focus, the research shows this third scenario from a defensive perspective, laying traps (honeypot) for the potential attackers.

- Visual scheme of the third scenario considered from a defensive perspective. -

Taking advantage of the fact that the attackers could also use the commercial software present in engineering stations to download the programming strategies of PLCs, it would be possible to use Evil PLC to infect these deliberately.

Like a double-edged sword, the counter-attack executed by Evil PLC would serve a method of dissuasion and for early detection of potential attacks.

Conclusions and best practices

Given that the vulnerabilities published by Team82 in this investigation were reported under a dissemination policy, all manufacturers have a patch to avoid their exploitation.

However, given the complexity of the patch presented by many of these systems, where scheduled or maintenance stoppages can be very limited, there are additional mitigation measures that could be applied to prevent these attacks:

• Network segmentation. One of the main mitigation measures starts with correct segmentation that limits access to the PLC to a small group of persons who execute works on same. This mitigation would reduce exposure to attack and prevent potential attacks.
• Client authentication. The use of authentication validation mechanisms for clients at engineering stations would limitation interaction with the PLCs. This process increases robustness as the engineering station requires a certificate to establish communication with the PLC. Some manufacturers already support TLS to establish communications between engineering stations and the PLC.
• Rollout of PKI infrastructure. One of the most robust solutions for implementing secure communications, but which involves great complexity in the industrial world, is the rollout of Public Key Infrastructure (PKI). Thanks to this infrastructure, it would be possible to encrypt all traffic between the engineering station as client and the PLC as the server.
• Supervision and monitoring of traffic. Given that the Evil PLC attack vector is focused in the loading or downloading of the programming logic related to the PLC, this action is executed through the network, so that continuous monitoring with supervision can allow for the generation of alerts to verify that this load or download is legitimate.
• Constant updating. As further research studies and other technical analyses geared towards discovering vulnerabilities are released, it is essential for industrial companies to update all assets and to have a solid industrial patching procedure in place.