Attacking a Programmable Logic Controller (PLC) to gain OT Privileged Access

Programmable logic controllers (PLCs) have been under siege by advanced attacks for over a decade. Threat actors, from Stuxnet to the recent Pipedream platform, are constantly trying to infiltrate and manipulate PLCs to disrupt operations, cause physical harm, and jeopardize safety. However, imagine if we could shift the tables and transform the PLC into the predator instead of the prey. What if we could weaponize PLCs to exploit engineering workstations, the very platforms used to configure and manage PLCs? These workstations serve as a crucial link between operational technology networks and corporate networks. By compromising an engineering workstation, an attacker could easily infiltrate the internal network, move laterally between systems, and gain access to other PLCs and critical systems. This attack directly impacts engineers who are dedicated to maintaining the safety and efficiency of industrial processes in sectors like utilities, electricity, water, heavy industry, manufacturing, and automotive. Claroty, an OT cybersecurity firm, has identified vulnerabilities in products from leading system automation companies such as Rockwell Automation, Schneider Electric, GE, OVARRO, and Emerson. While many companies have taken steps to address these vulnerabilities, it is crucial to ensure that all systems are promptly patched to prevent potential exploitation.

OT networks are often equipped with numerous PLCs that oversee industrial operations. In order to disrupt a process, an attacker would need to identify the right PLC to target through an extensive enumeration process. However, with the Evil PLC Attack, the PLCs themselves become the weapon. By compromising just one PLC, an attacker can gain access to the engineer's workstation, which holds valuable process-related information and can control all other PLCs on the network. This allows the attacker to easily manipulate the logic on any PLC. The key is to entice an engineer to connect to the compromised PLC, typically by causing a fault. This scenario is one that engineers are likely to encounter and respond to by using their engineering workstation application for troubleshooting. The attack vector involved identifying vulnerabilities in engineering workstation platforms, enabling the attacker to weaponize the PLC. Through a carefully crafted upload procedure, it is possible to execute malicious code on the engineering workstation, demonstrating the potential risks posed by such attacks.

This innovative technique empowers the PLC by incorporating additional data that may not be included in a typical static or offline project file. It allows for the execution of code during an engineering connection or upload process. Unlike the infamous Stuxnet malware, which discreetly altered PLC logic to cause physical harm, our objective is not to target the PLC itself. Instead, we aim to utilize the PLC as a strategic point of entry to launch attacks on the engineers responsible for programming and diagnosing it, thereby gaining deeper access to the OT network. It is crucial to emphasize that all the vulnerabilities we discovered were on the software side of the engineering workstation, rather than within the PLC firmware. These vulnerabilities primarily exist because the software unquestioningly trusted data received from the PLC, neglecting comprehensive security checks.

?

PLC Attack Scenarios

Scenario 1: Exploiting PLCs for Initial Network Access: Adversaries have the capability to exploit weaponized PLCs to establish an initial presence within internal networks, or even facilitate lateral movement.

PLCs that are connected to the internet often lack essential security measures like authentication and authorization, making them vulnerable to attacks. These exposed PLCs can easily be discovered through a Shodan and Censys search, providing an opportunity for malicious actors. Once an attacker gains access to a PLC, they can manipulate its parameters and behavior by employing malicious download procedures. In a typical scenario, opportunistic attackers identify internet-facing PLCs and connect to them using readily available engineering workstation software. They then upload the current project, which contains the code and settings of the PLC. By modifying the logic of the project, the attackers can effectively change the behavior of the PLC. A notable incident that exemplifies the consequences of such attacks occurred in 2020 when Israel's water supply was targeted. The attackers exploited accessible PLCs in an attempt to contaminate the water supply with chlorine. This incident highlights the potential severity of these attacks. Our research indicates that attackers could exploit internet-facing PLCs as a means to infiltrate the entire OT network. Instead of solely modifying the logic of the exposed PLCs, attackers could strategically manipulate these PLCs to intentionally cause a fault. This would attract the attention of an engineer who would then attempt to diagnose and resolve the issue by performing an upload procedure. Unfortunately, this action would unknowingly compromise the engineer's machine, providing the attackers with a foothold in the OT network. It is crucial to address the security vulnerabilities of internet-facing PLCs to prevent such attacks. Implementing robust authentication and authorization mechanisms, as well as regularly updating and patching the PLCs, can significantly enhance their security. By taking proactive measures, we can safeguard critical infrastructure and protect against potential threats.

?

Scenario 2: Targeting Mobile Integrators: Malicious actors may focus their efforts on system integrators and contractors as a strategic approach to infiltrate numerous organizations and locations globally.

In the realm of modern OT management, it has become common for third-party engineers and contractors to collaborate across various networks and PLCs. However, this interconnectedness also opens up opportunities for potential attacks. Picture this scenario: a system integrator acts as the crucial link between the PLC and the engineering workstation, overseeing multiple OT networks. Now, imagine an attacker identifying a PLC located in a remote facility that is managed by a system integrator or contractor, knowing that it may have weaker security measures. The attacker proceeds to exploit the PLC, intentionally causing a malfunction. This deliberate fault triggers the attention of the victim engineer, who is then enticed to investigate and diagnose the issue with the PLC. During the diagnostic process, the system integrator performs an upload procedure, unknowingly compromising their own machine. Once the attacker gains access to the integrator's machine, which is designed to connect with numerous other PLCs, they can proceed to launch attacks and even weaponize newly accessible PLCs within different organizations. This allows the attacker to expand their control and influence over a wider network.

Scenario 3: Utilizing PLCs as Decoy Systems: Defenders have the option to employ honeypot PLCs to lure and counter potential attackers, effectively dissuading and impeding their malicious activities.

This attack vector offers a valuable defensive strategy by effectively trapping attackers. By leveraging the fact that attackers often utilize the same commercial tools as engineers, defenders can intentionally establish weaponized PLCs that are publicly accessible, enticing attackers to engage with them. These PLCs serve as honeypots, luring attackers into interaction. In the event that an attacker falls into the trap and performs an upload from the decoy PLC during the enumeration process, the weaponized code will execute on the attacker's machine. This approach not only enables the early detection of attacks during enumeration but also acts as a deterrent for attackers targeting internet-facing PLCs. They will now have to consider securing themselves against the very target they intended to exploit.