Team82 is publishing details of our research into Unitronics' integrated PLCs/HMIs, which began on the heels of numerous critical infrastructure attacks that were disclosed last fall, in particular at water treatment facilities in the United States and Israel.
Iran-linked CyberAv3ngers is alleged to be responsible for the attacks.
We have developed two tools that we are making freely available today. These tools can be used to extract forensics information from Unitronics integrated HMIs/PLCs.
The first tool, PCOM2TCP, allows users to convert serial PCOM messages into TCP PCOM messages and vice versa. PCOM is Unitronics’ proprietary communication protocol.
The second, called PCOMClient, enables users to connect to their Unitronics Vision/Samba series PLC, query it, and extract forensics information from the PLC.
This blog describes our research setup, the process by which we unpacked the proprietary PCOM protocol, and the necessities that drove us to develop both tools to extract information from the devices.
As part of this research we uncovered two new vulnerabilities CVE-2024-38434, CVE-2024-38435. Unitronics recommends all users to upgrade to v9.9.1
Attacks last November against Unitronics’ integrated HMIs/PLCs demonstrated that APT actors such as the Iran-linked CyberAv3ngers remain intent on causing panic and fear around the cybersecurity of critical infrastructure, and have a desire to spread propaganda for political gain.
The attacks targeted devices operating in water treatment facilities in Israel and the United States, and demonstrated the group’s access to these Israel-made HMI/PLCs. While water treatment and quality was not impacted, the group did deface the Unitronics devices, leaving behind a message threatening other similar technology made in Israel.
CyberAv3ngers leveraged the fact that the Unitronics Vision and Samba series of products had no PCOM password protection at the time. The attackers could connect to, and control the devices remotely using the Unitronics VisiLogic engineering workstation software to download a malicious project to the PLC, defacing it.
With attacks affecting hundreds of devices around the world, we decided to research and develop a tool that allows users to extract forensic information from their Unitronics Vision/Samba HMI/PLCs. Information extracted from our tool, one of two that we are making freely available today on our GitHub page, could be used to identify attackers accessing these devices, in addition to extracting critical information from the device to help preserve forensic information during attacks.
Development of our tools required us to research and understand the proprietary PCOM communication protocol used by the Vision/Samba HMI/PLCs. The only existing documentation of the PCOM protocol was created by a set of researchers looking at Unitronics devices (A Comprehensive Security Analysis of a SCADA Protocol: from OSINT to Mitigation, Luis Rosa et al., 2019).
The first tool we developed, called PCOM2TCP, enables users to convert serial PCOM messages into TCP PCOM messages and vice versa. The second tool, called PCOMClient, enables users to connect to their Unitronics Vision/Samba series PLC, query it, and extract forensic information from the PLC.
The first step toward understanding the PCOM protocol and what artifacts could be extracted from a Unitronics device was buying one. Having a physical device allowed us to connect and communicate with it. So we bought a device, shipped it to our offices, and waited patiently to start our research. However, when it finally arrived, we discovered that we messed up: our device did not have an Ethernet port. By default, Unitronics Vision series devices do not ship with Ethernet connectivity, only with serial connections; an Ethernet card is sold separately. This meant we had no way to connect to our device.
To solve this problem, we had to read Unitronics documentation to understand the pinout of the RJ11 connector. In order to allow the PLC to communicate using serial, Unitronics implemented a serial port using an RJ11 connector, and RS232 as the communication standard. Our goal was to create a custom cable, connecting the Vision PLC and our laptop (using the DB9 connector on our laptop). From Unitronics documentation, we discovered that the RJ11 port has the following layout:
With this pinout in mind, our goal was to take an RJ11 cable and modify it to have a DB9 (male) connection on the other end, allowing us to connect to the PLC using the RJ11 side, and to our laptop using DB9 connection. Once again, we looked online for documentation on the DB9 pinout, which looks like this:
After observing the two pinouts, all we had to do is connect the RX pin to the TX and vice versa, as well as connect the ground cable, which looked like this:
By creating this custom cable, we were able to create a fully functional setup, connecting the Unitronics V570 to our lab laptop.
With that, we were able to connect to our PLC using Unitronics’ VisiLogic engineering workstation (EWS). We downloaded the EWS from the Unitronics site, installed it, and connected it to our PLC.
Next, our goal was to create a man-in-the-middle (MiTM) setup between the PLC and our EWS. This meant we could wiretap all traffic between these two endpoints, as well as modify any packets we chose. However, because we used our custom cable and not an Ethernet extension card, our EWS and PLC communicated over serial connection. Usually this is no problem because Wireshark offers the ability to sniff serial communication. However in this particular case, this was not possible, because the EWS opened the serial port in an exclusive mode on Windows, meaning no other process can open this port. Because of that, Wireshark wasn’t able to connect and sniff this port. This led us to develop our first tool PCOM2TCP to bypass this restriction.
The PCOM communication protocol allows the Visilogic EWS to connect to the PLC using one of two connection methods: serial or Ethernet. To do so, Unitronics implemented the PCOM protocol in either serial or TCP version (using TCP/20256). In both cases, the base PCOM layer exists, the only difference is that in TCP connection, the base PCOM packet is encapsulated with the PCOM/TCP layer.
This gave us an idea: if we could not create a MiTM setup using a serial connection, maybe we could create a Python tool that would convert PCOM serial messages to PCOM/TCP packets. That way, our EWS would connect to our Python script using TCP/IP, instead of serial, and we would convert the packets to serial PCOM and send it to the PLC. Then, we could sniff and monitor the traffic using Wireshark (searching for the TCP/IP TCP stream), and modify certain packets in our Python script.
This was a huge milestone for our research, because it allowed us to finally start debugging and trying to parse PCOM traffic.
At its core, the PCOM protocol is composed of requests sent by the EWS, and responses sent by the PLC. In order to differentiate between different commands/procedures, PCOM implements a wide set of function codes (opcodes), each with its own capabilities and parameters. That way, using different opcodes, the EWS can invoke different requests and procedures in the PLC.
In addition to different function codes (opcodes), Unitronics implemented two different protocols as part of the PCOM protocol: PCOM ASCII and PCOM Binary. These two protocols implement different opcodes, meaning that in order to fully understand the PCOM protocol, one will have to research both implementations. Let’s analyze each one:
First, let’s look at a PCOM Binary request/response. In this protocol, each packet must start with a magic/hard-coded byte sequence which is the string /_OPLC , followed by an ID, a few reserved parameters, and the opcode itself. The full structure of the Binary PCOM message can be seen here:
In order to check if a certain message is a request or a response, one would have to check the most-significant-bit (MSB) of the opcode; if it is 0 then the message is a request, and if it’s 1 then the message is a response.
When looking at PCOM ASCII message format, we see the following structure:
Unlike PCOM Binary, which in order to see if a message is a request or a response you had to check the command opcode (in this case - Command Code), in PCOM ASCII, a request and response have different magics. In case of a request, the magic / will be used, and if the message is a response the magic /a will be used.
After understanding the basics of the PCOM protocol, we moved on to build a basic PCOM client, researching and uncovering unknown opcodes in the process.
The next step in our research was implementing a fully-fledged PCOM client, allowing us to build on top of it any function codes/processes we choose. This gave us the ability to test different opcodes, debug the application, and try to understand undocumented opcodes.
Our client allows users to connect to their Unitronics PLC, extract its exact version, name and type, as well as read/write its raw memory. In addition to all the basic functionality, we added an interface for adding newly discovered opcodes.
Behind the scenes, to communicate with the PLC, Unitronics implemented dozens of different function codes, each invoking different functionalities within the PLC. For example, in order to request the PLC to replay its name, one would need to send a PCOM Binary request using the 0x0C function code. Some opcodes were already researched and documented by researchers that previously took a look at the Unitronics PCOM protocol (A Comprehensive Security Analysis of a SCADA Protocol: from OSINT to Mitigation, Luis Rosa et al., 2019).
To build our client, we had to research and understand the different function codes implemented by Unitronics. This process was done using mainly reverse-engineering, as well as protocol analysis from the Wireshark packets we managed to capture.
Another interesting opcode is 0x42, which allows users to reset the Upload Password mechanism. From Unitronics’ user manual, we discovered that operators can set up a password to protect their project. Operators can use this password to lock projects and deny others from reading them. We discovered this opcode can be used in a certain way to reset the Upload Password, and reported this issue to Unitronics, which was assigned as CVE-2024-38434. This is one of two vulnerabilities uncovered during our research and disclosed to the vendor.
Here is a list of known function codes in the PCOM protocol (important note: the descriptions we chose to give each opcode is simply our interpretation of the opcode):
Function Code (request / response) | Description |
0x01 / 0x81 | Read Memory |
0x02 / 0x82 | Check Password |
0x0C / 0x8C | Get PLC Name |
0x10 / 0x90 | Find Resource |
0x16 / 0x96 | Translate Resource Index to Address* |
0x1A / 0x9A | Flush Memory Buffer |
0x41 / 0xC1 | Write Memory |
0x42 / 0xC2 | Reset Upload Password (CVE-2024-38434) |
0x4D / 0xCD | Read Operand |
0xFF | Error |
ID (ASCII) | Get PLC ID |
UG (ASCII) | Get PLC UnitID |
GF (ASCII) | Get PLC Version |
After having a fairly good understanding of the Unitronics VIsion series ecosystem, as well as the PCOM communication protocol, we came back to our original goal: enabling forensic evidence extraction from an attacked PLC. After some more digging, we discovered two methods that allow forensic evidence extraction, which we believe could be used to better understand the attack, as well as contain sensitive information about the device, and the operations conducted on the device.
The first source of evidence we discovered was the VisiLogic Project file. Whenever an engineer uses VisiLogic (Unitronics EWS) to connect to the Vision PLC, they start by building a project. Then, using this project, the engineer can set up the PLC, its operation, functions, as well as its HMI screen. Using this project, the engineer can fully control the Vision PLC.
Behind the scenes, to save all of these configurations, as well as functions code, the EWS stores all of this data inside a zip file, containing an Access DB database (in the PLC’s memory, this file is stored in an encrypted format using hardcoded password). By parsing this database (using our Access DB python parser), and searching for specific fields in specific tables, it is possible to extract a lot of interesting data and forensic information regarding the user’s computer and setup, including the full path the project was created in (usually contains the computer’s username), the keyboard layout of the attacker (was used in the past to identify attackers, i.e used by Mandiant to identify APT-1), full log of all the connection made to the PLC and much more.
While the project file contains reams of forensic information, the file itself is not always stored on the PLC. In the Unitronics ecosystem, when downloading a project onto a PLC, one can choose whether to “burn” the project file. In the Unitronics ecosystem, “project burn” is a setting during the download procedure, which dictates whether the project file will be downloaded to the PLC and be available for upload later on. Essentially, if a project is downloaded to the PLC without burning it, users will not be able to perform an upload procedure and retrieve the project from the PLC later on. This mechanism was created to allow engineers to “protect” their project, and prevent people with access to the PLC itself from simply uploading it and getting access to the project.
Another protection mechanism Unitronics implemented to allow engineers to protect their project is the ability to set up an “upload password,” locking the ability to perform an upload procedure only to those who know the password that was set up. While we did manage to find a bypass to this password (bypassing the password requirement and allowing us to upload the project without knowing the password), if the project is not burned, there will be nothing to read from the PLC. All of this was added to our custom PCOM client.
In the case of the Unitronics attack, the attackers did not burn the project when performing the download procedure. This meant we could not obtain the attacker’s project, however our tool was still able to gain access to the old project that was downloaded to the PLC (before the attackers overwrote it), only if it was burned.
After reaching a dead end with the project file, we moved on to search for forensic evidence on the PLC memory itself. This was when we discovered an artifact stored on the PLC called Signature Log. This log contains a list of all the interactions that users performed with the PLC.
The extraction of this log is a long and tedious process, however we did manage to implement it into our PCOMClient. Using our client, anyone can extract the signature log from their PLC.
Inside the signature log, we can find a lot of super interesting forensic information, including exact dates of connections made to a PLC, the full path of the project that was downloaded to it, the username of the computer that connected to it, as well as information about the computer including its operating system, keyboard layout, etc.
Here is a list of most of the forensic evidence that could be extracted from a Unitronics Vision series PLC:
Forensic Evidence | Is Inside Signature Table | Is Inside Project File |
Project Path | Yes | Yes |
PC Username | Yes | No (could be in path) |
Project Creation Date | No | Yes |
PLC Connection Dates | Yes | Yes |
Computer Keyboards | Yes | Yes |
PLC Connection String | Yes | Yes |
Project Images | No | Yes |
Project Functions | No | Yes |
Team82’s extensive research into Unitronics’ integrated HMIs/PLCs began after the disclosure of attacks against numerous water treatment facilities and other critical infrastructure late last year. A group linked to Iran leveraged weak authentication on these devices in order to access and deface them.
While no impact to water quality was detected, the attacks did serve the group’s intent to spread chaos and fear about the cybersecurity of critical infrastructure in these areas.
This spurred us to look closer at these incidents and the Unitronics control systems in question. Attacks directly targeting industrial control systems remain relatively rare, therefore when there is an issue such as this one, our team wants to understand why and provide solutions that bring forth a safer ecosystem.
As we looked at the proprietary PCOM protocol developed by Unitronics for communications between devices and networks, it became clear that we had to develop our own tools to not only understand the inner workings of the protocol, but also help extract forensic information in the event of future attacks.
Today we made both our tools freely available. PCOM2TCP, enables users to convert serial PCOM messages into TCP PCOM messages and vice versa. The second tool, called PCOMClient, enables users to connect to their Unitronics Vision/Samba series PLC, query it, and extract forensic information from the PLC.
The information you can extract provides invaluable clues as to the attackers’ behavior on the device, including connection dates, keyboard layout, filesystem paths, and much more. We urge users to download each one and understand their analytical and forensic capabilities.
