Analysis of the PIPEDREAM Malware Local Exploit

May 23, 2022

Analysis of the PIPEDREAM Local Exploit

PIPEDREAM Malware: a Background

Recently, the US government or cybersecurity companies have issued security warnings for industrial control systems and pointed out that PIPEDREAM malware (also known as INCONTROLLER) can enable hackers to take control of multiple ICS/SCADA devices. Once the hacker has established initial access to the OT network, full system access makes it possible to scan, destroy, and control the affected devices, as researchers have confirmed [1]. The primary devices targeted this time include Omron and Schneider controllers, which can attack commonly used industrial communication protocols such as FINS, Modbus and OPC UA.


Components of PIPEDREAM Malware

According to research [1] [2], PIPEDREAM is a malware developed by the hacker organization CHERNOVITE. It has three main modules to perform many MITRE ATT&CK® techniques.

1. TAGRUN: An attack tool developed for detection, it can scan the OPC UA server on the network, read the information of the OPC UA server, and can tamper with the data on the server for better concealment.

2. CODECALL: This tool is mainly used to scan and identify Modbus-enabled control devices on the network. Especially it can use a tool called CODESYS to execute specific commands on Schneider controllers such as: delete files, DDoS attacks, try user login, download/upload files, and so on.

3. OMSHELL: This tool is mainly used to scan and identify Omron’s control devices on the network. This tool can use FINS and HTTP protocol for detection and performs network monitoring on Omron’s control devices or connects to the backdoor on the device and provides arbitrary command execution.


Although CHERNOVITE is explicitly targeting the PLC of Schneider Electric and Omron, it does not rule out may also be able to affect other suppliers. It takes advantage of the flaws in the design of the industrial communication protocol itself. For example, the device or software connection process does not secure two-way authorization and authentication. Hackers forge the client to connect, attack the target device, and achieve the invasion of various industrial control PLCs and industrial software. Since Modbus and OPC UA are widely used in the communication between devices, even the industrial control software development tool CODESYS offers extensive and integrated support for Modbus and OPC UA, so the impact is pervasive and needs special attention. Once successfully attacked by hackers, it may lead to the loss of security and availability of the industrial control system and affect the corporate image, life safety, and community safety risks.


What is an example of Local Exploit? The Analysis of PIPEDREAM Malware

We believe that not only Omron and Schneider customers should pay attention to PIPEDREAM, but all ICS asset owners should pay attention to this attack technique. In fact, we found that PIPEDREAM can attack Windows-based components as well. The following paragraph will explain how to use PIPEDREAM to perform a Local Exploit on Windows-based components in order to allow the industry to respond in advance.

Figure1: the flow of PIPEDREAM local exploit

Figure1: the flow of PIPEDREAM local exploit


According to our research, PIPEDREAM malware probably uses the compromised software supply chain to achieve initial access and get into the ICS environment. For example, we found that PIPEDREAM can use the motherboard manufacturer’s driver vulnerability CVE-2020-15368 to execute its shellcode to load the malicious driver via the motherboard manufacturer’s driver (i.e., AsrDrv103.sys). Based on our study, the attack may not be limited to the specific motherboard-related machines because no obvious hardware checking mechanism was found during the driver loading. Therefore, maybe all machines that can load AsrDrv103.sys are affected. As shown in the figure presented below, the driver’s digital signatures are signed by ASROCK incorporation. We can find the certificate expired in 2017. However, for some old and unpatched systems, it is still acceptable. That may be the reason for the adversaries choosing to use it to pass the Windows driver loading protection and then load the unsigned malicious driver.

Figure 2: The digital signature of the driver expired in 2017 is signed by ASR

Figure 2: The digital signature of the driver expired in 2017 is signed by ASRock


1. Read the malicious driver and load the vulnerable driver (AsrDrv103.sys) into the system

At this stage, the adversaries read the malicious driver that is what they need first. The name of the malicious driver is assigned by the first command-line parameter (i.e., argv[1]). After reading the malicious driver, it exports/drops the vulnerable driver (AsrDrv103.sys) to “C:\AsRockDrv.sys” and tries to load “C:\AsRockDrv.sys” into the Windows system. Due to “C:\AsRockDrv.sys” being a signed driver, it can pass the checking of Windows driver loading protection if the Windows is old or unpatched. And then, the adversaries can attack the loaded vulnerable driver.


2. Exploit AsrDrv103.sys and plant the shellcode into the IOCTL of AsrDrv103.sys

Since AsrDrv103.sys does not properly restrict access to userspace, it may trigger a triple fault via a request to zero CR3[3]. The vulnerability is called CVE-2020-15368. It is worth noting that the vulnerability has a CVSSv3 score of 5.5, which is not a high or critical vulnerability. However, PIPEDREAM can exploit this seemingly harmless vulnerability to execute shellcode and load the required malicious driver. Meanwhile, we also found a similar method on GitHub [4]. The details can be found in Appendix.


3. Restore the IOCTL of AsrDrv103.sys and clean malicious clues

After loading the malicious driver, for anti-tracing/anti-detection, the Malware will restore the IOCTL of AsrDrv103.sys so that the loaded AsrDrv103.sys looks unchanged. In short, AsrDrv103.sys is used as a shield to hide the malicious driver so that the malicious can pass the Windows driver loading protection. A complete cleanup can increase the difficulty of malware detection.


PIPEDREAM ICS Malware Mitigation: 3 Steps for Protection

PIPEDREAM has posed a significant risk to a wide range of OT equipment. Suppose there are multiple types of controllers in the OT environment. In that case, it is recommended that relevant organizations should take immediate defensive actions to confirm that the ICS equipment in the environment has taken appropriate security countermeasures. Mitigating PIPEDREAM will require a comprehensive strategy beyond traditional approaches to defending the ICS environment. TXOne recommends preventive mitigations as follows:


1. Asset inspection

We recommend that asset owners review the inventory and controls of all assets in the OT environment and confirm that assets are free of known vulnerabilities and malware, especially legacy systems. Trend Micro Portable Security™ 3 makes it easier for ICS asset owners and operators to scan for malware and vulnerabilities to collect asset information on stand-alone computers and air-gapped systems. At the same time, it allows users to perform on-demand malware scans without installing antivirus software on the computing device and never have to worry about the performance impact on the scanned computing device. The figure below shows that TMPS3 has supported PIPEDREAM malware detection using the latest updated model.

Figure 3: The TMPS3 successfully detects new malware

Figure 3: The TMPS3 successfully detects new malware


2. Endpoint Protection

We recommend that asset owners install advanced antivirus software on critical computing equipment to continuously monitor industrial control systems’ endpoint behavior and security status against known and unknown malware. The figure presented below shows that the latest version of TXOne’s StellarProtect has successfully blocked the Malware windows-based components.

Figure 4: The StellarProtect can also block the malware with the latest updated pattern
Figure 4: The StellarProtect can also block the malware with the latest updated pattern


3. Network Defense

According to the analysis in the above section, we know that the PIPEDREAM can scan the system on the network and then execute specific commands to run code or manipulate system functions, parameters, and data through the unauthorized method. Thus, the network defense can no longer be ignored. Asset owners can deploy intrusion prevention systems (IPS) to strengthen the east-west security for OT systems. The EdgeIPS™ Pro, EdgeIPS™, and EdgeFire™ can detect and block the malware windows-based components with the latest updated rule sets. Below are the blocking logs



Figure 5: The TXOne’s EdgeIPS series can detect and block the malware with the latest updated rule sets Appendix:

Figure 5: The TXOne’s EdgeIPS series can detect and block the malware with the latest updated rule sets



The details will be revealed with pseudo-C and Assembly languages in the following paragraphs.

At the entry point of the malware, it reads the binary of the vulnerable driver via the command line argument into the buffer.

The vulnerable driver file is dropped as “C:\AsRockDrv.sys” and loaded into the victim’s system.

And then, it creates a file for communicating to the driver, and the vulnerable driver will be linked as \\Device\AsrDrv103.

The IOCTL code 0x22EC00 of AsrDrv103 is used for decrypting commands with a hardcoded AES key and then proxy the embedded IOCTL code and its arguments to the other IOCTL handler functions.

The malware sends a request with IOCTL code 0x22e808 (Read Physical Memory) for scanning physical pages with the hardcoded pattern.

The hardcoded pattern unk_140062370 is corresponding to the IOCTL 0x22E858 handler sub_11f60() in AsrDrv103.

After searching the hardcoded pattern, the malware sends a request with IOCTL code 0x22E80C (Write Physical Memory) to patch the IOCTL 0x22E858 handler of AsrDrv103 with the hardcoded shellcode sub_140061ab0 which length is 0x98 bytes.

The PIPEDREAM malware sends a request with IOCTL code 0x22E858 to trigger the shellcode that is the modified sub_11f60() in AsrDrv103. It will be called at LABEL_78 finally.

The basic shellcode flow is presented below.

The basic shellcode flow.

This shellcode has two parts:

Part1: It allocates the nonpaged pool, copies the Part2 shellcode to the proper location, and then executes the Part2 shellcode.


Part2: It searches ntoskrnl by subtracting nt!KiSystemCall 64 address 0x1000 and checks the PE header format, and then gets exported function address from ntoskrnl.

After getting the required function addresses, it loads the malicious driver.


Finally, restore the original code to sub_11f60() of AsrDrv with unk_140062370, the pattern used to search and locate the physical address.

For reference, the .data section layout in the Malware is shown below.the .data section layout in the Malware



[1] Nathan Brubaker, Keith Lunden, Ken Proska, Muhammad Umair, Daniel Kapellmann Zafra, Corey Hildebrandt, Rob Caldwell, “INCONTROLLER: New State-Sponsored Cyber Attack Tools Target Multiple Industrial Control Systems”, Mandiant, Apr 13 2022, Accessed May 6 2022

[2] Dragos, “CHERNOVITE”, Accessed May 6 2022

[3] National Vulnerability Database, “CVE-2020-15368 Detail”, National Institute of Standards and Technology, July 9 2020, Accessed May 6 2022

[4] Stephen Tong, Matthias, “stong / CVE-2020-15368”, GitHub, Accessed May 6 2022

TXOne image
TXOne Networks

Need assistance?

TXOne’s global teams are here to help!

Find support